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