什麼是可靠性標準以及如何保證？ -DZone

banq發表於2020-11-03

托馬斯·裡德（Thomas Reid）曾經寫道：“整個一條鏈並不比鏈條中最薄弱的節點更強大。” 這對於任何具有相互依賴的連結的系統都是如此，無論是文字鏈還是軟體應用程式中的依賴鏈。如果一個連結斷開，負載就會崩潰。
對於SaaS，PaaS，IaaS和其他服務提供商，此概念可以成就或破壞業務。這些服務的客戶希望提供商能夠提供高水平的可用性和效能，因為任何問題都可能導致他們自己的服務失敗。換句話說，他們服務客戶併產生收入的能力直接取決於其服務提供商的能力。這給提供商帶來了巨大的壓力，要求提供商最大化其服務的可用性，否則就有可能將客戶流失給更可靠的競爭對手。
為了避免這種情況，服務提供商需要主動為可用性設定高標準。我們將在此部落格文章中說明操作方法。
 

什麼是“可靠性標準”？
鏈條中的每個連結都有一定的故障點。如果增加了過多的重量，或者鏈節的形狀不佳（生鏽，鑄件缺陷，焊接不良等），則會斷裂。由於連結是直接相互連線的，因此如果其中一個失敗，則會破壞整個鏈。
這也適用於軟體。如果我們的客戶依賴我們的服務，那麼我們服務中的任何故障都將導致他們的失敗。我們需要確保為所有客戶提供始終如一的可靠和高效能的體驗。這聽起來似乎很明顯，但是讓我們考慮一下對客戶產生重大影響的SaaS中斷的真實示例。
Slack是超過75萬家公司使用的數字通訊平臺。在最近的一次事件中，效能下降使團隊很難聊天，共享檔案和搜尋訊息，這是當今遠端優先工作環境中的所有基本任務。Slack具有99.99％或更高可用性的可靠性標準，這意味著每季度15分鐘或更短的停機時間。結果，像這樣的事件通常很少發生並且很快得到解決。
 

如何保證可靠性標準？
保證可靠性標準是組織範圍內的工作，其中包括：

  1. 培養可靠的文化。
  2. 設定可靠性目標。
  3. 確定我們服務中的潛在故障模式。
  4. 驗證我們的事件響應和災難恢復計劃。

 

培育可靠性文化
可靠性不僅是工程團隊的責任，而是整個組織的責任，並且需要成為執行人員級別的KPI。不可靠的產品或服務可能會對整個業務產生重大影響。因此，每個人都需要了解可靠性對業務成功的重要性。對業務很重要的指標包括：

  1. 跟蹤對預算支出的可靠性改進。
  2. 發起人淨得分（NPS）和客戶體驗的變化。
  3. 50％和90％的請求的最高百分比延遲。
  4. 正常執行時間和延遲。

考慮可靠性可能需要組織學習對工程速度和效率的不同思考。例如，一個常見的挑戰是，領導層以可靠性為代價，優先處理其他任務（例如，構建新功能）的優先順序。換句話說，犧牲了可靠性而有利於新功能特徵的推出速度。這會產生摩擦，並可能導致可靠性測試被推遲到開發結束的情況，從而增加了影響客戶的事件和中斷的風險。歸根結底，功能只有對客戶可靠才有價值。我們希望在不滿足可靠性標準的情況下最大化特徵速度。
我們已經看到組織進行這種對話的一種方式是透過為應用程式建立儀表板來顯示其可靠性和效率之間的關係。這使整個組織能夠確定何時投資於可靠性方面的工作，以最大化業務成果，並使業務利益相關者與可靠性計劃保持一致。 
 

設定可靠性目標
接下來，我們需要一種方法來定義可靠性目標並衡量實現這些目標的進度。這有助於我們向客戶證明我們正在達到所建立的標準。
許多服務提供商使用服務級別協議（SLA），該協議透過合同向客戶承諾最低的服務質量。如果我們未能達到該水平，他們還向客戶提供追索權。SLA通常將服務質量定義為正常執行時間：例如，一個SLA承諾99％的可用性意味著我們的服務每月只能停機7個小時左右。
如果我們的服務是客戶體系中至關重要的組成部分，那麼這意味著我們的客戶只能像我們一樣可靠。換句話說，他們可以向客戶保證最多99％的可用性。要求高可靠性的客戶可能會避開此類服務，而轉向更可靠的提供商。這就是為什麼像AWS，GCP和Azure這樣的主要提供商傾向於提供99.99％或更高的SLA。為確保我們達到SLA，我們應將內部可靠性目標（我們的服務水平目標或SLO）設定為高於SLA。如果我們的SLA為99％，則我們的SLO應該至少為99.5％（每月停機3.65小時）。這不僅使我們超越了客戶的期望，而且在發生重大故障時也提供了餘地。
 

識別潛在的故障模式
現代應用程式很複雜，並且可能以無法預測的方式失敗。隨著工程團隊越來越多地遷移到Kubernetes和OpenShift等分散式雲原生系統，尤其如此。與傳統的應用程式體系結構相比，這些系統具有明顯的優勢，但是它們還增加了未知變數和故障模式（在我們本已脆弱的依賴鏈中提供了更多連結）。為了減少停機的風險，我們需要在發現服務或客戶面臨風險之前，主動找到並解決故障模式。
這是Chaos Engineering提供幫助的地方。混沌工程是一門科學，它透過注入精確的和量度的傷害以對系統進行有目的的實驗，以提高其彈性。透過觀察系統如何應對這種危害，我們可以實施更改並針對這些型別的故障加強系統。我們還了解有關係統行為的更多資訊，這在遷移到新平臺或體系結構時特別有用。
混沌工程有助於發現我們的連結中的弱點，而這些弱點是我們無法透過傳統測試發現的。像Gremlin這樣的Chaos Engineering解決方案使我們能夠以受控方式進行實驗，並觀察我們的系統如何反應。然後，我們的工程師可以解決這些弱點，加強供應鏈，讓我們向客戶承諾更高的可靠性標準。
 

建立和驗證響應計劃
無論我們的應用程式有多強的彈性，都會發生事件，連結會斷開，但是要讓負載下降，我們需要準備好快速修復鏈條。我們的第一步是制定事件響應計劃（也稱為劇本或操作手冊），以指導工程師快速有效地解決事件。對於災難（例如資料中心中斷和洪水），我們使用災難恢復計劃在發生史無前例的事件後儘快恢復服務。制定響應計劃可以防止大量停機，從而幫助我們恢復正常執行時間，並減少事件發生時對工程師的壓力。
對事件進行計劃的挑戰是驗證我們的計劃是否有效。擁有未經測試的劇本與沒有劇本一樣糟糕，因為我們無法保證它會在現實世界的事件中正常工作。當然，沒有人願意等待事件只是發現我們的計劃缺少關鍵的一步。相反，我們可以使用Chaos Engineering主動測試和驗證我們的計劃，而不必使我們的系統，客戶或業務面臨風險。

 

相關文章