Архітектура операційного шару

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, телеметрія, політики, безпечні доступи і керовані зміни дають стійкі релізи, швидке відновлення і прозору вартість - тобто операційну передбачуваність для бізнесу.