無線運維的起源與項目建設思考
原本是計劃寫寫無線運維的項目年度總結的，但是想想一個項目總結文章，只是對自己和項目有個回顧和交代，對于無線運維這個新的概念，還不如放開討論一下。說到這里，可能一些好奇的同學可能會發出靈魂三問：什么是無線運維 ？為什么要做無線運維？無線運維能解決什么問題？因此，作為一個從開發轉入安全生產時間不太長的小白，結合自身在無線運維項目建設過程中的思考，來說說無線運維的起源，可能更好的重溫初心。
無線運維的來歷
說起運維一詞，很多人第一印象都會想到后端基礎設施的維護和保障，哪怕當前是無線互聯網繁榮的今天，基本也不會一下子想到運維跟無線端有什么大的聯系；那么首先我們來看看百度詞條對運維的釋義：
“運維，本質上是對網絡、服務器、服務的生命周期各個階段的運營與維護，在成本、穩定性、效率上達成一致可接受的狀態。”
從上面百度詞條對運維的釋義來看，運維是一個持續性的行為，范圍是基礎設施以及運行在基礎設施上的服務，同時職責上還要兼顧穩定性和效率；隨著國內外各大云廠商業態的出現和發展，基礎設施已經云化，互聯網的各個廠商可以更多的把精力放在業務服務上，因此保障提供的業務服務的穩定性成了現在運維的重點。
如今移動互聯網消費業務豐富多樣，拋開服務的架構和部署形態，單純從提供服務的組成來看，絕大多數都少不了提供數據計算和業務服務的后端程序和響應用戶交互的前端程序；提供數據計算和業務服務的后端程序的運維從之前的傳統運維繼承下來了很多成熟的運維工具和運維手段；響應用戶交互的前端程序這一塊，因為是運行在用戶的無線設備上，天生的分布式和設備差異，讓無線側的運維的復雜性增加了許多；如何保持業務和服務在用戶無線設備上的穩定運行，讓用戶擁有良好的使用體感，就是無線運維的來歷。
要解決的問題
在無線互聯網繁榮發展多年后，我們在無線端看到了很多的運維產品，比如用戶打點和監測日志，用戶輿情反饋和聚合訂閱，熱修復等生態工具和平臺，這些都是一些被動的或者等問題出現后才感知并去處理的工具和平臺；像手淘這樣的前后端上千人協同開發，頻繁發布和更新各種服務，擁有億級別用戶群的產品，被動發現問題就意味著后知后覺的線上故障；因此無線運維的北極星目標，就是提高線上問題的發現率。
如果一個事物各物理參數不隨時間變化處于平衡時的狀態，那么他基本上就處于物理學意義總的穩定；基于我們過往的線上問題處理經驗，也基本驗證了：穩定性的波動大多數都是變更帶來的；在業務迭代中，有的是上游或者下游的變動被動的對你的業務產生了穩定性影響，有的是自己的業務變更對自己的業務穩定性造成波動；因此無線運維在問題的發現率上，從兩個方面去著手：一個是日常的線上問題發現，一個基于自身變更灰度放量下的問題發現。
1.日常線上問題的發現效率
日常情況下，很多問題可能是由于業務上下游的變更導致當前的業務被動出現穩定性問題，也有一些是自身的變更造成長尾歷史版本出現穩定性問題；不論那種情況，這些被發現的問題，短的也逗留了幾天或一周，長的幾周甚至裸奔幾個月；對于這種問題，我們沒有啥未卜先知的好辦法，需要通過各個業務配置(不定期更新)業務核心監控和訂閱規則告警，以及用戶反饋的業務輿情信息的日常值班留觀。
配置訂閱的監控，告警，輿情等穩定性反饋渠道，對于手淘這種流量巨大的產品，底層數據的量級也是比較大的，通過2020年的基礎鏈路團隊從7月份到12月份的日常穩定性值班實踐情況來看，每天去Crash平臺，輿情平臺，告警記錄等都相對仔細的瀏覽一遍，人力上也要平均四十分鐘到一個小時左右的時間；如果有疑似問題，排查除疑那又是另外的時間了；因此日常線上問題的發現，發力點是提升問題的發現效率。
發現效率的提升，也就是要提升日常值班的效率；因此，對于Crash我們除了訂閱自己負責的業務模塊最好把自己業務重點依賴的模塊也訂閱上，然后通過排行，環比上升等方式來快速突顯快速變化的記錄；輿情方面，通過一段時間的正負樣本打標訓練來過濾技術性輿情，同時對于輿情圖片接入OCR和關鍵詞來區分輿情與業務的關聯性；告警方面，目前的告警很多都是基于一個閾值來觸發，但是線上如果有促銷活動，基于閾值的告警則誤告頻繁，因此基于時序算法的趨勢告警準確性更高。
2.小流量放量下問題的主動發現率
對于用戶規模比較大的移動互聯網產品，無灰度不變更是每個人都逐漸建立的安全生產意識；在小流量下的變更放量，對于產品側來說，可以收集用戶側的點擊、轉化等數據，來分析小規模用戶對新特性的接受程度，作為改進產品/運營策略或是鋪開/全量的一個輔助依據；對于開發和測試來說，通過小流量，能初步的驗證代碼變更在小范圍的不同的用戶設備上的運行的穩定性情況，有問題則迅速修復無問題則擴大放量比例。
不管是產品/運營還是開發/測試，要觀測小流量下的這一部分用戶反饋數據，單靠一個唯一的灰度版本號，并不能比較真實的從全局數據大盤中圈出這一小部分數據；因為放量推送10W，并不一定意味著被推送的用戶都看見/走到了你變更的那一部分新特性！因此要想知道新的特性是否真正的在用戶側觸達，端側需要對特性生效做"染色"。與此同時，用戶在新特性的實際暴露期，我們在APP的Crash報告，輿情反饋上報，監控埋點上報等環節，都帶上這個唯一的染色標記；這樣我們在放量后的沉淀階段，通過這個唯一的染色標，就可以清洗出此次新特性在用戶設備上生效時產生的各種用戶反饋數據。
作為一個多業務模塊的用戶產品，多團隊協同并行變更是常態，一個版本一個時間段內，可能不止一個業務在進行變更放量，比如一條Crash報告，如何區分到底是哪一個業務變更造成的呢 ? 這種很難快速判斷劃分，因此我們把當前多個在變更生效的特性的染色標都帶上，在變更染色下的Crash數據的清洗的時候，這條Crash就會出現在多個變更放量的留觀的Crash列表中，保證線上問題不遺漏；其他的穩定性染色數據的上報和清洗遵從同樣的規則。
有了能準確清洗出變更特性實際生效下染色多個穩定性指標數據的手段，我們在小流量放量并逐步加大放量的過程中，就能只看變更影響下的數據；如果沒有這個手段，小流量放量產生的問題，由于比例比較小，在大盤海量數據作為分母的情況下，連一個漣漪都不會泛起。等到大規模放量甚至全量的時候，問題被明顯暴露出來，之前的小范圍問題可能已經是大范圍故障了。
能解決什么問題
上面所說的日常線上問題發現效率和變更下問題的主動發現率，如果業務團隊都付出行動和努力，進行了值班留觀和變更染色接入，對于業務團隊來說，能多大程度解決業務同學在線上問題的安全焦慮？這個其實就看我們通過做了這兩方面的事情，深層次是解決了什么 ？
1.轉被動為主動
按照集團安全生產的要求，對于線上問題，要求5分鐘響應，15分鐘定位，60分鐘解決，這個目標來看，也是希望研測同學能盡早的響應和解決線上問題，越早的解決掉線上問題，業務同學也能相對的越主動。
在日常的業務值班方面，經過在基礎鏈路客戶端團隊2月份-3月份的實踐經驗來看，每天輪流花個十五分鐘到半個小時，進行線上穩定性的巡檢，能大大縮短問題的暴露時長，提高線上問題的響應效率，在問題影響變大之前，通過前后端的業務開關，降級預案，熱修復等手段，基本能快速解決大部分的巡檢出來的問題。
在變更灰度的放量監控方面，我們通過2021年的基礎鏈路部分重點項目的對接和業務開關平臺灰度發布監控的效果來看，我們通過染色下的輿情、Crash、服務端錯誤碼，在變更發布的小流量灰度放量期間，均有效捕獲了業務/技術上的有效問題。這些問題都是在小流量的驗證下發現，并通過服務端和放量平臺的流量回滾規避了問題的暴露和擴散，相對日常巡檢值班來說，可以算做是真正意義上的主動發現問題。
2.縮小問題爆炸半徑
一個線上問題對用戶的影響可以用三個維度來度量，三個維度疊加決定了問題的實際“爆炸半徑”：
- 問題持續時長：問題從發生到恢復的總體時長
- 問題影響面：發生的次數， 影響的設備數
- 問題嚴重程度： 對用戶使用造成的影響程度，可以大致分為幾個等級：阻塞不可用（閃退、核心功能不可用）、部分不可用、輕微不可用、無影響
日常的業務巡檢值班可以縮短線上問題的發現時間，減小問題持續時長；變更灰度的放量監控可以盡早捕捉問題和控制受影響的設備數量，減小問題的影響面和問題嚴重程度；無線運維緊抓日常和變更兩個場景，能有效的控制和縮小問題的爆炸半徑；
未來想解決什么問題
上述對無線運維要解決的問題，能解決什么問題的闡述內容，也是目前無線運維這一年探索和建設并且已經上線的部分。在過去的2021年里，對接業務日常和變更下的線上穩定性訴求過程中，深感目前我們還處于一個初期的階段，雖然從海量數據留觀走到了業務關心的小部分數據留觀和監控，但是目前還是需要業務同學投入較多的人肉工作量；業務同學也在這個過程中提出了更高的要求，希望能實現業務變更的分階段發布的流程化，業務Top輿情場景診斷和告警的智能化，從安全生產角度能卡住那些變更質量不達標的發布。
1.分階段發布
目前的業務變更放量，大多是通過業務開關、圈選人群或者類似一休這樣的放量平臺進行放量，通過不斷的擴量，不斷的留觀，直至業務全量；這個過程可能持續幾個月，對研測同學來說，線上穩定性是有足夠時間來保障，對產品運營同學來說，業務全量鋪開的效率顯得過低；因此期望，能有一個從內到外，流量從小到大的分階段發布流程，每個階段驗證無誤后，能快速流轉到下一個階段；
- 內網白名單：業務的產研測、上下游團隊以及TL，先進行內部體驗；
- 內網灰度：集團內網有很多熱心的同學積極反饋問題，能反饋很多產品體驗和功能bug，兜住家丑
- 外網人群：產品運營圈選的第一波人群用戶，觀測用戶數據反饋，研測關注外網用戶線上穩定性問題
- 外網分批灰度：分批遞增灰度放量，業務&體驗&穩定性綜合驗證
- 外網全量：多次灰度驗證完成，停止變更染色，業務全量
2.智能診斷
日常線上問題巡檢和變更下的線上問題的我們有監控和留觀等機制保障，但是有時確認一個問題它是否是一個需要處理的問題，這個過程往往也比較耗時；還有些問題并非是通過Crash，埋點監控告警能發現，比如頁面組件缺失導致業務阻塞等問題很多都是通過輿情來反饋的；如果問題的確認、分析和診斷，都靠拉群排查是偏低效的，通過規范化的埋點，體系化的排查手段，引入算法是比較好的輔助方式；
- 定義&完善業務日志規范，打好日志可視化基礎，建立全鏈路排查體系；
- 覆蓋業務阻塞/阻斷的輿情場景，結合用戶日志和埋點，進行智能分析診斷；
- Crash/告警，從基于閾值觸發升級到基于時序算法的趨勢智能告警；
3.發布卡口
雖然我們已經有了變更染色的手段，可以對變更下的穩定性問題進行多個指標的監控，但是當前批次的發布綜合的質量是否達到安全生產的要求，并沒有給出一個詳細的結論，更多是靠研測同學自行判斷決策；因此在發布過程中做每個批次的卡口，幫研測同學分析評估是否可以進入下一階段的發布，能有一個更高效和安全的體感。
- 線性遞增式發布：如業務開關、Patch，放量線性遞增，全量時間周期相對短，對于每次遞增放量，都應該綜合染色數據各項指標和灰度標準做Check，對于不滿足灰度標準或者染色數據指標有異常的，應該及時提示卡住；
- 回旋往復式發布：如一休、服務端自定義規則放量，多個分支的流量可以隨時自由調配或回滾，放量周期相對比較長，在不同的流量配置疊加驗證時，也要關注對線上命中用戶的穩定性影響，對于出現異常的實驗分支，要及時提示卡住；
