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

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

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

轉動命運之輪

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

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

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

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

設定可量化的可靠性目標

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

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

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

擁抱混亂

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

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

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

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

制定嚴格的復盤流程

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

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

獎勵可靠性工作

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

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

結論

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