OPS10-BP05 定義因應中斷的客戶通訊計劃 - AWS Well-Architected 架構
實作指引資源

OPS10-BP05 定義因應中斷的客戶通訊計劃

定義和測試系統中斷時您可以仰賴的通訊計劃，讓您的客戶和利害關係人在中斷期間持續獲得通知。使用者所使用的服務受到影響以及服務回到正常狀態時，直接與使用者通訊。

預期成果：

  • 您對於從排程維護到大型非預期失敗範圍的情況具有通訊計劃，包括叫用災難復原計劃。

  • 在您的通訊中，您提供清楚、透明的系統問題相關資訊，協助客戶避免第二次猜測他們系統的效能。

  • 您使用自訂錯誤訊息和狀態頁面，減少服務台請求的峰值，並且讓使用者了解情況。

  • 定期測試通訊計劃，以確認在實際發生中斷時，計劃會如預期執行。

常見的反模式：

  • 發生工作負載中斷，但是您沒有任何通訊計劃。使用者的請求淹沒您的故障票證系統，因為他們沒有任何有關中斷的資訊。

  • 您在中斷期間傳送電子郵件通知給您的使用者。通知不包含恢復服務的時間表，所以使用者無法針對中斷進行計劃。

  • 有中斷的通訊計劃，但是從未測試過。發生中斷且通訊計劃失敗，因為遺漏可以在測試中攔截的關鍵步驟。

  • 在中斷期間，您傳送給使用者的通知中包含太多 AWS NDA 之下的技術詳細資料和資訊。

建立此最佳實務的優勢：

  • 在中斷期間維護通訊可確保為客戶提供問題進度和解決方式預估時間的可見性。

  • 開發定義明確的通訊計劃，確認您的客戶和最終使用者了解情況，讓他們可以採取必要的額外步驟來緩解中斷的影響。

  • 透過適當的通訊和對於預定和意外中斷提高的感知，您可以改善客戶滿意度、限制意外的反應並且留住客戶。

  • 即時且透明的系統中斷通訊可建立信心，並且建立維護您與客戶之間關係所需的信任。

  • 中斷或危機期間經實證的通訊策略可減少可能會阻礙您的復原能力的推測和流言。

未建立此最佳實務時的風險暴露等級：中

實作指引

在中斷期間讓您的客戶了解狀況的通訊計劃是全方位的，並且涵蓋多個界面，包括面對客戶的錯誤頁面、自訂 API 錯誤訊息、系統狀態橫幅以及運作狀態頁面。如果您的系統包含已註冊的使用者，您可以透過例如電子郵件、簡訊或推送通知的傳訊通道進行通訊，將個人化訊息內容傳送給您的客戶。

客戶通訊工具

做為防禦的第一線，Web 和行動應用程式應該在中斷期間提供易讀且內容豐富的錯誤訊息，並且能夠將流量重新導向至狀態頁面。Amazon CloudFront 是全受管內容交付網路 (CDN)，其中包括定義和提供自訂錯誤內容的功能。CloudFront 中的自訂錯誤頁面是針對元件層級中斷的客戶傳訊良好第一層。CloudFront 也可以簡化管理和啟動狀態頁面，在預定和意外中斷期間攔截所有請求。

中斷隔離以離散服務時，自訂 API 錯誤訊息可以協助偵測和減少影響。Amazon API Gateway 可讓您為您的 REST API 設定自訂回應。這可讓您在 API Gateway 無法連線後端服務時，對 API 取用者提供清楚且有意義的訊息。特定系統功能由於服務層中斷而降級時，自訂訊息也可以用來支援中斷橫幅內容和通知。

直接傳訊是客戶傳訊最個人化的類型。Amazon Pinpoint 是可擴展多通道通訊的受管服務。Amazon Pinpoint 可讓您建置行銷活動，透過簡訊、電子郵件、語音、推送通知或您定義的自訂通道，廣泛地在您受影響的客戶之間廣播訊息。使用 Amazon Pinpoint 管理傳訊時，訊息行銷活動是明確定義、可測試，並且可以智慧化套用到目標客戶區段。一旦建立，可以依據活動排程或觸發行銷活動，並且可以輕易進行測試。

客戶範例

工作負載受損時，AnyCompany Retail 會將電子郵件通知傳送給他們的使用者。電子郵件說明哪個業務功能受損，並且提供服務何時還原的實際預估。此外，他們有狀態頁面，顯示有關工作負載運作狀態的即時資訊。通訊計劃每年兩次在開發環境中進行測試，驗證其有效性。

實作步驟

  1. 決定您的傳訊策略的通訊通道。考慮您的應用程式的架構層面，並且判斷最佳策略，將意見回饋交付給您的客戶。這可能包括一或多個概述的指引策略，包括錯誤和狀態頁面、自訂 API 錯誤回應或直接傳訊。

  2. 設計應用程式的狀態頁面。如果您判斷狀態或自訂錯誤頁面適合您的客戶，您需要為這些頁面設計您的內容和傳訊。錯誤頁面會向使用者說明為何應用程式無法使用、何時可再次變成可用，以及在此同時他們可以做什麼。如果您的應用程式使用 Amazon CloudFront，您可以提供自訂錯誤回應或在邊緣使用 Lambda 以轉譯錯誤並且重新撰寫頁面內容。CloudFront 也可讓您從應用程式內容切換到靜態 Amazon S3 內容來源這樣的目的地，其中包含您的維護或中斷狀態頁面。

  3. 為您的服務設計正確的一組 API 錯誤狀態。當 API Gateway 無法連線後端服務以及服務層例外狀況時所產生的錯誤訊息，可能不包含適合顯示給最終使用者的易讀訊息。不需要對您的後端服務進行程式碼變更，您可以設定 API Gateway 自訂錯誤回應將 HTTP 回應代碼對應至策劃 API 錯誤訊息。

  4. 從企業觀點設計訊息，讓它與系統的最終使用者相關，而且不包含技術詳細資料。請考慮您的對象並且調整您的訊息。例如，您可能會讓內部使用者採用利用替代系統的因應措施或手動程序。可能會要求外部使用者等候直到系統還原，或者訂閱更新以在系統還原時收到通知。針對多個情境定義已核准的傳訊，包括非預期中斷、預定維護和部分系統失敗，其中特定功能可能會降級或無法使用。

  5. 範本化及自動化您的客戶傳訊。一旦您建立您的訊息內容，您可以使用 Amazon Pinpoint 或其他工具來自動化您的傳訊行銷活動。使用 Amazon Pinpoint，您可以針對特定受影響的使用者建立客戶目標區段，並且將訊息轉換為範本。請參閱 Amazon Pinpoint 教學以了解如何設定傳訊行銷活動。

  6. 避免將傳訊功能緊密結合到您的面對客戶系統。您的傳訊策略不應該有與系統資料放區或服務的硬性相依性，以便確認您可以在遇到中斷時成功傳送訊息。請針對傳訊可用性考慮從多個可用區域或區域傳送訊息的能力。如果您使用 AWS 服務來傳送訊息，請透過控制平面操作利用資料平面來叫用您的傳訊。

實作計劃的工作量：高。開發通訊計劃以及傳送訊息的機制，需要大量工作量。

資源

相關的最佳實務：

相關文件：

相關範例：

相關服務：