企業如何預防雲端災難

大公司非常努力確保他們的服務不會出故障，原因很簡單，重大宕機會損害品牌，並將客戶推向具有更好穩定性記錄的競爭產品。

建立可靠的網路服務是一個複雜的技術問題，但對公司領導者來說，這也是一個人力挑戰。激勵工程團隊投入可靠性工作的難度在於，這類工作往往被認為沒有開發新功能那麼吸引人。

在大規模營運中，激勵機制占主導地位。頂級科技公司僱用了成千上萬的員工，並經營數百個網路服務。多年來，他們想出了巧妙的方法，確保工程師建立可靠的系統。本文討論了那些歷史上最成功的科技公司在大規模環境中採用的人力管理技術，無論你是員工還是領導者，都可以將這些技術應用於你的公司。

轉動命運之輪

AWS的營運評審是每週一次的會議，開放給整個公司。每次會議都會轉動“幸運輪”，隨機選擇數百個AWS服務中的一個進行即時審查。被抽中的團隊必須回答有經驗的營運領導提出的關於儀錶板和指標的尖銳問題。會議有數百名員工、數十位總監和幾位副總裁參加。

這激勵了每個團隊具備基本的營運能力。即使某個團隊被選中的機率很低(在AWS，低於1%)，但作為團隊的經理或技術負責人，你肯定不希望在半個公司面前顯得一無所知，尤其是在你“運氣不佳」的那一天。

定期檢視可靠性指標非常重要。對營運健康狀況感興趣的領導者會為整個企業樹立這樣的基調。 「轉動命運之輪」只是實現這一目標的工具之一。

但是，在這些營運評審中你應該做些什麼呢?這就引出了下一個關鍵點。

設定可量化的可靠性目標

你可能希望有「高正常運行時間」或「五個九」(99.999%的可用性)，但這些對你的客戶意味著什麼呢?實時互動(如聊天)的延遲容忍度遠低於異步工作負載(如訓練機器學習模型、上傳影片)。你的目標應反映客戶關心的內容。

在審查團隊的指標時，請他們描述可量化的可靠性目標。確保你理解他們為何選擇這些目標，也讓他們清楚這一點，然後，讓他們使用儀表板證明這些目標已實現。設定可量化的目標有助於你以數據驅動的方式優先考慮可靠性工作。

關注問題的檢測非常重要。如果你在他們的儀表板上看到異常，詢問他們問題的原因，同時問他們的值班人員是否接到了通知。理想情況下，你應該在客戶發現問題之前就察覺到問題的存在。

擁抱混亂

雲端運算彈性領域最具革命性的思維轉變之一是將故障注入生產環境。 Netflix將這個概念正式化為「混沌工程」——這個概念和它的名字一樣酷。

Netflix希望激勵其工程師建立容錯系統，而不是透過微觀管理來實現。他們認為，如果將系統性故障常態化而不是視為例外，工程師將不得不建構容錯系統。雖然花了一些時間實現這一點，但在Netflix，生產環境中從單一伺服器到整個可用區都會被常規性地「淘汰」。每個服務都被期望能夠自動吸收這些故障，而不影響服務可用性。

這種策略既昂貴又複雜，但如果你發布的產品需要高正常運行時間是絕對必要的，那麼在生產環境中註入故障是獲得類似「正確性證明」的一種非常有效的方法。如果你的產品需要這樣做，儘早引進這個策略。未來不會比現在更簡單或更便宜。

如果混沌工程看起來有些過於激進，至少應要求團隊每年進行一到兩次「演習日」(模擬宕機演練)，或在推出任何重大功能前進行。在演習日中，會有三種指定角色——第一個角色模擬宕機，第二個角色在事先不知曉問題的情況下修復它，第三個角色觀察並做詳細記錄。事後，整個團隊應該聚在一起對模擬事件進行複盤(參見下文)。演習日不僅會揭示系統在處理宕機時的不足，還會暴露出工程師應對這些問題的差距。

制定嚴格的複盤流程

一個公司的複盤流程能反映其文化。頂尖科技公司都要求團隊對重大宕機撰寫複盤報告。報告應描述事件、探究根本原因，並提出預防措施。複盤應嚴​​格執行並維持高標準，但此過程不應指責個人。複盤撰寫是一種糾正行為，而不是懲罰行為。如果某個工程師犯了錯誤，表示存在允許這錯誤發生的潛在問題。或許你需要更好的測試流程，或是更完善的關鍵系統保護措施。深入挖掘這些系統性漏洞並加以修復。

設計一個健全的複盤流程可以單獨寫成一篇文章，但可以肯定的是，擁有一個這樣的流程將大大減少下次宕機的發生。

獎勵可靠性工作

如果工程師認為只有開發新功能才能帶來加薪和晉升，那麼可靠性工作將會被擱置。大多數工程師，無論資歷如何，都應為營運卓越做出貢獻。在績效評估中獎勵可靠性改善工作。讓資深工程師為他們所監督系統的穩定性負責。

雖然這個建議看似顯而易見，但卻很容易被忽略。

結論

本文探討了一些將可靠性融入公司文化的基本工具。新創公司和早期階段的公司通常不會優先考慮可靠性。這可以理解——你們的公司必須專注於驗證產品與市場的匹配，以確保生存，然而，一旦你擁有了回頭客，你公司的未來將依賴於保持信任。人類透過可靠性贏得信任，網路服務也是如此。