摘要：自動化運維與管控在業界是一個非常普遍的話題，特别是在網際網路圈子裡面，近幾年随着大資料技術的爆發、系統規模和複雜度的提升以及行業開始對ServiceMesh、FAAS等雲原生技術體系的探索，自動化運維與管控在業界及公司内的重要性越發凸顯，然而，自動化運維與管控的應用目前主要集中在各大公司的運維團隊（包括大資料運維）、基礎技術或研發體系支撐團隊，占據研發人員大多數的業務産品技術團隊對其重視程度有限，多數依賴基礎技術産品/平台提供的自助工具并結合業務團隊開發的常用工具集來開展日常系統維護。這裡有個有趣的現象：如果某産品的客戶是技術/研發類人員，則其自動化程度會高些，而若産品的客戶是pd、營運、商家等非技術類人員則其系統自動化程度相對較低，究其原因這和産品研發團隊支援的客戶群體、問題量大小、産品穩定性、抽象程度有關，同時也和團隊規模、團隊文化及所處階段有關。
我們站在安全生産的大背景下來看自動化運維管控，安全生産雖然帶來了更嚴格的系統變更限制和更高的問題響應與處理的要求，但其本質還是要在保障系統風險可控的前提下提升産品研發效率并降低運維成本。這裡的運維需要更廣義的了解：一切的系統代碼、配置或資料的變更管理（變更檢查、執行、灰階、快速復原等）、問題的及時感覺、問題的快速定位與處理、業務或系統資料的監控、依賴的服務或資源的排程、甚至是問題的自助答疑排查等等。究其根本還是要從開發的思維角度來解決問題，那麼，如何建構自動化運維管控體系并衡量其好壞，我們可以嘗試從以下幾個方面來分析下。
自動化運維管控體系的演進
過去幾年，業界關于DevOps的讨論非常多，各大公司也有非常多的基于DevOps的實踐落地，同時近幾年随着大資料、AI概念的普及，AIOps成為當下研究和實踐的熱點方向，不管概念如何定義和演進，xxOps解決問題的核心思路基本遵循以下發展路徑：
自動化體系從其解決問題的角度來看經曆了以下三個發展階段：
1）操作自動化：采用內建的腳本或web類工具來解決同一類問題。
2）場景自動化：基于自動化系統平台，能夠結合目前系統上下文和外部環境并基于事先定義好的條件來做一系列的變更或分析需求。
3）資料驅動智能化：在場景自動化的基礎上，結合嚴格定義的系統名額或業務名額（metrics），具備系統關鍵名額的實時采集、分析、計算能力，再基于特定的算法模型主動識别确定性問題并驅動問題的告警/預警、路由和解決執行。
本文主要闡述如何設計一個好的基于場景的自動化運維管控系統，并向資料驅動智能自動化體系更新。
待解決的核心問題
在闡述這個問題之前，我們先來看以下幾個大家非常熟悉的場景：
1）業務要更新某個業務規則，小二需要在若幹系統管理背景裡做新規則配置，如業務規則應用的系統，風控管理的系統等等，經常出現某新人不熟悉完整流程漏了某個系統的配置，導緻完整的線上業務流程中斷，由于業務中斷的原因有多種，如何快速定位到并徹底解決這類問題成為痛點。
2）現在大資料算法在業務中發揮着巨大的價值，除了常見的推薦搜尋外，在訂單路由和履行決策等場景也大量應用。當更新某個算法模型時，如何做到按照最小業務單元的控制粒度來執行灰階，在出現新模型召回率、準确率下跌時如何做到快速復原并對受影響的訂單快速定位、分析和修複。
3）在分布式系統架構中，通過異步消息解耦複雜系統之間的強依賴是非常常見和優雅的架構設計政策，特别是一個center/platform級别系統通常會向依賴它的上下遊系統發出一些自身業務單據操作或其他實體事件的MQ資訊做為業務執行的觸發條件與依據。為了避免引入過于複雜的系統設計，大家普遍采取非事務一緻性消息模式，當遇到消費者系統故障或消息系統故障等各種因素導緻某些消費者（consumer）出現消息丢失的情形時，作為provider或consumer如何快速發現并補全這類丢失的消息。
4） 某算法引擎是個CPU計算密集型系統，但是由于VM資源隔離不幹淨經常出現同一台主控端上的VM互相幹擾導緻st持續飙高，一旦出現這種現象就會導緻算法引擎無法基于承諾的SAL給上遊傳回計算結果，進而影響業務行為。每次遇到這種情況，引擎的開發同學會第一時間分析是否為st飙高導緻，一旦确認則通過kill jvm來粗暴快速的解決此次問題。此類case非常頻繁，大多數通過客戶回報來驅動問題排查，在虛拟化資源隔離問題未徹底解決之前，作為上遊的業務系統如何更高效、及時、主動的解決這類問題；
5）我們時常遇到線上突然告警，然後開發同學介入排查并執行預案（一般是幾個配置變更）的場景，一般來說處理思路有如下幾種：對上遊做限流降級、對下遊做依賴降級或啟用備用方案、對某個變更做快速復原。對于此類場景我們能否把其中有明确異常信号及處理流程的解決步驟流程化自動化，然後再去人工介入徹底解決呢？人的響應能力畢竟是有極限的，特别是非工作時段，如果能做到先“自動止血”盡可能降低影響面，然後再人工介入，業務上所受的影響會得到一定程度的降低。我們在業務上對異常的定義、識别、定位需要快速精準，要有備用解決方案，采用類似“熔斷機制”的自主可控的處理思路來解決問題。
以上隻是列舉了幾種一線業務系統開發運維時常見的場景，類似的場景還有很多，日常的業務系統答疑、臨時需求解決、臨時變更、各種依賴和基礎環境不穩定時的異常問題跟進等事情占據了我們太多的時間，同時也帶來更多的不安全性，如何系統性的解決這些問題呢？從上面的典型case來看，我們面臨系統運維的效率問題和運維生産的安全性問題，我們需要給出一個具備以下5種特征的解決方案：
a) 名額精細透明：能夠對系統各名額（系統、業務）進行精準、細緻、體系化、實時的監控。
通常來講，衡量一個系統的監控體系做的是否足夠好在于我們能否基于這套名額監控體系講清楚目前業務發生的行為以及行為（正常行為和異常行為）産生的原因，超出目前業務或系統體系則需結合上下遊系統一起來診斷。是以，我們一般會從兩個視角來定義應用系統關鍵名額：業務視角和系統視角，這兩個視角密不可分（如接口調用量和業務單量）。我們将名額分為面向最終結果的名額和面向過程的名額，這些名額同樣也需要精确無歧義的定義，隻有這樣我們才能做到既能直覺了解到系統發生了什麼，也能快速定位背後的原因。最後，名額資料采集和展現的實時性非常重要，關系到我們能否快速了解系統最新的行為。
b) 問題快速發現：能否及時主動的發現系統、業務異常。
基于設計良好的監控名額體系，我們能快速掌握目前業務及系統運作情況，結合我們對業務或系統的專業了解能很快識别出目前系統運作是否正常。如果我們把這些業務或系統可能發生的異常行為通過相關的名額值來表達，則可以基于監控大盤+告警系統做到快速、主動的感覺具體異常行為的發生。更近一步，若能再融入大資料算法模型，把告警更新為預警則效果更好。
c) 預案自動執行：能夠自動執行系統容災或備份鍊路等系統預設的backup方案。
如果我們能用監控名額資料準确定義異常發生時的系統行為且能做到快速識别并有明确的異常處理系統化方案，則可以基于預設的異常條件與處理方案在異常發生時自動觸發系統流程來解決異常或降低異常對系統影響面，為後續開發的介入創造主動性。
d) 變更安全可控：系統變更（業務規則、系統配置等）可灰階執行、資料影響可追溯、變更可快速復原；
通過分析線上故障發現，很大比例的故障是在系統發生變更時産生，針對變更（包括但不限于系統配置項變更、資料訂正、業務規則切換、釋出等），我們一定要有快速復原方案。同時為了控制變更對系統可能産生的影響，一定要有變更灰階執行或灰階生效的機制，對于較常用的變更操作，特别是針對某類場景的組合類變更一定要有工具化、流程化、系統化的解決方案，盡可能降低因人為操作而導緻出錯的機率。
e) 答疑高效支援：針對内部、外部的答疑（問題的定位、分析、排查）提供高效、自助的一站式解決方案；
開發團隊每天都會花費大量精力應對系統内部或外部的問題咨詢與答疑，即使如此仍難免未能支援好所有人的需求。如果對系統的異常行為有清晰的定義和系統化排查與解決方案，則會極大的降低團隊内部排查問題的工作量；再進一步，如果我們把常見的問題抽象成通用的問題分析、處理平台并提供一站式解決方案提供我們的客戶，則不僅将極大降低開發團隊線上上咨詢方面處理的投入度，提升客戶滿意度，更重要的是避免了排查和解決問題時大量的線上操作行為，提升了系統安全與穩定性。
如果能夠很好地解決以上5類問題，不僅能支援好我們的客戶，同時也能極大提升開發團隊的研發效率，降低日常運維的成本，并增強了系統安全與可控性。再回到前述5個典型case，任一問題相信大家都有很好的解決方案，但若這些問題頻頻出現，就需要有系統化的整體解決方案了，而這絕不是一個小二工作台或工具平台能獨自完成的事情。下面我們就來探讨如何設計一個完整的自動化運維管控體系。
自動化運維管控體系設計思路
下圖是一個抽象的自動化運維管控系統的通用架構設計參考思路。
核心思路是把一切變更操作标準化、流程化、自助化、自動化，降低人工幹預程度，提升操作效率。實作這張架構圖并疊代演進是一個跨多個職能團隊協作（Cross-Functional Autonomous Teams ）的工作，一切要以客戶需求出發，進行持續的抽象和疊代。
我們來分解一下這裡面的核心子產品與其關鍵設計原則。
監控資料采集：監控大盤是觀察系統的眼睛，一個系統的監控名額是否精細、完整和實時直接關系到這個系統的可運維性，監控名額又分為兩大類：業務系統依賴的基礎設施的運作時名額（系統類名額）和業務系統自身的業務名額（業務類名額，又分為業務結果資料資料和業務執行過程資料）。具體需要監控哪些資料主要從兩個角度來梳理：系統類名額主要從可能會影響系統穩定的點來梳理哪些系統資料顯性化有助于我們快速分析定位問題；業務類名額要從業務關心的目标結果資料以及影響這些目标結果達成的過程資料來梳理。目前集團内業務系統依賴的基礎中間件、存儲、VM等關鍵系統名額資料非常全面，是以我們的側重點在業務類名額的梳理和完善上。又由于名額采集的工具、資料分析計算平台都很完備，做好系統資料的監控采集并不難。
異常自動識别：我們常從異常、失敗的角度來做資料的埋點、采集和監控，很大一部分異常可以直接通過設定單次元監控預警門檻值來進行識别，進而做到精準監控；部分異常需要結合上下文或上下遊依賴的資料利用業務知識做二次分析判斷，如監控到快遞公司某條線路的包裹時效出現波動，由于快遞網絡包裹配送是一個多角色協同的場景，具體哪個環節出了問題還需要結合更細粒度的資料來分析，這裡可能會引入一些算法模型。還有部分異常目前還做不到自動判斷，需要人工幹預。此外，目前還有一種高階的做法是基于AI技術做異常預警，基于目前的資料可以預測異常即将發生。
Root Cause分析定位：這個領域基本上是模闆驅動（Automated pattern discovery），前提是能夠準确分析某類異常發生的根本原因且在對應的業務系統自動化體系裡有現成的解決方案，否則就隻能人工介入做決策。在依靠人工對異常問題處理的幹預的同時，我們也能夠沉澱更多的自動解決方案。
異常/變更處理：整個體系最重要的環節，包含預設的解決方案（系統具備的自動處理能力）、變更安全管控子產品、對外核心處理能力的內建與驅動。
1） 預設的解決方案：通過業務知識的沉澱形成所謂的專家庫，這些沉澱一方面來自于系統業務邏輯設計時制定的規則，另外一方面來自于日常對各種問題處理時的積累，它是一個不斷疊代優化的過程。
2）變更安全管控子產品：自動化體系建設确實能夠提升解決問題的效率，但也使線上系統變更的成本變得更低了，為保證線上變更的安全性，需要對關鍵的變更做好權限控制，配置類變更需要做好版本控制和灰階釋出，同時也要具備變更暫停和快速復原的能力。對于大數量的變更或大量任務重試等還需要考慮限速限流的能力，避免把下遊系統“打垮”，同時基于“重監控、輕管控”的原則，系統也要做好變更操作的關鍵記錄便于事後追溯，有些變更帶來的影響具備較長的延時性，這時記錄資訊能夠起到非常關鍵的作用。
3）對外核心處理能力的內建與驅動：自動化管控系統不應涉及到太多的業務細節，它可能需要基于某個場景來協同多個系統單元來提供整體的自動化/自助化解決方案，但是每個系統單元的能力應該由各系統獨自封裝并以API的形式提供出來。自動化運維管控系統是目标驅動的，不關心API實作的細節，如：“我們需要修正某個包裹資訊裡面的業務規則并更新資訊至下遊合作夥伴系統”，業務運維管控系統裡面對小二提供的是個一鍵修正的功能。在管控系統實作層面可能會分别依賴業務系統A、業務系統B提供的不同API，至于每個接口内部如何實作管控系統并不關心。業務系統需要保證每個獨立API具備可重試和幂等的原則，并由管控系統來保證結果的最終執行，即使執行不成功原則上也不影響原有業務系統的資料和邏輯（由于非事物一緻性）。基礎系統也同樣遵循這個原則，隻不過目前阿裡體系内部研發基礎設施非常完備，基本上常用的中間件體系都有配套良好的運維控制系統，是以我們對這類系統的運維變更需求都是登入對應中間件管控平台操作，也有部分中間件産品對外開放了常用的API（基本都是RESTful 風格）供業務自動化運維管控系統來內建。
安全機制：這裡的安全指系統或資料安全。在研發人員心中自動化管控系統的重要性通常低于其服務的業務系統的，是以在系統架構設計、代碼品質、研發規範、安全等級等方面投入的精力和重視程度會打折扣。筆者曾見到一些系統的安全Bug在釋出前置檢查流程裡面安全校驗不通過則利用安全白名單機制繞開，這其實是不可取的，一個功能齊全的自動化運維管控系統對線上資料、業務變更的權限很大，可視作一個内部超級賬号，即使内網很安全，我們也要避免意外發生。
通過以上分析我們發現一個好的自動化運維管控系統平台絕不僅僅是一個功能複雜的工具集，它應具備良好的系統化架構與設計，需要和業務系統密切配合又不關心業務處理的細節，基于（問題）場景為使用者提供簡單直接的解決方案。管控系統和業務系統最大的差別是管控系統需要為業務系統服務，幫助業務系統快速定位問題、解決問題，而不是替業務系統解決問題。一個極端的例子是管控系統裡面包含大量直接操作業務系統庫表的工具集并自定義組裝業務變更的邏輯，這樣一旦業務模型更新或邏輯發生變化時，該管控系統就失去了應用的意義。
如何衡量自動化運維管控系統做的好壞
衡量自動化運維管控系統應看其到底要解決那些問題，如前文所說：問題的快速發現、預案的自動執行、變更操作安全可控、日常答疑高效支援、系統名額精細透明等。其本質還是解決安全與效率的問題，是以可以從以下幾個次元進行衡量。
1.由于系統變更導緻的線上故障分是否有所收斂，是否有因為變更導緻的故障，出現故障後是否有快速分析定位和修複問題的自動化機制等；
2.在滿足所負責産品日常答疑需求的前提下觀察團隊在答疑支援上面的投入程度，這是一個持續建設的過程，知識庫、自動化技術系統都需要持續完善；
3.開發人員在工作中被中斷的頻率是否下降，在重複性事務上花費的時間是否減少，關鍵産出是否提升等。
對于系統中哪些方面需要自動化，我的觀點是 Automate Everything You Can ！然而,自動化不是銀彈，它能保證問題的快速發現和響應，起到緩解問題的作用，但無法解決因為系統架構設計不合理帶來的根本性問題。本文沒有涉及研發階段非常重要的持續內建等概念，更多的是站在現有問題體系下闡述如何做好系統的自動化運維管控。
自動化運維管控體系技術展望
1.随着業務複雜度的提升，資料規模持續增長，AIOps的價值會越來越明顯，有些局部領域已經開始這方面的嘗試與突破；
2.随着雲計算的普及未來基于雲的研發模式會成為普遍現象，且随着雲原生技術的快速發展，未來在雲上提供開箱即用的基礎設施服務将使業務研發團隊更加聚焦在業務系統的研發上，業務系統的自動化管控運維也會更加聚焦自身所服務的業務系統上。雲原生基礎技術将更加大衆化，業務團隊不會再享受到過去那種基礎平台的貼身服務了，這也驅使業務研發團隊更加重視自身系統的自動化營運管控體系建設。
文章來源：AlibabaTechQA
開發者社群整理