作者 | Eugene Retunsky 

策劃 | 云昭

51CTO讀者成長計劃社群招募，咨詢小助手（微信號：CTOjishuzhan）

通過采用整體方法并利用工程原理和實踐，我們可以兩全其美——速度和可靠性。

當涉及到在線服務時，正常運行時間是至關重要的，但這并不是唯一需要考慮的事情。想象一下，經營一家網上商店——讓你的網站99.9%的時間都可用聽起來不錯，但如果0.1%的停機時間發生在假日購物季呢？這可能意味著失去大筆銷售額。如果你的大多數客戶只對少數受歡迎的商品感興趣呢？如果這些頁面不可用，那么網站的其他部分是否正常工作也沒關系。

有時，“在高峰時刻隨時待命”干系到你生意的成敗。不僅僅是電子商務——一小部分機場處理著大部分的空中交通，只有極少數名人家喻戶曉，每年只有少數賣座電影占據票房主導地位。到處都是相同的分布模式。

為了取得成功，重要的是不僅要保持正常運行時間，還要為重大事件做好準備。一些團隊在關鍵時間之前實施變更凍結，如黃金日、黑色星期五或網絡星期一。這種方法是合理的，但它可能是有限的，因為它不允許團隊對意外的機會或關鍵情況做出快速反應。此外，并不是所有的需求都可以預測，也不總是清楚這些高影響事件何時會發生。這就是“重要時的可靠性”的用武之地。我們需要能夠適應和快速響應客戶需求的變化，而不會被代碼凍結期所阻礙，并為不可預見的情況做好準備。

通過將時間視為一種寶貴的資源，并了解不同時刻的相對重要性，組織可以更好地轉化客戶價值，并相應地調整風險和可用性預算。這種方法使組織能夠靈活應對需求變化，而不會錯過關鍵功能或機會。最后，這是關于當運氣來臨時做好準備。

需要注意的是，一個系統不是靜態的，而是不斷變化的。系統本身、托管的基礎設施和工程組織都會隨著時間的推移而變化。這意味著有關系統的知識也會發生變化，這可能會影響可靠性。

除此之外，無論我們如何努力防止事故和停機，事故和停機都是不可避免的。錯誤將被發送，錯誤的配置將被部署，并且會發生人為錯誤。也可能存在相互依賴性，從而導致停機。一個事件很少有單一的原因，通常是多種因素共同作用的結果。解決方案也是如此，當它們涉及到原則和實踐的結合，以減輕停機的影響時，這些解決方案是最有效的。

操作系統通常意味著要應對現實世界的壓力，如時間、市場和管理需求，以更快地交付。這可能導致走捷徑，并可能損害系統的可靠性。用戶群和組織的增長和擴展也會帶來額外的復雜性，并導致意外或不可預見的行為和故障模式。然而，通過采用整體方法并利用我將在下面介紹的工程原理和實踐，我們可以兩全其美——速度和可靠性。這不是非此即彼的情況，而是兩者之間微妙的平衡。

1、什么是可靠性

可靠性是任何系統的重要組成部分，因為它不僅保證可用性，而且保證正常運行。一個系統可能是可訪問的，但如果它不能準確地運行，它就缺乏可靠性。目標是在系統內實現可用性和準確性，這需要控制故障并將其影響降至最低。然而，并非所有故障都具有同等的重要性。例如，阻止結賬和付款的問題遠比圖像加載中的小故障更重要。重要的是要專注于確保重要功能在關鍵時刻正確工作。

換句話說，我們希望專注于在高峰時段保持可用性和正確運行，為最重要的功能提供服務，無論是流行頁面還是流程的關鍵部分。確保系統在繁忙時期正常工作是很困難的，但重要的是要以深思熟慮和徹底的方式來處理。這包括對系統的技術、操作和組織方面的思考。這種方法的關鍵部分包括：

設計具有彈性、容錯和自我修復能力的系統。

在極端條件下主動測試系統，以識別潛在的弱點并防止倒退。

有效的操作實踐：定義托管拓撲、自動擴展、自動化部署/回滾、實施更改管理、監控和事件響應協議。

應對增長、市場需求和工程質量的競爭壓力。

培養一種重視協作、知識共享、開放、簡單和工藝的文化。它還需要關注結果，以避免猶豫不決，并為客戶提供盡可能好的體驗。

此外，我們將擴展“重要時的可靠性（Reliability when it matters）”的概念，并為組織提供切實可行的步驟，以確保關鍵時刻的可用性和功能。我們將討論關鍵要素，如設計可靠性系統、主動測試和監控，并深入研究自動化部署和事件響應協議等實際步驟。

2、可靠性度量：優化的重要工具

在優化服務或系統時，首先定義目標并建立監控進度的方法至關重要。您選擇的指標應能讓您全面了解系統的可靠性，易于理解、共享，并突出需要改進的領域。以下是一些常見的可靠性指標：

• 事件頻率：每單位時間內發生的事件數。
• 事件持續時間：事件持續的總時間。

雖然這些指標是一個很好的起點，但它們并沒有顯示事故對客戶的影響。讓我們考慮以下圖表：

?藍色-每五分鐘的請求數，紅色-錯誤，綠色-0..1中的可靠性

假設我們有兩個事件，一個在凌晨1點，另一個在下午2點，每個事件都導致大約10%的請求在30分鐘內失敗。將這些事件視為對可靠性同樣有影響，并不能反映它們對客戶的真實影響。通過考慮交通量，可靠性指標可以更好地表明高峰交通期間的事件具有更大的影響，值得更高的優先級。

我們的目標是有一個明確的信號，表明高峰交通期間的事故是一個應該解決的主要問題。這種區別有助于確定任務的優先級，并確保資源得到有效利用。例如，它可以防止營銷團隊為吸引更多訪客所做的努力被浪費。此外，跟蹤每個發布的事件頻率可以幫助改進部署和測試過程，并減少意外問題。最終，這將導致更快的交付和更低的風險。

3、深入挖掘指標

要更深入地了解這些指標并找到需要改進的地方，請嘗試跟蹤以下內容：

• 檢測時間：注意到一個事件需要多長時間。
• 通知時間：通知相關方需要多長時間。
• 修復時間：修復一個事件需要多長時間。
• 事件間隔時間：這可以揭示系統故障的模式或趨勢。
• 操作項完成率：完成任務的百分比。
• 行動項目解決時間：實施解決方案所需的時間。
• 高嚴重事故的百分比：這衡量系統的總體可靠性。

最后，在每周運營期間定期審查這些指標有助于關注進展、識別成功并確定優先級。通過將此作為您文化的常規組成部分，您可以使用這些指標中的數據來推動更好的決策并逐步優化系統。

記住，衡量標準的有用性在于從中采取的行動及其推動進步的能力。這是一個不斷完善數據和行動項目的反饋循環，以保持系統的改進。

4、彈性設計

一個沒有彈性的系統可能無法順利處理高峰時間。以下是一些有助于確保系統在各種條件下的可靠性的注意事項：

要做的：

• 為組件故障做好準備：通過劃分服務或使用隔離，可以限制爆炸半徑并減少故障的影響。
• 實現容錯：實現重試、請求對沖和背壓等機制將提高系統的可用性和性能。
• 使用速率限制和流量配額：不要僅僅依靠上游依賴關系來保護自己。使用速率限制和流量配額來確保您的系統保持可靠。
• 分類功能: 通過將職能劃分為“關鍵”、“正常”和“盡最大努力”類別來確定職能的優先級。這將有助于在高需求期間不惜一切代價保持基本功能的可用性。
• 實現錯誤定步和甩負荷：這些機制有助于防止或減輕流量濫用或濫用。
• 持續挑戰系統：持續挑戰系統并考慮潛在故障，以確定需要改進的領域。
• 恢復計劃：實施故障轉移機制，并在發生故障時計劃恢復。這將有助于減少停機時間，并確保在具有挑戰性的條件下提供基本服務。
• 進行戰略權衡：在具有挑戰性的外部條件下，進行戰略權衡并優先考慮基本服務。

不要做的：

• 不要以為調用者會按預期使用您的服務。
• 不要忽視罕見但潛在的失敗；規劃和設計預防措施。
• 不要忽視硬件故障的可能性。

5、可靠性測試

可靠性測試對于在高需求期間保持系統的可用性和功能性至關重要。為了確保系統的可靠性，重要的是：

• 針對可測試性進行設計，以便可以單獨測試每個組件。
• 有足夠好的測試覆蓋率作為敏捷的先決條件。
• 按重要性校準測試，將重點放在基本功能上，并對次要或實驗功能給予一點放松。
• 進行廣泛的非功能測試，如負載測試、壓力測試、故障注入測試、浸泡測試和模糊/組合測試。

有必要避免以下情況：

• 盲目追求高覆蓋率。
• 假設一個數據點可以提供全面的理解。確保結果具有可重復性。
• 測試環境和工具投資不足。

適當的測試不僅可以確保正確性，作為活的文檔，防止非功能性的倒退，還可以幫助工程師更深入地理解系統，在試圖挑戰系統的同時發揮他們的創造力，并最終為所有利益相關者創造更具彈性、更可靠的系統。

記住，如果你不故意對你的系統進行壓力測試，你的用戶會為你做的。那一刻何時到來，你將無法選擇。

6、以可靠性為導向的運維

運維分布式系統就像指揮管弦樂隊，這是一門精細的藝術，需要高水平的技能和對細節的關注。許多工程師傾向于低估操作的重要性，或者將其視為軟件開發的次要因素。然而，在現實中，操作可能會對系統的可靠性產生重大影響。

就像指揮家的技巧和對管弦樂隊的理解對于確保和諧的表演至關重要。例如，云計算提供商通常提供基于開源產品的服務。這不僅僅是關于使用軟件，還有你如何使用它。這是云計算提供商業務的重要組成部分。

為了確保可靠性，需要考慮運維的三個關鍵方面：

• 運行服務：這涉及到托管配置、部署過程和定期維護任務，如安全補丁、備份等。
• 事件預防：實時監控系統以快速檢測和解決問題，定期測試系統的性能和可靠性、容量規劃等。
• 事件響應：制定明確的事件響應協議，定義團隊成員在事件中的角色和責任，以及有效的審查、溝通和后續機制，以解決問題，防止類似事件發生或最大限度地減少其在未來的影響。

事件響應方面尤其重要，因為它可以作為現實核查。畢竟，所有采取的措施都是不夠的。這是一個謙遜的時刻，也是一個意識到世界比我們想象的要復雜得多的時刻。我們需要盡可能誠實地找出導致這起事件的所有工程和程序缺陷，并看看我們未來可以做得更好。

為了使事件回顧有效，考慮采用以下做法：

• 假設讀者事先不了解您的服務。首先，你寫這個回顧是為了分享知識，寫得清楚，讓別人理解。
• 確定事件的影響。這有助于調整在后續措施中投資所需的工作量。只有相對嚴重的事件才需要一個深入的過程，不要對每一個不可能產生持久影響的小問題都進行回顧，從而使回顧正常化。
• 不要停留在舒適的答案上。深入挖掘，不必擔心個人的自負。目標是改進流程，而不是責怪個人或感到內疚。
• 優先考慮本可以防止或大大降低事件嚴重程度的行動項目。目標是盡可能少的行動項目，每個項目都有關鍵的優先級。

就不止步于“舒適的答案”而言，重要的是要確定并解決長期可靠性的根本原因。以下是一些可能導致服務中斷的表面級別問題的示例：

• 推送配置時出現的人為錯誤
• 不可靠的上游依賴性導致無響應。
• 交通高峰導致我們的服務暫時無法使用。

根據這些診斷，很難提出長期提高可靠性的行動項目。另一方面，更深層次的根本原因聽起來可能是：

• 我們的系統允許在沒有安全檢查的情況下將無效配置部署到整套業務。
• 我們的服務沒有處理上游的不可用性，并加劇了停機。
• 我們的服務沒有保護自己不受過度流量的影響。

解決根本原因可能更具挑戰性，但這對于實現長期可靠性至關重要。這只是我們在運營方面應該努力的一個簡短概述，但還有更多的東西需要探索和考慮。從事件響應協議到容量規劃，有許多細微差別和最佳實踐需要注意。

7、系統可靠性中的人為因素

雖然程序和機制在確保系統可靠性方面發揮著至關重要的作用，但最終是人類將其付諸實踐。因此，這不僅僅是要擁有正確的工具，還要培養正確的心態，為這些機制注入活力，使其有效運行。以下是有助于（不僅如此）保持可靠性的一些關鍵品質和習慣：

• 與其他團隊和組織合作，以共享知識并朝著共同目標努力。
• 一定程度的謙遜和對新信息的開放態度，以適應和發展系統。
• 專注于簡單性和工藝性，以創建可進化和可維護的系統。
• 行動驅動、注重結果的心態，避免停滯不前和猶豫不決。
• 一種類似于兒童的好奇和實驗方法，不斷尋求了解系統是如何工作的，并找到改進它的方法。

8、總結

確保系統的可靠性是一項全面的工作，包括找出正確的指標，考慮到彈性進行設計，以及實施可靠性測試和操作。通過關注可用性、功能性和滿足最重要的需求，組織可以更好地轉化客戶價值，并相應地調整風險和優先級。

建立和維護一個即使在最惡劣的條件下也能處理的系統，不僅有助于推動業務成功并取悅客戶，而且還能給從事該系統的人帶來成就感。可靠性是一個持續的過程，需要關注、技能和紀律。通過遵循最佳實踐，不斷挑戰系統，培養有韌性的心態，團隊和組織可以創建強大可靠的系統，能夠承受任何挑戰。

原文鏈接：https://dzone.com/articles/the-art-of-being-ready-reliability-in-extreme-cond