Вы ведь уже задумывались о заработке в Telegram…

Сохраняли посты.
Читали советы.
Откладывали «на потом».

И вроде бы интерес есть…
но до действий так и не доходит.

Мозг выбирает самое простое — ничего не делать 👉 https://t.me/addlist/BHoA9CZmCi5lM2Yy

Чтобы разорвать этот круг, не нужно сразу «делать идеально».
Достаточно просто дать себе понятную точку входа.

Мы собрали папку, где уже есть база:
— как расти в Telegram
— как привлекать людей
— как выстраивать систему
— как приходить к доходу

Подпишись и просто начни с малого
https://t.me/addlist/BHoA9CZmCi5lM2Yy

Иногда самое сложное — это первый шаг.

Записывайся в подборку🫶

☀Объяснение:

ETL-процессы часто прерываются: сетевой сбой, таймаут, рестарт кластера. Если загрузка не спроектирована идемпотентно, после перезапуска могут появиться дубликаты.

Решение – использовать MERGE (в PostgreSQL) или INSERT ... ON CONFLICT DO UPDATE (в SQLite, PostgreSQL), или REPLACE (MySQL). Уникальный составной ключ (например, order_id + line_id) гарантирует, что повторная вставка не создаст дубль, а обновит существующую строку или проигнорирует её.

Пример кода:
sql

INSERT INTO dwh_orders (order_id, amount, loaded_at)
VALUES (123, 1000, NOW())
ON CONFLICT (order_id) DO UPDATE SET
  amount = EXCLUDED.amount,
  loaded_at = EXCLUDED.loaded_at;

Почему это важно для аналитика?
В требованиях к интеграции данных нужно явно указывать: «Загрузка должна быть идемпотентной. Повторный запуск того же пакета не должен порождать дубликатов». Без этого после каждого сбоя оператору придётся вручную чистить таблицу.
Реальный кейс: В крупном ретейлере из-за отсутствия идемпотентности при ночном сбое накопилось 15% дублей заказов. Отчётность встала на неделю.

☀Объяснение:

Функциональные требования описывают что система делает (например, «пользователь может посмотреть баланс»). Нефункциональные требования (NFR) описывают как система это делает (быстро, безопасно, надёжно).
«Открываться за 2 секунды» — это атрибут качества производительности. Это требование не меняет логику работы, а лишь накладывает ограничение на скорость.

Почему это важно?
NFR часто забывают или фиксируют в конце, а потом система работает медленно. Аналитик должен собирать такие требования наравне с функциональными.

Реальный кейс: В одном проекте забыли записать требование к производительности для поиска, и на проде поиск работал 30 секунд. Исправление стоило перепроектирования индексов и кэшей.

☀Объяснение:

По умолчанию Kafka сбрасывает данные на диск не сразу, а через интервал (чтобы повысить производительность). При внезапном отключении питания данные, ещё находящиеся в кэше ОС, теряются. Настройка flush.messages=1 заставляет Kafka сбрасывать каждое сообщение на диск перед тем, как подтвердить продюсеру. Недостаток: падает производительность записи.

Альтернатива: использовать репликацию с acks=all и min.insync.replicas=2, но при падении всех брокеров данные могут потеряться, если не сброшены на диск.

Реальный пример: В системе финансового мониторинга настроили персистентность Kafka, и даже при аварийном отключении не потеряли ни одного события.

Что должен зафиксировать аналитик:
Требование к durability (гарантия сохранности) — допускается ли потеря сообщений?
Для критичных логов — обязательная синхронная запись на диск.

☀Объяснение:

Аналитик проверял функциональность и корректность данных, но упустил, что отчёты могут печататься или экспортироваться в PDF. Печатные формы часто имеют отдельные CSS-стили, которые могут ломаться в разных браузерах.

Что нужно добавить в чек-лист:
Открыть отчёт в Chrome и Firefox, сравнить внешний вид.
Распечатать на PDF (Ctrl+P) и проверить, что все колонки на месте, нет разрывов.
Проверить альбомную/портретную ориентацию.

Реальный кейс: В бухгалтерской системе отлично работал интерфейс, но при печати счета колонки смещались, и клиенты не могли разобрать суммы. Аналитик добавил в чек-лист пункт «печатная форма», и проблема больше не возникала.

Вывод: Аналитик должен включать в приёмочные тесты не только GUI и API, но и вторичные сценарии (печать, экспорт, мобильная вёрстка).

☀Объяснение:

В BPMN промежуточное событие-таймер, прикреплённое к границе активности (например, к задаче «Согласование руководителем»), запускает альтернативный поток, если таймер истёк, а активность ещё не завершена. Это классический паттерн «тайм-аут». После срабатывания таймера заявка отправляется вышестоящему руководителю, а первоначальная задача может быть прервана или оставлена (в зависимости от настройки).

Почему это важно:
Автоматическая эскалация при задержках — частое требование в бизнес-процессах (закупки, согласования, инциденты). Аналитик должен уметь моделировать временные ограничения.

Реальный кейс: В системе согласования командировок при отсутствии ответа руководителя в течение 2 дней заявка автоматически считалась согласованной. Таймер помог избежать простоев.

☀Объяснение:

Диаграмма компонентов (Component Diagram) показывает компоненты (в микросервисной архитектуре — сервисы), их интерфейсы (предоставляемые и требуемые), а также зависимости между ними (пунктирные стрелки). Это идеальный инструмент для архитектурного обзора на уровне «чёрных ящиков».

Почему не другие диаграммы:
Диаграмма последовательности слишком детальна (показывает обмен сообщениями во времени).
Диаграмма классов не отражает архитектуру на уровне сервисов.
Диаграмма деятельности — для процессов, а не для структуры.

Реальный пример: В проекте с 50 микросервисами архитектор нарисовал диаграмму компонентов и сразу увидел циклические зависимости, которые пришлось разорвать.

Вывод: Аналитик может использовать диаграмму компонентов для документирования архитектуры и анализа связанности сервисов.

☀Объяснение:

Graceful degradation (изящная деградация) — способность системы сохранять основной функционал при отказе неключевых компонентов. В данном случае:

При недоступности платежного сервиса заказ создаётся со статусом «Ожидает оплаты».
Клиент получает уведомление: «Заказ оформлен, ссылка на оплату придёт позже».
Запрос на оплату сохраняется в очередь и будет обработан при восстановлении.

Чем отличается от Circuit Breaker?
Circuit Breaker отключает проблемный сервис, но не предлагает fallback-действие, а просто возвращает ошибку. Здесь же бизнес-процесс не прерывается.

Реальный пример: В Ozon при временной недоступности оплаты заказ всё равно принимается, а клиенту приходит смс с кнопкой оплатить позже.

Что должен зафиксировать аналитик:
Альтернативные сценарии при недоступности внешних систем.
Сохранение состояния и уведомление пользователя.
Механизм повторной обработки.