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