前言
伴隨公司業務快速發展，我們生產環境產品和應用越來越複雜，彼此連線依賴也越來越複雜；何一個應用出異常都有可能影響系統可用性，造成全域性影響。通過去年 2021 年 C 端故障全年度來看，從故障發現，響應時間、故障應急有待提升，故 NOC 要優化現有的告警響應質量，制定新的 NOC——SLA 體系化，標準服務等級協議！加速響應，做到事前發現！
一、得物交易 C 端介紹
1、C 端概念
1.1 什麼是 C 端
C 端指的是消費者、個人使用者 Consumer；顧名思義就是面向個人使用者提供服務的產品，是直接服務於使用者的，得物 C 端分為兩個場景“交易”“社群”兩個組成，C 端包含線上交易、社群、演算法，涉及到交易下的訂單、出價 &庫存、營銷、商品，社群域前後端、演算法交易推薦 &社群推薦為重要依賴。
1）交易角度
- 使用者登陸游覽商品詳情在到支付購買，整個面向使用者的交易流程就是交易 C 端業務。
2）社群角度
- 使用者登陸登發帖，在到社群遊覽點贊、互動所產生的社交就是社群 C 端業務。
2、C 端出現問題會怎麼樣？
2.1 在 2021 年 6 中旬，商品服務異常由於技術問題導致訂單連續下跌，影響使用者下單購買體驗。
- 推薦頁面白屏無資料 &包括頁面分類；
- 商品側：點選商品長時間載入或該商品下架不支援銷售；
- 出價 &寄存側：商品無法出價、出價報錯；
- 供應鏈側：影響部分分揀拍照鑑別，以及檢視商品詳情頁；
- 社群側：部分社群帖子載入過慢或延時；
- 商家側：開放平臺 dop 也受到了大面積影響；
2.2 在 2021 年第四季度供應鏈發版中由於技術問題，程式碼 bug 和 redis 快取解析異常導致交易訂單當天下跌異常，影響了使用者下單購買體驗
- 出價 &庫存：立即購買浮層開啟異常；
- 建立訂單 &支付訂單：無法開啟建立；
- 營銷：調取優惠核銷失敗；
總結：
伴隨公司業務快速發展，現在我們生產環境產品和應用越來越複雜，彼此連線依賴越來越複雜；一個應用出異常都有可能牽一髮而動全身，影響全域性。
二、針對 C 端歷史問題-為什麼要做 SLA
1、告警問題發現
1）在過去 2021 年度全年故障分析中影響 C 端故障佔比全年 34.7%，C 段告警發現率只有 42%。
- 在 C 端核心鏈路上的告警基本上已經全部覆蓋，但是在延伸到所有故障型別重大故障上，我們的告警覆蓋面仍然需要提升。（監控告警零散，NOC 體系監控告警收口能力弱）在告警質量上沒有有效收口。
2）從 2021 年度至今故障分析中 C 端中 NOC 的響應率從 3min-5min-15min 響應，來說所有待加強；
2、NOC 響應問題
在經歷過去年年底一次較大資損型別 P1 故障中，NOC-在該風險告警預警後，沒有第一時間判斷是否上升響應延遲，導致活動延遲下線資損擴大，如以下問題：
- 值班同學關注群較多，每日處理訊息過多，無法區分優先順序，因此在故障發生時，值班同學會出現響應慢或錯過訊息等情況；
- 故障發生時，值班同學無法準確評估影響面，因此無法準確找到對應負責人等，導致故障錯過最佳處理時機。
- NOC 值班同學對於 C 端業務理念不夠，無法做出有效判斷。
總結：
通過以上故障分析中告警問題發現率以及 NOC 在遇到重大故障判斷上出現的響應問題中， 從故障發現開始到故障拉起 NOC 同學每天處理問題沒有優先順序，關注點散亂被動告警接受缺乏規範，在故障處理中資訊分散，缺少抽象聚合，可以從點擴散到面的發現問題，監控系統對於業務的場景監控和 NOC 自身的業務場景理解投入度都有待提高。
三、SLA 整體介紹
因此 NOC—SLA 專項因此成立，統一收口接入 NOC——SLA 體系監控告警，輸出 SOP，針對全司業務場景區分 P0P1 優先順序，全面故障發現優化，從保障等級、受損型別、業務視角三個方面介紹 NOC-SLA 專項展開。
1、SLA 的劃分
1）按照 SLA 保障等級劃分
我們結合業務重要級別，故障定級標準將 SLA 保障等級分三級：P0(SLA 3 分鐘)、P1(SLA 5 分鐘)、P2(SLA 15 分鐘)
2）按照受損型別劃分
參考我們的業務受損型別，我們將 SLA 保障物件型別分為六項：業務受損，資損，基礎設施，資料質量，職場效能，開發測試。說明如下：
3）業務視角劃分
3.1 在業務研發視角具體分析業務受損場景如 P0 級別場景；
- 以【下單流程】業務方向舉例：從商詳-立即購買浮沉-提交訂單-支付訂單-收銀臺；
3.2 以運維基礎設施視角分析業務受損場景如 P0 級別；
- 以【下單流程】運維基礎設施舉例：從使用者請求-路由 internet-閘道器-App-業務中臺；
4）SOP 定義
- 對於業務定級邏輯從新定義，自動匹配 SLA 故障場景聯動一網打盡快速響應預定級
- 改變原有思路，由以前的“加法”變為“減法”，即減少 NOC 值班同學關注告警群，按照故障來源(監控告警、內部反饋、客服反饋)區分需要關注群資訊，P0/P1 告警資訊進行統一彙總，承諾之外訊息不保障 SLA；
- 對於 SLA 業務場景增加維護人，業務相關負責人；
2、接入流程
2.1SLA 接入規範
- 在告警頁完成配置後，發起 SLA 申請，由 NOC 同學在一網打盡中完成稽核，通過即保障 SLA，不通過在三天內完成優化，超時直接退回。
四、NOC—C 端接入 NOC-SLA 推進
前期準備
- 在方案實施中，先了解業務場景需求，對焦場景保障等級。
- 明確核心業務指標以及相結合的依賴大盤結構。
- 接入中場景基線是否合理，明確告警規則
- 接入完成、驗證歷史故障。
1、業務梳理 —需求
交易 C 端包含線上交易、社群、演算法，涉及到交易下的訂單、出價 &庫存、營銷、商品，社群域前後端、演算法交易推薦 &社群推薦為重要依賴，梳理了 C 端 9 個 P0 場景 17 個 P1 場景 100+的告警規則完善。
1.1 業重要等級劃分
舉例對於 C 端業務線，下單核心鏈路在下單核心場景當中區分 P0P1P2 級別優先順序
- 以影響訂單量為評估是否屬於 P0；(商品詳情、立即購買、建立訂單等場景)
- 以最終引導訂單下單的導購鏈路為 P1；(我的收藏、求購、天天領券等場景)
2、交易 C 端持續穩定性保障
交易 C 端 SLA 落地
在 SLA 專項落地階段，我們對於 SLA 業務監控場景指標對焦完畢後，在不斷的對於 C 斷業務場景核心規則+觸發條件編排力，對於歷史故障是否能做驗證反覆磨合，對於不同場景不同資料指標，不斷對基線計算公式打磨調優到後面開始嘗試接入智慧基線通過歷史波動資料做基礎演算法模型，以確保能在 P0 場景中快速發現 P1 和 P2 故障。
2.1 C 端 SLA 基線
1）目前整個 C 端的基線配置都是根據業務業務流量歷史峰值，不斷的反覆摸索確認
- 在確認基線前提時候，一定要思考及觀察歷史業務流量波動比例，在確認做用什麼型別基線，在實行 SLA 階段對於過去監控資料存在節假日波動影響往往高於歷史閾值 50%如果在業務高峰時出現業務問題造成不明顯下跌往往很難發現問題，需要做到每週對焦，之後我們引入智慧基線。
- 取元旦節假日為例流量水平高於基線 50%異常波動比例高達 112%
- 取值範圍在工作日波動比例在 20%以內符合預測範圍內
2） 智慧基線——Prophet 模型
- fbprophet 是 facebook 開源的一個時間序列預測演算法
- 可以通過歷史監控資料波動指標，運用預測演算法來訓練一個模型來預測未來指標走勢。
- 在 NOC——SLA 中為了確保 SLA 的問題發現率、可用性、準確性，每週 NOC 同學在觀察告警是否存在誤報觀察歷史監控資料，尤其節假日交易 C 端告警流量水位普遍高於正常閾值的 50%異常，在每週二下午會偶爾出現低於基線的正常水位 25%，隨著得物的業務體量不斷增加及活動季節性趨勢“618，雙十一”不斷的挑戰基線的可靠性。
- 智慧基線可以在較大的運算資料中預測未來預估避免節假日效應給出合理的基線數值，確保可用性及可靠性；
2.2 SLA 監控與告警優化
在監控告警配置方面，我們對於監控聚合維度升級優化，可以根據多場景，多規則不同的業務視角：應用告警-業務告警-基礎資源告警整合相關聯，通知告警模版更加清晰化，負責異常波動圖一目瞭然。
1） 資訊整合
- 場景確認區分上述 P0P1 場景
- 區分業務線型別及所屬的業務域
- 確認該場景的規則標題“通俗易懂”：如支付訂單同比基線下跌 35%
- 固定 NOC——SLA 維護人 &業務域相關負責人
- 業務的受損型別打標
2）SLA 專項監控 &告警規則——多樣性
- 以下的改進了對於“去人化”判斷，快速反應、訊息觸達聯動機制迅速。
\
3）NOC—SLA 專有告警邏輯
- 對於 SLA 專項告警資料誤報問題
基本描述：VM 資料延遲造成告警讀取支付訂單資料有誤，造成支付告警誤報
影響描述： P0-SLA-3m 告警規則 “支付訂單比例同比基線下跌超 35%”因資料延遲問題出現誤報
告警顯示波動比例為 40%，但所帶監控截圖和跳轉監控地址均無異常波動。
優化： 原定告警檢測時間點位為 12S，發現 12S 仍存在資料齊全度問題，易造成誤報，現關閉 12S 的時間檢測點位，切換為 20S 檢測點（20S 為新增測試點位，並非最終點位） ，預期切換後告警延遲在 25-30 秒左右， 後公式出 NOC—SLA 專有告警邏輯（通過計算公式獲取的值與閾值進行大小比較，閾值不需要沒有負數，只有正數，上升和下降通過比較符確認，比如環比下降 30，告警會自動處理正負號的邏輯）
- 老的告警邏輯 30 秒評估一次，防止告警噪音查詢資料向前推 1 分鐘，告警引擎會對告警進行去重、合併、抑制等路程大概 50 秒，整個流程會延遲 2 分多鐘
3、SLA 保鮮準確性：保鮮方式 &保鮮物件
- 業務鏈路的保鮮
- NOC&業務對焦
- 以月度為單位跟業務方覆盤總結對焦 SLA 目前健康狀況提高“售後服務”
- 對焦業務迭代是否發生資訊變化 （新上營銷活動、拍賣專案、可能會對 P0P1 場景定義，業務迭代後有新的變化，需要對原來定義監控、NOC 值班、應急、相應調整）
- NOC 指標鏈路資料正確性維護
- 定期梳理梳理（交易 C 端）場景業務指標鏈路資料正確性，做到場景依賴發現全；
- SLA 告警優化
- 故障 &冒煙點 SLA 問題發現率分析優化
- 按照故障 &冒煙中是否是 SLA 發現？其它告警發現？使用者 &員工反饋等來不斷完善提高 SLA 告警問題發現率“不誤殺”
- SLA 告警優化
- 根據每週 SLA 告警質量監控分析告警觸發率在哪個時間節點出現突增去分析原因做到告警閉環“有理有據”，增加準確性，減少告警噪音，收斂。 比如：低交易時段，秒殺搶購等活動導致訂單突增，出現監控毛刺的波動產生告警以此來做問題記錄告警歸類。
4、 NOC 加速應急
SLA 應急流程規範優化
1）NOC—SLA 落地後經過稽核後，加入 SOS（故障應急系統），出現 SLA 指標下跌後聯動 SOS 快速應急一鍵傳送；
2）增加應急小組，包含 NOC 二組/專家組，用於應急中引導加快故障快速恢復；
3）故障自動升級機制，根據故障新版定級為基礎判斷自動匹配 1min 自動拉群同步現有故障資訊概覽；
五、落地實踐故障發現
1、告警及時性
2、準確性和有效性
- 今年 2 月份社群的穿搭精選服務展示異常故障，因為資源計算新增程式碼 bug 故障中，我們根據場景關聯化，基於基線合理性和 SLA 告警配置的多樣性，發現了之前未發現的故障現象，當時線上所有告警無異常。
3、值班提升
1) 在 3/2【冒煙點】購買首頁/商詳/立即購買 QPS 跌，RT 飆升 阿里雲杭州地區(可用區 I )網路裝置發生異常，通過 SOS 預定級與 NOC—SLA 聯動自動匹配相應故障場景定級自動發出去人化 5 分鐘快速響應 ；
2) 使用者 &員工反饋建設 TS&NOC 上報標準流程，加強得物 App 使用者反饋渠道；
3）減少盯群，收斂群，減少打擾，讓 NOC 值班人更專注在有限的重點飛書群；
總結與展望
在我們經歷過多次大額資損類故障中和影響業務可用性嚴重性故障後，我們回顧總結怎麼從應急保障中做到快速響應，事前預警後。由被動變主動，向全員承諾發起 NOC-SLA 保障專項，痛定思痛下定決心將告警發現、處理、止血，定下 P0(SLA 3 分鐘)、P1(SLA 5 分鐘)、P2(SLA 15 分鐘)為目標力爭上游。同時梳理各業務域應用等級業務鏈路場景分成級，從告警聚合、聯動 SOS 故障快速拉起，目前在交易 C 端落地了 9 大核心 P0 場景 17 個 P1 場景，但是還不夠好，要不斷“保鮮”才能做到可持續性，準確性，可靠性。
從冒煙發現的角度來說，我們要不斷的打磨 NOC—SLA 增強告警延展性，可觀測場景不斷擴大深挖 P1 以下場景，著力從預防角度來說做到事前發現防止能預見的問題，快速恢復不能預防問題，避免小問題大故障，還有很長的路要走，目前做到 3min-5min-15min 快速響應，朝著業內阿里 1min-5min-10mi 定位和快速恢復能力前進，為得物穩定生產助力！
文/木魚耗子
關注得物技術，做最潮技術人！