Well-Architected Framework：可靠性支柱

Last reviewed 2025-02-14 UTC

Google Cloud 架構完善架構的可靠性支柱提供原則和建議，協助您在 Google Cloud中設計、部署及管理可靠的工作負載。

本文適用於雲端架構師、開發人員、平台工程師、管理員和網站可靠性工程師。

可靠性是指系統在定義的條件下，持續執行預期功能並維持不間斷服務的能力。確保穩定性的最佳做法包括冗餘、容錯設計、監控和自動復原程序。

復原能力是穩定性的一環，是指系統在發生故障或意外中斷時，能夠維持效能並從中復原的能力。Google Cloud 功能 (例如多區域部署、自動備份和災害復原解決方案) 有助於提升系統的復原能力。

可靠性對雲端策略至關重要，原因如下：

  • 盡量縮短停機時間：停機可能會導致收益損失、生產力降低，以及聲譽受損。彈性架構可確保系統在發生故障時能繼續運作，或從故障中有效復原。
  • 提升使用者體驗：使用者期望與技術互動時能順暢無礙。彈性系統有助於維持一致的效能和可用性，即使在需求量大或發生意外問題時，也能提供可靠的服務。
  • 資料完整性：故障可能會導致資料遺失或毀損。彈性系統會實作備份、備援和複製等機制，保護資料並確保資料準確且可存取。
  • 業務持續性：貴商家仰賴技術來執行重要作業。彈性架構有助於確保在發生災難性故障後，業務功能仍能持續運作，不會受到重大干擾，並能迅速復原。
  • 法規遵循：許多產業對系統可用性和資料保護都有法規要求。彈性架構可確保系統維持運作和安全，協助您符合這些標準。
  • 降低長期成本：彈性架構需要前期投資，但彈性有助於隨著時間推移降低成本，因為彈性可避免代價高昂的停機時間、避免反應式修正，並提高資源使用效率。

組織思維

如要確保系統穩定可靠，您需要擬定計畫並建立策略。這項策略必須包含教育訓練，以及優先處理可靠性問題的權限，同時兼顧其他計畫。

明確指出整個機構都必須負責確保可靠性，包括開發、產品管理、營運、平台工程和網站可靠性工程 (SRE)。即使是行銷和銷售等以業務為主的群組，也可能影響可靠性。

每個團隊都必須瞭解自家應用程式的可靠性目標和風險。團隊必須遵守這些規定。可靠性和一般產品功能開發之間的衝突必須優先處理，並視情況上報。

從整體角度規劃及管理可靠性，涵蓋所有職能和團隊。建議您設立卓越雲端中心 (CCoE)，並納入可靠性支柱。詳情請參閱「透過卓越雲端中心，最佳化貴機構的雲端歷程」。

可靠性重點領域

設計、部署及管理可靠系統時執行的活動，可歸類為下列重點領域。這個支柱中的每項可靠性原則和建議，都與其中一個重點領域相關。

  • 範圍界定：如要瞭解系統，請詳細分析其架構。您需要瞭解元件、元件的運作和互動方式、資料和動作在系統中的流動方式，以及可能發生的錯誤。找出潛在的失敗、瓶頸和風險，協助您採取行動來降低這些問題。
  • 觀察：為避免系統故障，請導入全面且持續的觀察和監控機制。透過這項觀察結果，您可以瞭解趨勢並主動找出潛在問題。
  • 回應：為減少失敗造成的影響，請適當回應並有效率地復原。自動回覆也有助於減少失敗造成的影響。即使經過規劃和控管，仍可能發生故障。
  • 學習：從每次體驗中學習，並採取適當行動，避免失敗再次發生。

核心原則

架構完善架構可靠性支柱的建議，會對應至下列核心原則：

貢獻者

作者：

其他貢獻者：

根據使用者體驗目標定義可靠性

Google Cloud Well-Architected Framework 的可靠性支柱包含這項原則，可協助您評估使用者體驗，然後將評估結果對應至可靠性目標和指標。

這項原則與可靠性的範圍 焦點領域相關。

原則總覽

可觀測性工具會提供大量資料，但並非所有資料都與對使用者的影響直接相關。舉例來說，您可能會發現 CPU 使用率偏高、伺服器作業緩慢，甚至是工作當機。不過，如果這些問題不會影響使用者體驗，就不算中斷服務。

如要評估使用者體驗，您必須區分內部系統行為和使用者遇到的問題。著重於使用者要求成功率等指標。請勿只依據以伺服器為中心的指標 (例如 CPU 用量)，這可能會導致您對服務穩定性做出誤導性結論。真正的可靠性是指使用者能持續有效地使用您的應用程式或服務。

建議

為協助您有效評估使用者體驗，請參考下列各節的建議。

評估使用者體驗

如要真正瞭解服務的穩定性，請優先考量反映使用者實際體驗的指標。例如，測量使用者的查詢成功率、應用程式延遲時間和錯誤率。

最好直接從使用者的裝置或瀏覽器收集這類資料。如果無法直接收集資料，請逐步將評估點從系統中的使用者移開。舉例來說，您可以將負載平衡器或前端服務做為測量點。這種做法有助於您找出並解決問題，以免使用者受到重大影響。

分析使用者歷程

如要瞭解使用者與系統的互動情形，可以使用追蹤工具，例如 Cloud Trace。追蹤使用者在應用程式中的歷程，找出可能導致使用者體驗不佳的瓶頸和延遲問題。Cloud Trace 會擷取服務架構中每個躍點的詳細效能資料。這項資料有助於更有效率地找出並解決效能問題，進而提供更可靠且令人滿意的使用者體驗。

設定實際可行的可靠性目標

Google Cloud Well-Architected Framework 的可靠性支柱中，這項原則可協助您為 Google Cloud中的工作負載，定義技術上可行的可靠性目標。

這項原則與可靠性的範圍 焦點領域相關。

原則總覽

設計系統時，只要確保可靠性足以讓使用者感到滿意即可。這可能看似違反直覺，但以 100% 可靠性為目標通常不是最有效的策略。可靠性越高，成本可能大幅增加，包括財務投資和創新潛力受限。如果使用者對目前的服務水準感到滿意，那麼進一步提升滿意度的努力可能無法帶來高投資報酬率。這樣一來，您就能將資源用於其他用途。

您需要判斷使用者滿意的可靠性程度，並找出增量改善的成本開始超過效益的點。當您判斷達到足夠的可靠性層級時，就能策略性地分配資源，並專注於為使用者提供更高價值的改善和功能。

建議

如要設定合理的可靠性目標，請參考下列小節的建議。

接受部分失敗並優先處理元件

目標是達到高可用性 (例如 99.99% 的運作時間)，但請勿將運作時間設為 100%。瞭解失敗在所難免。

100% 正常運作時間與 99.99% 目標之間的差距，就是容許的故障時間。這個差距通常稱為「錯誤預算」。錯誤預算可協助您承擔風險並進行創新，這對任何企業維持競爭力都至關重要。

優先確保系統中最重要元件的可靠性。 接受容錯程度較高的非關鍵元件。

在可靠性和成本之間取得平衡

如要判斷系統的最佳可靠性等級，請進行詳盡的成本效益分析。

請考量系統需求、失敗的後果，以及貴機構對特定應用程式的風險容許度等因素。請務必考量災難復原指標，例如復原時間目標 (RTO) 和復原點目標 (RPO)。根據預算和其他限制，決定可接受的可靠性等級。

尋找提高效率和降低成本的方法，同時不影響重要的可靠性功能。

透過資源備援機制建構高可用性系統

Google Cloud 架構完善架構的可靠性支柱中，這項原則提供相關建議，協助您規劃、建構及管理資源備援，避免發生故障。

這項原則與可靠性的範圍 焦點領域相關。

原則總覽

決定所需的可靠性等級後，您必須設計系統，避免出現任何單一故障點。系統中的每個重要元件都必須在多部機器、區域和地區之間複製。 舉例來說，重要資料庫不能只位於一個區域，中繼資料伺服器也不能只部署在單一可用區或區域。在這些範例中，如果唯一的可用區或區域發生中斷，系統就會發生全球性中斷。

建議

如要建構備援系統，請參考下列小節的建議。

找出故障網域並複製服務

從個別 VM 到區域，規劃系統的故障網域，並設計故障網域的備援機制。

為確保高可用性，請將服務和應用程式分散並複製到多個可用區和區域。設定系統自動容錯移轉，確保服務和應用程式在區域或地區中斷時仍可使用。

如需多區域和多地區架構的範例，請參閱「在 Google Cloud中為工作負載設計可靠的基礎架構」。

及時偵測及解決問題

持續追蹤失敗網域的狀態，以便及時偵測及解決問題。

您可以透過 Google Cloud Service Health 資訊主頁，監控所有區域的 Google Cloud 服務目前狀態。您也可以使用 Personalized Service Health 查看與專案相關的事件。 您可以使用負載平衡器偵測資源健康狀態，並自動將流量導向健康狀態良好的後端。詳情請參閱健康狀態檢查總覽。

測試容錯移轉情境

就像消防演習一樣，定期模擬故障狀況，驗證複製和容錯移轉策略的成效。

詳情請參閱「模擬區域 MIG 的可用區中斷情形」和「在 GKE 區域叢集中模擬可用區故障」。

善用水平擴充性

Google Cloud Well-Architected Framework 的可靠性支柱中，這項原則提供相關建議，協助您使用水平擴充功能。使用水平擴充功能，有助於確保Google Cloud 中的工作負載能有效擴充並維持效能。

這項原則與可靠性的範圍 焦點領域相關。

原則總覽

將系統重新架構為水平架構。如要因應流量或資料成長，可以新增更多資源。您也可以在資源未使用時移除。

如要瞭解水平擴充的價值，請考量垂直擴充的限制。

垂直擴充的常見情境是使用 MySQL 資料庫做為主要資料庫，儲存重要資料。隨著資料庫用量增加，需要更多 RAM 和 CPU。最終，資料庫會達到主機的記憶體上限，因此需要升級。這個程序可能需要重複幾次。問題在於資料庫的成長幅度有硬性限制。VM 大小並非無限。資料庫可能會達到無法再新增資源的程度。

即使資源不受限制，大型 VM 仍可能成為單一故障點。主要資料庫 VM 的任何問題都可能導致錯誤回應，或造成影響所有使用者的全系統中斷。如「透過資源冗餘建構高可用性系統」一文所述，請避免單點故障。

除了這些擴充限制外，垂直擴充的成本往往也比較高。隨著運算能力和記憶體容量更大的機器問世，成本可能會大幅增加。

相較之下，水平擴展的成本可能較低。在設計為可擴充的系統中，水平擴充的潛力幾乎不受限。

建議

如要從單一 VM 架構轉換為水平多機器架構，您需要仔細規劃並使用適當的工具。如要協助您達成水平擴充，請參考下列小節的建議。

使用代管服務

代管服務可免除手動管理水平擴縮的需要。舉例來說，您可以使用 Compute Engine 代管執行個體群組 (MIG) 新增或移除 VM，以水平調度應用程式資源。對於容器化應用程式，Cloud Run 是無伺服器平台，可根據傳入的流量自動調整無狀態容器的資源配置。

推廣模組化設計

模組化元件和清楚的介面可協助您視需要調整個別元件，而不必調整整個應用程式。詳情請參閱效能最佳化主題中的「推廣模組化設計」。

實作無狀態設計

設計無狀態應用程式，也就是不儲存本機資料。這樣一來，您就能新增或移除例項，不必擔心資料一致性的問題。

使用可觀測性偵測潛在故障

Google Cloud Well-Architected Framework 的可靠性支柱中，這項原則提供相關建議，協助您主動找出可能發生錯誤和失敗的領域。

這項原則與可靠性的觀察 重點領域相關。

原則總覽

如要維持及提升工作負載在Google Cloud中的可靠性，您需要使用指標、記錄和追蹤記錄，實作有效的觀測功能。

  • 指標是您想在特定時間間隔內追蹤的應用程式活動數值。舉例來說，您可能想追蹤要求率和錯誤率等技術指標，這些指標可用做服務水準指標 (SLI)。您可能也需要追蹤特定應用程式的業務指標，例如訂單數和收到的款項。
  • 記錄檔是應用程式或系統中發生的個別事件，並附有時間戳記。事件可能是失敗、錯誤或狀態變更。記錄可能包含指標，您也可以將記錄用於 SLI。
  • 追蹤記錄代表單一使用者或交易在多個獨立應用程式或應用程式元件中的歷程。舉例來說，這些元件可以是微服務。追蹤記錄可協助您追蹤旅程中使用的元件、瓶頸所在位置，以及旅程所需時間。

您可以透過指標、記錄和追蹤記錄持續監控系統。全面監控可協助您找出錯誤發生的位置和原因。您也可以在發生錯誤前偵測潛在的故障。

建議

如要有效偵測潛在失敗，請考慮下列小節中的建議。

取得全方位的洞察資料

如要追蹤回應時間和錯誤率等重要指標，請使用 Cloud Monitoring 和 Cloud Logging。這些工具也有助於確保指標持續符合工作負載需求。

如要根據資料做出決策，請分析預設服務指標，瞭解元件依附元件及其對整體工作負載效能的影響。

如要自訂監控策略，請使用 Google Cloud SDK 建立及發布自己的指標。

主動排解問題

在 Google Cloud中，針對工作負載的所有元件實作健全的錯誤處理機制，並啟用記錄功能。啟用記錄，例如 Cloud Storage 存取記錄和 VPC 流量記錄。

設定記錄時，請考量相關費用。如要控管記錄費用，您可以在記錄接收器上設定排除篩選器，排除特定記錄檔的儲存作業。

充分善用資源

監控 CPU 用量、網路 I/O 指標和磁碟 I/O 指標，偵測 GKE、Compute Engine 和 Dataproc 等服務中資源配置不足和過度配置的情況。如需支援服務的完整清單，請參閱 Cloud Monitoring 總覽。

確定警告處理順序

針對快訊，請著重於重要指標、設定適當的門檻，盡量避免快訊疲勞，並確保及時回應重大問題。這種有目標的處理方式可讓您主動維護工作負載的可靠性。詳情請參閱快訊總覽。

設計優雅降級機制

Google Cloud Well-Architected Framework 的可靠性支柱中，這項原則提供相關建議，協助您設計 Google Cloud 工作負載 Google Cloud ，確保工作負載在發生故障時能正常運作。

這項原則與可靠性的回應 焦點區域相關。

原則總覽

系統負載過高時，仍可繼續運作，但效能或準確度可能會降低。即使系統無法以最佳狀態運作，也能確保系統持續可用，避免完全故障。當負載恢復到可管理的水準時，系統就會恢復完整功能。

舉例來說，在負載量較高的期間，Google 搜尋會優先顯示排名較高的網頁結果，可能因此犧牲部分準確度。負載減少時，Google 搜尋會重新計算搜尋結果。

建議

如要設計系統，確保優雅降級，請參考下列小節的建議。

實作節流

請確保備用資源可獨立處理過載狀況，並在高流量情境中節流處理傳入的要求。這種做法有助於避免因區域間的過多流量轉移而導致連鎖故障。

在流量高峰期，請使用 Apigee 等工具控管 API 要求速率。您可以設定政策規則，反映您希望如何縮減要求。

提早捨棄超額要求

設定系統，在前端層捨棄過多的要求，以保護後端元件。捨棄部分要求可避免全域故障，並讓系統更順暢地復原。採用這種做法時，部分使用者可能會遇到錯誤。不過，相較於斷路等做法 (過載時所有流量都會遭到捨棄)，您可以盡量減少中斷造成的影響。

處理部分錯誤和重試

建構應用程式，順暢處理部分錯誤並重試。這項設計有助於確保在高負載情境下，盡可能提供最多流量。

測試過載情境

如要驗證節流和要求捨棄機制是否有效運作，請定期模擬系統過載情況。測試有助於確保系統已準備好因應實際流量暴增的情況。

監控流量尖峰

使用分析和監控工具預測及因應流量暴增情形，避免過載。及早偵測及回應有助於在需求量高的期間維持服務可用性。

測試從故障狀況復原的程序

Google Cloud 架構完善架構的可靠性支柱原則提供相關建議，協助您設計及執行測試，以便在發生故障時進行復原。

這項原則與可靠性的學習 重點領域相關。

原則總覽

為確保系統能從故障中復原，您必須定期執行測試，包括區域容錯移轉、版本回溯，以及從備份還原資料。

這項測試可協助您練習回應對可靠性造成重大風險的事件，例如整個區域發生服務中斷。 這項測試也有助於確認系統在發生中斷時是否能正常運作。

萬一整個區域發生故障，您需要將所有流量容錯移轉至其他區域。在工作負載的正常運作期間，資料修改後必須從主要區域同步至容錯移轉區域。您必須確認複製的資料一律為最新資料，以免使用者發生資料遺失或工作階段中斷的情況。負載平衡系統也必須能夠隨時將流量轉移至容錯移轉區域，且不會中斷服務。為了盡量縮短區域中斷後的停機時間，營運工程師也必須盡可能在短時間內，手動且有效率地將使用者流量從該區域移出。這項作業有時稱為「排空區域」，也就是停止傳入區域的流量，並將所有流量移至其他位置。

建議

設計及執行失敗復原測試時，請參考下列小節的建議。

定義測試目標和範圍

明確定義測試要達成的目標。舉例來說，您的目標可以包括：

  • 驗證復原時間目標 (RTO) 和復原點目標 (RPO)。詳情請參閱「DR 規劃的基本概念」。
  • 在各種故障情況下，評估系統的復原能力和容錯能力。
  • 測試自動容錯移轉機制的成效。

決定測試範圍涵蓋哪些元件、服務或區域。範圍可以包括前端、後端和資料庫等特定應用程式層級，也可以包括 Cloud SQL 執行個體或 GKE 叢集等特定 Google Cloud 資源。範圍也必須指定任何外部依附元件，例如第三方 API 或雲端互連。

準備測試環境

選擇適當的環境，最好是複製生產設定的暫存或沙箱環境。如果在正式環境中進行測試，請務必準備好安全措施，例如自動監控和手動復原程序。

建立備份方案。為重要資料庫和服務建立快照或備份，以免測試期間發生資料遺失。如果自動容錯移轉機制失敗，請確保團隊已準備好進行手動介入。

為避免測試中斷，請確認 IAM 角色、政策和容錯移轉設定正確無誤。確認測試工具和指令碼具備必要權限。

向利害關係人 (包括營運、開發運作和應用程式擁有者) 說明測試時間表、範圍和潛在影響。向利害關係人提供預估時間表，以及測試期間的預期行為。

模擬失敗情境

使用 Chaos Monkey 等工具規劃及執行失敗作業。您可以使用自訂指令碼模擬重要服務的故障情形，例如多區域 GKE 叢集中的主要節點關機，或是 Cloud SQL 執行個體遭到停用。您也可以根據測試範圍，使用防火牆規則或 API 限制，透過指令碼模擬區域網路中斷。逐步擴大故障情境，觀察系統在各種情況下的行為。

在發生中斷時，導入工作負載測試和失敗情境，模擬實際使用情況。測試連鎖故障的影響，例如後端服務無法使用時，前端系統的行為。

如要驗證設定變更，並評估系統抵禦人為錯誤的能力，請測試涉及設定錯誤的情境。舉例來說，使用不正確的 DNS 容錯移轉設定或不正確的 IAM 權限執行測試。

監控系統行為

監控負載平衡器、健康狀態檢查和其他機制如何重新導向流量。使用 Cloud Monitoring 和 Cloud Logging 等 Google Cloud 工具，擷取測試期間的指標和事件。

在失敗模擬期間和之後，觀察延遲時間、錯誤率和輸送量的變化，並監控整體效能影響。找出使用者體驗的任何退化或不一致之處。

確認系統會針對重要事件 (例如服務中斷或容錯移轉) 產生記錄並觸發快訊。您可以使用這項資料，驗證警報和事件回應系統的有效性。

根據 RTO 和 RPO 驗證復原作業

測量系統在發生故障後恢復正常運作所需的時間，然後將這項資料與定義的 RTO 進行比較，並記錄任何差距。

確保資料完整性和可用性符合 RPO。如要測試資料庫一致性，請比較故障前後的資料庫快照或備份。

評估服務還原作業，確認所有服務都已還原至正常運作狀態，且使用者受到的影響降至最低。

記錄及分析結果

記錄每個測試步驟、失敗情境和對應的系統行為。請附上時間戳記、記錄檔和指標，以利進行詳細分析。

強調測試期間觀察到的瓶頸、單點故障或意外行為。為協助您決定修正問題的優先順序，請依嚴重程度和影響程度將問題分類。

建議改善系統架構、容錯移轉機制或監控設定。根據測試結果，更新任何相關的容錯移轉政策和劇本。向利害關係人提交事後檢討報告。報表應總結結果、經驗教訓和後續步驟。詳情請參閱「徹底進行事後檢討」。

反覆測試及修正

為驗證持續的可靠性和韌性，請規劃定期測試 (例如每季一次)。

在不同情境下執行測試，包括基礎架構變更、軟體更新和流量負載增加。

使用 CI/CD 管道將可靠性測試整合到開發生命週期中，自動執行容錯移轉測試。

在事後檢討期間，請根據利害關係人和使用者的意見回饋，改善測試程序和系統復原能力。

執行資料遺失復原測試

Google Cloud Well-Architected Framework 的可靠性支柱中，這項原則提供相關建議，協助您設計及執行資料遺失復原測試。

這項原則與可靠性的學習 重點領域相關。

原則總覽

為確保系統能在資料遺失或損毀時復原，您需要針對這些情境執行測試。資料遺失可能是軟體錯誤或某種天災所致。發生這類事件後，您需要從備份還原資料，並使用剛還原的資料，讓所有服務再次上線。

建議您使用三項條件判斷這類復原測試是否成功：資料完整性、復原時間目標 (RTO) 和復原點目標 (RPO)。如要進一步瞭解 RTO 和 RPO 指標，請參閱「DR 規劃的基本概念」。

資料還原測試的目標是定期驗證貴機構是否能持續滿足業務持續性需求。除了評估復原時間目標 (RTO) 和復原點目標 (RPO) 之外，資料還原測試也必須包含整個應用程式堆疊和所有重要基礎架構服務的測試，並使用還原的資料。這是為了確認整個部署的應用程式在測試環境中運作無誤。

建議

設計及執行資料遺失復原測試時，請參考下列小節的建議。

確認備份一致性並測試還原程序

您必須確認備份內容包含一致且可用的資料快照，以便還原資料，立即讓應用程式恢復運作。如要驗證資料完整性，請設定自動一致性檢查，在每次備份後執行。

如要測試備份，請在非正式環境中還原備份。為確保備份資料能有效率地還原，且還原的資料符合應用程式需求，請定期模擬資料復原情境。記錄資料還原步驟，並訓練團隊在發生故障時有效執行這些步驟。

安排定期備份

為盡量減少還原期間的資料遺失，並達到 RPO 目標，請務必定期排定備份作業。根據復原點目標設定備份頻率。舉例來說，如果 RPO 為 15 分鐘，請安排備份作業至少每 15 分鐘執行一次。調整備份間隔，降低資料遺失的風險。

使用 Cloud Storage、Cloud SQL 自動備份或 Spanner 備份等 Google Cloud 工具，排定及管理備份作業。對於重要應用程式，請使用近乎連續的備份解決方案，例如 Cloud SQL 的時間點復原 (PITR) 功能，或是大型資料集的增量備份。

定義及監控 RPO

根據業務需求設定明確的 RPO，並監控是否符合 RPO。 如果備份間隔超過定義的 RPO，請使用 Cloud Monitoring 設定快訊。

監控備份健康狀態

使用Google Cloud 備份和 DR 服務或類似工具追蹤備份的健康狀態，並確認備份內容儲存在安全可靠的位置。確保備份資料複製到多個區域，進一步提升復原能力。

規劃備份以外的情境

結合備份與災難復原策略，例如主動-主動容錯移轉設定或跨區域複製，可在極端情況下縮短復原時間。詳情請參閱「災難復原規劃指南」。

徹底檢討

Google Cloud Well-Architected 架構的可靠性支柱中，這項原則提供相關建議，協助您在發生故障和事件後，有效進行事後檢討。

這項原則與可靠性的學習 重點領域相關。

原則總覽

事後檢討報告會記錄事件、影響、為減輕或解決事件而採取的行動、根本原因，以及為避免事件重演而採取的後續行動。事後檢討的目的是從錯誤中學習，而不是追究責任。

下圖顯示事後檢討的工作流程：

事後檢討工作流程。

事後檢討工作流程包含下列步驟：

  • 建立事後檢討報告
  • 擷取事實
  • 找出並分析根本原因
  • 為將來做規劃
  • 執行計畫

在重大事件和非重大事件 (例如以下事件) 發生後，進行檢討分析：

  • 使用者可見的停機時間或效能降低程度超過特定門檻。
  • 任何類型的資料遺失。
  • 值班待命工程師的介入措施，例如回溯版本或重新導向流量。
  • 解決時間超過定義的門檻。
  • 監控失敗，通常表示需要手動發現事件。

建議

在事件發生前定義事後檢討條件，讓所有人都知道何時需要進行事後檢討。

如要有效進行事後檢討，請參考下列小節的建議。

以不互相責難的態度檢討

有效的結案報告會著重於程序、工具和技術，不會將責任歸咎於個人或團隊。檢討報告分析的目的是改善技術和未來，而不是找出罪魁禍首。犯錯在所難免，目標應是分析錯誤並從中學習。

以下範例顯示指責式回饋與無責式回饋的差異：

  • 歸咎責任的意見：「我們需要重寫整個複雜的後端系統！過去三季以來，每週都會發生中斷問題，相信大家都很厭倦這種零星的修正方式。認真地說，如果我再收到一次呼叫，我就要自己重寫了…」
  • 無責回饋：「重寫整個後端系統的行動項目，或許能實際防止這些網頁繼續發生問題。這個版本的維護手冊相當長，很難完全掌握。相信日後的值班工程師會感謝我們！"

確保所有目標對象都能看懂結案報告

針對您打算納入報告的每項資訊，評估該資訊是否重要且必要，有助於目標對象瞭解發生了什麼事。您可以將補充資料和說明移至報表的附錄。審查人員可以要求提供更多資訊。

避免使用複雜或過度設計的解決方案

開始尋找問題解決方案前，請先評估問題的重要性，以及問題再次發生的可能性。為解決不太可能再次發生的問題，在系統中增加複雜度可能會導致不穩定性增加。

盡可能廣泛分享檢討報告

為確保問題獲得解決，請向廣大目標對象發布事後檢討結果，並尋求管理階層的支援。事後檢討的價值與事後檢討後發生的學習成正比。當更多人從事件中學習，類似的失敗再次發生的可能性就會降低。