網站出問題，先看最後一次部署是很自然的反應。但如果今天根本沒部署呢？前端沒改，API 沒改，連設定都沒動，使用者還是進不來。這時候「我這邊沒問題」大概是最沒有用、卻又可能完全屬實的一句話。
2025 年 10 月 20 日的 AWS 事故，就讓我想到這種無奈。雲端幫我們省掉了很多自己管理機器的工作，但網站到底依賴了多少東西，平常真的不太容易感覺到。往往是其中一個地方停下來，才發現原來那麼多功能都會跟著卡住。
這次起點在美國北維吉尼亞的 us-east-1 區域。依 AWS 的事故報告，DynamoDB 的自動 DNS 管理出了問題：兩個更新流程在特定時序下互相影響，舊設定覆蓋了新設定，後續清理又讓服務端點的位址紀錄被清空。
資料不見了嗎？倒不是。程式知道要找 DynamoDB，但 DNS 沒有回給它可連線的位址，就像知道對方的名字，通訊錄裡的號碼卻空了。新的連線建立不起來，依賴它的流程也就接著出問題。
我看報告時最在意的是後半段：DNS 修好後，事情沒有立刻結束。部分 EC2 管理流程先前已經累積大量待處理工作，恢復過程又有自己的阻塞。原本就在執行的 EC2 主機不一定有事，建立新主機等操作卻仍受到影響。故障的範圍和恢復的順序，比一句「AWS 掛了」複雜很多。
使用者不會替我們區分是哪一家壞了#
假設商品頁還能看，結帳卻一直轉圈圈，使用者只會覺得這個網站壞了。他不需要知道後面是哪個 AWS 服務，更不會因為我們沒部署就比較有耐心。
這也是前端還能做事的地方。購物車和已填好的內容能不能保留？現在是暫時無法送出，還是已送出、結果尚未確認？這兩種狀況，畫面不能都只寫「發生錯誤，請重試」。
尤其是付款，逾時不代表伺服器沒收到。它可能已經完成處理，只是回應沒有順利回來。如果使用者一直按，我們也一直重送，原本的等待問題就可能變成重複交易。前端需要等待確認的狀態，後端也要能查詢結果、避免重複處理。這是假想的購物網站，但光把這個情境想完整，就知道錯誤處理不是補個紅字而已。
看完這種事故，很容易想說乾脆多放一家雲端。但兩份資料怎麼同步、什麼時候切換、切過去到底能不能用，又是一批需要維護的問題。我會先把網站真正依賴的服務列出來，試著關掉其中一個，看看畫面剩下什麼。要是最後只剩一個不會停的 spinner，那至少先從那裡改起。