簡單覆盤一下 AWS 這次事件作為一個 AIGC Startup SRE 的一些操作吧，希望能幫到大家 從入職開始發現我們主要的集群在 USE1 之後，我就開始做一些準備了。 我主要做的事情有這幾件事 1. 將我們核心的幾個數據庫做了多地的備份，形成了 USE1，Tokyo，SG 三地備份。這樣在極端情況下，我們損失一部分數據，但是也能保證服務的繼續 2. 將我們 SG 的測試集群從原本的 EC2 自己簡單搭的 K3S，重構為了一個標準的 AWS EKS 集群。這樣可以在災害時刻快速 warmup 一個集群，複用 AWS 已有組件。將 manifest 變更的代價降至最小 3. 簡單梳理了一個 SOP，包含用戶公告，DNS 切換，封版等事宜 回到今天，我大概在 AWS 事故發生後的10min，發現了我們容器中有新的 Pod 無法 setup。 在和 AWS 支持確認是 USE1 的問題後，我意識到 ECR 的事件必然關聯其餘事件，於是我就果斷按照我自己規劃的 Tier1 等級事件開始處理（對於 SRE 來說，這種事情寧可錯，但是不能錯過） T+0 min，我發佈了全員公告，開始進入緊急模式。我 setup 了一個全員公開會議。所有人員可以隨時加入 T+2 min，我確認事件如我所預期的一樣，在逐漸擴大，我發出了兩個指令，1. 全線禁止任何代碼合入/提交（主要是避免新創建資源會導致 Pod rotate 進而影響流量），2. 請運營同學準備公告 T+3 min, 我開始按照 SOP，開始進行數據庫在 SG 區域的恢復，並且級聯創建諸如 OpenSearch / Redis 等在內的依賴 T+5 min，我們開始正式的確認上下游依賴的具體問題，確認一個新上線的核心服務受到影響 T+10min，我們停服公告和其餘服務的受影響公告發出 T+10min，我請另外兩位同時協助 setup 新的 ECR 以及清理測試環境已有資源，並同步 CTO ，在極端情況下，我們可能會存在保體驗，丟數據的決策。 T+15min， 我們最終確認目前已創建的資源以及流量入方向不會受到太大影響。切換方案掛起，但是我們繼續準備相關資源 T+30min，我們第一個數據庫恢復完畢 T+40min，我們第二個數據庫恢復完畢 T+1h，我們所有關聯的核心 infra，RDS/ES/Redis 都 stand by，並且按照生產架構設置主從等優化選項。同時我們也開始正在新的集群啟動新的服務 所幸，最終 AWS 的 crash 沒有影響我們全部服務。我們無須面對切換流量後複雜的數據修復工作 大概 T+2h 到 T+3h 後，我正式通報全員，緊急狀態解除。為保險起見，今晚依舊對 feature 封版。 回顧整個事故，我還可以做的更多 1. 將我之前為自己準備的極端 case SOP，對全員公開。這樣確保我即便不在線，也有人能接替我 2. 我們可以做一些提前的預先演練 3. 指令下達可以更果斷一些 差不多就是這樣，一點分享，希望能幫到大家

暴論一下 AI 時代的到來，codebase 和架構將以前所未有的速度不斷的腐化。 這會意味著穩定性越來越難做。之前被忽視的很多穩定性細節以及最佳實踐都會在 AI 時代被放大。越來越多的初創公司比預期的更早的遇到自己的架構瓶頸或者到了技術債務的償還時刻 而穩定性越來越難做的另外一層含義就是，能做穩定性的人也越來越少。而在 vibe coding 盛行的情況下，能靜下心來做穩定性，扣指標的人也越來越少