行动中的作用和责任
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 boundaries7.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/after8）流程和角色参与（摘要）
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 escalations14）结果
当角色透明，授权并嵌入工具时，操作是可持续的。角色目录，RACI，每个角色的清晰界面和度量标准将事件，发布和更改转换为托管流程：快速做出决策，控制风险，用户看到稳定的服务。