例行維護出大事：Optus 升級防火牆，救護車叫不到 13 小時

例行維護出大事：Optus 升級防火牆，救護車叫不到 13 小時 目錄 1. 事件始末 2. 「例行作業」為什麼最危險 3. 三個讓例行維護變成事故的模式 4. Change Management 的 QA 視角 5. 你的團隊在做例行維護前，有這份清單嗎 事件始末 2025 年 9 月，澳洲電信商 Optus 在執行一次「例行防火牆升級」時，工程師選錯了 process plan。 這個錯誤讓澳洲的緊急救援電話 Triple Zero（000）——也就是台灣的 119/110——對數萬名 Optus 用戶斷線了 13 個小時 。 13 個小時裡，有人心臟病發作打不通救護車，有人遭遇意外連不到警察，有人家裡起火卻無法呼叫消防隊。 這不是被駭客攻擊，不是硬體故障，不是自然災害。 是一個人選錯了一份文件。 「例行作業」為什麼最危險 軟體工程界有一個說法： 大多數的生產事故，不是來自複雜的新功能，而是來自「我以為我知道怎麼做」的例行操作。 DORA 2024 年報告將 變更失敗率（change failure rate） 列為衡量工程效能的四大核心指標之一。低效能團隊的變更失敗率高達 46 64%，而其中相當高比例的事故根源，正是缺乏嚴格管控的例行變更——而非新功能開發。 這背後有幾個心理因素： 熟悉感降低了警覺性 你做過 50 次資料庫備份，第 51 次你不會仔細確認每個步驟，因為你「知道要怎麼做」。但這次的環境參數跟上次不同，或是文件有更新版本，你沒有發現。 例行作業通常沒有完整的 review 流程 新功能上線要 code review、QA 測試、staging 驗證、上線計畫。 例行維護呢？很多時候是一個人登進去、執行指令、確認沒有明顯錯誤、收工。 回滾計畫是最容易被省略的 新功能上線前，大家會問：「如果出問題，怎麼回滾？」 例行維護前，很少人問這個問題。因為「這只是例行作業，不會出問題。」 三個讓例行維護變成事故的模式 模式一：選錯版本或文件 Optus 的事故就是這個——工程師選了錯誤的 process plan。 這類錯誤在有多個版本文件、多個環境（生產/測試/staging）、多個類似命名的 script 的系統裡特別常見。 模式二：在高風險時間點執行維護 Barclays 在發薪日（月底）銀行系統當機，就是在最不該出問題的時間點發生問題。 很多例行維護沒有「這個時間點可以動嗎」的評估機制，工程師有空就做，不考慮業務影響。 模式三：沒有 rollback 計畫，或 rollback 也失敗 防火牆設定改了之後發現有問題，但回滾的步驟沒有事先準備好。回滾本身也需要時間，而這段時間裡系統繼續掛著。 Change Management 的 QA 視角 「Change Management」聽起來是系統管理員和 DevOps 的事，但 QA 在這裡能貢獻的比大多數人以為的多。 QA 可以問的問題： 在變更計畫被批准之前： 這個變更的影響範圍是什麼？哪些服務、哪些功能可能受影響？ 這個時間點適合做這個變更嗎？（即將上線、節日前後、流量高峰期） 執行的 SOP 文件是最新版本嗎？有沒有環境差異需要注意？ 在變更執行前： 有沒有在 staging 或低風險環境先跑過？ 執行人和覆核人有沒有確認每個步驟？ Rollback plan 是什麼？Rollback 需要多長時間？ 在變更執行後： 有沒有 smoke test 確認核心功能正常？ 有沒有監控指標顯示異常？ 如果 15 分鐘後發現問題，誰負責執行 rollback？ 這些問題不需要 QA 進去跑測試，但讓這些問題在流程裡被問到，是 QA 對品質最直接的貢獻之一。 你的團隊在做例行維護前，有這份清單嗎 Optus 的工程師不是不專業，是整個流程沒有讓「選錯文件」這個人為錯誤有機會被攔下來。 Checklist 的存在，不是在懷疑執行者的能力，是在對抗人類在例行作業中天生的注意力下滑。 參考資料 1. TestDevLab — 9 Biggest Software Bugs of 2025 （Optus Triple Zero 事件）：https://www.testdevlab.com/blog/software bugs 2025 2. DORA — 2024 State of DevOps Report （change failure rate 指標與 Change Management 相關性）：https://dora.dev/research/2024/dora report/ 3. Google SRE Book — Managing Incidents ：https://sre.google/sre book/managing incidents/ 4. Martin Fowler — Continuous Delivery （部署前的驗證與 rollback 計畫）：https://martinfowler.com/books/continuousDelivery.html 5. Agile Alliance — Definition of Done ：https://www.agilealliance.org/glossary/definition of done/