與一個行業(yè)大牛的朋友交流時，在聽到他年輕時在思科的一些關于將工作方法升華為方法論，比如“監(jiān)、管、控”、“新網(wǎng)點”理念，并推動整個行業(yè)建設時為之一震。這個觸動讓我有了讓自己的運維知識體系建設做第一次飛躍的打算，即如何將知識體系通過一個主線串起來。

關于這個主線，找過一些朋友做了交流，比如“風險可控”、“一體化”、“更高效更優(yōu)化的資源配置”、“可擴展性”。由于自己主要身處一線運維團隊，所以選了“可擴展性”的主線，接下來打算根據(jù)這條主線，不斷完善知識體系，目標是體系化的整理知識體系，主要從組織、流程、工具的可持續(xù)整合。

以下內(nèi)容，主要是對運維整體的概覽，講講對運維的認識，以及一些轉(zhuǎn)型理念思考。

一、運維不簡單

前陣子，跟一個項目經(jīng)理溝通能否提前半天將變更申請?zhí)峤贿^來時，這位項目經(jīng)理很不理解地問我：“你們運維不就是在生產(chǎn)環(huán)境部署個程序這么簡單的工作嗎？你們又不懂程序，評審不出什么吧？”

運維多年，對運維的這類認識聽過很多，它反映了企業(yè)里不同的組織團隊對運維的認識往往僅限于一些簡單操作性的工作，比如生產(chǎn)應用系統(tǒng)在故障時的重啟、應用變更時敲敲命令、平時增刪改查數(shù)據(jù)，或者是辦公室和電有關的所有軟硬件的使用問題等等。

那么如何理解運維呢？百度百科對運維的解釋為：企業(yè)IT部門采用相關的方法、手段、技術、制度、流程和文檔等，對IT軟硬運行環(huán)境（軟件環(huán)境、網(wǎng)絡環(huán)境等）、IT業(yè)務系統(tǒng)和IT運維人員進行的綜合管理。從百度百科的解釋看，運維崗位需要一個綜合性的技術與管理能力，需要掌握大量的方法論與技術棧。

運維狹義“運維技術與資源”可以定義為“監(jiān)、管、控”，技術與資源主要是支撐運維/運營的質(zhì)量、效率、成本的平衡。以下簡單摘錄了運維的一些能力要求：

• 運維規(guī)范的落地：以ITIL、ISO20000、ITSS.1等方法論，結合外部監(jiān)管及內(nèi)部規(guī)范的落地；
• 監(jiān)管機構的要求落地：理解、快速響應、落地監(jiān)管機構的管理要求；
• 基本保障：配置、監(jiān)控、應用發(fā)布、資源擴容、事件、問題等；
• 基礎能力：網(wǎng)絡、服務器、操作系統(tǒng)、數(shù)據(jù)庫、中間件、JVM、應用等基本使用與調(diào)優(yōu)；
• 業(yè)務服務能力：SLA，服務臺、業(yè)務咨詢、維護、經(jīng)驗庫、等支持能力；
• 可用性管理能力：巡檢、業(yè)務系統(tǒng)連續(xù)性、可用性，基礎架構及應用系統(tǒng)的高可用、備件冗余資源；
• 風險、安全管理能力：操作、審計、監(jiān)管風險，漏洞、攻擊管控；
• 故障管理能力：事件、問題管理水平與能力；
• 持續(xù)交付能力：應用變更、基礎資源、辦公服務交付能力；
• 主動優(yōu)化能力：架構優(yōu)化、性能響應效率、客戶體驗等；
• 應急演練：架構高可用、突發(fā)事件、業(yè)務故障的架構、方案、文檔、人員熟練程度等；
• 業(yè)務支撐：數(shù)據(jù)維護、數(shù)據(jù)提取、參數(shù)維護等；
• 運行分析能力：容量、性能、可用性分析等；
• 運營能力：促進業(yè)務痛點的發(fā)現(xiàn)與解決、客戶及業(yè)務業(yè)務體驗等；
• 成本控制：更好地評估人力、硬件、帶寬、軟件，節(jié)省成本；
• 運維開發(fā)：運維自動化工具的建設，運維開發(fā)能力的培養(yǎng)；
• 其它

不同的企業(yè)需要運維的能力會有不同的擴展，同進上述能力要求每一點擴散出來都將是一個復雜的技術棧，比如“基礎能力”中的Linux操作系統(tǒng)的內(nèi)核關系圖（摘自互聯(lián)網(wǎng)，圖1.1），或再深入一些關于MySQL優(yōu)化（摘自互聯(lián)網(wǎng)，圖1.2），需要運維人員對技術能力深度的要求。

圖1.1

圖1.2

講到這，肯定會有人說上述的技術棧的能力要求，通常是由于某個運維組織的仍處于專家式運維，自動化程度不夠高導致。

的確，理論上所有運維操作性、命令的工作都可以整合為經(jīng)驗，并通過自動化落地實現(xiàn)，現(xiàn)在互聯(lián)網(wǎng)企業(yè)對外都宣稱自動化在運維工作覆蓋面很高，己經(jīng)開始邁向智能化，AIOps，甚至提出了NoOps的解決方案。

關于這些互聯(lián)網(wǎng)企業(yè)的自動化對日常運維工作真實的覆蓋面暫時無法考究，但以我的經(jīng)驗看，至少金融企業(yè)的自動化覆蓋面還有很長的路要走，且肯定還會很大一部分工作很難自動化，畢竟工作類型太多，在有限的投入上只能集中力氣去做投入產(chǎn)出比更高的運維自動化。這里再以一個運維工具思維導圖（圖1.3）簡單列示一些常規(guī)的運維操作，可以看出其實很難有一套能解決所有運維操作的工具平臺。

圖1.3

所以我覺得，隨著業(yè)務要求越來越高、規(guī)模越來越大、監(jiān)管要求越來越高，縱使外部如何宣稱自動化、智能化對運維人員經(jīng)驗、技術、管理能力替代，金融企業(yè)內(nèi)的運維還需要認清實際情況，結合企業(yè)的整體戰(zhàn)略定位，強調(diào)運維團隊在運維管理與技術能力的廣度與深度，再有側(cè)重、有先后的實現(xiàn)自動化水平。

在未來一段時間里，金融企業(yè)的運維崗位仍是一個復雜的、綜合性技能的工作崗位。

二、運維之痛

近年來，隨著運維技術的快速發(fā)展，各行業(yè)的運維水平在得到了較大的提升同時，運維圈的分享也越來越開放，從國外Google的SRE理念，到國內(nèi)新技術領跑者以及借助于各種運維專題的公眾號、運維大會有大量的互聯(lián)網(wǎng)、傳統(tǒng)企業(yè)的運維組織進行分享。

1、組織之痛

前面講過，在企業(yè)內(nèi)部其它團隊對運維的認識通常是簡單操作，出故障時才會找的團隊，隨著信息技術的發(fā)展與業(yè)務的發(fā)展，運維組織痛點越來越明顯，企業(yè)內(nèi)對運維組織的不滿的聲音越來越多，反思一下原因，分外部客觀因素和內(nèi)部因素。

1）外部客觀因素

在當前大數(shù)據(jù)時代，金融企業(yè)的運維面臨業(yè)務規(guī)模的不斷擴大，業(yè)務競爭越來越激烈，監(jiān)管要求越來越高，數(shù)據(jù)中心的規(guī)模也越來越高，大量新技術、開源架構的引入取代了傳統(tǒng)穩(wěn)定的系統(tǒng)架構等等因素影響。

• 運維組織的角色

絕大部分運維組織都是一個成本部門，企業(yè)對運維組織的重視程度通常不如開發(fā)組織，更不用說是前臺業(yè)務部門。這方面造成了運維部門的規(guī)模通常增長很慢，以Google為例，在《Google SRE運維解密》一書中提到，由于Google的數(shù)據(jù)中心規(guī)模急劇擴大，系統(tǒng)越來越復雜，而運維人員規(guī)模又跟不上，所以他們的運維組織采用組建SRE的運維開發(fā)團隊實現(xiàn)自救。

• 業(yè)務對運維服務質(zhì)量的要求 

越來越多的金融業(yè)務己從線下走到線上， 為了贏得更多用戶的青睞，一方面，業(yè)務要求更多、體驗更佳的業(yè)務性能；另一方面業(yè)務對應用發(fā)布的交付速度有了更高的要求。前者會產(chǎn)生更復雜的系統(tǒng)設計，后者需要更高效的應用發(fā)布支持，兩者都會對系統(tǒng)響應效率、穩(wěn)定性帶來影響。

• 外部監(jiān)管要求

長期以來，為了防范金融風險，監(jiān)管機構對金融企業(yè)保持強監(jiān)管的方式，十九大之后，監(jiān)管對金融企業(yè)的信息技術的穩(wěn)定性、規(guī)范性有增無減。在強監(jiān)管下，信息系統(tǒng)的穩(wěn)定性有了進一步保證，但也給運維組織帶來更高的要求，客觀上也加大了工作量，并由于規(guī)范流程帶來的工作效率的下降。

• 業(yè)務并發(fā)要求

用戶量的增加，營銷活動不斷推出，需要系統(tǒng)具備更高的并發(fā)處理能力要求，企業(yè)不斷引入大量分布式、開源架構替代傳統(tǒng)相對成熟穩(wěn)定的架構來滿足業(yè)務需要，這些變化都給運維能力帶來挑戰(zhàn)。

• 數(shù)據(jù)中心規(guī)模增大

數(shù)據(jù)中心的多中心建設，云化，去IOE，分布式架構的引入使得應用系統(tǒng)規(guī)模成倍地增大。

2）內(nèi)部因素

網(wǎng)上有一個調(diào)查數(shù)據(jù)，在整個運維成本的分配中，軟硬件和網(wǎng)絡設備的維護成本占 30%，維護服務成本占30%，內(nèi)部運維人力成本則占了40%。這里的人力成本包括現(xiàn)在維護、培訓、流失與引入等成本，如果將維護服務成本也納入到人力成本之上，則人力這一塊的成本將上升為70%，影響這個人力成本的因素主要有：

• 運維能力模型

ITIL、ISO20000、ITSS.1是運維領域中比較成體系化的方法論（目前更為火爆的DevOps更傾向于是一種思路），其中只有ITSS.1提出了運維能力模型的概念，但在量化運維人員具體能力的實際操作上也比較難落地。也就是說你很難評價一個運維人員如何做才是做得優(yōu)，如何是中，如何差，這些評價通常比較主觀，這也客戶觀影響了運維人員不斷增加技能、優(yōu)化工作效率的動力。

• 運維規(guī)范化

組織擴大到一定規(guī)模，以口口相傳的傳授，結合個體責任心、工作習慣為主的方式容易出現(xiàn)操作風險，且無法進行量化績效管理，管理規(guī)范無法落地。

• 運維精細化程度

組織通常是從縱向職能型的方式形成，這種方式能培養(yǎng)全能型、經(jīng)驗豐富的專家式人才，這些專家式人才利用經(jīng)驗能快速解決職責下的常規(guī)問題，且效率比較高，適合小型的組織。隨著組織的不斷壯大，面對的問題越來越復雜，技術要求越來越多，一方面很多人不能滿足這種專家式人才的要求；一方面也會產(chǎn)生很多重復性的工作；同時對于人員流失帶來的影響比較大。這時候就需要將縱向工作精細化，再輔助橫向人員對工作進行持續(xù)的優(yōu)化。

• 運維目標

運維的目標往往以被動式的目標為主，被動處理故障、被動解決問題、被動提供應用交付、被動節(jié)省成本等，這種被動式的運維目標導致計劃性工作不夠，缺乏持續(xù)不斷的自我優(yōu)化，主動提高效率、質(zhì)量，降低成本，并由運維向主動運營目標去轉(zhuǎn)變。

• 自動化能力

IT軟硬件體量龐大，且增長迅速，手工操作的機器任務太多；運維數(shù)據(jù)越來越多；故障定位越來越難，人工經(jīng)驗依賴高；監(jiān)控手段不夠及時、全面；應用發(fā)布、資源交付效率低下；沒有主動的容量、性能分析、體驗分析能力……這些都是常見的一些痛點。

2、個體之痛

作為運維組織中的運維人員同樣面臨不少痛點，有來自工作時間、工作壓力、學習壓力、職業(yè)發(fā)展等等，以下簡單羅列：

• 7*24小時制的工作時間

運維人員的節(jié)假日是不完整的，通常節(jié)假日需要運維值班保障或在家通過VPN遠程操作、或和家人團聚時還遠程指導進行故障應急；運維人員上班時間不同普通工作，為了不影響業(yè)務，應用發(fā)布、基礎設施變更、演練等工作都會放到晚上，對客的業(yè)務系統(tǒng)還可能要安排到深夜。這種隨時可能發(fā)生，隨處理可能要處理的工作狀態(tài)是其它行業(yè)所不具備的痛點。

• 高度壓力的工作

“如履薄冰”很好的形容了運維的工作狀態(tài)，因為任務一個生產(chǎn)操作都可能對業(yè)務帶來影響，所以運維的操作必須十分謹慎。同時在運維故障處理過程中，運維人員需要面臨著來自業(yè)務、客戶、開發(fā)、領導的各層的壓力下，冷靜地完成故障處理，是一個高壓的工作狀態(tài)。

• 被動的工作

經(jīng)常會有人形容運維就是一個“消防員”的工作，也就是被動救火的工作，這個形容很貼切，在缺乏一些主動分析、優(yōu)化、預測性的工作的背景下，運維組織的大部分工作是以被動為主，是負責應急救火、打掃戰(zhàn)場、負責收尾的那群默默的人。

• 對工作的認識

運維的人通常會認為自己就是一個背鍋的角色，開發(fā)程序問題、硬件問題、系統(tǒng)軟件問題、業(yè)務需求問題都需要運維去解決，而且這些問題對可用性的影響還要運維來承擔，這是運維特有的痛點。

• 職業(yè)壓力

運維工作一方面主要是和機器或系統(tǒng)軟件打交道，所以相對于開發(fā)、項目管理等IT崗位，轉(zhuǎn)型機會的面比較窄；同時，運維崗位中重復操作性的工作占比多，如缺乏引導容易讓運維人員產(chǎn)生麻木的狀態(tài)，失去持續(xù)改善的動力；另外，前面也提到運維需要掌握的技能和管理理念很多，對于運維人員的學習能力要求很高。

三、自救

1、SRE

SRE這個名詞最早是從《Google SRE 運維解密》一書中獲得，全稱是Site Reliability Engineering，翻譯過來就是：站點可靠性工程師。Google對SRE的職責描述為：確保站點的可用，為了達到這個目的，一方面他需要對站點涉及的系統(tǒng)、組件熟悉，也要關注生產(chǎn)運行時的狀態(tài)。

為此，他需要自開發(fā)并維護很多工具和系統(tǒng)支撐系統(tǒng)的運行，比如自動化發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)、日志系統(tǒng)、服務器資源分配和編排等。SRE是一個綜合素質(zhì)很高的全能手，如果對他的能力進行分解主要有三塊：

• 熟悉系統(tǒng)架構與運行狀態(tài)

SRE需要懂服務器基礎架構、操作系統(tǒng)、網(wǎng)絡、中間件容器、常用編程語言、全局的架構意識、非常強的問題分析能力、極高的抗壓能力（以便沉著高效地排障），他們還需要懂性能調(diào)優(yōu)理論。為了保證系統(tǒng)架構的高可用，SRE甚至會有意識地破壞自己的系統(tǒng)，以提高系統(tǒng)可用性。

• 熟悉運維涉及的管理方法

SRE需根據(jù)企業(yè)自身發(fā)展需要，清楚運維涉及的各項工作的流程方法論，比如故障處理、應用發(fā)布、可用性管理等等，SRE十分重視運維流程的持續(xù)改善，比如對故障的追丁溯源，懷疑一切的方式持續(xù)改進。

• 運維開發(fā)+產(chǎn)品經(jīng)理

SRE在運行保障過程中的手段更加自動化，更高效，這種高效來源于自動化工具、監(jiān)控工具的支撐，且他們還需要是這些工具的主要開發(fā)者，他們要不斷優(yōu)化和調(diào)整，使整個工具箱使起來更加得心應手。為此SRE有一個50%的理念，就是50%用于日常保障，50%用于項目性的工作，這個項目性的工作主要體現(xiàn)在運維開發(fā)與運維產(chǎn)品經(jīng)理的角色。

2、運維開發(fā)

關于運維開發(fā)的理解主要體現(xiàn)在運維工具層面，不同的組織有不同的理解，通常有三類：

• 完全自建

運維開發(fā)團隊利用開源技術結合自身需要進行一定的二次開發(fā)，這種方式在互聯(lián)網(wǎng)企業(yè)比較流行，具體的成效大小與何時能起來收效與對這個運維開發(fā)團隊的整體規(guī)劃或資源投入有關；

• 外購開發(fā)資源或工具產(chǎn)品

運維開發(fā)團隊主要是結合企業(yè)痛點承擔產(chǎn)品經(jīng)理的角色，設計、跟進、推廣工具，這種方式常出現(xiàn)在傳統(tǒng)的企業(yè)，尤其適用于投入運維開發(fā)人員比較少的企業(yè)，這種方式是投入收效快，但是對外部資源依賴比較大，不利于后續(xù)持續(xù)建設；

• 外購與自建相結合

運維開發(fā)團隊在整個工具體系下，針對部分組件選擇性的引入一些成熟的工具體系，同時要求這類成熟的工具需要開放一定的接口或源碼支持，對于一些與公司個性強的環(huán)節(jié)采用自研的方式。這種方式目前逐漸被一些傳統(tǒng)企業(yè)，比如金融企業(yè)所接受。

總的來說，不管選用上面哪一種方式，運維開發(fā)團隊都應該有一個整體、統(tǒng)一的一體化工具建設規(guī)劃，并在建設過程中始終保持對運維工具體系的掌控能力，并在工具體系的上層為其它運維人員提供簡易的、可創(chuàng)造性的“開發(fā)能力”，比如所見即所得的工具可視化、可定制的運維報表、拖拉拽方式的流程及腳本組件的拼裝等運維開發(fā)方式。

3、DevOps

1）DevOps概述

DevOps一詞的來自于Development和Operations的組合，突出重視軟件開發(fā)人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發(fā)布更加快捷、頻繁和可靠，他是一種方法論，包含一套基本原則和實踐，工具是為有效落實這套方法論提供支持。

在軟件全生命周期管理過程中，包括開發(fā)、構建、測試、發(fā)布、運營，在這個全生命周期管理過程中出現(xiàn)了開發(fā)組織與運維組織的部門墻，這是因為開發(fā)組織關注需求的實現(xiàn)，希望盡快實現(xiàn)變更；運維組織關注系統(tǒng)運行穩(wěn)定，而變更又往往是生產(chǎn)應用不穩(wěn)定的原因。

DevOps方法論的出現(xiàn)主要是為了解決這個協(xié)作問題，以讓軟件交付更加高效，質(zhì)量更高，生產(chǎn)端更加敏捷，生產(chǎn)運行過程中的問題能更加高效的反饋到開發(fā)，形成一個全生命周期的閉環(huán)。隨著業(yè)務對運維交付能力的時效性要求越來越高，運維組織面臨“吃力不討好”的問題：

• 吃力： 花費大量時間在應用部署的操作性工作中。這部分部署變更包括新功能的上線以及修復功能BUG兩方法。
• 不討好： 操作性的工作越大，帶來的操作風險越大，有這樣一個統(tǒng)計，如果手工運行5條命令的情況下，成功部署的概率就已跌至86%；如需手工運行55條命令，成功部署的概率將跌至22%；如需手工運行100條命令，成功部署的概率將趨近于0（僅2%）。

DevOps鼓勵軟件開發(fā)者和IT運維人員之間所進行的溝通、協(xié)作、集成和自動化，借此有助于改善雙方在交付軟件過程中的速度和質(zhì)量。側(cè)重于通過標準化開發(fā)環(huán)境和自動化交付流程改善交付工作的可預測性、效率、安全性，以及可維護性。

2）運維實踐中的DevOps

可以從工具鏈、組織文化、自動化、敏捷看板等角度講DevOps，比如在目前比較活躍的DevOps36計，基本覆蓋了運維領域很大的一塊：

圖1.4

從DevOps的落地效率來看，需要將DevOps進行聚焦，聚焦到交付能力上，這方面，行業(yè)里比較標準化的評估是去年底由中國信息通信研究院，聯(lián)合一些互聯(lián)網(wǎng)企業(yè)、運維社區(qū)，以及一些金融、傳統(tǒng)企業(yè)聯(lián)合進行編制的DevOps標準（券商行業(yè)中華泰參加了編制）。從這個能力模型公布出來的一些介紹看，標準對DevOps范圍比較克制主要以交付能力來分解敏捷開發(fā)、持續(xù)交付、技術運營、應用架構、組織架構，這和最早的DevOps能力環(huán)比較吻合：

圖1.5

從運維的交付場景看，主要是資源交付與應用交付，其中資源交付以IaaS、PaaS云的建設為主，通過云管平臺的工具鏈將基礎設施、網(wǎng)絡、硬件、虛擬化、容器、運行中間件等系統(tǒng)軟硬件交付能力自動化，并通過CMDB整合DevOps能力環(huán)之上的應用場景，實現(xiàn)資源的快速交付。

資源交付能力主要在于IaaS、PaaS層的云平臺標準化、自動化、平臺擴展性等方面的建設程度。應用的快速交付比資源交付更為復雜，應用交付涉及全鏈路的整合，鏈路上的節(jié)點越多落地的難度越大，因為它不僅涉及技術，還涉及理念的認同與聚焦。

應用交付能力要實現(xiàn)，最簡單的技術棧工具需要CMDB、應用發(fā)布工具、應用版本庫、監(jiān)控工具，上述工具對內(nèi)要與云平臺對接，對外要提供接口給開發(fā)、測試工具。當然如開發(fā)、測試也能和運維使用同一套發(fā)布工具、應用版本庫則效果更好，不過，實際實施過程中組織之間還是會有不少沖突，比如開發(fā)關注源代碼版本管理，測試、運維關注運行版本的管理，需各個組織共同付出共建技術鏈。

4、運營

關于運維圈里運營的概念，以轉(zhuǎn)型口號喊得比較多，我對運維當中的運營有業(yè)務運營與技術運營兩個維度的理解。業(yè)務運營是通過功能優(yōu)化或工具開發(fā)等方式解決業(yè)務工作痛點，或通過運行分析發(fā)現(xiàn)影響業(yè)務開展的因素，并推動相關的優(yōu)化，最終提升業(yè)務能力。技術運營則主要從技術角度去降低IT成本，提升IT服務質(zhì)量與效率。具體的實施內(nèi)容可以考慮如下：

圖1.6

從上述概括可以看出，當前運維里面的運營，與運維數(shù)據(jù)密切相關，需要基于運維大數(shù)據(jù)平臺來提升運營質(zhì)量。

為了進一步說明運營，這里舉兩個例子：

1）理論

優(yōu)锘科技CEO的陳傲寒在2016年寫過一篇文章《IT：從運維到運營》，仍是我讀過最好的一篇。全文從企業(yè)、運維組織角度出發(fā)分析什么是運維、什么是運營，再將運營分解到不同角色上的理解與落地的方向，全文均是干貨，值得通讀，這里只列出一個思維導圖。

圖1.7

2）實戰(zhàn)

參加過一場騰訊QQ關于DevOps的培訓，對于它們提到的一個自救方式的運營手段很有印象。那就是在騰訊QQ逐漸被微信團隊替代過程中，QQ技術運維團隊是如何通過各種方式去為企業(yè)帶來效益，比如他們通過運維分析，得到如何更加合理的使用帶寬、資源，大大減少了公司在基礎設施方面的投入。

在金融企業(yè)中，也同樣有很多空間可以去嘗試，比如分析業(yè)務痛點，為業(yè)務提供快速的策略性的工具來替代重復操作性的業(yè)務操作；通過運維數(shù)據(jù)分析，發(fā)現(xiàn)客戶體驗方面的痛點，推動業(yè)務功能的優(yōu)化等等。

4、AIOps

AIOps這個詞最早是在2016年由Gartner提出（當然國內(nèi)很多廠商也提出它們早幾年也提出了這個理念）。AIOps是Algorithmic IT Operations的縮寫，是基于算法的IT運維，即通過使用統(tǒng)計分析和機器學習的方法處理從各IT設備、業(yè)務應用、運維工具收集的數(shù)據(jù)，從而加強增強運維自動化能力，以便更快、更有效、更全面地自動化效果。以下是Gartner提出AIOps的一張圖：

圖1.8

Gartner通過使用圖1.9中的圖解釋了AIOps平臺的工作原理。AIOps有兩個主要組件：大數(shù)據(jù)和機器學習。它需要從孤立的IT數(shù)據(jù)中移除，以便將大量數(shù)據(jù)平臺內(nèi)的觀察數(shù)據(jù)（例如監(jiān)控系統(tǒng)和作業(yè)日志中發(fā)現(xiàn)的數(shù)據(jù)）與參與數(shù)據(jù)（通常在故障單，事件和事件記錄中找到）相結合。

AIO然后針對組合的IT數(shù)據(jù)實施全面的分析和機器學習（ML）策略。期望的結果是持續(xù)的見解，通過自動化產(chǎn)生持續(xù)的改進和修復。AIO可以被認為是核心IT功能的持續(xù)集成和部署（CI/CD）。

• 廣泛和多樣化的IT數(shù)據(jù)源，如日志類的設備日志、系統(tǒng)日志，應用日志、運維操作日志；指標類的監(jiān)控性能指標、事件。
• 具備針對海量數(shù)據(jù)處理與分析的運算平臺，能夠從現(xiàn)有的IT數(shù)據(jù)生成新的數(shù)據(jù)和元數(shù)據(jù)、計算和分析還消除噪音，識別模式或趨勢，隔離可能的原因，揭示潛在問題，并實現(xiàn)其他IT特定目標。
  
• 算法 ，充分利用IT領域的專業(yè)知識，更適當，高效地處理數(shù)據(jù)。
  
• 機器學習 ，從根據(jù)算法分析的輸出和引入系統(tǒng)的新數(shù)據(jù)自動更改或創(chuàng)建新的算法。
  
• 可視化 ，以易于消費的方式向IT行動提供洞察和建議，以促進理解和行動。
  
• 自動化 ，其使用分析和機器學習產(chǎn)生的結果自動創(chuàng)建和應用響應或改進已識別的問題。

關于分層的思路，Gartner這樣理解：

圖1.9

6、AIOps與自動化的關系

AIOps很火，所以對AIOps和自動化做了一些對比。暫以一句話作個區(qū)別：AIOps是基于對運維數(shù)據(jù)（日志類、指標類數(shù)據(jù)等）的機器學習，進一步解決自動化成本高或無法解決的問題，屬于運維自動化的優(yōu)化，細化一下區(qū)別有：

• 概念 

狹義的自動化則提運維“監(jiān)、管、控”的工具。AIOps是將AI技術應用到IT運維領域，需要有學習、類人交互、主動決策的特征。

• 實現(xiàn)思路 

自動化往往以過程為導向，AIOps則以目標為導向，通過對數(shù)據(jù)進行學習，得到如何實現(xiàn)目標。

• 門檻高度 

自動化手段有豐富的落地解決方案，適合作為替代標準化的運維操作性工作，即“面”的問題。AIOps目前仍處起步階段，不是適合替代現(xiàn)有的自動化，而是應該用于解決自動化不能解決或解決成本很高的問題，即“點”的問題。

• 如何整合

AIOps并非是要取代現(xiàn)有的自動化運維體系，而是賦予現(xiàn)有體系智能。AIOps就要“學習，了解”自動化工具 ，并且更好地“使用”這些工具，這個過程就是深度集成，它的核心是對這些工具API的自主認知和自主使用。

雖然行業(yè)內(nèi)的智能運維理念十分火熱，但實際落地成效上還主要處于研究階段。從運維工具技術解決方案的角度看，對于智能的解讀也有差別，如果將智能的特點解讀為具備“模擬人，具備自學習，能夠從數(shù)據(jù)中獲取知識，進而進行預測/決策”來判斷是否智能，智能是自動化的一個輔助手段，自動化才是終態(tài)。

建立在這個認識下，我們首先需要通過自動化手段解決痛點，提高工作效率，控制風險；利用運維數(shù)字化的建設為運維智能化提供數(shù)據(jù)、數(shù)據(jù)計算的能力；在自動化、數(shù)字化水平得到一定程度后，再通過人工智能的技術去解決自動化手段解決起來費力或無法解決的局部問題，讓自動化具備智能的水平。

四、體系

1、運維的可持續(xù)改進

在管理領域，戴明推出的PDCA循環(huán)可以解釋運維體系需要具備的可持續(xù)改進的能力條件。

PDCA循環(huán)為四個階段，即計劃（plan）、執(zhí)行（do）、檢查（check）、調(diào)整（Action），即在實際工作開展過程中，把各項工作按照作出計劃、計劃實施、檢查實施效果，然后將成功的納入標準，并不斷循環(huán)改進的過程。

將這個思路引入到企業(yè)的運維體系中則是針對企業(yè)業(yè)務發(fā)展的需求，制定運維體系的整體發(fā)展目標，通過不斷改進的措施提高運維工作效率、控制風險，以達到更高效、更優(yōu)化的資源配置，進而推動業(yè)務的發(fā)展。要做到運維體系的可持續(xù)改進，需要做到以業(yè)務導向，整體部局；組織、流程、工具三位一體；不斷審視優(yōu)化。

1）P：以業(yè)務導向、整體部局

運維的最根本作用是保障IT數(shù)據(jù)的連續(xù)性，這里的IT數(shù)據(jù)包括業(yè)務，以及反映業(yè)務的數(shù)據(jù)，或者換句話可以表達為：網(wǎng)絡不斷、系統(tǒng)不癱、數(shù)據(jù)不丟。隨著業(yè)務對IT系統(tǒng)依賴程度越來越高，運維又會承擔更高的期望，也就是運維向運營的轉(zhuǎn)化，這就需要從業(yè)務角度去不斷完善運維，以促進業(yè)務為大目標，要明白“IT for IT”是為了更好的“IT for Business”。

有了這個目標，那我們的運維體系的構建就需要與企業(yè)業(yè)務的發(fā)展保持同步，要讓運維體系具備可持續(xù)改進的能力。

另外，可持續(xù)改進的過程不應該是大拐彎的方式進行改進，而應該不斷的小調(diào)整，這就需要確保首先要建立一個整體、全局的運維體系，對運維各項工作做一個整體的規(guī)劃，把眼光看得更遠，往往可以更好的把控當前。

2）D：組織、流程、工具的三位一體

可持續(xù)改進的運維體系需要讓運維的組織、流程、工具三位一體的作用，比方說：提高工作效率，需要組織的專業(yè)化分工、流程的標準化、工具的自動化配合作用；推動業(yè)務的發(fā)展，既需精細化運維分析、業(yè)務服務、運營等維度的工作資源投入，也需要有工具的建設來減少操作性的工作來釋放人力，需要工具提供更高效的數(shù)據(jù)來源。

這里說的組織主要是從運維人力資源的分工、團隊建設、工作目標導向、運維KPI等；流程是指以成熟的運維方法論為主體，結合企業(yè)和外部監(jiān)管的規(guī)章制度、企業(yè)業(yè)務發(fā)展需要，而落地的標準化工作方法；工具既包括狹義運維的“監(jiān)、管、控”，也包括運營體系所需要數(shù)字化、智能化的工具平臺。

3）C+A : 不斷審視優(yōu)化

在實際工作過程中，審視檢查的過程很容易被忽略，但實際上最大的收獲可能就來自于這個總結、歸納的過程中，這也是可持續(xù)改進的運維體系的關鍵所在。

比方說，運維組織可以考慮在必要環(huán)節(jié)增加橫向的優(yōu)化團隊；運維流程也需要定期對流程的落地進行分析，并對規(guī)章制度進行查漏補缺、刪減不合理的流程規(guī)范、調(diào)整無法執(zhí)行的規(guī)范要求；工具的建設要不斷的分析工具的使用覆蓋率，如何提高覆蓋率，分析是否提高了運維的效率，還是帶來了反作用等分析，并不斷調(diào)整優(yōu)化工具的建設。

2、轉(zhuǎn)型思路

在提出可持續(xù)的運維體系前，我們先歸納一下運維組織常見的運維痛點，以提出運維轉(zhuǎn)型的思路，再看看如何構建一個可持續(xù)改進的運維體系來支撐運維轉(zhuǎn)型。前面的運維之痛中提到了 “救火”、“背鍋”、“低價值”、”重復操作“等標簽，我們歸納下己有特點再看轉(zhuǎn)型：

1）特點

• 被動救火式，以被動保障業(yè)務系統(tǒng)運行，日常計劃性工作容易被打斷、擱置；
• 問題驅(qū)動式， 以系統(tǒng)可用性、可靠性、業(yè)務請求等問題驅(qū)動運維工作；
• 操作運維，重復性、操作類點主要工作量的運維模式；
• 經(jīng)驗式運維，由人工經(jīng)驗驅(qū)動的運維模式，尤其是一些經(jīng)驗豐富的老員工的離職在短期內(nèi)會對運維質(zhì)量帶來一定的沖擊。

2）轉(zhuǎn)型

• 從被動救火式向主動精細化轉(zhuǎn)型，專業(yè)化分工、主動分析，主動優(yōu)化，驅(qū)動開發(fā)，促進DEVOPS的落地；
• 從問題驅(qū)動向價值驅(qū)動轉(zhuǎn)型，以企業(yè)業(yè)務發(fā)展目標為主線，業(yè)務體驗、服務滿意度、促進業(yè)務更好發(fā)展；
• 從操作運維向運維開發(fā)轉(zhuǎn)型，通過為運維人員提供運維開發(fā)平臺，降低運維開發(fā)門檻，快速落地一些緊迫的運維工具，降低操作性、重復性的運維工作；
• 從依靠經(jīng)驗向智能化驅(qū)動運維轉(zhuǎn)型，結合數(shù)據(jù)分析、知識庫、機器學習技術促進運維智能化。

圖1.10

3、構建運維體系

上二節(jié)提到運維體系以業(yè)務導向，整體部局，組織、流程、工具三位一體，不斷審視優(yōu)化的建設思路，也提出了“主動精細化”、“價值驅(qū)動”、“運維開發(fā)”、“智能化運維”的轉(zhuǎn)型目標，我們再將這些思路分解到組織、流程、工具的建設中，并歸納為：三大建設，十個文化的實踐方法：

1）組織建設：專業(yè)化、精細化、運營化

我們將運維實施主體運維組織理解為組織，理想情況下，優(yōu)秀的組織應該具備有合適的工作、合適的時間、合適的人、合適的行為四個要素組成。即組織要結合企業(yè)實際發(fā)展方向，制定符合企業(yè)、運維組織、個人發(fā)展的工作內(nèi)容，并選擇具備合適的知識、技能、認知、能力的人去完成工作，去實現(xiàn)個人的自我價值。

前面也提到，目前的運維織是一個被動保障業(yè)務系統(tǒng)運行，日常計劃性工作容易被打斷、擱置的工作，這種工作狀態(tài)下的運維組織往往工作效率不高、容易出現(xiàn)操作風險。

為了讓運維組織具備可持續(xù)改進的能力，需要提高運維組織的工作效率，我們需要將運維工作專業(yè)化，整合通用性、操作性的工作，提高工作效率，在釋放運維人員工作量后，引導運維人員有計劃、可量化的去做更多分析類、優(yōu)化類、業(yè)務運營的主動性工作。

2）流程建設：標準化、可視化、可量化

大部分運維組織會以內(nèi)部企業(yè)積累的規(guī)章制度、外部監(jiān)管機構的監(jiān)管要求為基礎，依照ITIL、ISO20000、ITSS.1、DevOps的方法論中的一個或多個組合的方式開展運維工作。這些規(guī)章制度、監(jiān)管要求、方法論的整合、落地、持續(xù)改進的過程即為流程建設的過程。

流程建設首先需要標準化流程，要先梳理好己有的流程制度，約定工作的流轉(zhuǎn)方式，再通過可視化將流程整合在日常工作中，最后通過流程落地數(shù)據(jù)的分析與工具建設，持續(xù)改善提高流程落地的效率，控制操作風險。

3）工具建設：自動化、數(shù)字化、智能化、服務化

工具的建設也以可持續(xù)改進的思路構建，以整合存量資源、引入成熟或開源技術為主，建立一體化的運維工具體系。

通過體系化的思路實現(xiàn)運維工具（“監(jiān)、管、控”）的互聯(lián)互通，有序建設，實現(xiàn)自動化運維，全面控制風險、提高工作效率、釋放人力；通過建立運維數(shù)據(jù)分析平臺，實現(xiàn)數(shù)字化運營，提供運維數(shù)據(jù)集中與治理、主動分析的能力；在數(shù)字化運營的基礎上通過運維數(shù)據(jù)挖掘、學習，優(yōu)化運維或運營場景，向智能化發(fā)展；服務化則是以IT服務的方式將運維能力向外輸出。