Архитектура операционного слоя
1) Задача операционного слоя
Операционный слой — это платформа и набор практик, которые обеспечивают предсказуемую эксплуатацию: быстрые релизы, низкий MTTR, комплаенс и управляемую стоимость. Он создает перила для продуктов и инфраструктуры: стандарты, автоматизацию, наблюдаемость, управление изменениями и безопасный доступ.
2) Логическая модель (плоскости и домены)
┌────────────────────────────────────────────────────────┐
│ Interface Plane (UX) │← ChatOps/Portals/API
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Control Plane: Policy, Orchestration, Identity, CMDB │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Data/Execution Plane: CI/CD, Jobs, IaC, Runtime Ops │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Telemetry Plane: Logs, Metrics, Traces, SLO Dashboards │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Security & Compliance Plane: Secrets, RBAC, Audit, IR │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Finance/Cost Plane: Usage, Quotas, Budgets, FinOps │
└────────────────────────────────────────────────────────┘
Ключевые домены:
- Сервис-каталог/CMDB: единый реестр сервисов, владельцев, SLO, зависимостей.
- Оркестрация: пайплайны, задачи, кроны, бэкапы, DR.
- Политики (Policy-as-Code): алерты, доступы, retentions, change-gates.
- Наблюдаемость: метрики/трейсы/логи, SLI/SLO, алерты и статус-страница.
- Доступы/секреты: JIT/JEA, токены, крипто, KMS/Vault.
- Инциденты/изменения: ITSM/тикеты, CAB/RFC, пост-мортемы, симуляции.
- DataOps: контракты данных, свежесть, lineage, качество.
- FinOps: учет затрат, лимиты, квоты, оптимизации.
3) Референс-потоки
3.1 Релиз (CI/CD → GitOps)
1. PR с кодом/манифестами → тесты/сканы → подпись артефактов.
2. Прогрессивный деплой (канарейка/blue-green) с SLO-гардрейлами.
3. Авто-роллбек при деградации; аннотации релиза в телеметрии.
3.2 Инцидент (Detect → Respond → Recover)
1. Burn-rate/симптомы + кворум → Page + war-room.
2. Диагностика по трассам/логам; плейбуки.
3. Откат/фолбэк/лимиты → AAR/RCA → CAPA.
3.3 Изменение (RFC/CAB)
1. Анализ риска + окно обслуживания + backout-план.
2. Suppression некритичных алертов, SLO-сигналы активны.
3. Evidence и отчет, пересмотр политик.
4) Сервис-каталог и CMDB
Атрибуты: владелец, SLI/SLO, зависимости (внутренние/внешние), дашборды, алерты, runbook’и, классы данных (PII/финансы), зоны (prod/stage/dev).
Авто-наполнение: из CI/CD, телеметрии и репозиториев.
Использование: маршрутизация алертов, эскалации, расчет blast radius, отчетность по зрелости.
5) Политики как код (Policy-as-Code)
Категории: доступы (RBAC/ABAC), безопасность (SAST/SCA/DAST), алерты/SLO, ретенции, change-gates, ресурсы/квоты.
Механика: декларативные правила (YAML/Rego/CEL), валидация в CI, принудительное исполнение в Control Plane.
Пример гейта: “деплой разрешен, если все SLO зеленые, нет активных SEV-1, тесты прошли, подписи валидны”.
6) Оркестрация и выполнение
CI/CD: build → scan → sign → promote.
Jobs/CronJobs/DAG: бэкапы/ротации/бэкфиллы; дедлайны и конкуренции (Forbid/Replace).
Идемпотентность и откаты: check-then-act, маркеры шагов, circuit-breaker.
Права запуска: JIT-учетки, ограниченные scope; аудит.
7) Наблюдаемость и качество сигналов
SLI/SLO по доменам: доступность/латентность/успех бизнес-операций, свежесть данных.
Алерты: burn-rate в двух окнах, кворум, дедуп/rate-limit, runbook и владелец.
Логи/метрики/трейсы связаны trace_id; каналы от графиков к логам.
Статус-страница: шаблоны, частоты апдейтов, аудит публикаций.
8) Доступы, секреты, крипто
Хранилища секретов (KMS/Vault), ротации, запрет секретов в репо.
JIT/JEA: выдача прав на время операции/смены.
mTLS/OIDC между сервисами; подпись образов/SBOM.
Аудит: неизменяемые журналы, WORM для критичных действий.
9) Инциденты, изменения, окна обслуживания
Инциденты: SEV-матрица, IC/TL/Comms/Scribe, шаблоны апдейтов, AAR→RCA→CAPA.
Изменения: RFC/CAB, риск-оценка, канарейки, backout.
Окна обслуживания: выбор времени, коммуникации, suppression правил, evidence.
10) DataOps в операционном слое
Контракты данных (схемы, SLA свежести/полноты).
DQ-тесты на каждом слое (Bronze/Silver/Gold).
Lineage и каталоги; карантин для брака.
SLO данных и алерты по свежести/дрейфу.
11) FinOps и стоимость
Unit-экономика: $/1k запросов, $/успешную транзакцию, $/GiB логов, $/SLO-пункт.
Квоты/лимиты: egress, лог-объемы, длительность задач.
Оптимизации: партиции/кэш/материализации/архивы (hot-warm-cold).
Отчеты: дешевые “дорогие” сервисы/запросы, алерты на перерасход.
12) Интерфейсы: ChatOps/Portals/API
Портал платформы: каталог сервисов, кнопки “деплой/откат”, статус SLO, слоты окон, политики.
ChatOps: `/deploy`, `/handover start`, `/mw create`, `/status update` — с аудитом и evidence.
API: для интеграции с ITSM/HR/биллингом/провайдерами.
13) Модель ответственности (RACI)
Platform/SRE: контрольная плоскость, политики, наблюдаемость, ротации.
Product/Dev: SLO сервисов, релизы, плейбуки.
Security: секреты, уязвимости, IR.
Data/Analytics: DataOps, SLA свежести/качества.
Compliance/Legal: регуляторика, хранение evidence.
Support/Comms: статус-страница, клиентские сообщения.
14) Метрики зрелости операционного слоя
SLO coverage: % сервисов с определенными SLI/SLO и burn-rate.
Alert hygiene: actionable ≥80%, FP ≤5%, alerts/on-call-hour (p95).
DORA: частота деплоев, lead time, MTTR, change-failure-rate.
Change governance: % изменений по RFC, % окон “on-time”, откаты.
Security: среднее время ротации секретов/сертификатов, закрытие уязвимостей.
FinOps: $/единицу и % экономии QoQ.
Docs: покрытие runbook/SOP, свежесть (≤90 дней).
15) Чек-лист “минимально жизнеспособный операционный слой (MVP)”
- Сервис-каталог/CMDB с владельцами, SLO, зависимостями и дашбордами.
- CI/CD + GitOps, подпись артефактов, прогрессивные релизы, авто-откат.
- Объединенная телеметрия (логи/метрики/трейсы) с trace_id и SLO-алертами (двойные окна, кворум).
- Policy-as-Code: доступы, алерты, ретенции, change-gates.
- Хранилище секретов, JIT/JEA, mTLS/SSO, неизменяемый аудит.
- ITSM/инциденты: SEV-матрица, плейбуки, статус-страница, шаблоны апдейтов.
- Окна обслуживания: календарь, RFC-шаблоны, backout-планы, evidence.
- FinOps: видимость затрат, квоты/лимиты, отчеты.
- Документация (Docs-as-Code), шаблоны SOP/Runbook, чек-лист готовности к прод.
16) Анти-паттерны
“Платформа = набор скриптов” без контрольной плоскости и политик.
Мониторинг “от всего” → лавина алертов, alert fatigue.
Ручные прод-изменения без GitOps/аудита.
Секреты в переменных окружения без хранилища и ротации.
Отсутствие SLO: спорим о чувствах, а не о целях качества.
Разрозненные каталоги/таблицы владельцев → потерянные эскалации.
Нет backout-плана у High-risk изменений.
Логи без структуры/корреляции → долгие расследования.
17) Мини-шаблоны
17.1 Карточка сервиса (каталог)
Service: checkout-api
Owner: @team-checkout
SLO: availability 99. 9% (28d), p95 latency ≤ 250 ms
Dependencies: payments-api, auth, redis, psp-a
Dashboards: SLO, errors, latency, capacity
Runbooks: rb://checkout/5xx, rb://checkout/rollout
Data: PII masked; retention 30d logs, 365d audit
Change gates: canary 1/5/25%, auto-rollback on burn-rate breach
17.2 Политика алерта (идея)
yaml id: checkout-latency-burn type: burn_rate sli: http_latency_p99 windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
quorum: [ "synthetic:eu,us", "rum:checkout" ]
owner: team-checkout runbook: rb://checkout/latency routing: page:oncall-checkout controls: {dedup_key: "svc=checkout,region={{region}}", rate_limit: "1/15m"}
17.3 Gate деплоя (псевдо)
yaml allow_deploy_when:
tests: passed signatures: valid active_sev: none_of [SEV-0, SEV-1]
slo_guardrails: green_last_30m rollback_plan: present
18) Дорожная карта внедрения (8–12 недель)
1. Нед. 1–2: инвентаризация сервисов → каталог/CMDB; базовые SLI/SLO и дашборды.
2. Нед. 3–4: GitOps + прогрессивные релизы; Policy-as-Code (алерты/ретенции).
3. Нед. 5–6: единая телеметрия и статус-страница; burn-rate с кворумом; runbook-покрытие.
4. Нед. 7–8: секреты/JIT, неизменяемый аудит; RFC/окна обслуживания.
5. Нед. 9–10: FinOps отчетность, квоты/лимиты; оптимизация логов и хранения.
6. Нед. 11–12: симуляции инцидентов/DR; метрики зрелости; план непрерывного улучшения.
19) Итог
Архитектура операционного слоя — это контрольная плоскость плюс стандартизированные практики, которые превращают эксплуатацию в повторяемый, измеримый и безопасный процесс. Сервис-каталог, GitOps, телеметрия, политики, безопасные доступы и управляемые изменения дают устойчивые релизы, быстрое восстановление и прозрачную стоимость — то есть операционную предсказуемость для бизнеса.