升級矩陣

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，時間，頻道，安全性例外以及與花花公子和狀態頁的集成，團隊以快速，一致和透明的方式做出反應，用戶可以看到可預測的升級和自信的恢復服務。