本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL11-BP06 當事件影響可用性時傳送通知
當偵測到閥值超標時傳送通知，即使問題造成的事件已自動解決。
自動修復功能可讓您的工作負載變得可靠。不過，也可能會遮蔽需要解決的潛在問題。實作適當的監控和事件，讓您能夠偵測到問題模式 (包括自動修復功能處理的問題模式)，以解決根本原因問題。
具有韌性的系統可將降級事件立即傳達給權責團隊。這些通知應該透過一個或多個通訊管道傳送。
預期結果：違反閾值時，警示會立即傳送至營運團隊，例如錯誤率、延遲或其他關鍵金鑰效能指標 （KPI） 指標，以便儘快解決這些問題，並避免或將使用者影響降至最低。
常見的反模式：
-
傳送太多警示。
-
傳送不可採取行動的警示。
-
警示閾值設置太高 (太敏感) 或太低 (太遲鈍)。
-
不傳送外部相依性的警示。
-
在設計監控和警示時，不考慮微小故障。
-
進行修復自動化，但不通知權責團隊需要修復。
建立此最佳實務的好處：復原通知可讓營運和業務團隊了解服務降級，以便他們能夠立即反應，將平均偵測時間 （MTTD） 和平均修復時間 （） 降至最低MTTR。回復事件的通知也會確認您不會忽略不常發生的問題。
未建立此最佳實務時的風險暴露等級：中。若無法實作適當的監控和事件通知機制，您可能就無法偵測到問題模式 (包括自動修復功能處理的問題模式)。只有當使用者聯絡客服或偶然情況下，團隊才會注意到系統降級。
實作指引
定義監控策略時，觸發警示是常見的事件。此事件可能包含警示的識別碼、警示狀態 (例如 IN ALARM 或 OK) 以及觸發原因詳情。在許多情況下，系統應檢測到警示事件並傳送電子郵件通知。這是警示動作範例。警示通知對於可觀測性至關重要，因為它會通知權責人員有問題發生。然而，當可觀測性解決方案對事件的回應措施夠熟練後，便可以自動修復問題，無需人為介入。
建立 KPI- 監控警示後，應在超過閾值時將警示傳送至適當的團隊。這些警示也可用於觸發嘗試修復降級的自動化程序。
針對更複雜的閾值監控，則應考慮使用複合警示。複合式警示會使用數個 KPI監控警示，根據操作業務邏輯建立警示。 CloudWatch 警示可設定為傳送電子郵件，或使用 Amazon SNS整合或 Amazon 將事件記錄到第三方事件追蹤系統中 EventBridge。
實作步驟
根據監控工作負載的方式建立各種警示類型，例如：
-
應用程式警示可用來偵測工作負載任何無法正常運作的部分。
-
基礎設施警示會指出何時擴展資源。警示可以視覺化顯示在儀表板上，透過 Amazon SNS或電子郵件傳送警示，並使用 Auto Scaling 來擴展工作負載資源。
-
可建立簡單的靜態指示，以監控指標在指定評估期間內超過靜態閾值的時間。
-
複合警示可以涵蓋來自多個來源的複雜警示。
-
建立警示後，請建立適當的通知事件。您可以直接叫用 Amazon SNSAPI傳送通知，並連結任何自動化以進行修復或通訊。
-
整合 Amazon Health Aware
監控，以允許監控可能降級 AWS 的資源可見性。對於業務必要工作負載，此解決方案可讓您存取 AWS 服務的主動和即時警示。
資源
相關 Well-Architected 的最佳實務：
相關文件：
相關工具：
