Создание дашбордов для SLO. Разница между дебаггингом и бизнес-дашбордами¶

Представьте, что вы пилот пассажирского лайнера. В кабине перед вами два типа приборов. Слева полётные индикаторы: скорость, высота, курс, горизонт. Справа — диагностическая панель: температура масла в каждом двигателе, давление в гидравлике, напряжение в электросети. Первые говорят вам: "Всё ли в порядке с полётом?". Вторые отвечают на вопрос: "А почему, собственно, не в порядке?", если что-то пошло не так.

В мире SRE дашборды делятся точно так же: на бизнес-дашборды (SLO-дашборды) и дебаг-дашборды. Путаница между ними одна из самых частых и дорогих ошибок, которая приводит к тому, что во время инцидента все смотрят на красивые, но бесполезные в данный момент графики.

Бизнес-дашборд для SLO: "Всё ли хорошо у пользователя?"¶

Это основной, стратегический дашборд. Его цель дать ответ на один вопрос: "Выполняем ли мы обещания по надёжности (SLO) для наших пользователей?"

Что в нем должно быть:

Фокус на пользовательском опыте: на нём отображаются только ключевые Service Level Indicators (SLI), которые напрямую влияют на пользователя: доступность, задержка (latency), частота ошибок.
Простота и однозначность: его должен понять любой человек за 10 секунд, от CEO до стажёра. Обычно это:
- Большой бейдж burn rate: "тратим Error Budget быстрее нормы" (красный) / "В пределах нормы" (зелёный).
- Простой тренд: график доступности за последние 30 дней с чёткой линией SLO (например, 99,95%).
- Минимализм: 3-5 графиков, не больше.
Должен сразу отвечать на вопрос: "Нужно ли нам что-то делать?" Зелёный - нет, работаем как обычно. Красный - да, возможно, нужно остановить релизы и заняться стабильностью.

Наример: - График 1: Доступность страницы заказа ВМ (цель: 99,95%). - График 2: p^95 задержки поиска нужного флейвора (цель: < 200 мс). - График 3: Процент успешных созданий ВМ (цель: > 99,8%). - Виджет: "Error Budget остаток: 65%" (зелёный).

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

Дебаг-дашборд (дашборд для расследования): "Почему у пользователя не всё хорошо?"¶

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

Что в нем должно быть:

Система и её компоненты: здесь сотни графиков: метрики инфраструктуры (CPU, память, диск), метрики приложения (очереди, таймауты, ошибки по эндпоинтам), метрики зависимостей (время отклика БД, сторонних API).
Детализация и глубина: это набор "срезов" системы. Можно посмотреть метрики по регионам, хостам, версиям приложения, конкретным пользовательским сегментам.
Сложность для непосвящённых: разобраться в нём может только инженер, знающий архитектуру. Это нормально.
Главный вопрос: "Где именно болит и почему?"

Например, при падении SLO заказа VM дебаг-дашборд будет включать: - Графики по каждому микросервису, который участвует в создании ВМ: auth-service, fraud-check, payment-gateway-adapter, some else. - Метрики сети между этими сервисами. - Очереди сообщений в Kafka. - Статус интеграций с конкретными сервисами. - Логи с ошибками, сгруппированные по типу.

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

Критическая разница: "Что" vs "Почему"¶

Критерий	Бизнес-дашборд (SLO-дашборд)	Дебаг-дашборд
Целевая аудитория	Руководство, продукт, вся команда.	Дежурные инженеры, разработчики.
Основной вопрос	"Что?" Что происходит с пользователем?	"Почему?" Почему это происходит?
Время понимания	< 10 секунд.	Минуты и часы для анализа.
Количество графиков	Минимум (3-7).	Максимум (десятки, сотни).
Когда смотрят	Постоянно, для контроля здоровья сервиса.	Во время инцидента или расследования.
Дизайн-принцип	"Glance-able" (понятно с первого взгляда).	"Drill-down" (возможность углубиться в детали).

Фатальная ошибка: смешивать два типа на одном экране¶

Самый частый антипаттерн это попытка создать "универсальный дашборд", где рядом с графиком доступности висят 20 графиков загрузки CPU. Это убивает обе цели:

Для руководства он становится непонятным. Они не знают, на что смотреть.
Для инженера во время инцидента он становится неэффективным. Нужная информация тонет в море "шума".

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

Как строить дашборды правильно¶

Создайте SLO-дашборд¶

Выберите 1-3 ключевых SLI, которые действительно определяют успех продукта с точки зрения пользователя, не нужно выбирать все подряд метрики, которые умеет генерировать продукт.
Создайте максимально простую страницу. Используйте синтетические проверки (black-box) как основной источник истины.
Добавьте явный, хорошо читаемый индикатор состояния Error Budget (например, "Budget burned: 70% за неделю").
Повесьте этот дашборд на большой монитор в офисе. Он должен быть всегда на виду.

Постройте иерархию дебаг-дашбордов¶

Создавайте дашборды по функциональным областям: "Создание ВМ", "Удаление ВМ", "Создание k8s кластера"...
Внутри каждой области используйте принцип сверху вниз:
- Верхний уровень: пользовательские метрики этого модуля.
- Средний уровень: метрики ключевых сервисов этого модуля.
- Нижний уровень: инфраструктурные метрики (CPU, память, сеть) для этих сервисов.
Связывайте дашборды. С SLO-дашборда должна быть ссылка "Investigate" на дашборд создания ВМ. С дашборда создания ВМ должны быть ссылки на дашборды конкретных сервисов.

Внедрите культуру использования¶

Для всей команды: "Состояние сервиса смотрите на SLO-дашборде. Если там зелёный - расслабьтесь."
Для дежурных: "Ваша святая троица во время инцидента: алерт -> SLO-дашборд (подтвердить проблему) -> дебаг-дашборд (найти причину)."
Для руководства: "Во время инцидента смотрите только на SLO-дашборд. Не заходите в дебаг-дашборды и не отвлекайте инженеров. У них есть канал для коммуникации, где они сообщат статус, смотрите туда"

Правильное разделение дашбордов это не техническая прихоть, а вопрос эффективности и спасения нервов.

Есть еще глава про "Модель здоровья продукта", можно ее тоже почитать.