Когда метрики лгут: как SRE-гиганты вроде Meta и Azure выживают после сбоев и создают неуязвимый мониторинг

Уроки постмортемов: как избежать ошибок в мониторинге и построить надежные системы

Примеры из реальных инцидентов и выводы для SRE-практики

1. Метрики должны быть честными, а не «красивыми»

Манипуляции с метриками создают иллюзию надежности, но маскируют реальные проблемы.

Пример 1: В 2021 году Facebook (Meta) пережил глобальный сбой продолжительностью 6 часов. Системы мониторинга не учли каскадный отказ DNS-серверов, так как метрики фокусировались на «зеленых» статусах сервисов, а не на доступности сетевой инфраструктуры. В результате команды потратили часы на поиск корневой причины.

Пример 2: В 2019 году Slack столкнулся с массовыми перебоями из-за ошибок авторизации. SLO рассчитывался только на основе HTTP 500, но пользователи получали ошибки 401 из-за сбоя в OAuth-провайдере. Метрики показывали «всё в порядке», пока клиенты не начали жаловаться.

Что делать:

Включайте в SLO все типы ошибок, влияющие на пользователей (4xx, 5xx, таймауты).
Используйте перцентили задержки (например, 99-й), а не средние значения.

2. Дашборды — не для красоты, а для действий

Дашборд полезен, только если он помогает быстро принимать решения.

Пример 1: В 2020 году Microsoft Azure столкнулся с сбоем балансировщика нагрузки. Инженеры не заметили проблему, так как дашборд отображал «успешные» health-чеки, но не показывал рост числа переподключений клиентов. Расследование заняло 3 часа.

Пример 2: В 2018 году GitLab потерял данные из-за некорректной репликации БД. Дашборды не отображали статус резервных копий, а алерты срабатывали только при полном отказе диска.

Что делать:

Добавляйте на дашборды метрики, которые напрямую влияют на пользователей (например, время ответа API, частота ошибок).
Используйте цветовую сигнализацию (красный/желтый/зеленый) для ключевых показателей.

3. Комплексный мониторинг: метрики + логи + трейсы

Без связки данных из разных источников диагностика инцидентов замедляется.

Пример 1: В 2017 году AWS S3 ушел в простой из-за ошибочной команды в консоли. Метрики показали рост ошибок, но без трейсов и логов команда не смогла быстро определить, что проблема возникла в системе управления разрешениями.

Пример 2: В 2022 году банк Revolut столкнулся с замедлением платежей. Логи выявили, что 30% запросов к внешнему провайдеру занимали >5 секунд, но эти данные не были интегрированы в SLO.

Что делать:

Связывайте логи, метрики и трейсы через trace_id (как в системах вроде Jaeger).
Настройте алерты на аномалии: например, если 95-й перцентиль задержки вырос на 50% за 10 минут.

4. Избегайте «перегруза»: меньше метрик, больше смысла

Избыток данных мешает увидеть критически важные сигналы.

Пример 1: В 2016 году Twitter пережил массовые отказы из-за DDoS-атаки. Система мониторинга генерировала 200+ алертов в минуту, что парализовало работу инженеров.

Пример 2: В 2021 году Salesforce сократил количество метрик на 60%, сосредоточившись на ключевых SLO (например, время отклика CRM). Это помогло снизить время реакции на инциденты в 2 раза.

Что делать:

Применяйте методологию RED (Rate, Errors, Duration) для сервисов.
Группируйте метрики с высокой кардинальностью (например, агрегируйте ошибки по типу, а не по ID пользователя).

5. Постмортемы — ваш лучший учитель

Анализ прошлых ошибок помогает предотвратить будущие.

Пример 1: В 2016 году GitHub потерял доступ к репозиториям на 24 часа из-за ошибки в конфигурации сети. Постмортем выявил, что алерты на аномальный трафик отсутствовали, а дашборды не включали метрики сетевых интерфейсов.

Пример 2: В 2018 году NASA потеряло связь с марсоходом Opportunity из-за перегруженного планировщика задач. Расследование показало, что мониторинг не отслеживал загрузку CPU в реальном времени.

Что делать:

Проводите регулярные chaos-тесты (например, отключайте случайные сервисы).
Документируйте решения прямо в дашбордах (например, добавляйте комментарии к проблемным нодам в Grafana).

Итоги

Честные метрики спасают репутацию. Не давайте ложного чувства безопасности.
Дашборды должны вести к действиям. Если графики не помогают принять решение — пересмотрите их.
Контекст — основа диагностики. Связывайте данные из метрик, логов и трейсов.
Учитесь на чужих ошибках. Каждый инцидент — урок, который стоит превратить в улучшение.

Как показывает опыт крупных компаний: мониторинг — это не сбор данных, а инструмент для предотвращения катастроф.