12 дашбордов для дежурных, которые успокаивают всех

Практичный план действий для специалистов по реагированию на инциденты, позволяющий превратить хаос в ясность.

Создайте 12 дашбордов для дежурств, которые сокращают среднее время восстановления и панику, охватывая SLO, золотые сигналы, зависимости, развертывания, очереди, затраты и влияние на пользователей с помощью реальных запросов.

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

Как эти дашборды сочетаются друг с другом

Подумайте о пирамиде: начните с результатов для пользователей (SLO), затем перейдите к состоянию сервиса (золотые сигналы), затем углубитесь в зависимости, развёртывания и затраты. Обеспечьте повторяемость каждой панели для разных сервисов и сред.

[Users/SLO]
   └─> [Golden Signals]
        └─> [Dependencies]
             └─> [Infra/Runtime]
                  └─> [Release/Feature Flags]
                       └─> [Queues/Jobs]
                            └─> [Costs]

Все 12 дашбордов могут храниться в виде папок в Grafana, Datadog или New Relic с использованием шаблонных переменных: service, env, cluster, version.

1) SLO и Error Budget (вид «Мы горим?»)

Почему это успокаивает: объединяет всех по единственному важному вопросу: соответствует ли пользовательский опыт целевому уровню прямо сейчас?

Дашборды:

• Скорость сжигания скользящего SLO (окна 1 ч/6 ч)
• Оставшийся бюджет ошибок (% и время до исчерпания)
• Наиболее проблемные SLI (доступность, задержка, качество)

Пример PromQL:

# 1h burn rate example (availability SLI)
(rate(http_requests_total{service="$service",code=~"5.."}[1h]))
/
(rate(http_requests_total{service="$service"}[1h]))

Совет: закрепите правила аннотаций для крупных релизов и всплесков трафика.

2) Четыре золотых сигнала (задержка, трафик, ошибки, насыщение)

Почему это успокаивает: классический вид SRE, который быстро показывает, что сломано.

Дашборды:

• Задержка p50/p95/p99, разделенная по маршруту
• Тенденции RPS/QPS
• Частота ошибок 4xx/5xx
• Насыщенность ресурсов (CPU, память, открытые дескрипторы)

Раскладка (ASCII):

[ p95 Latency ]  [ Error Rate   ]
[ RPS Trend   ]  [ Saturation % ]

3) Тепловая карта состояния зависимостей

Почему это успокаивает: большинство сбоев вызваны зависимостями. Позволяет видеть состояние upstream/downstream мгновенно.

Дашборды:

• Тепловая карта зависимостей с SLO и частотой ошибок
• Таблица выбросов: «Зависимости с отклонением ошибки >3x»
• Повторные попытки и тайм-ауты для каждой зависимости

Совет по запросу (в стиле LogQL):

sum by (dependency) (rate(http_client_errors_total{service="$service"}[5m]))

4) Развертывание и разница версий

Почему это успокаивает: подтверждает, имеете ли вы дело с неудачным развертыванием или скрытой ошибкой.

Дашборды:

• Запросы/уровень ошибок по version
• Сравнение канареечных и базовых значений
• Флаги функций с временными метками

Фрагмент PromQL:

sum by (version) (rate(http_requests_total{service="$service"}[5m]))

Включить: развертывание аннотаций, извлеченных из CI/CD (version, commit, author).

5) Мониторинг реальных пользователей (RUM) и синтетические пинги

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

Дашборды:

• Веб-показатели (LCP, CLS, FID) по странам
• Синтетические проверки успеха/задержки по POP
• Ошибки фронтенда (stack traces)

Подсказка по сортировке: зеленый бэкенд с красным RUM обычно означает проблемы с CDN, DNS или JavaScript.

6) API-контракт и «горячие» эндпоинты

Почему это успокаивает: концентрирует внимание на нескольких шумных маршрутах, которые являются причиной 80% инцидентов.

Дашборды:

• Топ N эндпоинтов по трафику/ошибкам
• Изменения версии схемы контракта
• Выбросы размеров запросов/ответов

Пример Datadog-метрики:

avg:service.request.duration{service:$service,resource:$route}.rollup(p95)

7) Очереди, задачи и обратное давление

Почему успокаивает: подавляет панику, показывая, восстановится ли система сама или ситуация будет ухудшаться.

Дашборды:

• Глубина очереди и время ожидания (time-in-queue)
• Задержка потребителя по каждому разделу
• Коэффициент DLQ и основные причины сбоев

Пример PromQL для Kafka:

max by (topic, partition) (kafka_consumergroup_lag{group="$service"})

8) Эффективность базы данных и кэша

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

Дашборды:

• DB p95/p99 по группам запросов
• Ожидание блокировки и взаимоблокировки
• Коэффициент попаданий в кэш (чтение/запись)

Пример Redis LFU:

# Ensure smarter eviction for hot keys
maxmemory-policy allkeys-lfu

Пример SQL (медленные запросы Postgres):

SELECT query, mean_time, calls
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;

9) Ограничения скорости, троттлинг и защитные механизмы

Почему успокаивает: показывает, сработали ли «ремни безопасности» — полезно во время наплыва трафика или атак ботов.

Дашборды:

• Запросы, заблокированые правилом
• Фактический RPS (запросов в секунду) по сравнению с установленным лимитом
• Распределение ответов 429 по IP/тенантам

PromQL:

sum by (rule) (rate(rate_limit_blocked_total{service="$service"}[5m]))

10) Стоимость и эффективность (да, во время инцидентов)

Почему это успокаивает: предотвращает необдуманное избыточное резервирование и информирует об откатах с учетом финансового контекста.

Дашборды:

• Стоимость за 1 тыс. запросов (амортизированная)
• Стоимость за минуту по сервису и региону
• Простаивающий и загруженный CPU

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

11) Таксономия ошибок и трассировки

Почему успокаивает: позволяет отделить «известные шумные» ошибки от «новых пугающих».

Дашборды:

• Классы ошибок с трендом (тайм-аут, валидация, аутентификация, зависимость)
• Новые сигнатуры ошибок за последний час
• Трассировочная диаграмма (waterfall) для трёх наиболее проблемных маршрутов

Фильтр OTel трассировок (псевдокод):

service.name = "$service" AND status.code = ERROR
| top span.attributes["http.target"] by count

12) Руководство на одном экране (человеческий дашборд)

Почему это успокаивает: ставит чеклист рядом с графиками. Никому не приходится искать ссылки в Confluence в 3 часа ночи.

Дашборды:

• Руководство в формате Markdown с деревом решений
• Расписание дежурств и кнопки эскалации
• Хронология недавних инцидентов и шаблон сообщений

Фрагмент ASCII-кода (путь решения):

[Budget burning?]--No-->[Monitor]
        |
       Yes
        v
[Latency spike?]--Yes-->[Check Dependencies Heatmap]
        | No
        v
[Error spike]-->[Rollout & Version Diff]->Rollback?

Минимальный шаблон настройки (чтобы можно было развернуть на этой неделе)

• Переменные: service , env, region, version, dependency.
• Стандартные аннотации: деплои, изменения конфигураций, изменения флагов функций, изменения правил rate-limit.
• Распространенные условные обозначения: красный = воздействие на пользователя, желтый = риск, синий = норма, серый = фон.
• Доступ: делитесь ссылками только для чтения с продуктовой командой/саппортом; добавьте подсказку «Что означает этот вид» на каждой панели.

Пример: спокойный инцидент на 15 минут

• Минута 1–3: SLO показывает расход за 1 час выше порога; золотые сигналы указывают на p99 задержку только для GET /search.
• Минута 4–6: индикатор зависимостей высвечивает ошибки кэша; БД выглядит нормально.
• Минута 7–9: дашборд с деплоями показывает новую версию на 25% канареечного деплоя, коррелирующую с обращениями к кэшу.
• Минута 10: устранение канареечных ошибок.
• Минуты 11–15: очереди освобождаются; расход SLO снижается. Дашборд стоимости подтверждает отсутствие неконтролируемых расходов. Все выдыхают.

Заметки и фрагменты реализации

Alert burn-rate (многооконный):

# Alerts if both short and long windows exceed thresholds
( rate(sli_errors_total{service="$s"}[5m]) / rate(sli_total{service="$s"}[5m]) > 0.02 )
and
( rate(sli_errors_total{service="$s"}[1h]) / rate(sli_total{service="$s"}[1h]) > 0.01 )

Пример шаблона Grafana (JSON):

{
  "templating": {
    "list": [
      {"type":"query","name":"service","query":"label_values(up, service)"},
      {"type":"query","name":"env","query":"label_values(up, env)"},
      {"type":"query","name":"version","query":"label_values(http_requests_total, version)"}
    ]
  }
}

Пример аннотации таймлайна инцидента (псевдо):

curl -X POST "$GRAFANA/api/annotations" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"text":"Canary 3 deployed","tags":["deploy","canary"],"time":1699999999999}'

Распространенные ошибки (и как эти дашборды их предотвращают)

• Разрастание панели управления: этих 12 достаточно. Не дублируйте по командам; используйте переменные.
• Отсутствие общего языка: называйте панели терминами SRE (SLO, burn rate, p95) и сохраняйте единообразие.
• Нет контекста: всегда аннотируйте деплои, флаги функций и изменения инфраструктуры.
• Устаревшие панели: Просматривайте ежемесячно; привязывайте графики к оповещениям, чтобы они никогда не смещались.

Заключение

Спокойствие — это результат ясности. Благодаря этим 12 дашбордам мониторинга вы предоставляете каждому сотруднику дежурной смены единый, надежный путь от устранения последствий для пользователя до первопричины — быстро и эффективно. Инциденты всё ещё случаются. Паника не обязательна.