Observability и SRE — от графиков к инженерным решениям

Проблема

Набор технических алертов и дашбордов сам по себе не обеспечивает предсказуемую диагностику, долгую историю метрик и системную работу с надёжностью.

Архитектура

В ЮНИКОРН спроектировал мониторинг и перенёс долгосрочное хранение метрик с Prometheus (около трёх недель retention) на кластер VictoriaMetrics (до шести месяцев). Заменил тяжёлый ELK-контур на Loki + Fluentd. Перешёл от нативных Jaeger-клиентов к OpenTelemetry SDK/Collector, оставив Jaeger backend и UI. В Jet Games построил observability для 50+ хостов на Prometheus/VictoriaMetrics, Grafana, Alertmanager, Loki, Blackbox, Uptime-Kuma и OpenSearch; отдельно мониторил Kafka Connect и Airflow (StatsD → Prometheus).

SRE-практики

Ввёл SLO для backend API, аналитической платформы и Airflow DAG на основе availability, latency и error rate, настроил алертинг по SLO. Error budget оценивался приблизительно и использовался для приоритизации: при нарушении ожиданий по надёжности часть задач откладывали, усиливали проверки, пропускали в релизы только критичные изменения. Ввёл недельную ротацию on-call среди DevOps, incident response, postmortem, release manager, календарь релизов, rollback-планы и нагрузочные проверки перед выкаткой.

Результат

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

Компромиссы и оговорки

Error budget оценивался приблизительно и использовался для приоритизации, а не считался автоматически; алерты настроены по SLO, автоматической остановки деплоев не было. Снижение числа аварий и шума не измерялось.

Технологии

• Prometheus
• VictoriaMetrics
• Grafana
• OpenTelemetry
• Loki
• Fluentd
• Jaeger
• Alertmanager
• OpenSearch
• SLO