Модуль 15. Команда, роли и процессы
BI/DWH-платформа на k8s — это продукт, а не «сервер со скриптами». Продукт требует:
- Чётких ролей (platform, data, BI, DBA, security, архитектор).
- Процессов (on-call, change-management, релизы, управление артефактами).
- Договорённостей (RACI на жизненный цикл витрин, Definition of Ready/Done).
- Гигиены (GitOps, секреты, политики, наблюдаемость, SLO).
- Развития компетенций (план обучения и скилл-матрица).
Роли и компетенции (что умеет каждая роль)
Платформенная команда k8s (Platform/DevOps/SRE)
Зона ответственности: кластер, сети/Ingress, хранилища, GitOps, наблюдаемость, безопасность платформы, SLO платформенных сервисов.
Ключевые компетенции: k8s (Deployments/StatefulSets/Ingress/NetworkPolicy), Helm/Kustomize, Argo CD/Flux, Prometheus/Grafana, Loki/EFK, Vault/ESO, Gatekeeper/Kyverno, DR/HA (PDB/topology spread).
Типичные решения: SSO на краю, default-deny, выделенные пулы нод, HPA/KEDA, cosign/подписи образов, burn-rate алерты.
Data Engineers (инженеры данных)
Зона ответственности: конвейеры (Airflow/Dagster), модели/dbt, CDC (Kafka/Debezium), Lakehouse (Iceberg), витрины.
Компетенции: SQL (PG/CH/Trino), партиционирование/инкременты, dbt tests, DQ (Great Expectations/Soda), OpenLineage, производительность запросов, cost-aware дизайн.
Админы СУБД (DBA: Postgres Pro/ClickHouse/ADPG/ADQM)
Зона ответственности: конфигурация, репликации, PITR, апгрейды, производительность, безопасности БД, pgBouncer.
Компетенции: Patroni/pgBackRest, logical/physical replication, индексация/профилирование, планировщик CH, ресурсы/IOPS.
BI-разработчики (Superset/Metabase/российские BI)
Зона ответственности: датасеты, дашборды, права, рассылки/экспорты, кэширование, UX.
Компетенции: подключение к Trino/PG/CH, роль-мэппинг через SSO, оптимизация запросов, кэш/фоны (Celery), версионирование артефактов BI.
Безопасность/Инфобез
Зона ответственности: IdP/SSO, RBAC, политики, аудит, секрет-менеджмент, соответствие, скан уязвимостей.
Компетенции: OIDC/SAML/LDAP, Vault/ESO, Pod Security/Gatekeeper/Kyverno, image signing/Trivy, SIEM.
Архитектор данных/платформы
Зона ответственности: целевая архитектура, стандарты (форматы, слои, SLA/SLO), RACI/границы команд, roadmap.
Компетенции: data mesh/моделирование доменов, lakehouse/warehouse, SLO-дизайн, TCO, DR, риски.
(Опционально: Data Steward/Owner — владельцы доменов и качества, см. Модуль 13.)
Командная топология и интерфейсы
- Платформа (горизонтальная): «k8s как сервис» + GitOps + безопасность + наблюдаемость.
- Доменные скводы (вертикальные): «данные как продукт» — от источника до витрины/BI.
- Сквозные соглашения: SLO/SLI, формат витрин (contract), release-gates (DQ/линейдж), Change Advisory (CAB) для критичных изменений, единый IdP.
RACI для жизненного цикла витрин (от источника до BI)
|
Этап |
Архитектор |
Платформа |
Data Eng |
DBA |
BI Dev |
Security |
Steward/Owner |
|---|---|---|---|---|---|---|---|
|
Дизайн витрины/контракта |
R |
C |
A |
C |
C |
C |
A |
|
Интеграция (CDC/ingest) |
C |
C |
A |
C |
C |
I |
|
|
Модели/dbt + DQ |
C |
A |
C |
R |
|||
|
Публикация в marts (GitOps) |
C |
A |
R |
C |
C |
I |
|
|
Подготовка датасетов/прав |
C |
A |
C |
R |
|||
|
Наблюдаемость/SLO/алерты |
C |
A |
R |
R |
R |
C |
I |
|
Инцидент качества |
C |
I |
A |
C |
C |
C |
R |
|
Изменение схем (expand/contract) |
A |
C |
R |
C |
C |
C |
R |
|
DR/бэкапы/восстановление |
C |
C |
I |
A |
I |
C |
I |
A = отвечает (Accountable), R = выполняет (Responsible), C = консультирует, I = информируется.
On-call и управление инцидентами
Политика дежурств
- Кого будим: first-line SRE/Platform (24×7), second-line (Data Eng/DBA) по эскалации.
- Севери-типы: SEV-1 (данные/BI недоступны/потеря данных), SEV-2 (деградация SLO), SEV-3 (локальные сбои).
- MTTA/MTTR таргеты: MTTA ≤ 10 мин (SEV-1), MTTR ≤ 60–120 мин (в зависимости от домена).
- Runbooks: «Debezium lag растёт», «Trino coordinator down», «pg failover», «BI 5xx/latency», «Vault секрет протух».
- Коммуникации: Incident Commander, канал #incident-room, шаблоны статусов (15/30/60 мин).
Дежурный набор инструментов
- Grafana/Alertmanager (burn-rate, freshness, queued queries), Loki/EFK, доступ к Argo CD, kubectl-readonly, DR-док, «кнопка» на rollback.
Change-management и релизная политика
Типы изменений
- Standard Change (автоматизировано, низкий риск): обновление Helm values, non-prod → prod через PR, все гейты зелёные.
- Normal Change (CAB): миграции схем/сложные конфиги, канареечные выкаты, окна работ.
- Emergency Change (E-CAB): быстрозакрывающие фиксы инцидента (после-фактум ревью).
Правила релиза
- GitOps-only: изменения в кластере — только через PR в env-repo.
- Canary/Blue-Green: BI/прокси/web — через Argo Rollouts; БД — expand/contract и PITR.
- Release-gates: SLO/DQ/линейдж/сигнатуры образов/политики безопасности — «зелёные», иначе стоп.
- Окна: нет релизов в пиковые «бизнес-окна» (например, 9–12 и 16–20), «заморозки» на отчётные периоды.
- Версионирование: semver для образов/чартов; для миграций БД — монотонный id и idempotency.
Контроль артефактов (чарты, манифесты, SQL-миграции, BI)
Репозитории:
- app-repos (код/образы), ops-charts (Helm/Kustomize), env-repo (окружения/версии/политики).
- BI-артефакты (дашборды/датасеты) — как код (экспорт/импорт, скрипты/CLI).
- dbt и DQ (GE/Soda) — рядом с моделями; миграции БД — отдельный репозиторий (Liquibase/Flyway).
Гейты CI:
- Линтеры Helm/Kustomize, schema-валидаторы CRD, Trivy/SBOM, подписи (cosign), unit-тесты DAG/dbt, DQ smoke.
Release notes: что меняется, риски, план отката, влияние на SLO.
Процессы и регулярные встречи (cadence)
- Еженедельно: Ops-обзор SLO/SLA, burn-rate инцидентов, top-N медленных запросов, capacity.
- Ежемесячно: CAB на крупные изменения/миграции, обзор ошибок качества (DQ) и план улучшений.
- Ежеквартально: DR-учение (restore + cutover rehearsal), пересмотр SLO/ретеншн логов, аудит политик Gatekeeper/Kyverno.
- Непрерывно: код-ревью, деплой по PR, пост-мортемы без поиска виноватых.
Метрики (DORA): частота релизов, lead time, change failure rate, MTTR. Цели — «зрелые»: релизы ежедневно/еженедельно, CFR < 15%, MTTR < 60–120 мин.
Риски оргуровня и анти-паттерны
|
Риск |
Проявление |
Что делать |
|---|---|---|
|
«Все делают всё» |
Сбои, дубли, нет ответственных |
Ввести RACI, интерфейсы команд, Definition of Ready/Done |
|
Обход GitOps |
«Таинственные» изменения в кластере |
Read-only доступ, admission-webhooks, аудит API, дисциплина PR |
|
Нет on-call |
Долгий MTTR, эскалация по знакомым |
Формализованный on-call, дежурства, тренировки |
|
Релизы «когда угодно» |
Пики инцидентов |
Окна/заморозки, canary, гейты, CAB |
|
BI-артефакты «ручками» |
Потеря изменений, не воспроизводимо |
Экспорт/импорт как код, репозитории, review |
|
«Забыли безопасность» |
Утечки, штрафы |
Security-by-design: секреты, политики, подписи, SSO, аудит |
Definition of Ready / Definition of Done (для витрины)
DoR (готово к разработке):
- Описан владелец/стeward/контракт схемы, источники, SLA свежести/качества, тестовые данные, план DQ.
DoD (готово к релизу):
- dbt/миграции и DQ-чек листы зелёные, lineage актуален, дашборды обновлены/ревью пройдено, SLO-гейты зелёные, runbooks обновлены, PR в env-repo слит.
Артефакт 1. Матрица навыков (пример-шаблон)
Оценка: 0 — нет, 1 — базовый, 2 — уверенный, 3 — эксперт. Заполняется по людям; «дырки» → в учебный план.
|
Навык \ Роль |
Platform/SRE |
Data Eng |
DBA |
BI Dev |
Security |
Архитектор |
|---|---|---|---|---|---|---|
|
k8s (Deploy/Stateful/NetPol/Ingress) |
3 |
2 |
1 |
1 |
2 |
2 |
|
Helm/Kustomize, Argo CD (GitOps) |
3 |
2 |
1 |
1 |
2 |
2 |
|
Observability (Prom/Graf/Loki, SLO) |
3 |
2 |
2 |
1 |
2 |
2 |
|
Vault/ESO, RBAC, Gatekeeper/Kyverno |
3 |
2 |
2 |
1 |
3 |
2 |
|
Postgres Pro (PITR, Patroni, perf) |
1 |
2 |
3 |
1 |
2 |
2 |
|
ClickHouse/Trino (perf, планы) |
2 |
3 |
2 |
1 |
1 |
2 |
|
Airflow/Dagster, dbt |
1 |
3 |
1 |
1 |
1 |
2 |
|
Kafka/Debezium |
2 |
3 |
2 |
0 |
1 |
2 |
|
DQ (GE/Soda/dbt tests) |
1 |
3 |
1 |
1 |
1 |
2 |
|
BI (Superset/Metabase, SSO, кэш) |
1 |
2 |
1 |
3 |
2 |
2 |
|
DR/HA (PDB/topology, PITR, cutover) |
3 |
2 |
3 |
1 |
2 |
3 |
|
Безопасность (SSO/OIDC, подписи, скан) |
2 |
2 |
2 |
1 |
3 |
2 |
|
Процессы (on-call, CAB, пост-мортем) |
3 |
2 |
2 |
1 |
2 |
3 |
(Добавьте строки по своим технологиям: Arenadata, Postgres Pro инструменты, российские BI и пр.)
Артефакт 2. Учебный план развития (12 недель, пример)
Цель: выровнять базовые компетенции до «минимума для продакшна», закрыть «красные зоны» матрицы.
|
Недели |
Модуль/Тема |
Для кого |
Формат/Критерий |
|---|---|---|---|
|
1–2 |
Kubernetes для дата-нагрузок (Pods/Stateful/NetPol/Ingress, PSA) |
Все инженеры |
Лабы + мини-экзамен (деплой stateful-БД, Ingress с mTLS) |
|
3 |
GitOps (Helm/Kustomize, Argo CD), релизы/гейты |
Platform, Data Eng, BI |
Практика: app-repo/env-repo, canary rollout |
|
4 |
Observability+SLO (kube-prom-stack, burn-rate) |
Все инженеры |
Дашборд SLO BI/Trino, 2 алерта burn-rate |
|
5 |
Postgres Pro (Patroni/PITR, pgBouncer), CH/Trino perf |
DBA, Data Eng |
Лаб: PITR, explain-анализ 3 запросов |
|
6 |
Kafka/Debezium + Lakehouse (Iceberg, compaction) |
Data Eng |
Лаб: CDC→S3→Iceberg→Trino |
|
7 |
DQ и Catalog (GE/Soda/dbt tests, OpenLineage) |
Data Eng, BI, Steward |
Лаб: gate DQ + публикация в каталог |
|
8 |
Security-by-design (Vault/ESO, Gatekeeper/Kyverno, cosign) |
Platform, Security |
Политики «enforce», подписи образов |
|
9 |
BI на k8s (Superset/Metabase), кэш/воркеры, SSO |
BI Dev, Platform |
Лаб: Celery+Redis, SSO, экспорт в S3 |
|
10 |
DR/HA и хаос-день |
Platform, DBA, Data Eng |
Учение: drain ноды, failover PG, проверка SLO |
|
11 |
Процессы (on-call, CAB, пост-мортемы) |
Лиды, IC |
Смоделированный инцидент SEV-1 |
|
12 |
Итоговый пилот (витрина + BI) |
Скводы |
Демо: SLO зелёные, релиз через гейты |
Материалы: ваши Модули 0–14, внутренние runbooks, шаблоны PR/релиз-нотов, чек-листы.
Практические примеры «как завтра жить лучше»
- Единая матрица ролей в IdP: bi-viewers, bi-analysts, bi-admins, data-eng, platform-sre, dba, security.
- Шаблоны репозиториев: template-dbt-project, template-airflow-dags, template-helm-app, с включёнными CI-чеками.
- Чек-лист релиза витрины (1 страница): гейты, SLO, DQ, lineage, BI-верификация, план отката.
- Еженедельный отчёт SLO: прогресс по ошибкам/свежести, «дорогие» запросы, расходы (TCO-линза, Модуль 12).
- On-call календарь: расписание на 8–12 недель, контакт лист, shadow-дежурные.
Надёжная платформа данных — это не только Kubernetes и Helm. Это согласованные роли, прозрачный RACI, дисциплина GitOps, зрелые процессы on-call/релизов/изменений и понятный план развития. Когда всё это есть, релизы становятся предсказуемыми, инциденты — управляемыми, а витрины — продуктом с меряемым качеством и понятными владельцами.