2023年11月12日，阿里雲產品因為某些故障，全線都受到影響。是的，雙十一的第二天，我的購物車還沒清空，阿里雲就不讓我買了。雲產品全面故障，影響之大一個大鐵鍋都裝不下。之所以阿里雲故障受到大家這麼關注，一方面是阿里雲投入多年技術領先，國內 IaaS 領導者，另外一方面是阿里雲使用者量大影響也大。
透過這幾天網上滿天飛的資訊，大家肯定也大概瞭解了事情原委，我想結合自己的經驗和教訓，大致說五點。
對生產環境要心生敬畏
任何一次變更，無論是程式碼、配置、甚至是網路、ACL的變更都可能引發嚴重事故。線上的生產事故意味著企業營收實實在在的損失，更意味著使用者對平臺信任的喪失。錢可以慢慢賺，但是使用者流失了就不是很快能回來的。
甭說什麼高效能，高併發，高可用，一鏟子下去三高全完。舉個簡單例子，如果你的儲存不穩定，而我上面存的是數字貨幣。結果因為雲端儲存導致我上面幾百個數字貨幣找不到了，這樣的損失使用者能接受得了麼？啥？幾百個數字貨幣你就給我一個月語雀會員？這不是找打麼。
雖然鏟子很厲害，但是資料表明，生產環境的故障90%以上都是變更引起的，所以我們要對變更格外重視和小心。發版要審批，變更要評審，上線要灰度，有問題快速回滾，系統有監控，異常有告警......這都是必備的。沒有一環又一環的系統保障，沒人敢對淘某寶這樣一個DAU超5億的站點進行變更。2015年5月27日16點40分，杭州市政建設工程施工過程中，一鏟子下去杭州電信管道內四條大對數光纜中斷，支付寶相關業務受到全面影響。至5月28日3點57分光纜陸續搶通，業務才逐步恢復。
某年的正月初六，大家還在春節的歡樂喜慶的氛圍中，公司 Gitlab 伺服器告警，硬碟故障，掛掉硬碟一塊。沒到五分鐘，告警電話再次打來，硬碟又掛掉一塊。伺服器只有四塊硬碟，這下raid5 也不好使了。冰冷的心，顫抖的手，就問你小腿抖不抖。
好在我們做了主備，也做了冷備，且演練了多次。但還是用了一個多小時來恢復服務和驗證資料。
對技術保障團隊價值要有足夠認知
還記得當初有個.NET開發的網站叫 360buy，每次促銷都崩，以至於最後老闆氣不過，在微博上高喊給我加三倍伺服器，促銷延長3小時。對，你猜的沒錯，就是現在的 jd.com。現在京東的穩定性早已經今非昔比，雙十一促銷30天也不會崩，但這是這麼多年真金白銀堆起來的。
研發總是在短期被重視，在長期被忽視；套用一下，技術保障團隊也是如此的尷尬，持續投入的公司很少，尤其是公司效益不佳、看不到 infra 價值的時候。從公司角度來說，公司做新東西開展新業務，搶佔市場，價值容易體現，每年帶來多少營收很容易算出來，但是把錢投入到技術保障上，花費大效果還不明顯。所以很多公司盤點業務的時候也不由自主地往業務發展上加碼。
從員工角度來說，也會把業務放在前面，給予高優先順序，花了多長時間出了多少活效果怎麼樣，畢竟這部分容易說清楚；同時也會降低技術保障類任務的優先順序，甚至只有在OKR Review的時候才會去看一眼。系統保障這種事一般體現在OKR中，但時間是不會體現的，只排活不排時間。這部分做了和做好所需要投入的時間差異很大，所以很多員工從自身利益出發也會偷偷地【權衡」掉系統保障應該花的時間，把時間放在開發功能做業務上。就像練武一樣，招式易學，內力不好練。
業務壓力大，需求排得緊，這是事實；員工願意做出活快，價值明顯的工作，這也是事實。但是我們要意識到技術保障也很重要，否則也不可能總要求在我們的OKR中有體現。就像業界區分產品、研發、測試、運維、DBA、SCM、安全這些崗位都是有意義的，是從這麼多年國內國外的實踐中總結沉澱出來的經驗，是用真金白銀買來的教訓。系統穩定性想要做好，只能靠大量的細節來落地，這意味著的是大量的投入，持續大量的投入，甚至要把穩定性當成業務一樣持續地投入。這就好比城市內澇治理，功夫在平時。
技術保障效果差的思考
很多穩定性的技術保障方案都是有的，但是就是做不好，歸根結底是組織的問題，是認知的問題。
首先從領導層，尤其是遠離技術團隊的領導就會質疑我們真的需要那麼多人去做技術保障工作麼？真的會出故障麼？你看去年我們裁了兩SRE不也沒出問題麼，今年再裁倆。
出事咋辦？找人救火，喪事喜辦也不是沒有。經常出現一種現象，修河堤的辛苦奔波狼狽不堪，抗洪救災的升官發財。
很多人對技術保障認知不夠深入。總覺得資金、人力和時間投入很大，但技術保障對業務的收入影響難以衡量。另外，技術保障團隊的努力也容易被業務團隊帶來的收益掩蓋。
平衡業務發展與技術保障建設
很多時候出故障的確不是技術問題，而是組織如何平衡業務發展和技術保障投入的問題。技術保障就是投入，紮紮實實地做，持續紮紮實實地做。
叫醒一個裝睡的人是很難的。曾經有一個人問我，公司現在1000人，有必要建立專門的研發效能團隊麼？我說，既然還沒體現出這塊的價值，那就沒必要。
如果你還沒意識到它的價值，讓你做也做不好。只有自身意識到它的價值了，心裡才會真的認可這件事。如果老闆自身都沒意識到它的價值，然後讓團隊去自證團隊存在的價值，老闆難，團隊也難。安全團隊的價值怎麼體現？一年沒有安全事故，安全團隊的價值何在？沒價值吧，裁倆。對於技術保障團隊，證偽容易，證真難。一個故障把你打回原型，想再化成人形又不知道要蟄伏多少年。
上雲信心受損，多雲部署+混合雲部署訴求上升
上雲帶來的是便捷的運維和較低成本，但也引入了一些風險，尤其是單一使用一家雲服務廠商的時候風險就會很大。其實Amazon AWS一樣也出故障，不過這次阿里雲掛的範圍確實也大了點，影響了的公司也忒多了點。這麼大的一個故障，上雲信心多多少少都會受影響。這次故障過後很多已經全面上雲的企業會擔心資料丟失，業務受損。所以經過這麼一次「昂貴」的教訓，估計很多企業會尋求多雲部署和混合雲部署。大家對對災備的認知也會更深刻一些。
「前沿數控」公司，所有資料都在雲硬碟上，結果因為雲硬碟故障，導致公司的所有資料全部丟失，無法恢復，一夜回到解放前，也不知道官司現在結果如何了。
本文小結
穩定性或者說質量都是錢堆出來的，花的是清清楚楚的錢，省的是糊裡糊塗的賬。但是系統一旦出故障損失的錢卻能算得清清楚楚。技術保障就是這樣，騎車去酒吧，該省的省該花的花。該花的錢不花，系統就死給你看，服務一掛，業務立刻受損，而且損失的不僅僅是錢，更重要的是商業信譽和使用者對你的信任。
閱讀我的更多文章
DevOps｜破除壁壘,重塑協作——業務閉環釋放產研運巨大效能(中）
DevOps｜服務治理與服務保障實踐指南
infra ｜ devops工具鏈基建建設評價標準