Модуль 19. Операционная модель: роли, on-call, процессы, SLO

Задача модуля — сделать так, чтобы слой витрин на ClickHouse жил как сервис: с явными ролями, дежурствами, SLO/SLA, управлением инцидентами и релизами, регулярными DR-тренировками, контролем «дорогих запросов» и формализованными ретро-пересчётами. Всё с примерами, чек-листами и готовыми артефактами.

К чему приходим (критерии «зрелого» сервиса)

SLO определены и измеряются: Freshness, Latency, Availability, DQ (балансы/инварианты).
On-call 24×7/12×5: регламенты, уровни эскалации, runbooks.
Инциденты управляются по канбан-процессу: единая точка входа, SLA реакции, постмортемы.
Релизы управляемые: «зелёные/жёлтые», канарейки, flip/rollback по alias, freeze-окна.
DR-практика: бэкапы проверены, RPO/RTO подтверждены.
Аудит нагрузки: «дорогие запросы» BI/API подсвечиваются и чинятся.
Ретро-пересчёты: по регламенту, с лимитами и планированием ресурсов.
Стоп-релизы: при исчерпании error-budget (по SLO) релизы блокируются автоматикой.

Роли, зоны ответственности и RACI

Роли

Product Analytics — владельцы метрик/дашбордов, формулы и паспорта метрик; приемка по бизнес-SLO.
DWH Engineer — модели/DDL/MV/«физика» витрин; ретро-пересчёты, миграции.
Platform/DevOps — кластеры CH, CI/CD, Terraform/K8s, бэкапы, мониторинг.
SRE — SLO/SLA, on-call, алертинг, error-budget, постмортемы.
(Опционально) Security/Compliance — PII, RLS/маскирование, доступы, аудит (см. М18).

Мини-RACI (пример)

Процесс	Product	DWH	Platform	SRE	Sec
Паспорт метрики	R	C	I	I	I
Деплой витрин	A	R	C	C	I
DR-день	I	C	R	A	I
Инциденты SLA	C	C	C	R/A	I
Ретро-пересчёты	A	R	C	C	I
«Дорогие запросы»	A	R	C	C	I

R — Responsible, A — Accountable, C — Consulted, I — Informed.

SLI/SLO/SLA и error-budget

SLI (что меряем) и SLO (на что подписываемся)

Freshness (NRT/Daily): now() - sem_meta.updated_at.
- SLO: NRT-витрины ≤ 5 минут p95; дневные ≤ 60 минут p95.
Latency (запросы BI/API): p95 по ответам источников vw_* в пределах порогов (плитки ≤ 1–2 c; отчёты ≤ 10–15 c).
Availability: успешные запросы к vw_* и API-эндпоинтам (2xx) / все запросы.
DQ: баланс vs CORE/GL (≤ 0.2% на окне 30 дней), инварианты (например, CR∈[0,1]).

Error-budget

Определяем бюджет нарушений SLO на период (месяц/квартал).
Пример: для Freshness-NRT — макс. 60 минут «красного» времени в месяц (в сумме).
Policy: если бюджет израсходован на 100% → заморозка релизов (кроме фиксов), «жёлтые» релизы запрещены.

SLO-манифест (YAML-пример)

service: data-marts
period: monthly
slos:
  - name: freshness_nrt
    indicator: freshness_minutes_p95
    target: 5
    budget_minutes: 60
  - name: bi_latency_tiles
    indicator: p95_ms_tiles
    target: 1500
    budget_breaches: 10
  - name: availability_api
    indicator: success_rate
    target: 99.9
    budget_minutes: 45

On-call: как устроить дежурства

Расписание

Ротация: Primary (первая линия), Secondary (эскалация), Manager on duty (дневная).
Зоны времени: старайтесь покрыть бизнес-часы ключевых рынков.

Каналы и инструменты

#oncall-data-marts (Slack/Teams), PagerDuty/Alertmanager, инцидентный борт (Jira/Linear).
Единая точка входа — бот «/incident» создаёт карточку с шаблоном.

Triage-матрица

SEV-1 (SLO под угрозой/BI «лежит»/DR событие): реакция ≤ 5 мин, коммуникация бизнесу ≤ 15 мин.
SEV-2 (отклонения без влияния на ключевые отчёты): реакция ≤ 15 мин.
SEV-3 (дефекты без SLA-влияния): в рабочее время.

Runbooks (сводка)

Lag NRT/Freshness красный → см. М14 (Kafka lag, merges backlog, replication_queue).
Latency BI p95 ↑ → проверить query_log на FINAL, DISTINCT/квантили «на лету», read_bytes (см. §7).
Диск full / S3 flaps → TTL/MOVE, чистка кэша, перевод тяжелых отчётов на rollup.

Инциденты: канбан-процесс

Жизненный цикл: Open → Triage → Mitigate → Verify → Postmortem → Done.

Шаблон карточки (issue) содержит:

Симптом (что видит пользователь), затронутые отчёты/эндпоинты.
SLO-влияние (Freshness/Latency/Availability).
Владелец (on-call), severity, ETA.
Коммуникация (канал, статус-апдейты).
Митигирующие действия и итоговый фикс.
Postmortem (обязателен для SEV-1/2) с action items и дедлайнами.

Метрики инцидентов: MTTA, MTTR, доля SEV-1/2, % выполнения action items в срок.

Релизы: «зелёные/жёлтые», канарейки, flip/rollback

Классы изменений

Зелёный: совместимые изменения VIEW/DDL, без смены формул; покрыты тестами/регрессами.
Жёлтый: смена логики метрик/ключей, миграции с ретро, изменение SLA/стоимости.

Процесс

Canary: 5% трафика/пользователей, затем 20% → 100%.
Alias-flip: vw_metric_v2 + vw_metric (alias). После dual-run/регресса — flip alias на v2.
Rollback: обратный flip, сохранённый снапшот схем/данных.
Freeze: отчётные периоды, пик-сезоны — только критические фиксы.

Гвардейки CI: запрет FINAL, SELECT *, enforce time-filter, проверка SLO-бюджета (если budget exhausted → job «Release blocks» fails).

DR-тренировки и устойчивость

RPO/RTO и сценарии

RPO ≤ 15 минут (потеря данных при аварии), RTO ≤ 60 минут (время восстановления).
Сценарии: падение ноды/шарда, потеря диска, потеря datacenter (если multi-region), порча данных/мутации, недоступность S3.

Процедуры

BACKUP/RESTORE (сниппеты см. М10/М11), keeper health, репликация — проверка очередей.
«DR-день» — ежеквартально: вытащить backup на стенде, прогнать smoke-тесты, сравнить баланс vs CORE.

Чек-пойнты DR: актуальны политики хранения, резервные конфиги, секреты/доступы, документирован «поверочный лист».

Аудит «дорогих запросов» и guardrails для BI/API

Топ «дорогих» (по read_bytes/duration)

SELECT
  user,
  any(log_comment) AS comment,
  sum(read_bytes) AS read_b,
  round(sum(read_bytes)/1e9,2) AS read_gb,
  quantileExact(0.95)(query_duration_ms) AS p95_ms,
  count() AS n
FROM system.query_log
WHERE type='QueryFinish'
  AND event_time >= now()-INTERVAL 1 DAY
  AND query_kind = 'Select'
GROUP BY user
ORDER BY read_b DESC
LIMIT 20;

Выявить FINAL, DISTINCT/квантили «на лету»

SELECT query_id, query_duration_ms, read_rows, read_bytes
FROM system.query_log
WHERE type='QueryFinish'
  AND event_time >= now()-INTERVAL 1 DAY
  AND (positionCaseInsensitive(query, ' FINAL ') > 0
       OR (positionCaseInsensitive(query,'DISTINCT')>0
           AND positionCaseInsensitive(query,'State(')=0))
ORDER BY query_duration_ms DESC
LIMIT 50;

Не «vw_*» (обход семантики)

SELECT query_id, user, any(query) AS q
FROM system.query_log
WHERE type='QueryFinish'
  AND event_time >= now()-INTERVAL 7 DAY
  AND positionCaseInsensitive(query, ' db_sem.vw_') = 0   -- ваш префикс семантики
  AND query_kind='Select'
GROUP BY query_id, user;

Действия: авто-отчёт в канал #bi-guardrails, тикеты на исправление (перевести источники на vw_*, вынести квантили/uniq в …State/…Merge или rollup).

Ретро-пересчёты: политика и эксплуатация

Когда допустимы

При фиксе источников/формул, при поздних событиях (NRT), при корректировках курсов/календаря.

Политика

Окно: 14/30/90 дней — по метрике (поле retro_window_days в YAML, см. М17).
Время: ночи/выходные (окна с низкой нагрузкой).
Квоты: max параллельность, max parts/partition, лимит read_bytes/час.
Валидация: регресс v1↔v2 на сэмпле/окне, DQ-баланс после замены партиций.

Технологика

Пересборка в tmp-таблицу → REPLACE PARTITION в целевую (см. М14).
Логировать в retro_jobs (owner, окно, ресурсы, результаты).
Алерты: при превышении лимитов на merges/replication_queue.

Практика (2 недели внедрения)

Неделя 1

SLO-манифест: зафиксировать индикаторы/пороговые значения.
Алерты: Freshness/Latency/Availability, parts/merges/replication.
On-call: расписание, каналы, triage-матрица, runbooks.
Инцидентный борт: шаблон карточки, автоматическое создание через бот.

Неделя 2

CI-гвардейки: линтер SQL, «stop-releases при исчерпании error-budget».
Guardrails BI/API: отчёт по «дорогим запросам», правила, тикеты.
DR-день (лайт): частичное восстановление на стенде, smoke-тесты.
Отчёт SLO: автоматическая генерация и рассылка.

Отчёт SLO: что в нём

Графики Freshness p50/p95 по основным vw_*; % времени в SLO.
Latency p95 по источникам/эндпоинтам; топ «дорогих» пользователей/запросов.
Availability (% 2xx) по API/BI.
DQ: баланс vs CORE/GL, инварианты за период.
Использование error-budget и «красные» периоды.
Тренды/рекомендации/запланированные работы (capacity, ретро).

SQL-заготовки для отчёта — см. §7; метаданные свежести — sem_meta/dq_results (М5/М10/М17).

Артефакты (что отдаём)

RACI-матрица (MD/Excel) и каталог ролей/контактов.
SLO-манифест (YAML) + шаблон ежемесячного отчёта.
Runbooks: Freshness-просадка, merges backlog, replication lag, disk full, Kafka lag, «дорогие запросы».
Регламенты: on-call, инциденты, релизы («зелёные/жёлтые», canary/flip/rollback), DR-день, ретро-пересчёты.
Шаблоны: карточки инцидента, постмортема (см. ниже), запроса на ретро, freeze-план.
Скрипты/SQL: отчёты query_log (топ «дорогих», FINAL/DISTINCT), агрегации DQ.

Шаблон постмортема (выдержка)

Инцидент: <датавремя, SEV, затронуто>
SLO-влияние: <Freshness/Latency/Availability/DQ>
TTR/TTD/MTTR: <числа>
Timeline: <минуты и события>
Причина: 5 Why’s
Что помогло / что мешало:
Фикс (временный/постоянный):
Action items (owner, due, статус):
Уроки и изменения процесса:

Чек-лист операционной модели

SLO на Freshness/Latency/Availability/DQ утверждены и публикуются.
Error-budget настроен; «stop-releases» при исчерпании включён.
On-call расписание, triage-матрица, каналы и runbooks доступны.
Инциденты ведутся в борде; постмортемы обязательны для SEV-1/2.
Релизы: канарейки, alias-flip/rollback, freeze-окна.
DR-день проведён (квартально), RPO/RTO подтверждены.
Guardrails BI/API: отчёты «дорогих запросов», запрет FINAL, enforce time-filter.
Ретро-пересчёты по регламенту (окна, квоты, ночные слоты).
Артефакты и контакты в каталоге (М17), владельцы назначены.

Риски и как их «зажать»

Риск	Проявление	Митигация
«Героизм» вместо процесса	инциденты тушат «кто свободен», знания теряются	RACI, runbooks, on-call, постмортемы, SLO/бюджеты как «жёсткие» рамки
Error-budget игнорируется	релизы ускоряют деградацию	Автоблок в CI; еженедельный обзор SLO; приоритезируем устойчивость
«Дорогие запросы» в BI	пиковые p95, падение SLA	Еженедельный отчёт, тикеты/SLG на исправление, линтеры и квоты
Ретро «в час пик»	падение свежести, merges backlog	Ночные окна, квоты, REPLACE PARTITION порционно
DR — только на бумаге	восстановление провалено	Квартальные тренировки; тестовые restore + smoke-тесты
Нет владельцев метрик	«чьи цифры?»	М17: no-owner→no-merge, каталог с owners, RACI

Приложение: полезные SQL-сниппеты

Freshness (по вьюхам):

SELECT view_name,
       now() - max(updated_at) AS lag
FROM sem_meta
GROUP BY view_name
ORDER BY lag DESC
LIMIT 50;

Latency p95 по источникам:

SELECT
  regexpExtract(query, 'FROM\\s+([a-zA-Z0-9_\\.]+)', 1) AS src,
  quantileExact(0.95)(query_duration_ms) AS p95_ms,
  count() n
FROM system.query_log
WHERE type='QueryFinish' AND event_time>=now()-INTERVAL 1 DAY
GROUP BY src ORDER BY p95_ms DESC LIMIT 50;

Availability API (если проходите через шлюз с логами в CH):

SELECT date_trunc('hour', ts) AS hh,
       countIf(status BETWEEN 200 AND 299)*100.0 / count() AS success_rate
FROM api_access_log
WHERE ts >= now()-INTERVAL 24 HOUR
GROUP BY hh ORDER BY hh;

Итог

Операционная модель = «как мы держим слой витрин живым и предсказуемым».
Определите SLO и бюджеты, заведите дежурства и инцидентный процесс, введите гвардейки для BI/API, регламент ретро и DR-практику. Это снимет «героизм», ускорит фиксы и поднимет доверие к данным.

Arenadata QuickMarts (ADQM) — корпоративная платформа на базе ClickHouse для быстрого слоя витрин и near-real-time аналитики. Решает задачи «быстрых» дашбордов и API с низкой латентностью и высокой конкуррентностью, работает поверх вашего DWH/лейкхауса как serving-уровень. Даёт предсказуемую производительность на терабайтно-петабайтных объёмах за счёт колоночного хранения, компрессии и предагрегатов (Materialized Views, AggregatingMergeTree), подключается к Kafka/S3 и стандартным BI-инструментам по SQL/HTTP. Для корпоративных ИТ ADQM предлагает поддержку и SLA, отказоустойчивые кластеры (HA/DR), безопасность (RBAC, LDAP/OIDC, шифрование трафика и данных), мониторинг и резервное копирование. Платформа хорошо ложится на методологию курса: семантика vw_*, роллап-слои, NRT-ингест, SLO/наблюдаемость и «гвардейки» для BI/API. Итог — быстрый запуск витрин за недели, снижённые риски в проде и предсказуемая стоимость владения.

← Предыдущая статья

Модуль 18. Расширенная безопасность и комплаенс

Следующая статья →

Модуль 20. Итоговая аттестация и template-пак