貝殼找房一站式報警平臺建設實踐

背景介紹

KeMonitor 是貝殼找房服務端一站式監控報警平臺。2018 年～2020 年是業務的快速發展階段，在這期間陸陸續續研發了基於 CAT、Prometheus、ELK、Skywalking、以及部分自研專有數據監控平臺，大大小小攻擊十餘個監控系統，各系統均自行建設了各自的報警能力。報警發生之後，一線研發同學就會同時打開多個平臺，去看基礎設施監控、應用監控、日誌等，五花八門的報警也給用戶帶來了最多的痛點。在此背景下具有一站式體驗的 KeMonitor 平臺就應運而生了。在 2021 年，由貝殼找房人店技術中心牽頭，聯合了多個部門，針對在報警環節進行了系統性的治理，治理報警的過程中也沉澱了一套完善的報警中心以及配套的報警響應 SOP 機制，下面會爲大家詳細介紹整體的建設經驗。

問題及挑戰

在 2020 年年底進行了一次面向公司範圍全體研發的用戶調研，用戶的訴求主要是希望項目組牽頭對公司範圍的研發側同學日常收到的報警進行系統性治理。分析用戶調研問卷的問題集合，一類是是報警太分散，缺少一站式平臺化的能力來系統性的根治報警漏報、報警風暴、誤報等問題；另外一大類問題就是在研發習慣層面對於如何補齊監控項以及報警如何治理的經驗的缺失。

平臺治理能力問題

主要是涉及到報警的一系列 “靈魂拷問”，該如何解決？

  1. 報警入口 / 觸達太分散，報警不統一五花八門

  2. 報警太多，每一天，需要很大的精力來響應報警

  3. 關鍵的報警漏掉了，沒發對人，也沒有人及時跟進

  4. 發給我的的報警，本身就不合理，並不適合我的系統特點，我應該如何治理？

技術運營層面問題

  1. 如何快速推進大家補齊監控？

  2. 如何形成一套標準的報警處理 SOP 機制？

解決思路

報警治理需要按照事前、事中、事後進行全生命週期的管理。

基於一線業務研發團隊實踐中的總結，監控 / 報警的成熟度，分爲三個階段：

詳細的報警分階段治理以及報警成熟度模型，如圖 1 所示：

圖片

圖 1 報警生命週期 & 報警成熟度階段

報警治理到成熟階段的數據表現如圖 2 所示，該案例節選自人店技術中心的某技術團隊，從圖中我們可以清楚的看出，隨着一段時間的報警治理、Review、覆盤，報警量整體上會呈一個下降的趨勢。

圖片

圖 2 報警治理趨勢圖

實現上述效果，在工具層面，則需要針對報警全生命週期管控的線上化平臺——KeMonitor 報警中心。

平臺能力介紹

KeMonitor 報警中心主要給大家提供完善的工具端的支持以及一套標準的報警 SOP 處理範式，以便大家能夠更好的將報警治理進行落地。圖 3 是報警中心的全景圖，報警中心主要起到連接用戶（研發——管理者 & 一線研發、DBA）以及監控能力提供方的銜接作用，核心解決在研發過程中，對於報警事件已經發生之後的最後一公里投遞給到研發同學的痛點。

圖片

圖 3 報警中心能力全景圖

一、統一配置（事前）

1）報警元信息標準化

在治理之前，大部分報警規則除了觸發閾值之外，僅有觸達方式一項可以進行配置，爲了更好的治理報警，我們在報警規則元信息配置中增加了如下信息：

如圖 4 所示，用戶以及通用報警能力提供方，均可針對報警規則添加的元信息，便於在事中階段的問題止損 & 問題定位環節提效。

圖片

圖 4 報警元信息標註

完成元信息標準化之後，報警內容中可以攜帶更多的定位、止損信息，減少用戶上下文切換操作其他各平臺的時間損耗，詳細如圖 5 所示：

圖片

圖 5 標準化報警文案

2）報警分級

根據不同等級的服務，報警也需要設定爲按照輕重緩急去有針對性的報警，不同的報警需要研發同學投入的關注度也是不同的，因此通過合理的分級機制。

詳細分級標準細則參考健康分的約束，0 級報警共計 2 款，1 級報警共計 12 款：健康分 - 監控 / 報警分規則

圖片

圖 6 報警等級

3）報警完備度度量機制

報警規則覆蓋完備度，是應用建設完善的監控體系，需要首先關注的點，因爲你只有覆蓋的報警場景足夠全面，才能夠提前發現更多的隱患。在前文元信息標準化度量的功能，標註報警場景，即可具備度量能力。

通過 Top 健康分技術運營活動，我們也梳理出來了，能夠符合絕大多數應用的監控範式：這也能夠回答一系列的靈魂拷問，什麼時候應該加監控？日誌需要怎麼記？應用監控應該注意什麼？

報警場景如下：

圖片

圖 7 必選報警場景

圖片

圖 8 可選報警場景

二、報警訂閱（事中）

報警的觸達，並不是只有我給用戶發短信、發郵件、發企微、發機器人消息，關鍵在於怎麼合理的使用上述觸達方式，避免漏報問題。

1）統一報警接收人

提供的資源監控統一串聯編排邏輯，以根治漏報。由於公司的監控體系衆多，公司範圍內發給研發的報警有 8 個以上（日後還有可能繼續增加）的監控報警能力提供方，如果有多套報警接收主體或者如果有人員的入離調轉，或者組織結構調整。這些都會產生潛在的漏報問題，實際生產過程中 2021 年上半年也出現過此類問題導致的故障。這裏通過服務視角的應用監控 | 日誌監控 (hawk、metric-dog-dog、fast、ketrace)、服務關聯的基礎設施（Redis、MySQL）監控 | 報警體系，建立：應用、人、組織、資源的監控 | 報警關聯關係，來系統性的解決這樣的問題。編排邏輯，如圖 4 所示：

圖片

圖 9 統一報警接收人編排機制

關於服務和實際的維護人員的組織關係的映射的長效治理機制，我們在健康分規則機制進行約束，考察一個服務的報警接收人，必須包含當 >=2 個當前部門的研發人員。這樣即可保障，不會出現最低級報警人員的遺漏的問題。

承接這一數據能力的系統，由私有云以及服務雲來完成，如圖 8 所示：

圖片

圖 10 應用視角報警接收人

2）統一報警觸達方式

報警規則覆蓋面不齊，同時設計的足夠靈敏之後，帶來的一個問題就是報警量過多，在觸達通道中如果都混在一起，很難保證能夠看完每一條報警，這往往會導致報警漏報；同時，報警平臺多還會伴隨而來的問題，就是報警觸達應用號多（10 個以上），這也會導致大家難以兼顧看每一個號，這就又產生了漏報。因此在觸達方式層面，有分級應用號、報警機制人兩種新機制來收口觸達，避免漏報。

2.1）觸達應用號分級

針對第一個問題，主要通過設定不同等級的報警，不同等級的報警發送到不同應用號，這樣報警的組織是按照重要性來劃分，不是按照報警類型來劃分，這樣即可減少用戶的理解成本。大家日常僅需要把主要精力投入在最關鍵的報警應用號，對於非關鍵的報警應用號，可以採取定期篩查的方式來進行處理。圖 9、圖 10、圖 11 是分級報警應用號的截圖示意：

圖片

圖片

圖片

圖 11  分級報警應用號

2.2）報警機器人提醒

機器人提醒的機制，最核心的價值是，機器人所在的羣，在組織結構上對齊了生產過程中物理組織——研發小組（5～20 人）、部門（20～50 人）、業務線（50～100 人）；同時形成了從總監、經理、一線員工的報警管理互相監督的管理動作，是一種精細化觸達的機制，研發同學如圖 12 所示配置完成開啓哪些種類的報警之後，在報警觸發之後即可出現如圖 13 所示的機器人消息提醒。

圖片

圖 12 報警機器人提醒配置

圖片

圖 13 報警機器人提醒文案

機器人消息提醒機制，不僅只是簡單的增加一種觸達方式，而且還增加了 @人跟進報警、處理誤報、填寫報警解決紀要、定位問題的快捷入口、解決問題的快捷入口等智能提醒機制，這些機制會在下文詳細介紹。

3）報警值班

報警聯動值班機制，也是降低漏報問題的一種最佳實踐，同時也能夠提高跟進效率。

有了值班機制之後，每天都有專人來跟進穩定性保障。在報警響應方面，該同學會第一時間響應報警，確保報警第一時間有人相應。這樣的機制，除了保證報警不會遺漏之外，還能夠更高效利用研發資源，不至於研發同學都同時跟進報警，造成不必要的浪費。

圖片

圖 14 關聯 keOnes 值班表

圖片

圖 15 報警聯動值班

三、報警響應（事中）

事中階段，最重要的是針對已經發生的報警，第一時間進行響應，並且將處理結論進行及時同步，對應如下幾種情況：

1、如果是問題需要立即進行解決

2、如果是誤報或者報警閾值設計不合理，則需要及時調整下線報警規則，或者調整閾值，或者進行消息免打擾操作

3、如果報警是合理的，但是影響十分輕微，只是一般性的提醒，則需要對報警級別進行調整修正，修正成 2 級報警

4、如果是正在處理中的報警，預計需要處理一段時間，期間會持續產生報警，則無需過多的佔用大家的關注度，可以設置臨時性的設置報警屏蔽，做消息免打擾操作。

報警跟進

這一系列機制，都通過綁定了精確的研發部門的報警機器人來承載此項能力，下面是報警跟進的流程詳細操作步驟，供大家參考：

（1）報警發生時，會通過 appId 找到對應的企微機器人發送消息，發送如下消息，表明報警類型、內容、@人（值班人、服務負責人按優先順序決定）

圖片

圖 16 機器人提醒【我來跟進】

（2）消息中可點擊【我來跟進】按鈕（請在當天內點擊，過了當天點擊無效），點下即進行了跟進（默認爲當天以來到未來 5 分鐘的當前標題都會自動跟進），在彈出的頁面可以修改上述默認值（其他標題、未來時間段）。

圖片

圖 17 填寫跟進明細

（3）同時機器人會立即發送如下消息，讓羣內周知跟進情況：

圖片

圖 18 報警已跟進消息通知

（4）被跟進範圍涵蓋的新來的報警（follow 步驟 2 中的跟進時效），會顯示這樣的樣式，說明無需再跟進：

圖片

圖 19 已經跟進報警再次觸發

（5）如果在步驟（1）中點擊的是【誤報】，則會對該次報警標記成無效類型，同時可進行消息【免打擾】，臨時或者永久屏蔽該報警。

圖片

圖 20 標註無效報警

（6）報警解決

從上述報警跟進通知的企微消息（步驟 3）“填寫處理結論” 可以進入報警歷史頁面。

在該 appId 的報警歷史中，按照報警類型 + 報警標題 + 是否已處理 聚合展示條目

可判斷哪幾類報警是同一件事情、同一個原因、同一種解決方案，可以勾選上，點擊 “批量處理”，從而創建了一個處理，關聯上了多個報警

圖片

圖 21 批量處理報警

創建的當時可填寫結論：

圖片

圖 22 填寫處理結論

結論目前有這麼幾種可選，能夠描述大家碰到的絕大部分情況：

填寫結論並且提交之後，企微機器人會發送通知：

圖片

圖 23 報警已解決羣提醒

2）多級 onCall 機制

多級 onCall 機制主要針對最重要的報警，這類要保持足夠的關注度，是保證最核心的報警不會發生漏報的 “核武器”，如未能保證在規定的時效內跟進動作的完成，則開始通過精細化的按照組織結構層級進行逐級電話通知，第一級 oncall 通知【值班人】/【服務 owner】，第二級通知經理，第三級通知總監，每一級默認 3 分鐘。通過這樣的機制，即可保證從一線研發再到以上的研發組長、研發經理、研發總監以及各穩定性保障角色，均能夠第一時間知曉潛在，保持信息通暢。

3）報警屏蔽

報警屏蔽，主要解決的問題是治理無效報警、減少誤報，或者用於減小報警信息對於研發的不必要打擾。報警屏蔽，業務層面適用於臨時的屏蔽掉由於某些原因，臨時不收報警機器人羣提醒或者報警消息（定點給某個人發送的，短信、郵件、企微應用消息、回調等），典型案例如下所示

1、某臺機器下線，先臨時屏蔽這個報警，避免轟炸

   如：企業微信和短信收到報警，只想屏蔽該服務這條類型的報警 5 分鐘

圖片

圖 24 臨時屏蔽報警

2、由於某些原因，某些發送到羣內的消息提醒，如：業務報警、或者提醒類型的報警，無需轉發到大羣

3、某些通用型的報警規則，由於業務特點，不適用該應用的所有的應用場景。比如：GC STW 時長的報警、或者 kafka 消費積壓超過 2000 報警

   如：服務操作的傳統機器 “停服”，之後越來越多項目上雲後應該會有同樣操作。這應該是預期內的正常停服下線，不用報警，所有相關的通用報警信息全部屏蔽

圖片

圖 25 字段屏蔽報警

4、上線過程中，比如：KeMonitor 上面有個 checkServicePort 的檢測，默認是 3 分鐘，我們有的服務起來要大於 3 分鐘，導致就會在監控羣裏誤報，可以進行字段粒度的屏蔽。

4）報警自愈

如果報警期間，已經出現了故障，此時最重要的舉措就是執行預案，做止損 / 恢復的動作。絕大多數情況，一個系統的常見的止損 / 恢復動作，都是固定的，有固定的操作步驟，如：重啓、摘流、熔斷、開關等；同時，一般情況也能夠從一些報警能夠反映出來，如系統依賴下游長時間響應慢，這種需要執行降級。在報警文案內疊加上止損恢復的快捷入口，能夠大幅減少上下文切換（瀏覽器輸入地址切換專有止損 / 恢復系統）的時間，從而達到提效的效果。

圖片

圖 26 報警自愈快捷入口

四、報警覆盤（事後）

事後階段，主要是用來系統性的分析，一個長跨度時間範圍的報警以及解決情況，分析系統瓶頸點，這裏就需要在報警解決環節，填寫完備的原因以及舉措，詳細如圖 26 所示：

圖片

圖 27 報警解決紀要

五、自助化接入

報警中心面向監控 / 報警能力提供方（如：DBA、SRE 等基礎服務提供方等角色），還提供了報警規則等的一鍵導入、報警消息觸達的一站式聯調能力。

圖片

圖 28 報警自助化接入

在接入平臺化改造之前，需要一人周時間的報警規則列表、報警觸達的對接集成，目前最快僅需要 10 分鐘即可完成自助化接入。

總結

通過對於報警的系統性治理，沉澱而來的報警中心，系統性解決的治理漏報、治理誤報 / 報警風暴等問題，同時提升了報警響應、止損恢復、定位問題等環節的效率。下面三點，是最具貝殼特色的幾點舉措。

KeMonitor 平臺的下一步建設重點就在於進一步提升平臺體驗體驗。在報警報警套餐的基礎之上，進一步對監控指標進行模版化、” 傻瓜化 “的治理，會基於貝殼技術體系的基礎設施以及技術棧進一步細化梳理指標口徑定義、指標釋義、報警閾值設定建議、定位問題、快速止損恢復專家建議，以及增加模版化配置能力，形成完備監控指標集市，便於用戶更方便獲取全面的監控能力。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/f8QOEK6AAZjAN1X_Z3cYhg

猜你喜歡