前言
二十年內可能會發生很多事情，尤其是當你忙於開發時。
二十年前，谷歌有一對小資料中心，每個中心有幾千臺伺服器，通過一對 24G網路鏈路環連線。 我們使用 python 指令碼，例如"assigner"、"autoreplacer "跟"babysitter"執行我們的私有雲（儘管我們當時沒有這麼稱呼它），這些指令碼在包含單個伺服器名稱的配置檔案上執行。 我們有乙個小型機器資料庫 （MDB），可以幫助組織和儲存來自各個伺服器的資訊。 我們的小型工程師團隊使用指令碼和配置檔案來自動解決常見問題，並減少管理伺服器群所需的體力勞動。
隨著時間的流逝，谷歌的使用者開始搜尋，免費獲得GB Gmail，我們的車隊和網路也在增長。 今天，我們的計算能力是 20 年前的 1,000 多倍;在網路方面，我們的規模是 20 年前的 10,000 多倍，我們在每台伺服器上花費的精力比以前少得多，而我們的服務堆疊更可靠。 我們的工具已經從一系列 python 指令碼發展到乙個整合的服務生態系統，再到乙個預設提供可靠性的統一平台。 隨著我們遇到新型故障，我們對分布式系統的問題和故障模式的理解也在不斷發展。 我們創造了不幸之輪（"wheel of misfortune"[1]、服務最佳實踐指南（"service best practices guides"[2]，出版了《谷歌》一書'最熱門的歌曲“，今天，我們非常高興地向大家介紹：
Benjamin Trainor Sloss，Google SRE 的建立者
從二十年的可靠性工程中吸取的經驗教訓
讓我們從 2016 年開始，當時 YouTube 仍然可用"阿黛爾的拼車卡拉OK"而且總是令人著迷"pen-pineapple-apple-pen"等待你的最愛**。 由於 YouTube 的分布式記憶體快取系統出現錯誤，YouTube 經歷了 15 分鐘的全球中斷，導致 YouTube 服務功能中斷**。 以下是我們從這次事件中吸取的教訓。
1.緩解措施的風險應與中斷的嚴重程度成正比
有乙個笑話，說乙個人在網上發了一張他家裡蜘蛛的照片，船長說"是時候搬到新房子了！"。這個笑話的意思是，對於這個事件（看到乙隻可怕的蜘蛛），將採取嚴厲的緩解措施（放棄你現在的家，搬到乙個新的家）。 我們在 SRE 方面也有一些有趣的經驗，即選擇一種比它試圖解決的失敗風險更大的緩解措施。 在前面提到的 YouTube 故障事件中，乙個有風險的負載切割過程並沒有解決故障。 ......相反，它導致了級聯故障。
我們敏銳地意識到，在事件發生期間，我們應該監控和評估情況的嚴重性，並選擇適合嚴重性的緩解路徑。 在最好的情況下，有風險的緩解措施可以解決故障。 在最壞的情況下，故障緩解措施可能會失敗，從而導致更長的中斷時間。 此外，如果一切正常，您可以做出明智的決定，繞過標準程式。
2.在緊急情況發生之前，應全面測試恢復機制
在高層城市建築中進行緊急消防疏散是首次使用梯子的絕佳機會。 同樣，中斷是首次嘗試危險的負載下降過程的絕佳機會。 為了在高風險、高壓力的情況下保持冷靜，重要的是要事先練習習恢復機制和緩解措施，並驗證以下內容：
他們為您提供保障。
你知道怎麼做。
測試恢復機制的另乙個有趣的方面是，它降低了執行其中一些操作的風險。 自從下面出現這個混亂的故障以來，我們已經加倍努力來測試它。
3.Canary 所有更改
有一次，我們想推動快取配置更改。 我們非常確定這不會導致任何不良後果。 但"很確定"這不是100%確定的。 事實證明，快取對 YouTube 來說是乙個相當關鍵的功能，配置更改產生了一些意想不到的後果，使服務完全癱瘓了 13 分鐘。 如果我們採用漸進式發布策略，Canaried These Global Changes[3]，這種失敗本可以在它產生全球影響之前得到控制。 在此處閱讀有關金絲雀策略的更多資訊[4]，並在** [5]中了解更多資訊。
大約在同一時間，YouTube 稍微年輕的兄弟姐妹 Google 日曆也經歷了崩潰，這是接下來兩節課的背景。
4.有乙個"大紅色（緊急停止）按鈕"(h**e a "big red button")
急停按鈕"這是乙個獨特但非常有用的安全功能：它應該啟動乙個簡單、易於觸發的操作，該操作可以恢復觸發錯誤狀態的原因，以（理想情況下）關閉正在發生的一切。 "急停按鈕"有多種形狀和大小——在採取潛在危險行動之前，確定這些紅色按鈕可能是什麼非常重要。 我們差點觸發乙個重大故障，但幸運的是，提交潛在觸發更改的工程師在更改傳播之前拔下了台式計算機的電源。 因此，在規劃重大部署時，請考慮我的內容"紅色按鈕"？確保每個服務依賴項都有乙個"紅色按鈕"在緊急情況下使用。 有關詳細資訊，請參閱："一般緩解措施"[6]！
5.僅靠單元測試是不夠的，還需要整合測試
是的。。。。。。。單元測試。 它們驗證各個元件是否按照我們的要求執行。 單元測試故意限制了測試的範圍，並且很有用，但它們也不能完全複製執行時環境和可能的生產要求。 這就是為什麼我們是整合測試的大力倡導者！我們可以使用整合測試來驗證作業和任務是否可以執行冷啟動。 事情會按照我們想要的方式進行嗎？這些元件是否按照我們的要求協同工作？這些元件能否成功建立我們想要的系統？我們在日曆失敗中吸取了這一教訓，我們的測試沒有遵循與我們實際使用的路徑相同的路徑，導致大量測試......這無助於我們評估更改在現實世界中的表現。
繼續討論 2017 年 2 月發生的事件，我們找到了接下來的兩個教訓。
首先，不可用的 OAuth 令牌導致數百萬使用者登出裝置和服務，32,000 臺 Onhub 和 Google WiFi 裝置執行了恢復出廠設定。 由於登入失敗，手動恢復帳戶的要求增加了 10 倍。 谷歌花了大約12個小時才從故障中完全恢復過來。
6.溝通渠道！還有備用頻道！！和備份！！ 這些備份通道communication channels! and backup channels!! and backups for those backup channels!!!
是的，那是一段糟糕的時光。 你想知道是什麼讓它變得更糟嗎？團隊希望能夠使用 Google Hangouts 和 Google Meet 來管理活動。 但是，當 35 億使用者登出其裝置和服務。 ......回想起來，依賴這些谷歌服務是乙個錯誤的決定。 確保您有乙個不依賴且已經過測試的備用通訊通道。
然後，2024年的同一事件讓我們對優雅的退化有了更好的理解：[7]。
7.故意降低效能模式
可用性很容易理解為："完全正常"或"一切正常"...但是，通過效能降級模式始終如一地提供最少的功能有助於提供更一致的使用者體驗。 因此，我們仔細而刻意地構建了一種效能下降模式，因此在不穩定的情況下，使用者可能根本無法看到它（這可能正在發生！）。服務應正常降級，並在特殊情況下繼續執行。
下一課是一項建議，旨在確保最後一道防線系統在極端情況下（如自然災害或網路攻擊）按預期執行，從而導致生產力或服務可用性損失。
8.抗災能力測試
除了單元測試和整合測試之外，還有其他型別的重要測試：災難彈性和恢復測試。 災難恢復測試用於驗證您的服務或系統在發生故障、延遲或中斷時是否可以繼續執行，而恢復測試則驗證您的服務是否可以在完全關閉後恢復到正常狀態。 因此"在意想不到的環境中生存下來"[8] 兩者都應該是業務連續性戰略的關鍵部分。 乙個有用的活動也可以是與團隊坐下來討論其中一些場景在理論上如何以棋盤遊戲的形式發生。 這也是對那些可怕的探索"如果"有趣的機會，例如，"如果部分網路連線意外關閉，該怎麼辦
9.自動執行緩解措施
2023 年 3 月，多個資料中心的多個網路裝置幾乎同時發生故障，導致大面積丟包。 在這 6 天的中斷期間，估計有 70% 的服務受到不同程度的影響，具體取決於網路故障時的位置、服務負載和配置。
在這種情況下，您可以通過自動採取緩解措施來縮短平均解決時間 （MTTR）。 如果有明確的訊號表明正在發生故障，為什麼不能自動啟動緩解措施有時，最好先使用自動緩解措施，並保留根本原因，直到它避免影響使用者。
10.縮短推出之間的時間，以降低推出出錯的可能性
2022 年 3 月，支付系統出現大範圍故障，導致客戶無法完成交易，導致 Pokemon GO 社群日推遲。 原因是刪除了單個資料庫字段，這應該是安全的，因為該字段的所有使用都已事先從 ** 中刪除。 不幸的是，由於系統的一部分發布速度較慢，這意味著該字段仍在被實時系統使用。
由於發布之間的延遲時間很長，尤其是在複雜的多元件系統中，因此很難從發布中推斷出特定更改的安全性。 頻繁發布 [9] – 通過適當的測試 – 可以減少此類故障的意外發生。
11.單個全域性硬體版本是單點故障
僅使用一種特定型號的裝置執行關鍵功能可簡化操作和維護。 但是，這意味著如果模型出現問題，則不再執行該關鍵功能。
這發生在 2020 年 3 月，當時具有未發現的零日漏洞的網路裝置經歷了觸發該漏洞的流量模式更改。 由於整個網路使用相同型號和版本的裝置，因此存在嚴重的區域故障。 得益於多個網路骨幹網，高優先順序流量能夠通過仍在執行的替代裝置傳輸，從而避免了完全中斷。
關鍵基礎設施中的潛在漏洞可能無法被發現，直到看似無害的事件觸發它們。 維護多樣化的基礎設施雖然成本高昂，但可能意味著失敗和完全失敗之間的區別。
就是這樣！從 Google 二十年的可靠性工程中吸取的 11 個教訓。 為什麼是 11 節課？嗯，你看，谷歌的可靠性部門有著悠久的歷史，但它仍然處於鼎盛時期。
引用
1] 不幸之輪 （"wheel of misfortune")
2] 服務最佳實踐指南 （"service best practices guides")
3] 對那些全球變化進行抨擊
4] 在此處閱讀有關金絲雀策略的更多資訊。
5] 在**中了解更多資訊。
6] "一般緩解措施"
7] 優雅退化
8] "在意想不到的環境中生存下來"
9] 頻繁發布。
作者丨Adrienne Walcer 編譯丨***東風未明科技部落格（ID：ewhisperCN） DBAPLUS社群歡迎技術人員投稿，投稿郵箱：editor@dbapluscn