Ролі інфраструктурних команд
1) Картина цілком: навіщо спеціалізація
Передбачуваність і швидкість: чіткі власники зменшують «сірі зони».
Надійність і безпека: розподіл відповідальності за доменами (K8s, мережі, БД, безпека).
Економіка: FinOps відокремлює вартість від споживання і управляє «ціною дев'яток».
Developer Experience: платформа як продукт - самосервіс, шаблони, каталоги.
2) Основні ролі та зони відповідальності
3) Межі відповідальності (межі володіння)
Платформа володіє рівнями L3-L7 платформних сервісів (K8s, сітка, observability), але не бізнес-логікою.
SRE володіє процесом надійності (SLO/інциденти/постмортеми), а не кожною конкретною метрикою команди продукту.
Release/Delivery володіє механікою викладок, але відповідальність за «що» викладається - у команд фіч.
DBRE володіє кластерами/політиками даних, а схемою/міграціями володіє команда продукту (за стандартами DBRE).
SecOps володіє політиками і контролями, а впровадження - спільно з власниками доменів.
4) Операційні моделі
1. Централізована платформа - швидкий старт, ризик «пляшкового горлечка».
2. Платформа як продукт (PaaP) - самосервісні шаблони, каталоги, «внутрішній маркетплейс» сервісів.
3. Федерація/Гільдії - експерти вбудовуються в продуктові домени (chapter/embedded SRE/DBRE).
4. Матриця - стратегічні стандарти центру + виконання в доменах.
Рекомендація: поєднувати PaaP для базових потреб і embedded для критичних доменів.
5) Інтерфейси та OLAs (внутрішні угоди)
Сервіс-каталог: що доступно «як послуга» (K8s namespace, БД-кластер, черга, дашборд SLO, алерт-профіль).
OLA (Operational Level Agreement): терміни реакцій, арени відповідальності, точки ескалацій.
SLO-картки платформних сервісів: доступність, латентність API, час розгортання з шаблону.
yaml service: "Kubernetes Namespace Provisioning"
owner: "Platform"
request_channel: "Service Catalog"
targets:
response_time: "≤ 15 min"
delivery_time: "≤ 1 hour (without manual approvals)"
scope:
includes: "quota, RBAC, secrets integration"
excludes: "business configs, database migrations"
escalation: "#plat-ops-oncall"6) RACI: Хто робить що
Легенда: R - виконує, A - відповідає, C - консалтинг, I - інформується.
7) KPI і метрики ефективності за ролями
Platform: lead time на надання сервісу,% самосервісу, DevEx NPS.
SRE: MTTR/MTTD, виконання SLO, покриття плейбуками, частка авто-мітігейтів.
CloudOps/NetOps: аптайм периметра, час виконання ченджів, інциденти по конфігурації.
DBRE: RPO/RTO, успішність відновлень, реплікаційний лаг p95.
Release: відсоток канарських релізів, rate відкатів, час оточень.
Observability: повнота сигналів, час відповіді запитів/дашбордів, anti-noise ratio.
SecOps: час закриття критичних CVE, MTTD/MTTR інцидентів безпеки, охоплення секрет-менеджером.
FinOps: cost per service/RPS, rightsizing savings, прогноз точності.
8) Онбординг і DevEx
Start pack: шаблони Terraform/Helm, пайплайни CI/CD, checklists «Hello, Service».
Док-портал: стандарти, приклади, «живі» дашборди, кнопки Self-Service.
Воркшопи/office hours: за ролями (SRE 101, SecOps 101, DBRE 101).
Політика ескалацій: кого кликати ночами і коли достатньо тікету.
9) Межі володіння даних і доступів
IAM-страховка: власники ролей, термін життя доступів, JIT (just-in-time) доступи.
Секрети: централізований секрет-менеджер, ротація, заборона секретів в ENV/репо.
Data Ownership: продукт володіє схемою/даними домену; DBRE володіє «посудиною» (кластерами і політиками).
10) Процеси: інциденти, зміни, релізи
Інциденти: IC/war-room/постмортем (див. «Інциденти і SRE-плейбуки»).
Зміни (Change Management): risk-based, fast lane для low risk, CAB тільки для high risk.
Релізи: progressive delivery, freeze-правила при згорянні бюджету помилок.
11) Чек-листи за ролями (вичавка)
Platform
- Сервіс-каталог і SLA по кожному сервісу платформи
- Шаблони IaC + політики (OPA/Conftest)
SRE
- SLO-картки топ-шляхів, burn-rate алерти, плейбуки
- Щомісячний звіт з помилкового бюджету
DBRE
- DR-дрилі, тест відновлення, RPO/RTO підписані
- Політики міграцій та індексації
SecOps
- Тріаж вразливостей і патч-вікна
- DLP/PII-контролі, аудит-доступи
Release
- Канарські кроки за замовчуванням, авто-rollback
- Фіча-прапори і kill-switch
Observability
- Стандарти метрик/лейблів, budget-дешборди
- Anti-noise (quorum, multi-window), SLO-віджети
FinOps
- Chargeback/showback, rightsizing-рекомендації
- «Cost per 9», прогнозування
12) Анти-патерни організації
«DevOps - це людина»: перевантаження «універсалів», відсутність власників доменів.
«Платформа = квиткова каса»: все через ручні тікети, немає самосервісу.
«SRE = чергові пожежники»: без SLO і повноважень.
«Security як стоп-кран»: пізніше включення, замість «guardrails by design».
«Observability = красиві графіки»: без actionable-алертів і SLO.
«FinOps тільки про звіт»: без рекомендацій і auto-rightsizing.
13) Шаблони артефактів
Шаблон картки платформної послуги
yaml service: "Managed PostgreSQL"
owner: "DBRE"
plan: "S, M, L"
slo:
availability: "99. 95 %/quarter"
rpo: "≤ 5 min"
rto: "≤ 15 min"
interfaces:
request: "Service Catalog → Postgres"
incidents: "#dbre-oncall"
changes: "Change Policy L2"
security:
secrets: "Vault"
access: "JIT/RBAC"
finops:
pricing: "по vCPU/GB/IOPS"
limits: "quota per tenant"Міні-RACI для релізів
yaml release:
strategy: canary
R: Release/Delivery
A: Product Owner
C: SRE, SecOps
I: Platform14) План впровадження (4 ітерації)
1. Стандартизація (2-3 тижні): карта ролей, каталогу послуг, RACI, OLAs, канали ескалацій.
2. DevEx (3-4 тижні): сервіс-каталог, шаблони CI/CD, Terraform-модулі, базові SLO/дашборди.
3. Надійність і безпека (4-6 тижнів): плейбуки інцидентів, DR-дрилі, WAF/DLP, секрет-менеджер.
4. ФінОпс і оптимізація (безперервно): chargeback, rightsizing, «cost per 9», авто-політики.
15) Міні-FAQ
Де тримати SRE - в платформі або в продуктах?
Гібрид: стратегічний SRE в платформі, embedded-SRE в критичних доменах.
Хто володіє SLO сервісів?
Продуктові команди. SRE забезпечує методологію, tooling і контроль процесу.
Як уникнути «тіньових ІТ»?
Каталог послуг, явні OLAs, швидкий самосервіс і прозорі ціни (showback/chargeback).
Підсумок
Сильна інфраструктурна функція - це чіткі ролі + продуктовий підхід до платформи + домовленості по інтерфейсам і метрикам. Зафіксуйте RACI і OLAs, дайте самосервіс і стандарти, вимірюйте ефективність по KPI кожної ролі і регулярно покращуйте DevEx, SLO і вартість. Це знизить операційні ризики, прискорить релізи і зробить інфраструктуру передбачуваною.