"Incident-Response"
- Atlassian 2022 April Multi-tenant Deletion Outage
2022-04 Atlassian 因維運腳本誤刪多租戶站點造成長時間事故的解析：恢復分批、跨團隊指揮與對外通訊節奏。
- AWS S3 2017 US-EAST-1 Service Disruption
2017-02-28 AWS S3 us-east-1 事故解析：內部操作命令、index / placement 子系統重啟、區域依賴擴散與狀態頁依賴回寫。
- Cloudflare 2019 Regex CPU Outage
2019-07-02 Cloudflare WAF 規則更新導致全球 CPU 飆升的事故解析：觸發條件、擴散機制、止血決策與可回寫控制面。
- Fastly 2021 June Global Edge Config-triggered Outage
2021-06-08 Fastly 全球 edge 事故解析：有效客戶配置觸發潛藏 bug、分鐘級擴散與快速隔離恢復。
- GCP 2019 US Network Congestion Multi-service Incident
2019-06-02 Google Cloud 因美國區域網路壅塞造成多服務退化的事故解析：跨產品依賴、流量控制與區域隔離判讀。
- GitHub 2018 Oct21 MySQL Topology Incident
2018-10-21 GitHub 因 network partition 觸發跨區資料庫拓撲異常的事故解析：資料一致性優先、fail-forward 決策與長時間恢復。
- Roblox 2021 Oct Prolonged Core Infra Outage
2021-10 Roblox 長時間平台中斷的事故解析：核心基礎設施壓力失衡、根因定位延遲與長尾恢復。
- 8.1 事故分級與啟動條件
建立統一分級標準與事故啟動門檻
- AWS 2021 US-EAST-1 Control Plane Degradation
2021-12-07 AWS us-east-1 控制面退化案例：內部網路壅塞、API 錯誤率升高、跨服務依賴連鎖與通訊節奏調整。
- Cloudflare 2023 Control Plane Token Incident
2023-01-24 Cloudflare service token 錯誤變更導致多產品連鎖影響的事故解析：信任邊界、擴散機制、止血策略與流程回寫。
- 8.2 事故指揮與角色分工
定義 incident commander 與跨角色協作責任
- AWS：Control Plane 事故的責任邊界與通訊節奏樣式（2023）
以 AWS 2023 年公開事件樣式為主，整理 control plane 退化時如何建立責任邊界、決策紀錄與對外更新節奏。
- Cloudflare 2026 BYOIP BGP Withdrawal
2026-02-20 Cloudflare BYOIP prefixes 被非預期撤告的事故解析：Addressing API bug、BGP withdrawal、狀態恢復與控制面回寫。
- 8.3 止血、降級與回復策略
把短期止血與正式回復拆成可執行步驟
- Cloudflare 2023 Workers KV Deployment Tool Misconfiguration
2023-10-30 Cloudflare 控制面事故：deployment tool 設定錯誤造成 Workers KV 連鎖影響，重點在變更範圍限制與決策回寫。
- 8.4 事故通訊與狀態更新
建立內外部通報節奏與狀態更新格式
- 8.5 復盤與改進追蹤
把 RCA 與 action items 轉成可驗證閉環
- 8.6 演練與值班能力建設
用演練與值班訓練提升事故反應品質
- 8.7 失敗模式審查（Failure Mode Audit）
以概念層判讀事故流程弱點，聚焦分級、指揮、回復與交接節奏
- 8.9 事故型態庫入口
把跨服務的共通事故型態抽成型態卡，作為新事故的判讀錨點
- 8.10 Stakeholder 通訊與外部狀態頁
把 impact scope、status page、補償政策串成節奏
- Slack：2022 連線恢復與狀態通訊節奏
在通訊平台自身失效時，如何同步恢復節奏與對外狀態揭露。
- 8.11 Observability / Reliability / Incident Response 閉環
把 04 / 06 / 08 三個模組的雙向反饋串成可判讀循環，定義閉環健康度判讀訊號
- 0.12 觀測、可靠性與事故服務選型
從訊號、驗證與響應三層能力判斷操作控制服務的選型順序
- 8.12 IC Handoff 與長事故跨班次協調
把 24h+ / 跨 timezone 事故的接班節奏變成可重複流程
- 0.13 操作控制 vertical slice 實作入口
用一個服務串起觀測證據、可靠性驗證、事故決策與回寫閉環
- 8.13 Repeated Incident 與 Toil 治理
把同型事故反覆發生與重複手動修復作為工程化治理對象
- 8.14 Multi-incident Coordination
把同時多事故的優先序、資源分配與 incident command system pool 協調變成可執行流程
- 8.15 Vendor / 第三方依賴事故處理
依賴方掛掉、自己無 control 時的決策模型
- 8.16 Runbook Lifecycle 管理
把 runbook 從一次性文件變成有版本、有演練、會過期的 artifact
- 8.17 Security Incident vs Operational Incident 分流
把資安事故跟可用性事故的 IR 流程分支點明確化
- 8.18 Incident Intake & Evidence Triage
把告警、客訴、支援回報與第三方狀態轉成同一個 intake / evidence 判讀流程
- 8.19 Incident Decision Log
把事中假設、決策、證據、回退條件與責任人留下可復盤紀錄
- 8.20 Customer Impact Assessment
把受影響用戶、功能、區域、金額、SLO 與補償判斷串成影響評估模型
- Datadog：2023 多區觀測中斷事件
監控平台自身退化時，如何避免客戶誤判系統健康狀態。
- 8.21 Incident Workflow Automation Boundary
定義哪些事故流程適合自動化，哪些決策需要保留人工確認
- 8.22 Incident Evidence Write-back
把事故證據、決策與復盤結論回寫到 observability、reliability 與 runbook
- 8.23 Control Plane Decision Log and Write-back 實作示範
以 rule/config rollout 事故示範 decision log 與 write-back 如何形成可回放閉環。
- Discord：Gateway 容量事件與恢復節奏
長連線平台在容量邊界被擊穿時，如何控制擴散並分批恢復。
- Azure AD：2021 身分控制面中斷事件
身分服務失效時，如何評估跨產品影響與收斂優先序。
- Heroku：Routing 控制事件與多租戶影響
PaaS 路由層異常時，如何限制租戶擴散並維持可用通訊。
- Reddit：2023 Kubernetes 升級事故
平台升級變更如何觸發服務退化，以及如何設計可回退的升級策略。
- Microsoft 365：套件級身分驗證事故
企業套件在身份依賴失效時，如何同步處理跨產品影響與對外揭露。
- 8.8 事故報告轉 workflow：從案例到日常流程
把事故報告拆成可執行流程，並與 red-team 案例庫建立雙向引用
- Runbook
說明 runbook 如何把事故判斷與操作步驟標準化
- Incident Timeline
說明事故時間線如何支援判斷、溝通與復盤
- Fail-forward
說明無法回到舊狀態時如何用受控前進完成修復
- Stop Condition
說明變更、實驗或事故處理何時必須暫停、回退或改路線
- Rollback Condition
說明決策執行後出現哪些訊號時要撤回、回退或改路線
- On-Call
說明值班制度如何承接告警、事故分級與升級流程
- Ownership
說明 ownership 如何把問題、決策與交接責任固定到可執行角色
- Action Item Closure
說明事故行動項如何被驗證完成，而不是只停留在待辦清單
- Time Range
說明證據、查詢與事故判讀如何用時間窗保留可回放上下文
- Query Link
說明證據包如何保存可重跑查詢入口，而不是只保留截圖或口頭結論
- Data Quality
說明證據欄位如何標示 completeness、freshness、sampling 與資料限制
- Confidence
說明證據包如何標示 confirmed、suspected 或 needs follow-up 的判讀信心
- Known Gap
說明證據包如何明確保存已知缺口，避免下游高估證據完整性
- 7.B6 Incident Triage Loop
把資安訊號轉成 triage、severity、owner、containment 與 evidence 的回應循環
- NIST SP 800-61r3：事故回應作為風險管理能力
把 NIST SP 800-61r3 轉成藍隊事故回應與風險治理素材
- CISA Playbooks：事故與漏洞回應程序
把 CISA incident and vulnerability response playbooks 轉成藍隊流程素材
- CISA GeoServer 2024：IR 協調壓力
把 CISA GeoServer incident response lessons learned 轉成修補、EDR、IR plan 與第三方協調壓力素材
- Atlassian Statuspage → Instatus：status page 成本下降、但 compatibility audit 不能跳
Atlassian Statuspage → Instatus 是 Type B drop-in migration、6 維 audit 全 Low；典型情境是從 Statuspage Business / Enterprise 降到 Instatus Pro / Business、但 savings 取決於 subscriber、SSO、audit 與 SLA report 需求。本文走 compatibility audit prefix（subscriber channel 完整度 / SAML SSO / audit log / metrics integration / SLA report / API parity）、4 階段 cutover（DNS TTL + parallel run）、5 個 production 踩雷（SSO tier 選錯、metrics 來源整合斷、subscriber import format / SLA report 缺、custom CSS 不完全相容）、何時不要切（enterprise compliance / 強 Atlassian 整合）
- PagerDuty → incident.io：「On-call」是個 retconned word、同名不同 contract
PagerDuty → incident.io 不是 schema translation — 兩家的「on-call」字面相同、contract 不同（alert routing vs IR coordination + Slack-native + retrospective）。本文走 Type E paradigm shift、6 維 audit 顯示 paradigm / schema / operational 三軸 High、用 4-phase partial migration（不收斂、Phase 1-2 多數 org 停留）、5 個 production 踩雷（雙系統 state drift / severity 翻譯失真 / schedule layer 漏 / Slack channel 過載 / retrospective 斷層）、跟 PagerDuty Process Automation / AIOps 沒對應的 capability gap
- PagerDuty → Opsgenie：Atlassian 全家桶整合 vs Opsgenie 2027 EOL 的 vendor consolidation 取捨
PagerDuty → Opsgenie 是 Type A phased schema translation、但 Atlassian 已宣布 Opsgenie 2027-04 EOL — 這條 migration 只在 Atlassian-heavy org + 明確 JSM unification roadmap 下成立、本質是 PD → Opsgenie → JSM Cloud 的雙 hop migration。本文走 6 維 audit（Schema Medium-High 其他 Low）、PagerDuty ↔ Opsgenie ↔ JSM field mapping 對照、5 production 踩雷（escalation step / Heartbeat 缺對應 / integration key dedup 重設 / schedule 時區 / Atlassian Identity SSO 整合）、何時直接走 PD → JSM 跳過 Opsgenie