Atlassian on Tarragonhttps://tarrragon.github.io/blog/backend/08-incident-response/cases/atlassian/Recent content in Atlassian on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 01 May 2026 00:00:00 +0000Atlassian 2022 April Multi-tenant Deletion Outagehttps://tarrragon.github.io/blog/backend/08-incident-response/cases/atlassian/2022-april-multi-tenant-deletion-outage/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/atlassian/2022-april-multi-tenant-deletion-outage/<p>Atlassian 2022 事故的核心教訓是：在多租戶 SaaS 中，誤刪不只是一個資料問題，而是恢復編排、客戶通訊與跨團隊協調同時失效的系統級事件。</p> <h2 id="事故摘要">事故摘要</h2> <p>Atlassian 官方 PIR 指出，2022-04-05 起有 775 客戶受影響，部分恢復歷時長達 14 天。事故起因是維運腳本使用了錯誤識別資訊，導致站點被刪除，後續需要多工作流並行恢復與驗證。</p> <p>事件特徵是「影響客戶數有限，但每一個客戶的恢復成本高」，因此恢復策略必須分批與分層。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>事故中代表什麼</th> <th>第一波決策價值</th> </tr> </thead> <tbody> <tr> <td>客戶站點直接不可用</td> <td>已是 tenant 級資料生命週期事件</td> <td>立即升級 major incident</td> </tr> <tr> <td>恢復進度呈現長尾分布</td> <td>不同租戶恢復難度差異大</td> <td>改分批恢復與分層追蹤</td> </tr> <tr> <td>初期通訊管道壓力高</td> <td>客戶影響與資訊需求同步上升</td> <td>固定通訊節奏，區分已知事實與待確認項</td> </tr> <tr> <td>後續發現部分資料恢復點不一致</td> <td>恢復策略與資料一致性治理待補</td> <td>增加恢復後審核與補救流程</td> </tr> </tbody> </table> <h2 id="事故路徑">事故路徑</h2> <ol> <li>維運腳本操作錯誤導致多租戶站點被刪除。</li> <li>客戶無法存取產品並建立支援事件。</li> <li>事故升級後成立跨職能指揮團隊，24x7 推進恢復。</li> <li>恢復以分批方式進行，並持續更新 status 與客戶通訊。</li> <li>事後回寫到 soft delete、恢復自動化與通訊流程改善。</li> </ol> <h2 id="可回寫控制面">可回寫控制面</h2> <table> <thead> <tr> <th>控制面</th> <th>這次事故暴露的缺口</th> <th>回寫方向</th> </tr> </thead> <tbody> <tr> <td>Script safety guardrail</td> <td>腳本輸入與刪除對象校驗不足</td> <td>高風險刪除操作增加雙重驗證與範圍確認</td> </tr> <tr> <td>Multi-tenant restore orchestration</td> <td>大規模租戶恢復缺少標準化分批流程</td> <td>建立恢復編排工具與租戶優先序模型</td> </tr> <tr> <td>Data restoration consistency</td> <td>恢復點一致性在早期流程中不穩</td> <td>增加恢復後一致性審核與回補流程</td> </tr> <tr> <td>Incident communication resilience</td> <td>長事故中的客戶通訊節奏與聯絡資料治理</td> <td>固定 cadence、改善受影響客戶聯絡資訊可得性</td> </tr> </tbody> </table> <h2 id="下一步路由">下一步路由</h2> <ul> <li>事故通訊： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-communication/" data-link-title="8.4 事故通訊與狀態更新" data-link-desc="建立內外部通報節奏與狀態更新格式">8.4 Incident Communication</a></li> <li>客戶影響評估： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/customer-impact-assessment/" data-link-title="8.20 Customer Impact Assessment" data-link-desc="把受影響用戶、功能、區域、金額、SLO 與補償判斷串成影響評估模型">8.20 Customer Impact Assessment</a></li> <li>事中決策紀錄： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-decision-log/" data-link-title="8.19 Incident Decision Log" data-link-desc="把事中假設、決策、證據、回退條件與責任人留下可復盤紀錄">8.19 Incident Decision Log</a></li> <li>證據回寫流程： <a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-evidence-write-back/" data-link-title="8.22 Incident Evidence Write-back" data-link-desc="把事故證據、決策與復盤結論回寫到 observability、reliability 與 runbook">8.22 Incident Evidence Write-back</a></li> <li>穩態與恢復完成： <a href="https://tarrragon.github.io/blog/backend/06-reliability/steady-state-definition/" data-link-title="6.22 Steady State Definition" data-link-desc="在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化">6.22 Steady State Definition</a></li> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://www.atlassian.com/blog/atlassian-engineering/post-incident-review-april-2022-outage">Post-Incident Review on the Atlassian April 2022 outage</a></li> <li><a href="https://www.atlassian.com/blog/atlassian-engineering/april-2022-outage-update">Update on the Atlassian outage affecting some customers</a></li> </ul>Atlassian 2022 事故的核心教訓是：在多租戶 SaaS 中，誤刪不只是一個資料問題，而是恢復編排、客戶通訊與跨團隊協調同時失效的系統級事件。

事故摘要

Atlassian 官方 PIR 指出，2022-04-05 起有 775 客戶受影響，部分恢復歷時長達 14 天。事故起因是維運腳本使用了錯誤識別資訊，導致站點被刪除，後續需要多工作流並行恢復與驗證。

事件特徵是「影響客戶數有限，但每一個客戶的恢復成本高」，因此恢復策略必須分批與分層。

判讀訊號

訊號 事故中代表什麼 第一波決策價值
客戶站點直接不可用 已是 tenant 級資料生命週期事件 立即升級 major incident
恢復進度呈現長尾分布 不同租戶恢復難度差異大 改分批恢復與分層追蹤
初期通訊管道壓力高 客戶影響與資訊需求同步上升 固定通訊節奏，區分已知事實與待確認項
後續發現部分資料恢復點不一致 恢復策略與資料一致性治理待補 增加恢復後審核與補救流程

事故路徑

  1. 維運腳本操作錯誤導致多租戶站點被刪除。
  2. 客戶無法存取產品並建立支援事件。
  3. 事故升級後成立跨職能指揮團隊，24x7 推進恢復。
  4. 恢復以分批方式進行，並持續更新 status 與客戶通訊。
  5. 事後回寫到 soft delete、恢復自動化與通訊流程改善。

可回寫控制面

控制面 這次事故暴露的缺口 回寫方向
Script safety guardrail 腳本輸入與刪除對象校驗不足 高風險刪除操作增加雙重驗證與範圍確認
Multi-tenant restore orchestration 大規模租戶恢復缺少標準化分批流程 建立恢復編排工具與租戶優先序模型
Data restoration consistency 恢復點一致性在早期流程中不穩 增加恢復後一致性審核與回補流程
Incident communication resilience 長事故中的客戶通訊節奏與聯絡資料治理 固定 cadence、改善受影響客戶聯絡資訊可得性

下一步路由

引用源

]]>