Роли и обязанности в операциях

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