我的監控故事

我做過兩年多的運維工作，后面就轉做運維平臺開發了，也一步步看著監控系統越來越沒用。 

1、有用的監控 

當我做運維要負責oncall時，我一直認為監控系統做得還可以，并不是因為做了太多事情，而是因為運維的業務還是單體應用，也沒有太多的監控需要加。 

記得那會公司還是用Nagios(估計新人已經沒多少人知道了)，不過監控的維護工作著實費勁。后面我就開始研究zabbix，最大的好處就是它可以discovery&自動添加監控。后面我又搭了一套ELK，把業務日志都收集到一起，監控就齊活了。 

由于沒有添加太多告警，那會的每個告警基本都得處理，最常見的問題就是百度來爬數據，我有一套屢試不爽的處理流程： 

• 看指標：如果是xx業務的負載高, 有90%的概率是爬蟲導致的。
• 看日志：在kibana上看訪問記錄，找出topx的IP段。
• 封訪問：用iptables封掉。

這就是我唯一一段的運維監控經歷。由于業務簡單、監控原始反而讓我感覺告警是有用的。 

2、無用的儀表盤 

1）瘋狂自動化 

當我轉運維開發后，我發現運維對監控的需求也變了。因為自動化能力的提升，各種開源的監控系統逐步完善，運維就開始在平臺里面拼命的加各種自動化的需求，對于監控系統就是自動的給業務綁定各種監控模板、告警模板、grafana儀表盤。

結果也可想而知，由于告警實在太多，運維直接屏蔽了公司的告警短信。大部分情況下都是靠業務側發現問題，運維再介入排查。 

2）好看而沒用的儀表盤 

由于收集的指標數據實在太多，為了可以給業務側輸出，運維就搞起了grafana儀表盤。不過由于grafana儀表盤上的指標實在太多，頁面還會經常卡住，業務研發看著一個頁面上幾十個指標，也不知道哪個有用，最終還是得來找運維。 

為了方便研發查看日志，運維也搞了ELK，將各種日志全部收集進去，然后將kibana丟給了業務研發。結果也可想而知，除了少數幾個愛折騰的，kibana上的dashboard也沒有太多人看。 

我一直相信運維的初衷都是好的，但從結果上來看，嗨的只有運維，畢竟運維很少看自己做的儀表盤……

3、沒有質變 

隨著google sre概念的興起，運維似乎是找到了最后一根稻草，畢竟這是google的運維方法論。于是，運維又開始同研發制定各種SLO、SLI指標，依據4個黃金指標(延遲、流量、錯誤和飽和度)來繼續自豐富自己的告警庫，并制定P0、P1、P2等各種告警分級，試圖改變當前困境。 

但是由于業務架構微服務化，并且采用敏捷開發的模式，實際上業務的迭代速度非常快。大部分sre本身并不是做開發出身，同時嚴重的配比不足(研發和運維比例)，導致各種指標隨著時間快速失效。其結果就是告警依舊沒用，每次復盤就是再加一條告警，當然這條告警也幾乎不會被觸發。 

這就是我經歷的監控故事，你有哪些故事呢？ 

對監控的偏見

在對這些失敗的監控經驗的總結過程中，我發現兩個本質的問題： 

• 一直試圖通過歸納過去發生的單個問題，來預測未來可能發生的普遍問題，并忽略未來在時空上復雜的變化。

• 一直專注于優化傳統的探針模型(使用腳本測試,檢查恢復并且報警)、圖形化趨勢展示、報警模型, 并不斷提升相關流程的自動化。

上述問題只代表我當前對監控的認知，并不知道對錯，也沒有答案。下面則是我對監控系統當前建設的一些偏見。

1、人工智能還是人機交互 

喝著咖啡做運維。

前同事令我印象最深刻的就是這句話了。說完這句話的半年后，他就開始研究AIOps了，又過了半年他就離職了，組里也再沒人提AIOps了。大部分運維對AIOPS最大的需求可能就是根因分析了，不過這就像是一座大山立在AIOps的門外，大部分運維團隊連爬的勇氣也沒有。 

我一直沒想明白一個問題： 

運維自己都不一定能排查出問題原因，為什么會指望機器能實現這個事情。 

人和機器相比，機器更擅長于做海量數據的分析，而人則更擅長做決策。所以相比aiops我認為人機交互可能更靠譜一些。

機器對海量數據進行全面分析，由運維對分析結果進行人腦決策。

不過感覺這事也并不容易，因為現在的sre癡迷開發的程度已經顧不上做這些事情了。決策本身也需要對數據有一定的敏感性。

2、監控要專注能力建設

在過去的監控系統建設中，大家一般喜歡按照架構做垂直切分，可能長這個樣子： 

我認為產生這種分層的主要原因是：組織架構(康威定律)和職責分離。在這種分層下，運維通常就只負責下面兩層，對于上層問題的處理，可能定位到某個具體的URL就結束了，剩下的就是研發的事情了。 

如果要解決當前這個困境，我認為應該摒棄過去按照職責進行系統建設的方式，比如做個基礎監控系統、網絡監控系統、業務監控系統，而是轉向圍繞業務價值分階段進行能力建設，比如基礎的數據采集、傳輸、分析、存儲、展示等能力。轉型成為提供海量數據收集和中央化規則計算、統一分析和報警能力的現代化監控系統【google sre】

在能力建設過程中，平臺團隊應該以真實需求為目標，搭建最小可用平臺(Thinnesr Viable Platform, TVP)，并在團隊中分享最佳實踐和主動賦能用戶，逐步成就卓越用戶。同時要避免分享的都是沒落地的方法論，畢竟大家都很忙。 

3、嘗試變得有效 

當處理問題時，就會發現公司的監控系統比知道的多，運維、研發、DBA、redis等每個部門都有自己的監控系統和儀表盤，出問題時，每個人看的都是自己部門搞的監控。為了能夠建立統一的視角，有能力的公司又會倒騰出統一監控這種東西：從不同的系統里面獲取各種數據，統一進行匯總分析存儲，最終統一監控又會帶來數據實時性、準確性、存儲成本、海量數據處理等新的問題，而且這事一時半會也搞不定。 

不過這事真的有意義嘛？對于這種基礎的數據的采集、分析和存儲其實已經有很多商業化的方案，為什么會覺得自己幾個人的小團隊，配合一堆開源軟件，可以做的比一個幾十人的專業團隊做的更好呢，而且這事離業務那么遠，除了能讓自己的kpi更好看，可能也并沒有帶來什么別的改變。 

隨著造的輪子越多，也慢慢發現自己變得越無效，一直在基礎問題上徘徊。通常越基礎的問題，解決方案也越通用，同時解決這類問題的ROI也越低，所做的工作也越無效。也不要過分強調自己場景的特殊性，除非只是想搞一些虛榮指標，而不解決本質問題。 

那什么是有效的呢？我認為核心就是： 

關注用戶、關注業務，放棄過去通過經驗的歸納來解決普遍問題，嘗試利用數據分析的人機交互聚焦于核心業務，并通過AI/自動化處理支撐業務和通用業務。

不過這事很難，好在我不做監控。

展望

去年有一個跟監控相關的很火的方向：可觀測性。我對可觀測性并沒有太多的實踐，不過在跟朋友聊可觀測性時發現一些問題，這里更多的是想寫下自己的困惑： 

1）可觀測性解決什么問題 

每當聊可觀測性時，我就發現大家一致認為可觀測性可以解決所有的問題，就好比一把屠龍刀，所過之處寸草不生。可你要是詳細問問用可觀測性做了什么的時候，就會有點時光倒流的感覺，又回到各種儀表盤，滿屏指標的時代。你有可觀測性的故事嘛？ 

2）數據收集全面開花 

可觀測性技術發展速度感覺非常快，相關開源項目也越來越多，不過在數據收集上有個令我詫異的問題：有一天別人跟我說，可以在生產環境收集profiling做可觀測性定位業務代碼問題。詫異的點并不是技術實現，而是在于什么樣的業務需要這種級別的可觀測性，這種可觀測性面向的用戶又是誰，要解決的問題是什么？你有答案嘛?

3）新瓶裝舊酒 

如果你跟同事介紹可觀測性由metric、log、tracing三部分組成的時候，很容易被老運維diss，他會告訴你我們現在都已經有了，只是不太好用，豐富下就可以了，這沒什么新技術，不過是新瓶裝舊酒而已。這時候我通常就會提出google之前發的關于<<有意義的可用性>>里面提到的問題，如何衡量用戶級別的有意義的可用性，雖然我也沒有答案，不過我只想啟發下對問題的思考。你是怎么理解這個問題的呢？ 

傳統監控已死，可觀測性已來。我的監控故事就到這里，可以在評論里聊聊你的故事。?