Netflix有哪些來之不易的系統高可用經驗？

作者 | Netflix Technology Blog

譯者 | 無明

正是這些從實戰中總結出來的寶貴經驗，成就了Netflix這樣的全球流媒體巨頭。

在過去四年中，Netflix 已從不到 5000 萬用戶增加到 1.25 億用戶。這種增長給我們帶來了伸縮性方面的挑戰，但實際上，我們已經設法在這段時間內提高了服務的整體可用性。在這個過程中，我們學到了很多東西，我們也更加明白該如何提升系統的可用性。但天下沒有免費的午餐，這些經驗來之不易：在出現問題時我們忙成一團，有時候還要處理用戶事件。儘管我們還沒有完全掃清所有的問題，我們的系統仍然還有很多可以改進的地方，但我們分享的這些經驗都是從實戰中總結出來的。希望你們能夠從中收穫點什麼，以免在凌晨三點鐘收到要你起床處理用戶事件的電話。

在 Netflix，我們使用 Spinnaker 作為持續集成和交付的平台。這裡討論的很多最佳實踐都已納入到 Spinnaker 中，這些技巧和最佳實踐具有通用性，將幫到任何想要提升系統可用性的人。

（註：Spinnaker 是 Netflix 開源的持續交付平台，定位於將產品快速且持續地部署到多種雲平台上。）

優先考慮區域部署而不是全球部署

我們的目標是儘可能提供最佳的客戶體驗。因此，我們要限制系統變更的影響範圍，對變更進行驗證，然後將變更推給客戶。更具體地說，我們一次只部署一個 AWS 區域，這為我們的生產部署提供了額外的安全保障。我們能夠快速地轉移受影響的客戶流量，這也是我們最重要的四大補救手段之一。

我們還建議在每個區域部署之間對應用程序功能進行驗證，並避免在目標區域的高峰時段進行部署。

在 Spinnaker 中，指定部署的目標區域非常簡單。

使用紅黑部署策略進行生產部署

在紅黑（也稱為藍綠）部署中，新版本的應用程序（紅色）在通過健康檢查之後立即開始接收流量。在確定紅色版本的健康狀態之後，之前的（黑色）版本將被禁用，並且不會收到任何流量。如果要回滾，只需要啟用以前的版本即可，非常簡單。這種模型加快了我們的部署流程，並可以在出現問題時回滾到之前的狀態。

要使用 Spinnaker 完成紅黑部署，只需要在管道中指定策略（並可選擇性地在策略中設置參數），Spinnaker 將負責完成部署。

使用部署窗口

每當你在部署新版本應用時，都要記住以下兩點：首先，你（或你的同事）是否有監控部署，並在必要時進行補救？第二，如果出現了問題，你是否能夠儘可能減小影響範圍？

我們的流媒體流量遵循相對可預測的模式，大多數人會在晚上打開視頻流。因此，我們建議選擇工作時段和非高峰時段的部署窗口。

Spinnaker 為此提供了一個界面，讓我們可以輕鬆地指定運行部署管道的日期和時間。

不要在非工作時段或周末自動觸發部署

部署窗口也適用於自動觸發的事件。在 Spinnaker 中，可以使用 cron 表達式作為管道觸發器，這也可能是一個冒險的策略：有些 cron 表達式可能會在非工作時段或周末執行管道，但這不是我們所期望的。無論你使用哪一種自動化機制，都要確保任何自動觸發的管道都可以在無人值守的模式下運行。

啟用 Chaos Monkey

Chaos Monkey 由 Netflix 創建並開源，是我們混沌工程工具套件的一部分。Chaos Monkey 以不可預測的方式隨機終止生產環境中的實例，以此來增強服務，讓服務具備應對單實例故障的彈性能力。如果某些服務不具備彈性能力，Chaos Monkey 將會暴露出它們的漏洞，服務所有者就可以在這些漏洞演變成影響用戶的事故之前修復它們。在 Netflix，生產環境中的所有服務都應該啟用 Chaos Monkey，在 Chaos Monkey 終止應用程序實例時，服務所有者不應該檢測到任何問題。

在將代碼推送到生產環境之前使用各種測試和金絲雀分析來驗證代碼

實現快速部署的關鍵是在部署之前自動驗證新版本的軟體。理想情況下，所有必要的測試套件都應該在沒有人工干預的情況下運行。

此外，我們建議使用金絲雀分析。金絲雀分析是一種通過實時流量來驗證服務變更的有效方法。最近我們開源了內部工具 Kayenta，它可以輕鬆集成到 Spinnaker 中，並結合人工判斷，成為放開所有生產流量之前的最後一道門檻。

必要的人工干預

儘可能使用自動化，但在必要的時候也需要人工干預。例如，在將新版本推向生產環境之前需要檢查金絲雀運行的結果。

部署時儘可能只用已經測試過的東西

既然你已經對新版本進行了大量的測試和驗證，我們強烈建議你在進行生產環境部署時只用測試過的東西。對於我們來說，我們更傾向於從測試環境中複製經過驗證的鏡像，而不是重新構建新的鏡像。

定期檢查聯繫人設置

有時候，為了確保應用程序的可用性，你所要做的其實很簡單。如果你的應用程序會出問題，並且很可能會在某個時間點出問題，那麼此時最重要的是找到能解決問題的人。因此，請定期檢查你的聯繫人設置，這樣可以確保在發生事故時能夠迅速找到解決問題的人。

Spinnaker 提供了一個「Page application owner」按鈕，請確保這裡配置的信息是最新的，這樣就不會在發生問題時找錯人。

知道如何快速回滾部署

即使有可靠的測試、金絲雀和其他驗證過程，將某些東西部署到生產環境中仍然會出現問題。也許這是一種由競態條件導致的罕見錯誤，只會在達到一定規模時才發生。但無論是何種情況，最重要的是你要知道在必要時如何快速恢復到之前正常的狀態。

在 Spinnaker 中，如果應用程序的新版本出現問題，可以通過「Server Group」下的「Rollback」選項進行回滾。回滾將啟用你選擇的 ASG（通常是之前的），並禁用發生故障的 ASG。Spinnaker 還支持創建可在發生管道故障時執行或通過手動觸發的回滾管道。

如果實例運行不正常，將部署視為失敗

多年來，有幾次我們在部署成功後感覺狀態不對，實例起來了，但不能正常處理流量。「成功」的部署給我們造成了一種假象，當一個關鍵的服務運行不正常時，請求很快會堆積起來，有時會導致重試雪崩，造成各種各樣的破壞。因此，當實例運行不正常時，要將部署視為失敗。

Spinnaker 提供了一種靈活的方法用於關聯實例的健康狀況。當一個實例不健康時，Spinnaker 會將其標註出來，更重要的是，不健康的實例將收不到流量。如果 ASG 中的所有實例都不健康，Spinnaker 會將部署視為失敗。Spinnaker 還用不同的顏色來標記實例的狀態，如啟動中、等待發現、不健康和健康，如下所示。

在進行自動部署時，需要通知團隊有關部署的情況

讓人們知道部署已成功進入生產環境，這對成功的運維來說至關重要。在出現問題時，需要知道發生了哪些變更以及這些變更是在什麼時候發生的。因此，在進行自動部署時，需要通知團隊，讓他們密切關注服務的健康狀況。在 Netflix，我們使用 Slack 發送通知。在 Spinnaker 中，管道可以在部署完成時通知相應的 Slack 頻道。

自動化非典型部署，而不是進行一次性手動部署

每個工程師都為非典型情況編寫過一次性腳本。而當這類「一次性」情況再次發生時，團隊的其他成員並不知道寫腳本的那個工程師在腳本里都幹了什麼，因為腳本本來是打算運行一次就丟掉的！很多人都遇到過這種情況。

管道是自動執行一系列步驟的有效手段，即使有些步驟並不會每天都執行。例如，一個用於緊急推送的管道，它使用參數作為控制執行的條件（比如跳過部署窗口）。

不要忘記定期測試非關鍵場景的非典型（和典型）部署管道！

使用先決條件驗證預期狀態

現如今，系統經常發生變化是常態。在 Netflix，我們的數百個微服務在不斷發生變化。做出無根據的假設（比如假設其他系統的狀態）是很危險的。我們現在使用先決條件來確保在部署新代碼或進行其他變更時假設仍然有效。這對於長時間執行的管道（可能是因為人工判斷或部署窗口造成延遲）來說尤為重要。我們可以在發生潛在的破壞性操作之前使用先決條件來驗證預期的狀態。

總結

這篇文章總結了我們多年來在 Netflix 積累的各種技巧和最佳實踐。我們的方法是儘可能圍繞這些最佳實踐構建工具。我們始終把提高服務可用性作為目標。在真正需要人工干預時，我們才會介入，否則就不插手。工程師的時間用在了那些可以提高可用性的任務上，而在不需要他們參與的情況下，他們可以專註其他事情。

活動推薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！