Центральный дашборд управления

1) Назначение и принципы

Центральный дашборд управления (далее ЦДУ) — единое окно для принятия решений в операциях. Он агрегирует сигналы из телеметрии, ITSM, CI/CD, каталога сервисов, календаря работ и провайдеров, превращая их в действуемые (actionable) виджеты.

• SLO-first: наверху — целевые SLO и burn-rate по Tier-0/1.
• One-click to action: из виджета — в плейбук/runbook или тикет.
• Единый словарь: одинаковые SEV, статусы, цвета и пороги.
• Аннотации событий: релизы/конфиги/окна на всех графиках.
• Роли и разрешения: персональные представления (on-call, IC, менеджмент).
• Низкий шум: кворум источников, дедупликация и подавление по окнам.

2) Роли и ключевые сценарии

On-call (P1/P2): быстро понять «что горит» и открыть плейбук (≤1 клик).
IC: объявить SEV, запустить war-room-режим, контролировать cadence комм-апдейтов.
Release Manager: видеть гейты, прогресс канареек, готовность отката.
Service Owner/Product: бизнес-SLI (успех платежей/регистраций), влияние фич.
SRE/Platform: емкость, автоскейл, аномалии, DR-готовность.
FinOps: $/единицу, перерасходы, бюджетные алерты.
Security/Legal: posture, ключевые сертификаты, окна ротаций, WORM-аудит ссылками.

3) Информационная архитектура ЦДУ

• SLO по Tier-0/1 (availability/latency/success) с burn-rate 2-окна.
• SEV-статус: активные инциденты и их таймлайн.
• Статус релизов: канарейка/blue-green, активные гейты.
• «Traffic lights» провайдеров (PSP/KYC/CDN).

• Окна обслуживания (сейчас/24ч), suppression-карта.
• Емкость: CPU/RAM/IO/queue-depth/p95 latency с прогнозом.
• FinOps: $/1k txn, дневной спенд vs бюджет, аномалии лог-объемов.
• DataOps: свежесть витрин, SLA пайплайнов, DQ-ошибки.
• Security: срок сертификатов, ротации секретов, критичные уязвимости (age/SLA).

• Корреляции «релиз ↔ SLO», «провайдер ↔ отказ/латентность».
• Быстрые ссылки: логи, трейсы, тикеты, плейбуки, SOP, матрица эскалаций.

4) Виджеты (референс-набор)

1. SLO & Burn-rate

Показывает текущие SLI, цель и расход бюджета ошибок (1ч/6ч).
Действие: открыть плейбук деградации сервиса.

2. Инциденты (SEV-панель)

Активные/последние, таймеры Declare/Comms, роли IC/Comms.
Действие: открыть war-room, шаблон апдейта, чек-лист IC.

3. Релизы/Конфиги

Канарейка 1→5→25%, флаги, откат (кнопка/ссылка на SOP).
Аннотации: версия, коммиты, автор.

4. Окна обслуживания

Текущие/грядущие, impacted-сервисы/регионы; suppression-маска.
Действие: согласовать уведомления, включить стражи SLO.

5. Емкость/Автоскейл

Прогноз потребления (Naive/AR), hotspot-карта, warm-pool.
Действие: запрос квот/скейл-правил (PR в repo-политик).

6. FinOps

$/единицу, топ «дорогих» запросов/логов, daily burn vs budget.
Действие: открыть отчет и рекомендацию (семплинг логов, архивы).

7. Провайдеры

SLA/статус PSP/KYC/CDN, веса маршрутов, фолбэк готовность.
Действие: переключить вес, шаблон коммуникации партнерам.

8. Security

Сертификаты (≤30д), просрочки ротаций, уязвимости (age), подозрительные события.
Действие: открыть IR-плейбук/тикет.

9. DataOps

Свежесть витрин, процент пропуска, отказ пайплайна, DLQ.
Действие: бэкфилл/карантин/rollback трансформации.

5) Состояния/цвета/пороги (эталон)

Green: SLI в пределах цели, burn-rate < 1×.
Amber: SLI деградирует, burn-rate 1–2×, рост p95, но workaround есть.
Red: breach или прогнозный burn-out < 1ч; открывать SEV-1/0.
Grey: suppression (окно), нет телеметрии (ошибка источника).

6) Аннотации и корреляции

Релиз/конфиг/окно/провайдерские статусы отображаются на SLO-графах.
Клик по маркеру → diff, автор, гейты, кнопка «Откат/Фолбэк/SOP».
В инциденте таймлайн строится из аннотаций и действий ChatOps.

7) Источники данных и верификация

Телеметрия: метрики/трейсы/логи с trace_id.
ITSM: инциденты/проблемы/изменения (статусы/SLA).
CI/CD: релизы, подписи, артефакты, тесты.
Каталог сервисов/CMDB: владельцы, SLO, зависимости.
Календарь: окна обслуживания.
Провайдеры: статус-API + ручные подтверждения (приземление в отдельную витрину).
FinOps: биллинг/теги ресурсов, лог-объемы, egress.

Контроль качества: кворум, дублирующие зонды, SLA свежести, алерты на «немые» источники.

8) Режимы отображения

War-room: фиксированная раскладка SLO/Incidents/Releases/Comms-таймер.
Executive (28 дней): тренды MTTR/MTTD/SEV mix, $/ед., SLO-адгеренс.
On-call: компактная «ночная» панель (темный режим, крупные цифры).
Мульти-тенант/регион: фильтры service/region/tenant; пресеты.

9) Навигация и действия (one-click)

Кнопки: `/declare sev1`, `/freeze`, `/rollback`, `/status update`, «открыть плейбук».
Дрилл-ดาวн: SLO → график → логи/трейсы с предзаполненными фильтрами (trace_id, release_id).
Шэринг: снэпшот панелей в тикет/статус-страницу.

10) Безопасность, доступы, аудит

SSO/OIDC + RBAC/ABAC: роли и скоупы (view/action).
JIT/JEA: действие «опасное» доступно только с временным повышением.
Аудит неизменяемый: кто что нажал, какие запросы/команды ушли.
Секреты: не отображаются, только ссылки на менеджер секретов.

11) Метрики зрелости ЦДУ

Actionability ≥ 90%: клики ведут к действиям, а не только к графикам.
Time-to-First-Action ≤ 2 мин из ЦДУ при SEV-1/0.
Доля инцидентов, где ЦДУ был “источником правды” ≥ 95%.
Freshness виджетов: % с данными «свежее 5 мин».
Coverage: % критичных сервисов, имеющих SLO-карточки и аннотации релизов.
Zero-blind-spots: «немых» источников за неделю = 0.

12) Чек-листы

Проектирование

• Роли и сценарии описаны (P1/P2/IC/Exec/FinOps/Security/DataOps).
• Словарь цветов/SEV/порогов согласован.
• Источники данных с кворумом и SLA свежести.
• Макеты War-room/On-call/Executive.
• План интеграции ChatOps/ITSM/CI/CD/CMDB.

Эксплуатация

• Виджеты проходят линтер (обязательные поля, owner, пороги).
• Раз в неделю — Escalation/Alert Review с улучшениями ЦДУ.
• Снапшоты инцидентов прикладываются в AAR/RCA.
• Темный режим/мобильный пресет для дежурств.
• Тесты на «немоту» источников и корректность аннотаций.

13) Шаблоны (идеи)

13.1 Определение виджета (YAML)

yaml id: slo-payments title: "SLO: Success of payments (EU)"
owner: team-payments type: slo_burnrate sli:
metric: "biz. payment_success_ratio"
target_pct: 99. 5 burn_rate:
short_window: "1h"
long_window: "6h"
thresholds:
amber: { burn_rate: 1. 2 }
red:  { burn_rate: 2. 0 }
actions:
- label: "Open playbook"
link: "rb://payments/slo-degrade"
- label: "Release rollback"
link: "sop://REL-ROLLBACK-01"
annotations:
release: true change: true filters:
region: "eu"
tier: "0"

13.2 Карточка инцидентов (JSON)

json
{
"id": "incidents-active",
"type": "incident_board",
"sev": ["SEV-0", "SEV-1", "SEV-2"],
"fields": ["id","sev","service","since","ic","next_comms_at"],
"actions": [{"label":"War-room","cmd":"/declare sev1"}]
}

13.3 Связь с релизом

yaml id: release-canary type: release_progress source: cicd://checkout gates: ["tests","signatures","slo_guardrails"]
canary_steps: [1,5,25]
rollback: "sop://REL-ROLLBACK-01"
annotations: { on_charts: ["slo-latency","slo-success"] }

13.4 Виджет FinOps

yaml id: finops-burn type: cost_unit metrics:
- id: "cost_per_1k_txn"
- id: "logs_daily_gib"
alerts:
- when: "cost_per_1k_txn > target1. 2"
action: "open://finops/reco-logs-sampling"

14) Анти-паттерны

«Стена графиков» без действий и плейбуков.
Разные цвета/пороги по командам → путаница в SEV.
Нет аннотаций релизов/окон — сложная корреляция причин.
Дублирующие источники без кворума — ложные Page/шум.
Секреты/ключи на панели — риск утечки.
Медленный рендер (не кешированы запросы/агрегации) — панели не открывают в бою.

15) Дорожная карта внедрения (4–8 недель)

1. Нед. 1: сбор требований по ролям, словарь статусов/цветов, макеты трех режимов.
2. Нед. 2: подключение SLO/Incidents/Releases/Windows, аннотации, ChatOps-действия.
3. Нед. 3: добавление FinOps/Capacity/Providers/DataOps/Security, кворум источников.
4. Нед. 4: War-room режим, снэпшоты в ITSM, пилот на Tier-0.
5. Нед. 5–6: оптимизация производительности, мобильный/on-call пресет, линтер виджетов.
6. Нед. 7–8: метрики зрелости, еженедельный обзор, автоматические рекомендации (семплинг логов, квоты, фолбэк).

16) Итог

ЦДУ — это не «красивые графики», а панель решений: SLO и burn-rate сверху, инциденты/релизы/окна в одном контексте, мгновенные действия через ChatOps и SOP, подтвержденные источники и аннотации. Такой дашборд снижает MTTA/MTTR, упрощает коммуникации, поддерживает FinOps и делает эксплуатацию прозрачной и предсказуемой.