質量是公司的生命線！這個口號喊出去容易，做起來還是有挑戰的，很多公司的口頭禪也都是這個。

線上的產品成型，涉及的角色有銷售，運營，項目，產品，測試，研發，運維，客服等等。但是交付給用戶體驗的最后一道關卡是運維。

運維負責將代碼放到機器上供用戶使用，一旦出現問題，運維也是第一個收到消息，他需要直接解決或者聯合其他人員一層一層的定位修復。

服務的穩定保障分三個階段：事前，事中，事后。要想SLA服務可靠性如99%，99.9%，99.99%，99.999%，那么必須在事前做的足夠好才行，這也是告警體系需要發揮的的價值。

為什么一定要建設告警體系？

地震來了，要不要先通知你跑人？這就是告警體系的作用。

事前考驗的是我們的架構能力和體系建設能力；事中考驗的是我們的經驗和技術能力；事后就需要我們復盤吸取教訓完善事前和事中。

事故一般什么時候發生？

普通的正常的業務迭代研發上線，只要服務集群足夠不會有太多的沖擊，就算有也不會是致命的。

活動沖擊才是致命的，德魯克總結說企業有兩個基本職能：營銷和創新。

恰恰公司運營活動是經常有的，這個大家應該都遇到過。活動前期準備工作我們會考慮到各種因素，但是大型活動心里還是有擔心的怕有遺漏的怕出事故。

因此一個活動要做好，必須有動員能力，戰備能力，后勤能力， 任何一個環節出現問題都是致命的。

動員能力：相關人員一定要參與核心會議，比如明天活動8點開始，沒通知運維在崗就完蛋了。

戰備能力：準備方案，進行方案的討論和對應人負責落地。

后勤能力：除了相關的核心技術人員要在崗，還有技術經理，運維經理，架構師，甚至總監都要在崗，因為一旦出了問題，他們的經驗會發揮超級大的價值，加快服務恢復速度。

事前的告警能力？

有沒有發現，這個時候忽略了一個很重要的工作要做，就是告警。你想想兄弟們要去干仗了，家伙事帶齊準備沖，但是前面有地雷，你要不要得到告警做應變，還是當炮灰。知己知彼才能百戰不殆，監控體系的建設是至關重要的！

監控體系建設

關于建設監控體系可以分三個階段來建設，可根據輕重緩急和團隊的配置來做并不斷完善

第1階段：主機監控

參與角色：SYS系統運維+DBA數據庫運維。

這個階段是最基礎的，你需要保障應用process，port，機器負載，數據庫負載等，一定要做的100%的監控到位且能發出報警信息。

第2階段：應用性能監控

參與角色：SRE應用運維+DEV運維研發

這個階段關注的應用的可靠性，將應用的性能發揮到最優，給予研發同學最直接的支持。比如找出頻繁GC的代碼，SlowSql，最大優化tps，rt等等

第3階段：日志監控

參與角色：SRE應用運維+DEV運維研發

這個階段關注的是業務數據全局觀，也就是上帝視角。如服務HTTP200成功率，失敗率，平均響應時間，日志歸集統一查看等等

第1-3階段：持續優化

1,告警規則：

監控面對的是不同的業務部門，不同的產品，那么要根據這些創建合適的觸發告警的規則。

設定告警級別：1級，2級， 3級，4級。具體的1，2，3，4級重要程度，可以根據業務關注的點來設定。

設定閥值：將維度，指標，閥值與告警級別關聯。

2,告警通知：

設置通知：郵件，IM，短信，電話。1，2級別可以用電話+短信通知。 3級可以是短信+IM。4級可以只是IM。

設置告警分組：不同產品負責人只收到對應產品的告警信息。如果你創建一個大群什么信息都往群里丟，干擾消息多了大家會開啟免打擾模式。

設置值班組：對應的值班組的人員接收全部告警信息且需在崗并努力恢復服務解除告警。

3,業務可視化

這個非常重要！你需讓收到通知的人，點擊通知里面的鏈接能跳轉到一個可視化的頁面，從而幫助他分析問題，快速解決問題。這個可視化是一個非常重要的監控系統平臺，需要持續的去建設。

打比方，我們之前遇到個場景，用戶說登錄不了，同時我們也收到了java服務掛掉的報警，我們先將日志記錄并將服務啟動。但是服務依然沒有恢復，這個時候經過分析判斷可能是負載高接著去擴容機器，發現依然沒有恢復，最后發現是數據庫掛了。

這就是解決問題沒有解決在根本點上，白白浪費了時間。當然其中告警系統也故障了，理論來說數據庫掛掉你應該收到消息。任何時候告警信息一旦收到，你第一時間去看的應該是大盤。用上帝視角去排查，會加快問題的解決速度。這就是業務全局可視化的重要性。

總結：

告警體系是需要花精力花功夫持續建設的，所謂的養兵千日用兵一時真的是最好的形容了。

在穩定時期你做的這些對業務方是無感的，也會覺得沒什么價值。 但是如果一旦出了事故，你努力3個月想拿一個A到頭來結果等來一個D，而且整個團隊都是D，那真是RILE！

運維保障服務的穩定性就是給公司創造的最大價值，做不了王，那就做王背后的男人吧。