您的工程團隊是否正在經歷警覺疲勞？ 問這8個問題

警報疲勞是處理運營和維護基礎設施的工程團隊的常見問題。

問題通常源於隨著團隊的成長和開始使用越來越複雜的更多基礎設施而隨意編寫警報的方法。 這是很正常的——隨著公司或團隊的成長，可觀察性文化和可靠的警報實踐通常需要時間才能形成。

創建過於敏感、過於嘈雜和過於謹慎的警報很容易。 一開始，一切似乎都值得警惕，因為最好在產品的早期階段小心並最大化生產信號。

“隨著功能和基礎設施的數量和復雜性的增長，改進警報通常是優先級列表中的一部分”

自然地，這種方法不能很好地擴展，但隨著功能和基礎設施的數量和復雜性的增長，改進警報通常是優先級列表中的一部分。 結果是為待命工程師提供了許多半有意義的警報、噪音、上下文切換和多任務處理。 在極端情況下，隊友精疲力盡，警報被忽略，您的待命團隊從提高服務質量轉變為持續救火而沒有任何有意義的影響。

像所有公司一樣，Intercom 也不能倖免於這些低效率。 因此，我們設計了一個相對輕量級的流程來對抗警覺疲勞。

我們如何看待警報策略

“警報紀律”的概念是控制警報的核心。 像功能工作一樣，警報和警報策略應該以一種深思熟慮的、結構化的方式來處理。 然而，與專題工作不同，這不是可以提前計劃好的事情。

畢竟，您不太可能在發布新功能之前預測其運行狀況和噪音。 您必須定期、有計劃地監控警報，以免警報工作達到不可持續的水平。

評估團隊警報時要問的 8 個問題

我們為處理頻繁警報的團隊引入了定期警報審查會議。 這些最初每六週的工程週期發生一次或多次，但隨著警報和監視器的狀態提高到更易於管理的水平，它們之間的間隔變得更大。

每個警報審查會話都以在上一期間觸發的警報的有序列表開始，按觸發頻率排序。 我們使用 PagerDuty 平台作為我們的警報源，其分析功能為我們提供了分解警報頻率和響應所需的信息。 首先審查對整體噪音貢獻最大的警報（即最頻繁的火災）。

然後通過問題清單傳遞每個警報：

1. 警報仍然相關嗎？

任何由過時或未維護的系統觸發的警報都不應打擾待命工程師，應立即刪除。

2. 警報是否可行？

如果隨叫隨到的工程師收到警報，他們是否可以立即採取措施來修復或改善根本原因？ 如果警報不可操作且無用，則應將其刪除。 問題或性能下降的每週摘要可能是警報中信息的更好位置。

3. 即使不可操作，警報中的信息是否立即有用？

我們可以將警報信息分為兩大類。

• 信號：這些警報警告系統運行在其極限，但並不一定意味著服務受到影響。 例如，您的一台服務器以 100% 的 CPU 運行。 如果服務仍然運行良好，是否應該花費寶貴的時間進行調查？ 畢竟，您的服務器只是以最佳的工作成本比運行！
• 症狀：當客戶體驗受到影響時，會觸發這些警報。 這裡的一個例子是您的服務返回給調用者的 5XX HTTP 錯誤的數量。

這兩個類別協同工作效果最好。 待命人員應對症狀做出反應並排除故障，並將信號僅作為進一步的信息來源。

4、如果alert是可操作的，分頁的，是否需要立即處理？

如果問題不需要立即處理，它不應該在半夜叫醒任何人。 在這些情況下，團隊應決定在警報中顯示信息的替代方法，例如，Slack 或儀表板通知，或問題跟踪機制中的打開任務。

5. 如果可行，是否有運行手冊或故障排除鏈接？ 這些步驟是否足夠清晰，團隊中的任何工程師都可以遵循？

作為一名隨叫隨到的工程師——尤其是新工程師——最糟糕的經歷之一是隨著時間的推移在工程團隊中積累的大量部落知識。 僅僅為了意識到你不熟悉系統的那個區域並且沒有很好的記錄，就跳上一個高嚴重性的生產事件是令人生畏的。

“使警報故障排除信息保持清晰、簡單和最新，這對於減少平均緩解和從事件中恢復的時間大有幫助”

即使你有專業知識，你也可能很久以前就寫過代碼，以至於你記不清它應該做什麼。 保持警報故障排除信息清晰、簡單且最新，這對於減少緩解事件和從事件中恢復的平均時間（MTTM 和 MTTR）大有幫助。

6. 如果可行，是否有儀表板鏈接，是否顯示所有已知的潛在原因？

儀表板是一次顯示大量系統信息的好方法，這意味著工程師不必深入研究各種日誌、指標和跟踪來找出問題的原因。 將數據聚合到儀表板中並提供鏈接作為警報的一部分，可以更快地進行故障排除。

7. 警報是否過於敏感或不夠具體？ 它會從脫敏或範圍變化中受益嗎？

許多警報很有用，但校準錯誤。 它們可能太寬泛而沒有每次都應該開槍，或者太具體而針對同一事件開槍多次，這只會增加噪音。

8. 最後，是否必須由人來進行修復？

在某種程度上，所有計算機代碼都將人類可以做的事情自動化。 那麼為什麼不自動修復觸發警報的問題呢？ 雖然某些棘手的警報很難自動修復，例如代碼中的錯誤或系統中的性能問題，但自動操作可以解決許多常見問題。

如果您在 AWS 等雲平台上運行並且可以預置基礎設施而不必擔心請求額外的硬件，則尤其如此。 例如，如果您的搜索集群中的某個節點顯示出故障磁盤，為什麼不自動替換它呢？ 如果服務由於流量增加而導致計算資源不足，為什麼不擴大規模並添加額外的虛擬機或容器呢？ 然後可以通過非警報渠道將補救的詳細信息發送給團隊，以便他們可以在空閒時進行查看。

您對這些問題中的任何一個回答“否”了嗎？

對這些問題中的任何一個回答“否”都會引發團隊的一項高優先級任務，即需要做一些工作來改進警報——無論這意味著阻止它分頁、改進故障排除步驟、自動化它，還是簡單地修復底層系統問題。

該方法的關鍵是以定期和有計劃的方式執行此操作。 它可以保持低噪音水平，讓您的運營和隨叫隨到的工程師感到高興和高效。 他們可以專注於提高質量和產生影響，而不是救火。

您對我們在 Intercom 的工作方式感興趣嗎？ 我們很樂意與您交談——查看我們的開放工程職位。