行動中的作用和責任

1）為什麼要正式化角色

明確的角色分配減少了MTTA/MTTR，消除了「灰色區域」，加快了發行速度，並使SLO/合規性可重現。角色=責任+權力+接口（我們寫給誰，我們升級誰，授權哪些解決方案）。

2）基本的RACI模型

R （Responsible）-執行工作。
A（Accountable）-承擔最終責任並做出決定。
C（咨詢）-專家,在之前或期間咨詢。
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： triage,啟動花花公子,鏈接到IC。

P2： 備用,復雜的變化,保持上下文,在暴風雨中-采取安全帶.

3.3 SRE / Platform Engineer

目標：平臺和欄桿的可靠性（SLO，Alerta，GitOps，Autoscale，DR）。
任務：SLI/SLO，警報衛生，漸進版本，基礎架構作為代碼，能力，觀察能力。
在事件中：根診斷，回滾/倒退，degrade-UX啟用。

3.4 Service Owner / Product Owner

目的：從商業意義上講服務質量。
任務：確定SLO/優先級，協調發布/窗口，參與Go/No-Go。
Comms：決定何時以及如何與Comms一起告訴客戶。

3.5 Release Manager

目標：安全地交付更改。
任務：編排發行，跳閘門，金絲雀/藍綠色，發行註釋，事件中凍結。

3.6 CAB Chair / Change Manager

目標：管理變更風險。
任務：RFC過程，計劃/後退，沖突日歷，高風險批準。

3.7 RCA Lead / Problem Manager

目的：事後分析，CAPA。
任務：時間線，證據因果關系，糾正/預防行動，D+14/D+30控制。

3.8 Security (IR Lead, AppSec/CloudSec)

目標：安全和應對安全事件。
任務：三元安全事件,鍵輪換,隔離,正交,監管通知,WORM審核。

3.9 DataOps / Analytics

目的：數據和管道可靠性。
任務：新鮮/質量（DQ）,數據合同,線性,後門,SLA BI/報告。

3.10 FinOps

目的：管理成本。
任務：配額/限額，報告$/單位，預算門，優化（日誌卷，egress，冗余）。

3.11 Compliance / Legal

目的：遵守監管和合同。
目標：通知的時間、復審/不可變性、公共文本的協調。

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分鐘）。
安靜時間：P2/P3信號不會醒來；安全信號-總是。

5）交互接口（誰與誰以及如何）

IC ↔發布管理器：freeze/rollback解決方案。
IC ↔ Comms：更新文本和頻率。
SRE ↔ DataOps：SLO Gardrails中的商業SLI（支付成功，數據新鮮）。
安全↔法律：安全事件報告，通知時間。

Vendor Owner ↔ IC： 提供商身份,switchover/folback.

6）KPI按角色（地標）

IC：時間到決定，Comms SLA遵守，MTTR SEV-1/0。
P1/P2：MTTA，時間到第一動作，播放次數百分比。
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 backfills。
Comms： Status Accuracy, Complaint Rate/Event。
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發行管理卡

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 根據反應/comms發布。
• 該角色可在每個服務的目錄（CMDB）中使用。

9.2輪班和搬家

• 輪班卡已更新（活動事件、風險、窗口）。
• JIT/JEA訪問已驗證。
• 回聲到通道的消息是：「接受/放棄更改。」

9.3事後事件

• 舉行了AAR，任命了RCA。
• CAPA擁有所有者/截止日期，D+14/D+30控制。
• 更新了花花公子/alerta/policies。

10）反模式

不清楚的「誰決定」→延誤和努力。
IC與P1配對-領導力喪失。
未與Legal/Comms協調的公共公社。
沒有Release Manager和門的版本→ CFR的增長。
不保留角色（疾病/休假）。
「英雄主義」而不是過程：我們用手營救，但不固定欄桿。
角色未反映在CMDB/服務目錄 →丟失的升級中。

11）嵌入工具

ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.

目錄/CMDB：服務包括所有者、呼叫、SLO、行車記錄儀、花花公子、窗口。
警報作為代碼：每個Page都有默認的owner和花花公子。
GitOps： IC/Release解決方案反映在發布註釋和字幕中。

12）角色分配成熟度度量

目錄中的角色覆蓋：≥ 100%的關鍵服務。
通話SLA：Ack p 95 ≤ 5分鐘；Page Storm p95已得到控制。

Postmortem SLA： 草稿≤ 72小時；CAPA completion ≥ 85%.

變革管理：RFC/CAB的高風險變化百分比≥ 95％。

Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.

13）迷你模板

13.1 RACI for service （repo文件）

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，每個角色的清晰界面和度量標準將事件，發布和更改轉換為托管流程：快速做出決策，控制風險，用戶看到穩定的服務。