共用方式為

可靠性取捨

  • 發行項

可靠的工作負載一致符合其定義的可靠性目標。 最好是規避影響可靠性的事件，以達到已建立的復原目標。 不過，實際上，工作負載必須容忍和控制這類事件的影響，並在作用中故障期間維持預先決定層級的作業。 即使在災害期間，可靠的工作負載也必須在指定時間內復原到特定狀態，這兩者在專案關係人之間都已達成一致。 事件回應計劃可讓您達成快速偵測和復原非常重要。

在工作負載的設計階段，您必須考慮根據可靠性設計原則和可靠性設計檢閱檢查清單中的建議，決策如何影響其他要素的目標和優化。 某些決策可能會有利於某些支柱，但對其他人構成取捨。 本文說明在設計工作負載架構和作業以維護可靠性時，工作負載小組可能會遇到的取捨範例。

使用安全性的可靠性取捨

取捨：工作負載介面區增加。 安全性支柱會排定縮減和包含的介面區優先順序，以將攻擊媒介降到最低，並減少安全性控制的管理。

  • 可靠性通常是透過復寫取得。 複寫可能發生在元件層級、數據層級，甚至是地理層級。 根據設計，復本會增加工作負載的介面區。 從安全性的觀點來看，偏好減少和包含的介面區，以將潛在的攻擊媒介降到最低，並簡化安全性控件的管理。

  • 同樣地，災害復原解決方案，例如備份，會增加工作負載的介面區。 不過，它們通常會與工作負載的運行時間隔離。 這些解決方案需要實作額外的安全性控制，這可能專屬於災害復原方法。

  • 為了達到可靠性目標，架構可能需要額外的元件，這會增加介面區。 例如，可能會新增訊息總線，以透過分離來讓要求具有復原性。 這會增加複雜性，藉由新增需要保護的新元件來增加工作負載的介面區，可能以系統尚未使用的方式。 這些元件通常會伴隨著額外的程式代碼和連結庫，以支援其使用或一般可靠性模式，這也會增加應用程式介面區。

取捨：安全性控制略過。 安全性支柱建議所有控件在正常和壓力的系統中都保持作用中。

  • 當工作負載遇到在作用中事件回應下解決的可靠性事件時，緊急狀況可能會給工作負載小組造成壓力，以略過針對例行存取優化的安全性控制。

  • 疑難解答活動可能會導致小組暫時停用安全性通訊協定，讓已承受壓力的系統可能會面臨額外的安全性風險。 安全性通訊協定也不會立即重新建立的風險。

  • 安全性控件的細微實作，例如自定義角色型訪問控制指派或縮小防火牆規則，引進設定複雜度和敏感度，增加設定錯誤的機會。 使用廣泛的規則來減輕這種潛在的可靠性影響，會削弱這三個 零信任 架構原則。

取捨：舊軟體版本。 安全性要素鼓勵廠商安全性修補程式的「取得最新狀態、保持最新狀態」的方法。

  • 套用安全性修補程式或軟體更新可能會中斷目標元件，導致軟體變更期間無法使用。 延遲或避免修補可能會避免潛在的可靠性風險，但會讓系統不受不斷演變的威脅保護。

  • 上述考慮也適用於工作負載的程序代碼。 例如，它適用於使用舊連結庫的應用程式程序代碼，以及使用舊基底映射的容器。 如果更新和部署應用程式程式代碼被視為未明確的可靠性風險，應用程式就會隨著時間而暴露在額外的安全性風險中。

成本優化的可靠性取捨

取捨：增加實作備援或浪費。 成本優化的工作負載可將使用量過低的資源降到最低，並避免過度布建資源。

  • 復寫是可靠性的重要策略。 具體來說，策略是有足夠的復寫來處理指定數目的並行節點失敗。 更多並行節點失敗的容錯需要較高的複本計數，這會導致成本增加。

  • 過度布建是吸收系統非預期負載的另一種技術，例如在故障轉移事件期間，否則可能會導致可靠性問題。 未使用的任何過剩容量都會被視為浪費。

  • 如果工作負載使用過度滿足工作負載恢復點和時間目標的災害復原解決方案，則過多會導致成本較高，因為浪費。

  • 工作負載部署本身是可靠性影響的潛在來源，而且這種影響通常會透過藍色/綠色等部署策略，在部署時透過備援來減輕影響。 在安全部署期間，這種暫時性的資源重複通常會在這些期間增加工作負載的整體成本。 部署頻率會增加成本。

取捨：增加對不符合功能需求的作業投資。 成本優化的方法之一是評估任何已部署解決方案所提供的值。

  • 為了達到可靠性，系統需要可觀察性。 監視系統需要可觀察性數據傳輸和收集。 隨著監視功能的增加，數據的頻率和數量增加，導致額外的成本。

  • 工作負載中的可靠性能供性需要測試和演練。 設計和執行測試需要時間和潛在的特製化工具，這會產生成本。

  • 具有高可靠性目標的工作負載通常會有快速響應程式，需要技術小組成員成為正式通話輪替的一部分。 此程式會產生額外的人員成本，並因為可能導向其他地方的注意力而遺失商機成本。 這也會產生程式管理的潛在工具成本。

  • 與技術提供者的支援合約是可靠工作負載的重要元件。 因為支援層級過度布建而未使用的支援合約會產生浪費。

使用卓越營運的可靠性取捨

取捨：增加作業複雜度。 卓越營運，例如可靠性本身，會優先簡化。

  • 可靠性通常會增加工作負載的複雜性。 隨著工作負載的複雜性增加，工作負載的操作元素也可以增加，以支援在部署協調和設定介面區方面新增的元件和程式。

  • 擁有工作負載的完整監視策略是卓越營運的關鍵部分。 將其他元件引入架構以實作可靠性設計模式，會導致更多的數據源要管理，增加實作分散式追蹤和可檢視性的複雜性。

  • 使用多個區域來克服單一區域資源容量限制和/或實作主動/主動架構，會增加工作負載作業管理的複雜性。 這項複雜性是由管理多個區域的需求所引進，而且需要管理它們之間的數據復寫。

取捨：增加產生小組知識和意識的努力。 營運卓越支柱建議保留和維護程式與拓撲的檔存放庫。

  • 隨著工作負載透過新增可靠性元件和模式變得更強固，維護作業程式和成品檔需要更多時間。

  • 隨著工作負載中的元件數目增加，定型會變得更複雜。 這種複雜性會影響上線所需的時間。 複雜性也會增加追蹤產品藍圖和最新服務等級指引所需的知識。

效能效率的可靠性取捨

取捨：增加延遲。 效能效率需要系統才能達到使用者和數據流的效能目標。

  • 可靠性模式通常會納入數據復寫，以在複本故障中倖存下來。 復寫為可靠的數據寫入作業引進了額外的延遲，這會耗用特定使用者或數據流的一部分效能預算。

  • 可靠性有時會採用各種形式的資源平衡，將負載分散或轉散發至狀況良好的復本。 用於平衡的專用元件通常會影響平衡要求或程式的效能。

  • 將元件分散到地理界限或可用性區域，以在範圍影響中倖存下來，會在跨越這些可用性界限的元件之間的通訊中帶來網路等待時間。

  • 大量程式可用來觀察工作負載的健康情況。 雖然監視對於可靠性很重要，但檢測可能會影響系統效能。 隨著可觀察性增加，效能可能會降低。

取捨：過度布建增加。 效能效率支柱不建議過度布建，而是建議使用足夠的資源來滿足需求。

  • 自動調整作業不是瞬間的，因此無法可靠地處理無法成形或平滑的需求突然和急劇增加。 因此，透過較大的實例或更多實例過度布建是重要的可靠性策略，可考慮需求訊號與供應建立之間的延遲，以協助吸收高載。 未使用的容量會反駁效能效率的目標。

  • 有時候元件無法調整以回應需求，而且該需求無法完全預測。 使用大型實例來涵蓋最差的情況，會導致在該使用案例外部的情況下過度布建浪費。

探索其他要素的取捨：