Ролі та обов'язки в операціях

1) Навіщо формалізувати ролі

Чіткий розподіл ролей знижує MTTA/MTTR, усуває «сірі зони», прискорює релізи і робить відповідність SLO/комплаєнсу відтворюваним. Ролі = відповідальність + повноваження + інтерфейси (кому пишемо, кого ескалуємо, які рішення уповноважені).

2) Базова RACI-модель

R (Responsible) - виконує роботу.
A (Accountable) - несе підсумкову відповідальність і приймає рішення.
C (Consulted) - експерт, консультується до/під час.
I (Informed) - інформується по SLA.

3) Каталог ролей (описи та обов'язки)

3. 1 Incident Commander (IC)

Мета: керує відповіддю на інцидент SEV-1/0.
Повноваження: оголошувати SEV, заморожувати релізи, перемикати трафік, ескалувати.
Основні завдання: таймлайн, прийняття рішень, утримання фокусу, розподіл завдань, Go/No-Go.
Артефакти: картка інциденту, апдейти по SLA, підсумковий AAR.

3. 2 P1/P2 On-Call (Primary/Secondary)

Мета: первинний відгук і технічні дії.
P1: тріаж, запуск плейбуків, зв'язок з IC.
P2: бекап, складні зміни, утримання контексту, при штормах - бере сабпотоки.

3. 3 SRE / Platform Engineer

Мета: надійність платформи і перила (SLO, алерти, GitOps, автоскейл, DR).
Завдання: SLI/SLO, алерт-гігієна, прогресивні релізи, інфраструктура як код, capacity, observability.
Під час інциденту: діагностика кореня, відкати/фолбеки, включення degrade-UX.

3. 4 Service Owner / Product Owner

Мета: якість сервісу в бізнес-сенсі.
Завдання: визначення SLO/пріоритетів, узгодження релізів/вікон, участь в Go/No-Go.
Коммс: рішення, коли і що говорити клієнтам разом з Comms.

3. 5 Release Manager

Мета: безпечна доставка змін.
Завдання: оркестрація релізів, чекап гейтів, канарка/blue-green, анотації релізів, freeze при інцидентах.

3. 6 CAB Chair / Change Manager

Мета: управління ризиком змін.
Завдання: процес RFC, план/backout, календар конфліктів, схвалення high-risk.

3. 7 RCA Lead / Problem Manager

Мета: пост-інцидентний розбір, CAPA.
Завдання: таймлайн, доказова причинність, дії виправити/запобігти, контроль D + 14/D + 30.

3. 8 Security (IR Lead, AppSec/CloudSec)

Мета: безпека і реагування на інциденти безпеки.
Завдання: triage security-подій, ротація ключів, ізоляція, форензика, регуляторні повідомлення, WORM-аудит.

3. 9 DataOps / Analytics

Мета: надійність даних і пайплайнів.
Завдання: свіжість/якість (DQ), контракти даних, lineage, бекфіли, SLA BI/звітів.

3. 10 FinOps

Мета: Керована вартість.
Завдання: квоти/ліміти, звіти $/одиницю, бюджетні гейти, оптимізації (лог-обсяги, egress, резервування).

3. 11 Compliance / Legal

Мета: відповідність регуляториці та контрактам.
Завдання: терміни повідомлень, ретенції/незмінюваність evidence, узгодження публічних текстів.

3. 12 Support / Comms

Мета: комунікації з клієнтами/внутрішніми стейкхолдерами.
Завдання: статус-сторінка, макети апдейтів, частота і ясність повідомлень, збір зворотного зв'язку.

3. 13 Vendor Manager / Provider Owner

Мета: відносини із зовнішніми провайдерами (PSP/KYC/CDN тощо).
Завдання: ескалації, SLA/OLA, резервні маршрути, координація вікон.

4) Ролі в зміні та ескалації

Зміна: P1/P2 + IC-of-the-day (не поєднувати з P1).
Ескалації за часом: P1→P2 (5 хв без ack) → IC (10 хв) → Duty Manager (15 хв).
Quiet Hours: P2/P3-сигнали не будять; security-сигнали - завжди.

5) Інтерфейси взаємодій (хто з ким і як)

IC ↔ Release Manager: freeze/rollback рішення.
IC ↔ Comms: тексти апдейтів і частота.
SRE ↔ DataOps: бізнес-SLI (успіх платежів, свіжість даних) в SLO-гардрейлах.
Security ↔ Legal: повідомлення про security-інциденти, терміни повідомлень.
Vendor Owner ↔ IC: статус провайдера, switchover/фолбек.

6) KPI за ролями (орієнтири)

IC: Time-to-Declare, дотримання Comms SLA, MTTR по SEV-1/0.
P1/P2: MTTA, Time-to-First-Action,% слідування плейбукам.
SRE/Platform: SLO coverage, Alert Hygiene,% авто-відкатів успішний.
Release Manager: Change Failure Rate, On-time windows, Mean Rollback Time.
RCA Lead: Postmortem Lead Time, CAPA Completion/Overdue, Reopen ≤ 5–10%.
Security: Mean Time to Contain, Secret/Cert Rotation Time.
DataOps: Freshness SLO Adherence, Success Rate бекфілів.
Comms: Status Accuracy, Complaint Rate/інцидент.
FinOps: $/одиницю,% економії QoQ, дотримання квот.

7) Шаблони карток ролей

7. 1 Картка IC

Role: Incident Commander
Scope: SEV-1/0 (prod)
Decisions: declare SEV, freeze deploy, traffic shift, rollback/failover
Runbooks: rb://core/ic, rb://comms/status
SLA: TTD ≤10m, first comms ≤15m, updates q=15–30m
Escalations: Duty Manager (15m), Exec On-call (30m)

7. 2 Картка P1/P2

Role: Primary/Secondary On-call (service: checkout-api)
Runbooks: rb://checkout/5xx, rb://checkout/rollback
Tools: logs, traces, SLO board, feature flags
SLA: Ack ≤5m, first action ≤10m, handover at shift boundaries

7. 3 Картка Release Manager

Role: Release Manager
Gates: tests, signatures, active_sev=none, SLO guardrails green 30m
Strategy: canary 1/5/25%, blue-green optional, auto-rollback on burn
Evidence: release annotations, diff configs, dashboards before/after

8) Процеси та участь ролей (зведення)

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

9) Чек-листи

9. 1 Призначення ролей

• У кожної ролі є власник, заступник і зона покриття.
• Описані повноваження (які рішення може приймати).
• Прив'язані плейбуки і канали зв'язку.
• Опубліковані SLA по реакції/коммс.
• Роль доступна в каталозі (CMDB) у кожного сервісу.

9. 2 Зміна і handover

• Картка зміни оновлена (активні інциденти, ризики, вікна).
• Доступи JIT/JEA перевірені.
• Ехо-повідомлення в канал: «зміна прийнята/здана».

9. 3 Пост-інцидент

• AAR проведений, RCA призначений.
• CAPA з власниками/термінами, D + 14/D + 30 контроль.
• Оновлені плейбуки/алерти/політики.

10) Анти-патерни

Неясне «хто вирішує» → затримки і дублі зусиль.
IC поєднаний з P1 - втрата керівництва.
Публічні коммс без узгодження з Legal/Comms.
Реліз без Release Manager і гейтів → зростання CFR.
Відсутність резервування ролей (хвороба/відпустка).
«Геройство» замість процесу: рятуємо вручну, але не фіксуємо перила.
Ролі не відображені в CMDB/каталозі сервісу → втрачені ескалації.

11) Вбудовування в інструменти

ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.
Каталог/CMDB: у сервісу - власник, on-call, SLO, дашборди, плейбуки, вікна.
Alert-as-Code: у кожного Page є owner і плейбук за замовчуванням.
GitOps: рішення IC/Release відображаються в анотаціях релізів і тікетах.

12) Метрики зрілості розподілу ролей

Coverage ролей в каталогах: ≥ 100% критичних сервісів.
On-call SLA: Ack p95 ≤ 5 хв; Page Storm p95 під контролем.
Postmortem SLA: чернетка ≤ 72ч; CAPA completion ≥ 85%.
Change governance: % high-risk змін з RFC/CAB ≥ 95%.
Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.

13) Міні-шаблони

13. 1 RACI для сервісу (файл в репо)

yaml service: payments-api roles:
owner: team-payments oncall: oncall-payments ic: ic-of-the-day raci:
incident:  {A: ic-of-the-day, R: oncall-payments, C: security,data, I: mgmt,comms}
releases:  {A: release-manager, R: dev,platform, C: security, I: support}
changes:  {A: cab, R: owner, C: sre,security, I: affected-teams}
postmortem: {A: rca-lead, R: owner, C: security,data, I: mgmt}

13. 2 Профіль ролі (Markdown)

Role: Duty Manager
Purpose: Escalation and SEV-1/0
Powers: Assign ICs, reallocate resources, approve freeze
Inputs: # war-room channel, SLO dashboards, IC reports
Outputs: resolutions, post-factual report, CAPA escalations

14) Підсумок

Операції стійкі, коли ролі прозорі, забезпечені повноваженнями і вбудовані в інструменти. Каталог ролей, RACI, чіткі інтерфейси і метрики по кожній ролі перетворюють інциденти, релізи і зміни в керовані процеси: рішення приймаються швидко, ризики контролюються, а користувачі бачать стабільний сервіс.