原本是計劃寫寫無線運維的項目年度總結(jié)的，但是想想一個項目總結(jié)文章，只是對自己和項目有個回顧和交代，對于無線運維這個新的概念，還不如放開討論一下。說到這里，可能一些好奇的同學(xué)可能會發(fā)出靈魂三問：什么是無線運維 ？為什么要做無線運維？無線運維能解決什么問題？因此，作為一個從開發(fā)轉(zhuǎn)入安全生產(chǎn)時間不太長的小白，結(jié)合自身在無線運維項目建設(shè)過程中的思考，來說說無線運維的起源，可能更好的重溫初心。

無線運維的來歷

說起運維一詞，很多人第一印象都會想到后端基礎(chǔ)設(shè)施的維護和保障，哪怕當前是無線互聯(lián)網(wǎng)繁榮的今天，基本也不會一下子想到運維跟無線端有什么大的聯(lián)系；那么首先我們來看看百度詞條對運維的釋義：

“運維，本質(zhì)上是對網(wǎng)絡(luò)、服務(wù)器、服務(wù)的生命周期各個階段的運營與維護，在成本、穩(wěn)定性、效率上達成一致可接受的狀態(tài)。” 

從上面百度詞條對運維的釋義來看，運維是一個持續(xù)性的行為，范圍是基礎(chǔ)設(shè)施以及運行在基礎(chǔ)設(shè)施上的服務(wù)，同時職責上還要兼顧穩(wěn)定性和效率；隨著國內(nèi)外各大云廠商業(yè)態(tài)的出現(xiàn)和發(fā)展，基礎(chǔ)設(shè)施已經(jīng)云化，互聯(lián)網(wǎng)的各個廠商可以更多的把精力放在業(yè)務(wù)服務(wù)上，因此保障提供的業(yè)務(wù)服務(wù)的穩(wěn)定性成了現(xiàn)在運維的重點。

如今移動互聯(lián)網(wǎng)消費業(yè)務(wù)豐富多樣，拋開服務(wù)的架構(gòu)和部署形態(tài)，單純從提供服務(wù)的組成來看，絕大多數(shù)都少不了提供數(shù)據(jù)計算和業(yè)務(wù)服務(wù)的后端程序和響應(yīng)用戶交互的前端程序；提供數(shù)據(jù)計算和業(yè)務(wù)服務(wù)的后端程序的運維從之前的傳統(tǒng)運維繼承下來了很多成熟的運維工具和運維手段；響應(yīng)用戶交互的前端程序這一塊，因為是運行在用戶的無線設(shè)備上，天生的分布式和設(shè)備差異，讓無線側(cè)的運維的復(fù)雜性增加了許多；如何保持業(yè)務(wù)和服務(wù)在用戶無線設(shè)備上的穩(wěn)定運行，讓用戶擁有良好的使用體感，就是無線運維的來歷。

要解決的問題

在無線互聯(lián)網(wǎng)繁榮發(fā)展多年后，我們在無線端看到了很多的運維產(chǎn)品，比如用戶打點和監(jiān)測日志，用戶輿情反饋和聚合訂閱，熱修復(fù)等生態(tài)工具和平臺，這些都是一些被動的或者等問題出現(xiàn)后才感知并去處理的工具和平臺；像手淘這樣的前后端上千人協(xié)同開發(fā)，頻繁發(fā)布和更新各種服務(wù)，擁有億級別用戶群的產(chǎn)品，被動發(fā)現(xiàn)問題就意味著后知后覺的線上故障；因此無線運維的北極星目標，就是提高線上問題的發(fā)現(xiàn)率。

如果一個事物各物理參數(shù)不隨時間變化處于平衡時的狀態(tài)，那么他基本上就處于物理學(xué)意義總的穩(wěn)定；基于我們過往的線上問題處理經(jīng)驗，也基本驗證了：穩(wěn)定性的波動大多數(shù)都是變更帶來的；在業(yè)務(wù)迭代中，有的是上游或者下游的變動被動的對你的業(yè)務(wù)產(chǎn)生了穩(wěn)定性影響，有的是自己的業(yè)務(wù)變更對自己的業(yè)務(wù)穩(wěn)定性造成波動；因此無線運維在問題的發(fā)現(xiàn)率上，從兩個方面去著手：一個是日常的線上問題發(fā)現(xiàn)，一個基于自身變更灰度放量下的問題發(fā)現(xiàn)。

1.日常線上問題的發(fā)現(xiàn)效率

日常情況下，很多問題可能是由于業(yè)務(wù)上下游的變更導(dǎo)致當前的業(yè)務(wù)被動出現(xiàn)穩(wěn)定性問題，也有一些是自身的變更造成長尾歷史版本出現(xiàn)穩(wěn)定性問題；不論那種情況，這些被發(fā)現(xiàn)的問題，短的也逗留了幾天或一周，長的幾周甚至裸奔幾個月；對于這種問題，我們沒有啥未卜先知的好辦法，需要通過各個業(yè)務(wù)配置(不定期更新)業(yè)務(wù)核心監(jiān)控和訂閱規(guī)則告警，以及用戶反饋的業(yè)務(wù)輿情信息的日常值班留觀。

配置訂閱的監(jiān)控，告警，輿情等穩(wěn)定性反饋渠道，對于手淘這種流量巨大的產(chǎn)品，底層數(shù)據(jù)的量級也是比較大的，通過2020年的基礎(chǔ)鏈路團隊從7月份到12月份的日常穩(wěn)定性值班實踐情況來看，每天去Crash平臺，輿情平臺，告警記錄等都相對仔細的瀏覽一遍，人力上也要平均四十分鐘到一個小時左右的時間；如果有疑似問題，排查除疑那又是另外的時間了；因此日常線上問題的發(fā)現(xiàn)，發(fā)力點是提升問題的發(fā)現(xiàn)效率。

發(fā)現(xiàn)效率的提升，也就是要提升日常值班的效率；因此，對于Crash我們除了訂閱自己負責的業(yè)務(wù)模塊最好把自己業(yè)務(wù)重點依賴的模塊也訂閱上，然后通過排行，環(huán)比上升等方式來快速突顯快速變化的記錄；輿情方面，通過一段時間的正負樣本打標訓(xùn)練來過濾技術(shù)性輿情，同時對于輿情圖片接入OCR和關(guān)鍵詞來區(qū)分輿情與業(yè)務(wù)的關(guān)聯(lián)性；告警方面，目前的告警很多都是基于一個閾值來觸發(fā)，但是線上如果有促銷活動，基于閾值的告警則誤告頻繁，因此基于時序算法的趨勢告警準確性更高。

2.小流量放量下問題的主動發(fā)現(xiàn)率

對于用戶規(guī)模比較大的移動互聯(lián)網(wǎng)產(chǎn)品，無灰度不變更是每個人都逐漸建立的安全生產(chǎn)意識；在小流量下的變更放量，對于產(chǎn)品側(cè)來說，可以收集用戶側(cè)的點擊、轉(zhuǎn)化等數(shù)據(jù)，來分析小規(guī)模用戶對新特性的接受程度，作為改進產(chǎn)品/運營策略或是鋪開/全量的一個輔助依據(jù)；對于開發(fā)和測試來說，通過小流量，能初步的驗證代碼變更在小范圍的不同的用戶設(shè)備上的運行的穩(wěn)定性情況，有問題則迅速修復(fù)無問題則擴大放量比例。

不管是產(chǎn)品/運營還是開發(fā)/測試，要觀測小流量下的這一部分用戶反饋數(shù)據(jù)，單靠一個唯一的灰度版本號，并不能比較真實的從全局數(shù)據(jù)大盤中圈出這一小部分數(shù)據(jù)；因為放量推送10W，并不一定意味著被推送的用戶都看見/走到了你變更的那一部分新特性！因此要想知道新的特性是否真正的在用戶側(cè)觸達，端側(cè)需要對特性生效做"染色"。與此同時，用戶在新特性的實際暴露期，我們在APP的Crash報告，輿情反饋上報，監(jiān)控埋點上報等環(huán)節(jié)，都帶上這個唯一的染色標記；這樣我們在放量后的沉淀階段，通過這個唯一的染色標，就可以清洗出此次新特性在用戶設(shè)備上生效時產(chǎn)生的各種用戶反饋數(shù)據(jù)。

作為一個多業(yè)務(wù)模塊的用戶產(chǎn)品，多團隊協(xié)同并行變更是常態(tài)，一個版本一個時間段內(nèi)，可能不止一個業(yè)務(wù)在進行變更放量，比如一條Crash報告，如何區(qū)分到底是哪一個業(yè)務(wù)變更造成的呢 ? 這種很難快速判斷劃分，因此我們把當前多個在變更生效的特性的染色標都帶上，在變更染色下的Crash數(shù)據(jù)的清洗的時候，這條Crash就會出現(xiàn)在多個變更放量的留觀的Crash列表中，保證線上問題不遺漏；其他的穩(wěn)定性染色數(shù)據(jù)的上報和清洗遵從同樣的規(guī)則。

有了能準確清洗出變更特性實際生效下染色多個穩(wěn)定性指標數(shù)據(jù)的手段，我們在小流量放量并逐步加大放量的過程中，就能只看變更影響下的數(shù)據(jù)；如果沒有這個手段，小流量放量產(chǎn)生的問題，由于比例比較小，在大盤海量數(shù)據(jù)作為分母的情況下，連一個漣漪都不會泛起。等到大規(guī)模放量甚至全量的時候，問題被明顯暴露出來，之前的小范圍問題可能已經(jīng)是大范圍故障了。

能解決什么問題

上面所說的日常線上問題發(fā)現(xiàn)效率和變更下問題的主動發(fā)現(xiàn)率，如果業(yè)務(wù)團隊都付出行動和努力，進行了值班留觀和變更染色接入，對于業(yè)務(wù)團隊來說，能多大程度解決業(yè)務(wù)同學(xué)在線上問題的安全焦慮？這個其實就看我們通過做了這兩方面的事情，深層次是解決了什么 ？ 

1.轉(zhuǎn)被動為主動

按照集團安全生產(chǎn)的要求，對于線上問題，要求5分鐘響應(yīng)，15分鐘定位，60分鐘解決，這個目標來看，也是希望研測同學(xué)能盡早的響應(yīng)和解決線上問題，越早的解決掉線上問題，業(yè)務(wù)同學(xué)也能相對的越主動。

在日常的業(yè)務(wù)值班方面，經(jīng)過在基礎(chǔ)鏈路客戶端團隊2月份-3月份的實踐經(jīng)驗來看，每天輪流花個十五分鐘到半個小時，進行線上穩(wěn)定性的巡檢，能大大縮短問題的暴露時長，提高線上問題的響應(yīng)效率，在問題影響變大之前，通過前后端的業(yè)務(wù)開關(guān)，降級預(yù)案，熱修復(fù)等手段，基本能快速解決大部分的巡檢出來的問題。

在變更灰度的放量監(jiān)控方面，我們通過2021年的基礎(chǔ)鏈路部分重點項目的對接和業(yè)務(wù)開關(guān)平臺灰度發(fā)布監(jiān)控的效果來看，我們通過染色下的輿情、Crash、服務(wù)端錯誤碼，在變更發(fā)布的小流量灰度放量期間，均有效捕獲了業(yè)務(wù)/技術(shù)上的有效問題。這些問題都是在小流量的驗證下發(fā)現(xiàn)，并通過服務(wù)端和放量平臺的流量回滾規(guī)避了問題的暴露和擴散，相對日常巡檢值班來說，可以算做是真正意義上的主動發(fā)現(xiàn)問題。

2.縮小問題爆炸半徑

一個線上問題對用戶的影響可以用三個維度來度量，三個維度疊加決定了問題的實際“爆炸半徑”：

1. 問題持續(xù)時長：問題從發(fā)生到恢復(fù)的總體時長
2. 問題影響面：發(fā)生的次數(shù)， 影響的設(shè)備數(shù)
3. 問題嚴重程度： 對用戶使用造成的影響程度，可以大致分為幾個等級：阻塞不可用（閃退、核心功能不可用）、部分不可用、輕微不可用、無影響

日常的業(yè)務(wù)巡檢值班可以縮短線上問題的發(fā)現(xiàn)時間，減小問題持續(xù)時長；變更灰度的放量監(jiān)控可以盡早捕捉問題和控制受影響的設(shè)備數(shù)量，減小問題的影響面和問題嚴重程度；無線運維緊抓日常和變更兩個場景，能有效的控制和縮小問題的爆炸半徑；

未來想解決什么問題

上述對無線運維要解決的問題，能解決什么問題的闡述內(nèi)容，也是目前無線運維這一年探索和建設(shè)并且已經(jīng)上線的部分。在過去的2021年里，對接業(yè)務(wù)日常和變更下的線上穩(wěn)定性訴求過程中，深感目前我們還處于一個初期的階段，雖然從海量數(shù)據(jù)留觀走到了業(yè)務(wù)關(guān)心的小部分數(shù)據(jù)留觀和監(jiān)控，但是目前還是需要業(yè)務(wù)同學(xué)投入較多的人肉工作量；業(yè)務(wù)同學(xué)也在這個過程中提出了更高的要求，希望能實現(xiàn)業(yè)務(wù)變更的分階段發(fā)布的流程化，業(yè)務(wù)Top輿情場景診斷和告警的智能化，從安全生產(chǎn)角度能卡住那些變更質(zhì)量不達標的發(fā)布。

1.分階段發(fā)布

目前的業(yè)務(wù)變更放量，大多是通過業(yè)務(wù)開關(guān)、圈選人群或者類似一休這樣的放量平臺進行放量，通過不斷的擴量，不斷的留觀，直至業(yè)務(wù)全量；這個過程可能持續(xù)幾個月，對研測同學(xué)來說，線上穩(wěn)定性是有足夠時間來保障，對產(chǎn)品運營同學(xué)來說，業(yè)務(wù)全量鋪開的效率顯得過低；因此期望，能有一個從內(nèi)到外，流量從小到大的分階段發(fā)布流程，每個階段驗證無誤后，能快速流轉(zhuǎn)到下一個階段；

• 內(nèi)網(wǎng)白名單：業(yè)務(wù)的產(chǎn)研測、上下游團隊以及TL，先進行內(nèi)部體驗；
• 內(nèi)網(wǎng)灰度：集團內(nèi)網(wǎng)有很多熱心的同學(xué)積極反饋問題，能反饋很多產(chǎn)品體驗和功能bug，兜住家丑
• 外網(wǎng)人群：產(chǎn)品運營圈選的第一波人群用戶，觀測用戶數(shù)據(jù)反饋，研測關(guān)注外網(wǎng)用戶線上穩(wěn)定性問題
• 外網(wǎng)分批灰度：分批遞增灰度放量，業(yè)務(wù)&體驗&穩(wěn)定性綜合驗證
• 外網(wǎng)全量：多次灰度驗證完成，停止變更染色，業(yè)務(wù)全量

2.智能診斷

日常線上問題巡檢和變更下的線上問題的我們有監(jiān)控和留觀等機制保障，但是有時確認一個問題它是否是一個需要處理的問題，這個過程往往也比較耗時；還有些問題并非是通過Crash，埋點監(jiān)控告警能發(fā)現(xiàn)，比如頁面組件缺失導(dǎo)致業(yè)務(wù)阻塞等問題很多都是通過輿情來反饋的；如果問題的確認、分析和診斷，都靠拉群排查是偏低效的，通過規(guī)范化的埋點，體系化的排查手段，引入算法是比較好的輔助方式；

1. 定義&完善業(yè)務(wù)日志規(guī)范，打好日志可視化基礎(chǔ)，建立全鏈路排查體系；
2. 覆蓋業(yè)務(wù)阻塞/阻斷的輿情場景，結(jié)合用戶日志和埋點，進行智能分析診斷；
3. Crash/告警，從基于閾值觸發(fā)升級到基于時序算法的趨勢智能告警；

3.發(fā)布卡口

雖然我們已經(jīng)有了變更染色的手段，可以對變更下的穩(wěn)定性問題進行多個指標的監(jiān)控，但是當前批次的發(fā)布綜合的質(zhì)量是否達到安全生產(chǎn)的要求，并沒有給出一個詳細的結(jié)論，更多是靠研測同學(xué)自行判斷決策；因此在發(fā)布過程中做每個批次的卡口，幫研測同學(xué)分析評估是否可以進入下一階段的發(fā)布，能有一個更高效和安全的體感。

• 線性遞增式發(fā)布：如業(yè)務(wù)開關(guān)、Patch，放量線性遞增，全量時間周期相對短，對于每次遞增放量，都應(yīng)該綜合染色數(shù)據(jù)各項指標和灰度標準做Check，對于不滿足灰度標準或者染色數(shù)據(jù)指標有異常的，應(yīng)該及時提示卡??；
• 回旋往復(fù)式發(fā)布：如一休、服務(wù)端自定義規(guī)則放量，多個分支的流量可以隨時自由調(diào)配或回滾，放量周期相對比較長，在不同的流量配置疊加驗證時，也要關(guān)注對線上命中用戶的穩(wěn)定性影響，對于出現(xiàn)異常的實驗分支，要及時提示卡住；