升级矩阵

1）矩阵分配

• SEV水平及其标准；
• 计时（检测→ ack →升级→升级）；
• 每个步骤的角色/渠道；
• 例外（安全性和合规性没有"安静时钟"）；
• 与花花公子和状态页的捆绑。

2）重度分类（SEV）

指定您的域和SLO下的目标数字。

3）"何时/何地"基本矩阵"

4）升级的关键树（精髓）

1.SLO上有已确认的冲击吗?

→是：指定IC，宣布SEV，打开战争室。
→不：门票/观察，没有分页。

2.按时有ACK吗?

→是：继续玩花花公子。
→否：P2 → IC → DM（时间林地）。

3.安全/泄漏/PII？

→始终是安全IR+法律，公共消息是一致的。

4.外部提供商?

→ Vendor Owner升级，路线切换，状态假。

5）在升级中的角色和责任（简称）

P1（小学）：三重奏，花花公子开始，与IC的联系。
P2（二级）：备用、复杂动作、上下文保留。
IC（事件指挥官）：宣布SEV，解决freeze/rollback，保持节奏。
Duty Manager：解除锁定、重新分配资源、做出组织决策。
Comms：状态页面，SLA更新。
安全IR：隔离，正式，法律通知。
Vendor Owner：外部提供商,switchover/fallback。

6）临时海德（地标）

SEV-1/0: ACK ≤ 5 м, Declare ≤ 10 м, First Comms ≤ 15 м, Updates q=15–30 м.

升级林地：P1→P2 （5m） → IC （10m） → Duty Manager （15m） → Exec on call （30m）。
安全：没有延误和"安静时间"，后期q=15 m。

7）路由和细分

通过服务/区域/tenant：路由密钥="服务+区域+tenant"。
探头法定人数：只有在确认≥2独立来源（来自2个区域的synthetic+RUM/business SLI）时才升级。
Dedup：一个主警报而不是数十种症状（DB"红色"干扰5xx噪声）。

8）例外和特殊制度

安全/法律：安全性IR和法律升级脱队；公共文本只能通过协调。
提供者：一个单独的OLA/SLA矩阵（联系人、时区、优先级）。
Change Freeze： SEV-1/0时-自动冻结版本和configs。

9）矩阵成熟度度量

Ack p95（SEV-1/0）≤ 5分钟。
时间到决定（中位）≤ 10分钟。

Comms SLA Adherence ≥ 95%.

逃逸成功（决定为P1/P2级）≥ 70％。

No-ACK escalations ↓ QoQ.

Vendor Response Time在合同范围内的关键提供商中。

10）支票单

可操作（用于呼叫）

• 已确定对SLO和潜在SEV的影响。
• 成为ACK并指定为IC（用于SEV-1/0）。
• 打开战争室，附有花花公子。
• 状态升级已在SLA下发布/计划。
• 启用freeze（如果需要）,升级提供商/安全性。

处理器（每周审查）

• 升级梯子是否在SLA上运行？
• IC之前没有额外的升级吗？
• 客户通知是否及时准确?
• 是否存在阻止器（访问，提供商联系人，"静音"频道）？
• 过程失败的CAPA也已启动。

11）模板

11.1升级政策（YAML想法）

yaml policy:
sev_levels:
- id: SEV-0 declare_tgt_min: 5 first_comms_min: 10 update_cadence_min: 15
- id: SEV-1 declare_tgt_min: 10 first_comms_min: 15 update_cadence_min: 30 ack_sla_min:
default: 5 ladder:
- after_min: 5 escalate_to: "P2:oncall-<service>"
- after_min: 10 escalate_to: "IC:ic-of-the-day"
- after_min: 15 escalate_to: "DutyManager:duty"
- after_min: 30 escalate_to: "Exec:oncall-exec"
channels:
war_room: "#war-room-<service>"
alerts: "#alerts-<service>"
security: "#sec-war-room"
providers: "vendors@list"
quorum:
required_sources: 2 sources: ["synthetic:eu,us", "rum:<service>", "biz_sli:<kpi>"]
exceptions:
security: { quiet_hours: false, legal_approval_required: true }
providers: { auto_switch: true, notify_vendor_owner: true }

11.2卡"时间升级"（适用于机器人）

T + 05m: no ACK → escalated to P2
T + 10m: no ACK/Declare → escalated to IC, war-room open
T + 15m: no Comms → reminder Comms, escalation Duty Manager
T + 30m: no Updates → IC reminder, Exec on-call CC

11.3首次公开升级模板

Impact: [services/regions] affected, [symptoms e.g. delays/errors].
Reason: Investigating; confirmed by monitoring quorum.
Actions: bypass routes/restrictions are enabled, provider switching is in progress.
Next update: [time, time zone].

12）整合

警报作为代码：每个页面规则都恰好引用一个花花公子，并且知道其升级矩阵。
ChatOps：命令'/declare sev1'，'/page p2'，'/status update'，自动更新计时器。
CMDB/目录：服务包括所有者、呼叫、矩阵、提供商、频道。
状态页：SEV-1/0模板、更新历史记录、指向RCA的链接。

13）反模式

"我们立即升级所有人"→噪音和模煳的责任。
没有IC/战争室-解决方桉遍布聊天室。
第一个升级的延迟是投诉和公关风险的增加。
安全性没有例外-法律风险。
没有所有者和联系人的外部提供商。
楼梯不是自动化的-所有的"在手柄上"。

14）实施路线图（3-5周）

1.奈德。1：记录SEV标准和计时；收集角色/提供商的联系人；选择渠道。
2.奈德。2：描述政策（YAML），绑定警报作为代码，在寻呼机/机器人中包括树木。
3.奈德。3：2-3项关键服务的飞行员；调试Comms SLA和模板。
4.奈德。4-5：扩大覆盖范围，引入每周逃逸评论和成熟度量标准。

15）结果

升级矩阵是事件的操作宪法：谁，何时以及如何连接。凭借清晰的SEV，时间，频道，安全性例外以及与花花公子和状态页的集成，团队以快速，一致和透明的方式做出反应，用户可以看到可预测的升级和自信的恢复服务。