Мониторинг и отказоустойчивость

Инфраструктура, которую не видно, ломается молча: о проблеме узнают от пользователей, а не от системы. Наблюдаемость переворачивает это — метрики, логи и трейсы показывают состояние в реальном времени, а алерты предупреждают до того, как упадёт прод. Цель не «собрать все графики», а видеть то, что влияет на пользователя, и получать сигнал тогда, когда действительно нужно вмешаться.

Метрики — Prometheus с экспортёрами для узлов, баз, nginx, очередей и приложений; визуализация и дашборды — Grafana. Логи — Loki или ELK/OpenSearch с централизацией, структурированием и поиском по инцидентам. Распределённый трейсинг (OpenTelemetry, Tempo, Jaeger) показывает, где в цепочке сервисов теряется время. Всё это сводится в дашборды по золотым сигналам: латентность, трафик, ошибки, насыщение.

Алертинг строю по SLO, а не по каждому чиху: пороги на то, что бьёт по пользователю, группировка и подавление шума через Alertmanager, эскалация в Telegram, Slack, PagerDuty. Дежурный получает не сто уведомлений, а один осмысленный сигнал с контекстом. К каждому важному алерту — runbook: что проверить и что сделать, чтобы реакция не зависела от того, кто именно на смене.

Отказоустойчивость — это устранение единых точек отказа: репликация БД и автоматический failover, резервирование сервисов, health-checks и корректные ретраи, план восстановления с проверяемыми бэкапами. Перед релизом — нагрузочное тестирование (k6, JMeter, Locust): где предел системы, как она деградирует и что тюнить. Параллельно разбираю стоимость инфраструктуры — переразмеренные ресурсы и неэффективные конфигурации часто дают экономию без потери надёжности.