❌🙅‍♀️🙅‍♂️ Что системному аналитику НЕ нужно уметь в работе с логированием и мониторингом, а что нужно? 🔎

Нужно ли аналитику самостоятельно устанавливать OpenTelemetry Collector, разворачивать Prometheus и администрировать Elasticsearch?

Нет. Это задача DevOps и/или разработчиков.

Но и требования «логировать запросы и ошибки» или «добавить мониторинг» тоже не результат работы аналитика.



🟢 Задача СА определить:

▫️ какие данные должна формировать система
▫️ как связать события одного сценария
▫️ какие показатели измерять
▫️ как обнаруживать отклонения
▫️ что должны увидеть разработчики, поддержка и бизнес при возникновении проблемы



👉 Что системному аналитику обычно НЕ нужно уметь?

❌ Самостоятельно разворачивать и администрировать весь observability-стек

❌ Настраивать кластеры Prometheus, Elasticsearch, OpenSearch, Loki или Tempo

❌ Устанавливать и конфигурировать агенты, exporters и collectors

❌ Владеть сложными запросами на PromQL, LogQL, TraceQL или KQL

❌ Самостоятельно проектировать инфраструктуру хранения телеметрии и рассчитывать её ресурсы

❌ Настраивать маршрутизацию уведомлений в Alertmanager и других системах на уровне DevOps

❌ Самостоятельно реализовывать весь набор дашбордов и диагностировать ошибки в коде вместо разработчиков

❌ Знать интерфейс каждого инструмента на уровне администратора



💡 При этом «не нужно администрировать» не означает «не нужно открывать инструменты».

Аналитику полезно уметь зайти в Grafana, Kibana, Jaeger или OpenShift Console, выбрать нужный период, применить фильтры и найти информацию по конкретной операции.



👉 Что системному аналитику действительно нужно уметь?

✅ Отличать метрики, логи и трассировки.

✅ Понимать назначение инструментов сбора, хранения и анализа телеметрии, которые используются в вашем проекте

✅ Использовать инструменты проекта для поиска и фильтрации логов, метрик и трассировок: выбрать период, сервис и среду, найти данные по конкретной операции.

✅ Проверить путь запроса между компонентами и определить, на каком шаге возникла ошибка или задержка.

✅ Определить обязательные события и поля структурированных логов, чтобы решать 2 предыдущие задачи с ошибками прода без боли.

✅ Описать технические и бизнес-метрики.

✅ Указать точки начала и завершения измеряемых интервалов.

✅ Задать условия алертов: порог, период наблюдения, severity, получателя и ожидаемое действие.

✅ Определить сроки хранения логов, метрик и трассировок.

✅ Предусмотреть маскирование персональных данных, токенов, паролей и других секретов в логах.

✅ Уметь проверить передачу контекста трассировки через HTTP, брокеры сообщений и фоновые задачи.

✅ Определить, какие дашборды и фильтры нужны поддержке, разработчикам и бизнесу.



📌 Недостаточно написать:
«Логировать процесс формирования отчёта»

Нужно определить:

▫️ события:
+ задача зарегистрирована
+ сообщение опубликовано
+ обработка начата
+ файл создан
+ операция завершена успешно или ошибкой

▫️ обязательные поля логов:
+ время
+ сервис
+ среда
+ operationId, requestId, traceId, messageId
+ номер попытки
+ результат
+ HTTP-код для событий HTTP

▫️ технические метрики:
+ время ожидания в очереди
+ длительность обработки
+ полное время операции
+ доля ошибок
+ возраст незавершённых задач

▫️ алерты:
+ если более 5% операций завершаются ошибкой в течение 10 минут, то отправить уведомление ответственной команде с уровнем High



👉 Что фиксировать в постановке задачи?

В разделе «Логирование, мониторинг и аудит» для задачи определить:

☑️ перечень событий, которые должны записываться
☑️ структуру записей и обязательные поля
☑️ правила создания и передачи идентификаторов
☑️ перечень метрик и правила их расчёта
☑️ точки начала и завершения измеряемых интервалов
☑️ требования к распределённой трассировке
☑️ условия срабатывания алертов
☑️ каналы уведомлений и ответственных
☑️ сроки хранения и правила доступа к данным
☑️ требования к маскированию чувствительной информации
☑️ состав дашбордов, графиков и фильтров.


Сохраняйте как чек-лист для ваших постановок задач 🤝

#АрхитектураGA #ИнтеграцииGA


📱 Tg | 💙 ВК | 💬 Max