我的監(jiān)控故事

我做過兩年多的運(yùn)維工作，后面就轉(zhuǎn)做運(yùn)維平臺(tái)開發(fā)了，也一步步看著監(jiān)控系統(tǒng)越來越?jīng)]用。 

1、有用的監(jiān)控 

當(dāng)我做運(yùn)維要負(fù)責(zé)oncall時(shí)，我一直認(rèn)為監(jiān)控系統(tǒng)做得還可以，并不是因?yàn)樽隽颂嗍虑?，而是因?yàn)檫\(yùn)維的業(yè)務(wù)還是單體應(yīng)用，也沒有太多的監(jiān)控需要加。 

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

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

• 看指標(biāo)：如果是xx業(yè)務(wù)的負(fù)載高, 有90%的概率是爬蟲導(dǎo)致的。
• 看日志：在kibana上看訪問記錄，找出topx的IP段。
• 封訪問：用iptables封掉。

這就是我唯一一段的運(yùn)維監(jiān)控經(jīng)歷。由于業(yè)務(wù)簡單、監(jiān)控原始反而讓我感覺告警是有用的。 

2、無用的儀表盤 

1）瘋狂自動(dòng)化 

當(dāng)我轉(zhuǎn)運(yùn)維開發(fā)后，我發(fā)現(xiàn)運(yùn)維對監(jiān)控的需求也變了。因?yàn)樽詣?dòng)化能力的提升，各種開源的監(jiān)控系統(tǒng)逐步完善，運(yùn)維就開始在平臺(tái)里面拼命的加各種自動(dòng)化的需求，對于監(jiān)控系統(tǒng)就是自動(dòng)的給業(yè)務(wù)綁定各種監(jiān)控模板、告警模板、grafana儀表盤。

結(jié)果也可想而知，由于告警實(shí)在太多，運(yùn)維直接屏蔽了公司的告警短信。大部分情況下都是靠業(yè)務(wù)側(cè)發(fā)現(xiàn)問題，運(yùn)維再介入排查。 

2）好看而沒用的儀表盤 

由于收集的指標(biāo)數(shù)據(jù)實(shí)在太多，為了可以給業(yè)務(wù)側(cè)輸出，運(yùn)維就搞起了grafana儀表盤。不過由于grafana儀表盤上的指標(biāo)實(shí)在太多，頁面還會(huì)經(jīng)?？ㄗ。瑯I(yè)務(wù)研發(fā)看著一個(gè)頁面上幾十個(gè)指標(biāo)，也不知道哪個(gè)有用，最終還是得來找運(yùn)維。 

為了方便研發(fā)查看日志，運(yùn)維也搞了ELK，將各種日志全部收集進(jìn)去，然后將kibana丟給了業(yè)務(wù)研發(fā)。結(jié)果也可想而知，除了少數(shù)幾個(gè)愛折騰的，kibana上的dashboard也沒有太多人看。 

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

3、沒有質(zhì)變 

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

但是由于業(yè)務(wù)架構(gòu)微服務(wù)化，并且采用敏捷開發(fā)的模式，實(shí)際上業(yè)務(wù)的迭代速度非?？臁４蟛糠謘re本身并不是做開發(fā)出身，同時(shí)嚴(yán)重的配比不足(研發(fā)和運(yùn)維比例)，導(dǎo)致各種指標(biāo)隨著時(shí)間快速失效。其結(jié)果就是告警依舊沒用，每次復(fù)盤就是再加一條告警，當(dāng)然這條告警也幾乎不會(huì)被觸發(fā)。 

這就是我經(jīng)歷的監(jiān)控故事，你有哪些故事呢？ 

對監(jiān)控的偏見

在對這些失敗的監(jiān)控經(jīng)驗(yàn)的總結(jié)過程中，我發(fā)現(xiàn)兩個(gè)本質(zhì)的問題： 

• 一直試圖通過歸納過去發(fā)生的單個(gè)問題，來預(yù)測未來可能發(fā)生的普遍問題，并忽略未來在時(shí)空上復(fù)雜的變化。

• 一直專注于優(yōu)化傳統(tǒng)的探針模型(使用腳本測試,檢查恢復(fù)并且報(bào)警)、圖形化趨勢展示、報(bào)警模型, 并不斷提升相關(guān)流程的自動(dòng)化。

上述問題只代表我當(dāng)前對監(jiān)控的認(rèn)知，并不知道對錯(cuò)，也沒有答案。下面則是我對監(jiān)控系統(tǒng)當(dāng)前建設(shè)的一些偏見。

1、人工智能還是人機(jī)交互 

喝著咖啡做運(yùn)維。

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

我一直沒想明白一個(gè)問題： 

運(yùn)維自己都不一定能排查出問題原因，為什么會(huì)指望機(jī)器能實(shí)現(xiàn)這個(gè)事情。 

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

機(jī)器對海量數(shù)據(jù)進(jìn)行全面分析，由運(yùn)維對分析結(jié)果進(jìn)行人腦決策。

不過感覺這事也并不容易，因?yàn)楝F(xiàn)在的sre癡迷開發(fā)的程度已經(jīng)顧不上做這些事情了。決策本身也需要對數(shù)據(jù)有一定的敏感性。

2、監(jiān)控要專注能力建設(shè)

在過去的監(jiān)控系統(tǒng)建設(shè)中，大家一般喜歡按照架構(gòu)做垂直切分，可能長這個(gè)樣子： 

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

如果要解決當(dāng)前這個(gè)困境，我認(rèn)為應(yīng)該摒棄過去按照職責(zé)進(jìn)行系統(tǒng)建設(shè)的方式，比如做個(gè)基礎(chǔ)監(jiān)控系統(tǒng)、網(wǎng)絡(luò)監(jiān)控系統(tǒng)、業(yè)務(wù)監(jiān)控系統(tǒng)，而是轉(zhuǎn)向圍繞業(yè)務(wù)價(jià)值分階段進(jìn)行能力建設(shè)，比如基礎(chǔ)的數(shù)據(jù)采集、傳輸、分析、存儲(chǔ)、展示等能力。轉(zhuǎn)型成為提供海量數(shù)據(jù)收集和中央化規(guī)則計(jì)算、統(tǒng)一分析和報(bào)警能力的現(xiàn)代化監(jiān)控系統(tǒng)【google sre】

在能力建設(shè)過程中，平臺(tái)團(tuán)隊(duì)?wèi)?yīng)該以真實(shí)需求為目標(biāo)，搭建最小可用平臺(tái)(Thinnesr Viable Platform, TVP)，并在團(tuán)隊(duì)中分享最佳實(shí)踐和主動(dòng)賦能用戶，逐步成就卓越用戶。同時(shí)要避免分享的都是沒落地的方法論，畢竟大家都很忙。 

3、嘗試變得有效 

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

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

隨著造的輪子越多，也慢慢發(fā)現(xiàn)自己變得越無效，一直在基礎(chǔ)問題上徘徊。通常越基礎(chǔ)的問題，解決方案也越通用，同時(shí)解決這類問題的ROI也越低，所做的工作也越無效。也不要過分強(qiáng)調(diào)自己場景的特殊性，除非只是想搞一些虛榮指標(biāo)，而不解決本質(zhì)問題。 

那什么是有效的呢？我認(rèn)為核心就是： 

關(guān)注用戶、關(guān)注業(yè)務(wù)，放棄過去通過經(jīng)驗(yàn)的歸納來解決普遍問題，嘗試?yán)脭?shù)據(jù)分析的人機(jī)交互聚焦于核心業(yè)務(wù)，并通過AI/自動(dòng)化處理支撐業(yè)務(wù)和通用業(yè)務(wù)。

不過這事很難，好在我不做監(jiān)控。

展望

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

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

每當(dāng)聊可觀測性時(shí)，我就發(fā)現(xiàn)大家一致認(rèn)為可觀測性可以解決所有的問題，就好比一把屠龍刀，所過之處寸草不生。可你要是詳細(xì)問問用可觀測性做了什么的時(shí)候，就會(huì)有點(diǎn)時(shí)光倒流的感覺，又回到各種儀表盤，滿屏指標(biāo)的時(shí)代。你有可觀測性的故事嘛？ 

2）數(shù)據(jù)收集全面開花 

可觀測性技術(shù)發(fā)展速度感覺非?？欤嚓P(guān)開源項(xiàng)目也越來越多，不過在數(shù)據(jù)收集上有個(gè)令我詫異的問題：有一天別人跟我說，可以在生產(chǎn)環(huán)境收集profiling做可觀測性定位業(yè)務(wù)代碼問題。詫異的點(diǎn)并不是技術(shù)實(shí)現(xiàn)，而是在于什么樣的業(yè)務(wù)需要這種級(jí)別的可觀測性，這種可觀測性面向的用戶又是誰，要解決的問題是什么？你有答案嘛?

3）新瓶裝舊酒 

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

傳統(tǒng)監(jiān)控已死，可觀測性已來。我的監(jiān)控故事就到這里，可以在評論里聊聊你的故事。?