茲伊伊因！ 凌晨 3 點，你正在做美夢，突然接到電話。 你這週值班，顯然發生了一些事。 自動化系統會呼叫以找出問題所在。 這是管理現代電腦系統的一個重要方面，但讓我們看看如何讓通知更好地為人們服務。
熟悉我在不同監控團隊的數十年職責中誕生的監控理念。 她很大程度上受到羅布·埃瓦什丘克（Rob Evashchuk）的真實聖經的影響 （我的通知哲學）包含在書中 ，以及約翰·阿爾斯波的書 （有關設定警報的注意事項）。
, и — 感謝您幫忙編輯這篇文章。
什麼是案例？
我決定想出一個漂亮的縮寫，例如 或 。 我稱之為 案例法。 他介紹了自動監控工作中需要注意的四點：
- （上下文綁定）
- （實用價值）
- （強調症狀）
- （年級）
如果您使用 CASE，您會以健康的冷漠態度對待通知，並且不會在晚上吵醒人們。 應定期評估監測的有用性和有效性。 當一個人收到通知時，他們會有更好的思考模式和更多的信心。
為了更容易記住，想像一下你需要一個 CASE [即一個案例，一個理由 - 譯者註] 來證明每個警報的合理性。 :太陽眼鏡:
而這一切又是為什麼呢？
。 出於很多原因。 CASE 不會將它們全部消除。 但有了它，您將在晚上醒來時收到更好的通知。 該方法涵蓋了對解決此問題也將有所幫助的各種組織流程。
RED 和 USE 方法的美妙之處在於，在它們的幫助下，我們不僅知道如何運作，而且彼此之間可以說相同的語言。 我希望 CASE 方法能夠更輕鬆地討論保護我們的系統但讓我們的同事忙碌的通知。
關鍵是您需要在組織中創造一種文化，以健康的冷漠態度對待通知。 通知可以為特定目的而創建，但事實並非它們以後不會失去價值。 我們為什麼要設定這個通知？ 其標準多久前修訂過？ 有了CASE，這些問題都可以得到解答。
Context-Heavy - 上下文綁定
凌晨 3 點並不是閱讀包含大量智慧詞彙的訊息的最佳時間。 為了有效地做出反應，您需要資訊。 理想情況下，這應該是有關特定問題的信息，其上下文立即清晰，並且應該配置通知以便實現這一點。 這就是“觀察”和“定向” 。 花時間在這個設定上並不丟人，因為不斷分散一個人的注意力甚至會更加昂貴。 讓我們互相尊重吧。
問題有很多來源。 尤其是鬼。
我該如何幫助值班人員？ 值班人員首先看到的是一條通知，因此他根據通知建立了所有假設。 然後他查看說明和儀表板，但是否總是有特定通知的數據，而不僅僅是一般資訊？ Alspaugh 建議「思考如何解釋或回應通知」（投影片 29）。 好的通知應該集中在值班人員身上，而不僅僅是透過閾值配置。
因此，這裡有一些關於如何改進通知上下文的想法：
- 向使用者展示一些有用且專門創建的東西，而不僅僅是普通的說明或儀表板。 以前，我和這些人使用了為特定通知配置的調查儀表板。 如果問題已知，這會有所幫助，但只會讓其他人感到困惑。 我們需要在這裡找到一個平衡點。
- 請告訴我們該通知的歷史記錄：是新的嗎？ 經常起作用嗎？ 是季節性的嗎？
- 顯示系統狀態的最近變更。 最近有什麼變化嗎？ （例如，部署或啟用/停用功能。）
- 顯示關係並為心智模型提供資訊：系統依賴性應該清晰可見，最好帶有功能指示。
- 快速將用戶與團隊聯繫起來：他們能否看到正在發生的事件，或者他們能否找出公司中的其他人收到了通知？ 程式 活性？
理想情況下，事件管理計劃將提供有關如何改善事件調查的通知上下文的建議。 總是有一些事情需要努力！
可操作-實用價值
值班人員是否應該根據通知採取行動？ 如果你不需要做任何事或不清楚該做什麼，為什麼要叫醒他？ 您需要避免那些惹惱值班人員且不需要採取行動的通知。
我該怎麼辦？ 你想要什麼？
過去，當系統很簡單、團隊規模很小時，我們設定監控只是為了掌握最新狀況。 如果服務隨後出現故障，堆上的負載已增加的通知將為我們提供上下文。 從大規模來看，此類通知只會造成混亂，因為我們的系統始終在不同嚴重程度的降級狀態下運作。 這很快導致 當然，還會失去敏感性。 因此，值班人員會忽略甚至過濾此類通知，並且並非總是根據需要做出回應。 不要落入這個陷阱！ 不要連續設定所有通知，然後透過電子郵件將它們發送到某個被遺棄的資料夾。
具有實用價值的通知如下：
- 通知需要採取行動，而不僅僅是報告新聞。
- 此操作很難自動化，或有風險。 如果一個動作可以自動化，那就自動化它，別再糾纏人了！
- 該通知包含以下形式的緊急建議 （SLA）或 （RTO）。 然後值班人員可以啟動組織的事件管理程序。
我想澄清一下：我並不是說通知應該只針對 API 最重要的 SLO（服務等級目標）。 SLO 監控不斷分散和劃分，並且需要對所有服務採取相同的方法。 很明顯，您將追蹤向您付款的客戶最重要的 SLO。 但基礎設施 SLO（例如資料庫）也需要監控。 很快您將不得不與內部客戶打交道並為他們提供支援。 如此下去，無止境。
基於症狀－強調症狀
無論你喜歡與否，你都在分散式系統中工作（Kavaj）。 因此，您可以使用不同的策略來隔離服務並防止它們故障（Trainor 等人）3。 儘管延遲的垃圾收集或停滯的資料庫查詢表明存在問題，但如果用戶在不久的將來沒有出現問題，則無需急於修復它們。
這些是重要的信號並且可能具有實用價值，但是如果它們不打擾用戶，那麼就不足以分散服務員的注意力。 基於原因的通知是我們關於系統故障的心理模型的快照。 追蹤重要的症狀比嘗試列出故障的所有可能原因更好。
為了使通知有意義，請關注 ，對使用者很重要。 Evashchuk 稱之為「對使用者的監控」。 請記住，這理念必須應用於整個組織。 如果某項服務在基礎設施深處出現緊急問題，適當的團隊將會處理這些問題。 保護系統免受此類故障的影響是完全不同的事情（Trainer 等人，有關最小化關鍵依賴性的策略的部分）.
症狀並不多變
理查德·庫克提醒我們，複雜的系統充滿缺陷、缺點和問題。 試圖列出所有可能的原因是一項西西弗斯式的任務。 你試圖描述問題，但它們一直在變化。 Cindy Sridharan 認為“系統不必每秒都處於完美狀態”，最好使用更人性化的方法（ （“監控分散式系統”），7）.
避免事件發生後收到通知
通常，原因通知被配置為糾正事件。 這些關於所發生事件事實的有限通知會產生一種錯誤的安全感，因為系統每次都會想出新的破解方法。
不要被原因通知所愚弄。 最好這樣想：
- 為什麼基於症狀的通知沒有註意到問題？
- 改善使用者的環境會有幫助嗎？
- 如何改進監控工具以更快地做出診斷，而不是累積所發生事件的通知？
只有當您將診斷監控工具視為從症狀轉向解決方案的一種方式時，它們才會有所幫助。 如果沒有這種回饋，您只會收到有關過去失敗的最新通知和圖表的轟炸，而不會收到有關未來失敗的任何資訊。 對於組織來說，這是從防禦轉向攻擊的絕佳機會。 而開發人員和產品經理會有相同的期望和明確的目標。 每個通知的情況 - CASE (:wink:) - 都很清楚。
基於原因的通知是可以容忍的
有時，我們的系統在基於原因的通知方面讓我們別無選擇。 有時值班人員很清楚，一個症狀肯定會導致失敗，因此具有實用價值。 也許您只是不確定發生了什麼，因此為了安全起見而設置了通知。 希望此操作是暫時的，直到我們可以更改系統以解決效能問題為止。
處理這些情況時，請記住 CASE 的其他組成部分。 僅僅因為它是暫時的並不意味著你可以停止用頭腦思考。
已評估-評估
對系統的任何變更（新程式碼、新基礎設施、任何新事物）都會擴大故障範圍（庫克，3）。 此通知是否仍如預期運作？ 清晰且目前的系統心理模型以及回應某些支援通知的經驗 - 這些是主要特徵 。 系統中的缺陷不斷演變，我們必須跟上它們。
您需要不斷評估每個通知的質量，以確保它們按預期工作。 尊敬的各位領導！ 如果您幫助您的團隊建立此流程，那麼對他們來說會更容易！ 以下是一些評估想法：
- 使用 , 或其他通知測試方法。 團隊可以自己完成，無需依賴繁重的活動管理系統！
- 將所有與事件相關的通知的集合合併到您的事件管理計畫中。 標記有用、有害、不適當、不清楚等。將它們用作回饋。
- 正確的通知很少被觸發，並且經過仔細測試。 確保所有連結都有效，指向正確的上下文等。
- 如果通知從未觸發或觸發過於頻繁，則表示有問題。 修復它或刪除它。 謹防過度被動或主動！
- 設定帶有到期日期的通知時間戳記。 如果過期日期已過期，請使用 CASE 方法評估通知並更新時間戳記。 就像食物一樣，定期檢查保質期。
- 簡化改進通知的流程。 使用監控作為程式碼並將通知儲存在 Git 儲存庫中。 拉取請求有助於吸引團隊並為您提供過去通知的歷史記錄。 您將不再害怕更改通知或徵求負責人的許可。
- 設定通知回饋，即使很簡單 ，以便值班人員將通知標記為無用或侵入性。 將連結或號召性用語嵌入通知本身中，並定期查看您的回饋。
- 在團隊裡制定一條規則──工作少的時候就讓值班的人幹，簡化值班。 願你之後的一切都比之前好一點。
結論
我相信 CASE 方法可以幫助開發人員和組織討論設定和發送自動通知。 開發人員可以開始使用 CASE 方法評估通知，然後整個組織將與其他開發人員、管理層和事件管理程序一起加入，以保持通知處於良好狀態。 這不需要任何特殊工具或複雜的過程。
整個產業需要在值班時考慮人為因素，同時又不犧牲一流的客戶服務。 所有這些工具和實踐都可以而且應該得到改進。 我希望 CASE 方法能對此有所幫助。
享受改進的通知！
來源： www.habr.com