作者 | Adrienne Walcer, Kavita Guliani, Mikel Ward, Sunny Hsiao, and VrAI Stacey
譯者 | 劉雅夢
策劃 | Tina
讓我們回到 2016 年，當時 YouTube 提供了大家最喜歡的視頻，例如“Carpool Karaoke with Adele”和一直很吸引人的“Pen-PineApple-Apple-Pen”。由于 YouTube 的分布式內存緩存系統的一個 bug，YouTube 經歷了長達 15 分鐘的全球宕機故障，中斷了 YouTube 的視頻提供能力。以下是我們從這次故障中學到的三個經驗教訓。
1. 故障削減措施的風險應與故障的嚴重程度成比例
有一個表情包，其中一個人發布了一張在他們家里看到蜘蛛的照片，家長說：“是時候搬新家了!”。可笑的是，這一事件（看到一只可怕的蜘蛛）會得到嚴厲的削減措施（放棄你現在的家，搬到新家中）。我們 SRE 在選擇比宕機風險更大的削減措施方面有一些有趣的經驗。在上述 YouTube 宕機期間，一個有風險的減載過程并沒有解決宕機問題……反而造成了級聯故障。
我們得到了慘痛的教訓，在故障發生期間，我們應該監控和評估情況的嚴重性，并選擇一條風險適合該嚴重程度的故障削減路徑。在最好的情況下，風險削減措施可以解決宕機問題。在最壞的情況下，風險削減措施會失靈，并且本應修復問題的措施會導致宕機時間的延長。此外，如果一切都壞了，我們可以做出明智的決定來繞過標準程序。
2. 在發生緊急情況之前，應對恢復機制進行全面測試
在高層城市建筑中進行緊急消防疏散是首次使用梯子的可怕時機。同樣，在故障中首次嘗試風險減載過程也是一個糟糕的時機。為了在高風險和高壓力的情況下保持冷靜，事先演練恢復機制和故障削減措施很重要，并需要驗證：
- 它們會做你需要它們做的事
- 你知道怎么做
演練恢復機制有一個有趣的副作用，即可以降低執行其中一些操作的風險。自從這次混亂的宕機以來，我們加倍努力地進行演練。
3. 金絲雀所有變更
有一次，我們想要推送緩存配置變更。我們很肯定那不會導致任何壞事。但相當肯定并不是百分之百確定。事實證明，緩存對于 YouTube 來說是一個非常關鍵的功能，而配置變更產生了一些意想不到的后果，導致該服務完全癱瘓了 13 分鐘。如果我們采用漸進式的發布策略來應對這些全球變更，那么這次故障本可以在產生全球影響之前得到遏制。可以閱讀這篇論文中了解有關金絲雀策略的更多信息，也可以通過本視頻以了解更多信息。
大約在同一時間段，比 YouTube 稍微年輕的兄弟公司谷歌日歷（google Calendar）也經歷了宕機故障，這也是接下來兩個經驗教訓的背景。
4. 有一個“大紅色按鈕”
“大紅色按鈕”（Big Red Button）是一種獨特但高度實用的安全功能：它應該啟動一個簡單、易于觸發的動作，該動作將觸發不良狀態恢復到（理想情況下）關閉正在發生的任何情況。“大紅色按鈕”有多種形狀和大小，在提交一個有潛在風險的操作之前，識別這些大紅色按鈕可能是什么非常重要的。我們曾經差點就能避免一次重大的宕機故障，因為提交可能觸發變更的工程師在更改傳播之前拔掉了臺式電腦的電源插頭。因此，在計劃重大部署時，請考慮大紅色按鈕是什么？確保每個服務依賴項都有一個“大紅色按鈕”，以便在緊急情況下使用。請參閱“通用削減措施”以了解更多信息！
5. 僅僅進行單元測試是不夠的，還需要進行集成測試
啊……單元測試。它們驗證單個組件是否可以按照我們需要的方式執行。單元測試的范圍是有意限制的，而且非常有用，但它們也不能完全復制可能存在的運行時環境和生產需求。因此，我們大力提倡集成測試！我們可以使用集成測試來驗證作業和任務是否可以執行冷啟動。事情會按照我們希望的方式進行嗎？組件也會按照我們想要的方式協同工作嗎？這些組件會成功創建我們想要的系統嗎？這一教訓是在谷歌日歷（Calendar）的故障處理中學到的，在這次故障中，我們的測試沒有遵循與實際使用相同的路徑，導致了大量的測試...... 但這并不能幫助我們評估變更在現實中的執行情況。
轉到 2017 年 2 月發生的一個故障，我們學到了接下來的兩個經驗教訓。
首先，不可用的 OAuth 令牌導致數百萬用戶退出設備和服務，并導致 32000 個 OnHub 和 Google wifi 設備執行出廠重置。由于登錄失敗，手動帳戶恢復索賠增加了 10 倍。谷歌花了大約 12 個小時才從這次故障中完全恢復過來。
6. 溝通渠道！還有備份通道！！以及這些備份通道的備份！！！
是的，那是一段糟糕的時光。你想知道是什么讓情況變得更糟的嗎？團隊希望能夠使用 Google Hangouts 和 Google Meet 來管理事件。但當 3.5 億用戶退出他們的設備和服務時……回想起來，依賴這些谷歌服務是一個糟糕的決定。確保你擁有獨立的備份通信通道，并且已對其進行了測試。
然后，2017 年的同一故障讓我們更好地理解了優雅降級：
7. 故意降級性能模式
人們很容易將可用性視為“完全啟動”或“完全關閉”……但是能夠通過降級性能模式提供連續的最小功能有助于提供更一致的用戶體驗。因此，我們謹慎而有意地構建了性能降級模式——因此，在粗略的補丁程序中，它甚至可能不會被用戶看到（它可能現在正在發生！）。服務應該適度降級，并在特殊情況下繼續運行。
下一個經驗教訓建議我們確保最后一道防線系統在極端情況下能如預期的那樣工作，例如自然災害或網絡攻擊，這些情況會導致生產力或服務可用性的損失。
8. 故障彈性測試
除了單元測試和集成測試之外，還有一些非常重要的其他類型的測試：故障彈性和恢復測試。彈性測試驗證我們的服務或系統在發生故障、延遲或中斷時是否正常運行，而恢復測試則驗證服務在完全關閉后是否能夠恢復到穩態。兩者都應該是業務連續性戰略的關鍵部分——如“抵御意外”中所描述的那樣。一個有用的活動還可以是讓你的團隊坐下來，研究其中一些場景在理論上是如何發揮作用的——桌面游戲風格。這也是一個探索那些可怕的“假設”的有趣機會，例如，“如果部分網絡連接意外關閉怎么辦？”。
9. 自動化故障削減措施
2023 年 3 月，幾個數據中心的多個網絡設備幾乎同時發生故障，導致大范圍的數據包丟失。在這 6 天的宕機故障中，估計 70% 的服務受到了不同程度的影響，具體取決于網絡故障時的位置、服務負載和配置。
在這種情況下，我們可以通過手動自動化故障削減措施來減少平均解決時間（MTTR）。如果有一個明確的信號表明某個特定的故障正在發生，那么為什么不能以自動化的方式啟動故障削減措施呢？有時，最好先使用自動故障削減措施，并在避免了用戶影響之后再解決根本原因。
10. 縮短部署之間的時間間隔，以降低部署出錯的可能性
2022 年 3 月，支付系統大范圍故障，客戶無法完成交易，導致 Pokémon GO 社區日被推遲了。原因是刪除了一個數據庫字段，這應該是安全的，因為該字段的所有使用都事先從代碼中刪除的。不幸的是，系統某一部分的緩慢部署節奏意味著該字段仍在被線上系統所使用。
部署之間有很長的間隔，尤其是在復雜的多組件系統中，會使得我們很難推斷出特定變更的安全性。間隔很近部署（并進行適當的測試）可以減少此類故障的意外發生。
11. 單一全球硬件版本會是單點故障
只使用一種特定型號的設備來執行關鍵功能可以簡化操作并能使運維更簡單。然而，這也意味著，如果該模型出現問題，則該關鍵功能將不再執行。
這一故障發生在 2020 年 3 月，當時一臺網絡設備遇到了一個未被發現的零日漏洞，該漏洞觸發了流量模式的變更。由于整個網絡都在使用相同型號和版本的設備，因此出現了嚴重的區域性故障。防止這種情況全面故障的原因是存在多個網絡主干網，這些主干網允許高優先級流量通過仍在工作的替代路由。
關鍵基礎設施中的潛在漏洞可能潛伏在未被發現的地方，直到一個看似無害的事件觸發了它們。維護多樣化的基礎設施雖然本身會產生成本，但可能意味著麻煩的區域故障和全面故障之間的差異。
所以你學到了嘛！從谷歌 20 年的站點可靠性工程中汲取的 11 個經驗教訓。為什么是 11 個呢？好吧，你看，谷歌站點可靠性有著豐富的歷史并仍然處于鼎盛時期。
原文鏈接：
https://sre.google/resources/practices-and-processes/twenty-years-of-sre-lessons-learned/
