1.1 運維不簡單
前陣子，跟一個項目經理溝通能否提前半天將變更申請提交過來時，這位項目經理很不理解的問我，“你們運維不就是在生產環境部署個程序這麼簡單的工作嗎？你們又不懂程序，評審不出什麼吧？”。
運維多年，對運維的這類認識聽過很多，它反映了企業裡不同的組織團隊對運維的認識往往僅限於一些簡單操作性的工作，比如生產應用系統在故障時的重啟、應用變更時敲敲命令、平時增刪改查數據，或者是辦公室和電有關的所有軟硬件的使用問題等等。
那麼如何理解運維呢？百度百科對運維的解釋為：企業 IT 部門採用相關的方法、手段、技術、制度、流程和文檔等，對IT 軟硬運行環境(軟件環境、網絡環境等)、IT 業務系統和 IT 運維人員進行的綜合管理。從百度百科的解釋看，運維崗位需要一個綜合性的技術與管理能力，需要掌握大量的方法論與技術棧。
運維狹義“運維技術與資源”可以定義為“監、管、控”，技術與資源主要是支撐運維/運營的質量、效率、成本的平衡。以下簡單摘錄了運維的一些能力要求：
運維規範的落地：以ITIL、ISO20000、ITSS.1等方法論，結合外部監管及內部規範的落地；
監管機構的要求落地：理解、快速響應、落地監管機構的管理要求；基本保障：配置、監控、應用發佈、資源擴容、事件、問題等；
基礎能力：網絡、服務器、操作系統、數據庫、中間件、JVM、應用等基本使用與調優；
業務服務能力：SLA，服務檯、業務諮詢、維護、經驗庫、等支持能力；
可用性管理能力：巡檢、業務系統連續性、可用性，基礎架構及應用系統的高可用、備件冗餘資源；
風險、安全管理能力：操作、審計、監管風險，漏洞、攻擊管控；
故障管理能力：事件、問題管理水平與能力；
持續交付能力：應用變更、基礎資源、辦公服務交付能力；
主動優化能力：架構優化、性能響應效率、客戶體驗等
應急演練：架構高可用、突發事件、業務故障的架構、方案、文檔、人員熟練程度等
業務支撐：數據維護、數據提取、參數維護等；
運行分析能力：容量、性能、可用性分析等；
運營能力：促進業務痛點的發現與解決、客戶及業務業務體驗等；
成本控制：更好的評估人力、硬件、帶寬、軟件，節省成本；
運維開發：運維自動化工具的建設，運維開發能力的培養；
其它
不同的企業需要運維的能力會有不同的擴展，同進上述能力要求每一點擴散出來都將是一個複雜的技術棧，比如“基礎能力”中的LINUX操作系統的內核關係圖（摘自互聯網見，圖1.1），或再深入一些關於mysql優化（摘自互聯網見，圖1.2），需要運維人員對技術能力深度的要求。
講到這，肯定會有人說上述的技術棧的能力要求通常是由於某個運維組織的仍處於專家式運維，自動化程度不夠高導致。
的確，理論上所有運維操作性、命令的工作都可以整合為經驗，並通過自動化落地實現，現在互聯網企業對外都宣稱自動化在運維工作覆蓋面很高，己經開始邁向智能化，AIOps，甚至提出了NoOps的解決方案。
關於這些互聯網企業的自動化對日常運維工作真實的覆蓋面暫時無法考究，但以我的經驗看，至少金融企業的自動化覆蓋面還有很長的路要走，且肯定還會很大一部份工作很難自動化，畢竟工作類型太多，在有限的投入上只能集中力氣去做投入產出比更高的運維自動化。
這裡再以一個運維工具思維導圖（圖1.3）簡單列示一些常規的運維操作，可以看出其實很難有一套能解決所有運維操作的工具平臺。
所以我覺得，隨著業務要求越來越高、規模越來越大、監管要求越來越高，縱使外部如何宣稱自動化、智能化對運維人員經驗、技術、管理能力替代，金融企業內的運維還需要認清實際情況，結合企業的整體戰略定位，強調運維團隊在運維管理與技術能力的廣度與深度，再有側重、有先後的實現自動化水平。
在未來一段時間裡，金融企業的運維崗位仍是一個複雜的、綜合性技能的工作崗位。
1.2運維之痛
近年來，隨著運維技術的快速發展，各行業的運維水平在得到了較大的提升同時，運維圈的分享也越來越開放，從國外google的SRE理念，到國內新技術領跑者騰訊遊戲的藍鯨、織雲，以及藉助於各種運維專題的公眾號、運維大會有大量的互聯網、傳統企業的運維組織進行分享。
1.2.1組織之痛
前面講過，在企業內部其它團隊對運維的認識通常是簡單操作，出故障時才會找的同團隊，隨著信息技術的發展與業務的發展，運維組織痛點越來越明顯，企業內對運維組織的不滿的聲音越來越多，反思一下原因，分外部客觀因素和內部因素。
1）外部客觀因素
在當前大數據時代，金融企業的運維面臨業務規模的不斷擴大，業務競爭越來越激烈，監管要求越來越高，數據中心的規模也越來越高，大量新技術、開源架構的引入取代了傳統穩定的系統架構等等因素影響。
運維組織的角色：絕大部份運維組織都是一個成本部門，企業對運維組織的重視程度通常不如開發組織，更不用說是前臺業務部門。這方面造成了運維部門的規模通常增長很慢，以 Google 為例，在《Google SRE 運維解密》一書中提到，由於Google的數據中心規模急劇擴大，系統越來越複雜，而運維人員規模又跟不上，所以他們的運維組織採用組建 SRE 的運維開發團隊實現自救。
業務對運維服務質量的要求：越來越多的金融業務己從線下走到線上， 為了贏得更多用戶的青睞，一方面，業務要求更多、體驗更佳的業務性能；另一方面業務對應用發佈的交付速度有了更高的要求。前者會產生更復雜的系統設計，後者需要更高效的應用發佈支持，兩者都會對系統響應效率、穩定性帶來影響。
外部監管要求：長期以來，為了防範金融風險，監管機構對金融企業保持強監管的方式，十九大之後，監管對金融企業的信息技術的穩定性、規範性有增無減。在強監管下，信息系統的穩定性有了進一步保證，但也給運維組織帶來更高的要求，客觀上也加大了工作量，並由於規範流程帶來的工作效率的下降。
業務併發要求：用戶量的增加，營銷活動不斷推出，需要系統具備更高的併發處理能力要求，企業不斷引入大量分佈式、開源架構替代傳統相對成熟穩定的架構來滿足業務需要，這些變化都給運維能力帶來挑戰。
數據中心規模增大：數據中心的多中心建設，雲化，去IOE，分佈式架構的引入使得應用系統規模成倍的增大。
2）內部因素
網上有一個調查數據，在整個運維成本的分配中，軟硬件和網絡設備的維護成本佔 30%，維護服務成本佔30%，內部運維人力成本則佔了40%。
這裡的人力成本包括現在維護、培訓、流失與引入等成本，如果將維護服務成本也納入到人力成本之上，則人力這一塊的成本將上升為70%，影響這個人力成本的因素主要有：
運維能力模型：ITIL、ISO20000、ITSS.1是運維領域中比較成體系化的方法論（目前更為火爆的 DevOps 更傾向於是一種思路），其中只有ITSS.1提出了運維能力模型的概念，但在量化運維人員具體能力的實際操作上也比較難落地。也就是說你很難評價一個運維人員如何做才是做得優，如何是中，如何差，這些評價通常比較主觀，這也客戶觀影響了運維人員不斷增加技能、優化工作效率的動力。
運維規範化：組織擴大到一定規模，以口口相傳的傳授，結合個體責任心、工作習慣為主的方式容易出現操作風險，且無法進行量化績效管理，管理規範無法落地。
運維精細化程度：組織通常是從縱向職能型的方式形成，這種方式能培養全能型、經驗豐富的專家式人才，這些專家式人才利用經驗能快速解決職責下的常規問題，且效率比較高，適合小型的組織。
隨著組織的不斷壯大，面對的問題越來越複雜，技術要求越來越多，一方面很多人不能滿足這種專家式人才的要求；一方面也會產生很多重複性的工作；同時對於人員流失帶來的影響比較大。這時候就需要將縱向工作精細化，再輔助橫向人員對工作進行持續的優化。
運維目標：運維的目標往往以被動式的目標為主，被動處理故障、被動解決問題、被動提供應用交付、被動節省成本等，這種被動式的運維目標導致計劃性工作不夠，缺乏持續不斷的自我優化，主動提高效率、質量，降低成本，並由運維向主動運營目標去轉變。
自動化能力 ：IT軟硬件體量龐大，且增長迅速，手工操作的機器任務太多；運維數據越來越多；故障定位越來越難，人工經驗依賴高；監控手段不夠及時、全面；應用發佈、資源交付效率低下；沒有主動的容量、性能分析、體驗分析能力……這些都是常見的一些痛點。
個體之痛作為運維組織中的運維人員同樣面臨不少痛點，有來自工作時間、工作壓力、學習壓力、職業發展等等，以下簡單羅列：
7*24小時制的工作時間：運維人員的節假日是不完整的，通常節假日需要運維值班保障或在家通過VPN遠程操作、或和家人團聚時還遠程指導進行故障應急；運維人員上班時間不同普通工作，為了不影響業務，應用發佈、基礎設施變更、演練等工作都會放到晚上，對客的業務系統還可能要安排到深夜。這種隨時可能發生，隨處理可能要處理的工作狀態是其它行業所不具備的痛點。
高度壓力的工作：“如履薄冰”很好的形容了運維的工作狀態，因為任務一個生產操作都可能對業務帶來影響，所以運維的操作必須十分謹慎。同時在運維故障處理過程中，運維人員需要面臨著來自業務、客戶、開發、領導的各層的壓力下，冷靜的完成故障處理，是一個高壓的工作狀態。
被動的工作：經常會有人形容運維就是一個“消防員”的工作，也就是被動救火的工作，這個形容很貼切，在缺乏一些主動分析、優化、預測性的工作的背景下，運維組織的大部份工作是以被動為主，是負責應急救火、打掃戰場、負責收尾的那群默默的人。
對工作的認識：運維的人通常會認為自己就是一個背鍋的角色，開發程序問題、硬件問題、系統軟件問題、業務需求問題都需要運維去解決，而且這些問題對可用性的影響還要運維來承擔，這是運維特有的痛點。
職業壓力：運維工作一方面主要是和機器或系統軟件打交道，所以相對於開發、項目管理等IT崗位，轉型機會的面比較窄；同時，運維崗位中重複操作性的工作佔比多，如缺乏引導容易讓運維人員產生麻木的狀態，失去持續改善的動力；另外，前面也提到運維需要掌握的技能和管理理念很多，對於運維人員的學習能力要求很高。
1.3 自救
1.3.1 SRE
SRE這個名詞最早是從《Google SRE 運維解密》一書中獲得，全稱是Site Reliability Engineering，翻譯過來就是：站點可靠性工程師。
Google 對 SRE 的職責描述為：確保站點的可用，為了達到這個目的，一方面他需要對站點涉及的系統、組件熟悉，也要關注生產運行時的狀態，為此，他需要自開發並維護很多工具和系統支撐系統的運行，比如自動化發佈系統，監控系統，日誌系統，服務器資源分配和編排等。SRE是一個綜合素質很高的全能手，如果對他的能力進行分解主要有三塊：
熟悉系統架構與運行狀態：SRE需要懂服務器基礎架構、操作系統、網絡、中間件容器、常用編程語言、全局的架構意識、非常強的問題分析能力、極高的抗壓能力（以便沉著高效地排障），他們還需要懂性能調優理論。為了保證系統架構的高可用，SRE甚至會有意識的破壞自己的系統，以提高系統可用性。
熟悉運維涉及的管理方法：SRE需根據企業自身發展需要，清楚運維涉及的各項工作的流程方法論，比如故障處理、應用發佈、可用性管理等等，SRE十分重視運維流程的持續改善，比如對故障的追根溯源，懷疑一切的方式持續改進。
運維開發+產品經理：SRE 在運行保障過程中的手段更加自動化，更高效，這種高效來源於自動化工具、監控工具的支撐，且他們還需要是這些工具的主要開發者，他們要不斷優化和調整，使整個工具箱使起來更加得心應手。為此SRE有一個50%的理念，就是50%用於日常保障，50%用於項目性的工作，這個項目性的工作主要體現在運維開發與運維產品經理的角色。
運維開發關於運維開發的理解主要體現在運維工具層面，不同的組織有不同的理解，通常有三類：
完全自建：運維開發團隊利用開源技術結合自身需要進行一定的二次開發，這種方式在互聯網企業比較流行，具體的成效大小與何時能起來收效與對這個運維開發團隊的整體規劃或資源投入有關；
外購開發資源或工具產品：運維開發團隊主要是結合企業痛點承擔產品經理的角色，設計、跟進、推廣工具，這種方式常出現在傳統的企業，尤其適用於投入運維開發人員比較少的企業，這種方式是投入收效快，但是對外部資源依賴比較大，不利於後續持續建設；
外購與自建相結合：運維開發團隊在整個工具體系下，針對部份組件選擇性的引入一些成熟的工具體系，同時要求這類成熟的工具需要開放一定的接口或源碼支持，對於一些與公司個性強的環節採用自研的方式。這種方式目前逐漸被運一些傳統企業，比如金融企業所接受。
總的來說，不管選用上面哪一種方式，運維開發團隊都應該有一個整體、統一的一體化工具建設規劃，並在建設過程中始終保持對運維工具體系的掌控能力，並在工具體系的上層為其它運維人員提供簡易的、可創造性的“開發能力”，比如所見即所得的工具可視化、可定製的運維報表、拖拉拽方式的流程及腳本組件的拼裝等運維開發方式。
1.3.3 DevOps
1.3.3.1 DevOps 概述
DevOps 一詞的來自於 Development 和 Operations 的組合，突出重視軟件開發人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠，他是一種方法論，包含一套基本原則和實踐，工具是為有效落實這套方法論提供支持。
在軟件全生命週期管理過程中，包括開發，構建，測試，發佈，運營，在這個全生命週期管理過程中出現了開發組織與運維組織的部門牆，這是因為開發組織關注需求的實現，希望儘快實現變更；運維組織關注系統運行穩定，而變更又往往是生產應用不穩定的原因。
DevOps 方法論的出現主要是為了解決這個協作問題，以讓軟件交付更加高效，質量更高，生產端更加敏捷，生產運行過程中的問題能更加高效的反饋到開發，形成一個全生命週期的閉環。隨著業務對運維交付能力的時效性要求越來越高，運維組織面臨“吃力不討好”的問題：
吃力 ：花費大量時間在應用部署的操作性工作中。這部份部署變更包括新功能的上線以及修復功能BUG兩方法。
不討好：操作性的工作越來，帶來的操作風險越大，有這樣一個統計，如果手工運行5條命令的情況下，成功部署的概率就已跌至86%；如需手工運行55條命令，成功部署的概率將跌至 22%；如需手工運行100條命令，成功部署的概率將趨近於0（僅2%）。
DevOps 鼓勵軟件開發者和IT運維人員之間所進行的溝通、協作、集成和自動化，藉此有助於改善雙方在交付軟件過程中的速度和質量。側重於通過標準化開發環境和自動化交付流程改善交付工作的可預測性、效率、安全性，以及可維護性。
1.3.3.2運維實踐中的DevOps
可以從工具鏈、組織文化、自動化、敏捷看板等角度講DevOps，比如在目前比較活躍的 DevOps36計中，基本覆蓋了運維領域很大的一塊：
從 DevOps 的落地效率來看，需要將 DevOps 進行聚焦，聚焦到交付能力上，這方面，行業裡比較標準化的評估是去年底由中國信息通信研究院，聯合一些互聯網企業、運維社區，以及一些金融、傳統企業聯合進行編制的 DevOps 標準（券商行業中華泰參加了編制）。
從這個能力模型公佈出來的一些介紹看，標準對 DevOps 範圍比較剋制，主要以交付能力來分解敏捷開發、持續交付、技術運營、應用架構、組織架構，這和最早的 DevOps 能力環比較吻合：
從運維的交付場景看，主要是資源交付與應用交付，其中資源交付以IAAS、PAAS雲的建設為主，通過雲管平臺的工具鏈將基礎設施、網絡、硬件、虛擬化、容器、運行中間件等系統軟硬件交付能力自動化，並通過CMDB整合DevOps能力環之上的應用場景，實現資源的快速交付。
資源交付能力主要在於IAAS、PAAS層的雲平臺標準化、自動化、平臺擴展性等方面的建設程度。
應用的快速交付比資源交付更為複雜，應用交付涉及全鏈路的整合，鏈路上的節點越多落地的難度越大，因為它不僅涉及技術，還涉及理念的認同與聚焦。應用交付能力要實現，最簡單的技術棧工具需要CMDB、應用發佈工具、應用版本庫、監控工具，上述工具對內要與雲平臺對接，對外要提供接口給開發、測試工具。
當然如開發、測試也能和運維使用同一套發佈工具、應用版本庫則效果更好，不過，實際實施過程中組織之間還是會有不少衝突，比如開發關注源代碼版本管理，測試、運維關注運行版本的管理，需各個組織共同付出共建技術鏈。
1.3.4 運營
關於運維圈裡運營的概念，以轉型口號喊得比較多，我對運維當中的運營有業務運營與技術運營兩個維度的理解。業務運營是通過功能優化或工具開發等方式解決業務工作痛點，或通過運行分析發現影響業務開展的因素，並推動相關的優化，最終提升業務能力。技術運營則主要從技術角度去降低IT成本，提升IT服務質量與效率。具體的實施內容可以考慮如下：
從上述概括可以看出，當前運維裡面的運營，與運維數據密切相關，需要基於運維大數據平臺來提升運營質量。
為了進一步說明運營，這裡舉兩個例子：
1）理論：
優鍩科技CEO的陳傲寒在2016年寫過一篇文章《IT：從運維到運營》，雖然己過去1年多，仍是我讀過最好的一篇。全文從企業、運維組織角度出發分析什麼是運維、什麼是運營，再將運營分解到不同角色上的理解與落地的方向，全文均是乾貨，值得通讀，這裡只列出一個思維導圖。
2）實戰
去年參加了一場騰訊QQ關於 DevOps 的培訓，對於它們提到的一個自救方式的運營手段很有印象。那就是在騰訊QQ逐漸被微信團隊替代過程中，QQ技術運維團隊是如何通過各種方式去為企業帶來效益，比如他們通過運維分析，得到如何更加合理的使用帶寬、資源，大大減少了公司在基礎設施方面的投入。
在金融企業中，也同樣有很多空間可以去嘗試，比如分析業務痛點，為業務提供快速的策略性的工具來替代重複操作性的業務操作；通過運維數據分析，發現客戶體驗方面的痛點，推動業務功能的優化等等。
1.3.5 AIOps
AIOps這個詞最早是在2016年由Gartner提出（當然國內很多廠商也提出它們早幾年也提出了這個理念）。
AIOps是Algorithmic IT Operations的縮寫，是基於算法的IT運維，即通過使用統計分析和機器學習的方法處理從各IT設備、業務應用、運維工具收集的數據，從而加強增強運維自動化能力，以便更快、更有效、更全面的實現自動化效果。
Gartner通過使用圖1中的圖解釋了AIOps平臺的工作原理.AIOps有兩個主要組件：大數據和機器學習。它需要從孤立的IT數據中移除，以便將大量數據平臺內的觀察數據（例如監控系統和作業日誌中發現的數據）與參與數據（通常在故障單，事件和事件記錄中找到）相結合。
然後針對組合的IT數據實施全面的分析和機器學習（ML）策略。期望的結果是持續的見解，通過自動化產生持續的改進和修復。AIO可以被認為是核心IT功能的持續集成和部署（CI / CD）。
廣泛和多樣化的IT 數據源：如日誌類的設備日誌、系統日誌，應用日誌、運維操作日誌；指標類的監控性能指標、事件。
具備針對海量數據處理與分析的運算平臺，能夠從現有的IT數據生成新的數據和元數據、計算和分析還消除噪音，識別模式或趨勢，隔離可能的原因，揭示潛在問題，並實現其他IT特定目標。
算法，充分利用IT領域的專業知識，更適當，高效的處理數據。
機器學習，從根據算法分析的輸出和引入系統的新數據自動更改或創建新的算法。
可視化，以易於消費的方式向IT行動提供洞察和建議，以促進理解和行動。
自動化，其使用分析和機器學習產生的結果自動創建和應用響應或改進已識別的問題。
1.3.5 AIOps 與自動化的關係
AIOps很火，所以對AIOps和自動化做了一些對比。暫以一句話作個區別：AIOps 是基於對運維數據（日誌類、指標類數據等）的機器學習，進一步解決自動化成本高或無法解決的問題，屬於運維自動化的優化，細化一下區別有：
概念：
狹義的自動化則提運維“監、管、控”的工具。AIOps是將AI技術應用到IT運維領域，需要有學習、類人交互、主動決策的特徵。
實現思路：
自動化往往以過程為導向，AIOps則以目標為導向，通過對數據進行學習，得到如何實現目標。
門檻高度：
自動化手段有豐富的落地解決方案，適合作為替代標準化的運維操作性工作，即“面”的問題。AIOps目前仍處起步階段，不是適合替代現有的自動化，而是應該用於解決自動化不能解決或解決成本很高的問題，即“點”的問題。
如何整合：
AIOps並非是要取代現有的自動化運維體系，而是賦予現有體系智能。AIOps就要“學習，瞭解”自動化工具，並且更好的“使用”這些工具，這個過程就是深度集成，它的核心是對這些工具API的自主認知和自主使用。
雖然行業內的智能運維理念十分火熱，但實際落地成效上還主要處於研究階段。從運維工具技術解決方案的角度看，對於智能的解讀也有差別，如果將智能的特點解讀為具備”模擬人，具備自學習，能夠從數據中獲取知識，進而進行預測/決策“來判斷是否智能，智能是自動化的一個輔助手段，自動化才是終態。
建立在這個認識下，我們首先需要通過自動化手段解決痛點，提高工作效率，控制風險；利用運維數字化的建設為運維智能化提供數據、數據計算的能力；在自動化、數字化水平得到一定程度後，再通過人工智能的技術去解決自動化手段解決起來費力或無法解決的局部問題，讓自動化具備智能的水平。
1.4 體系
1.4.1 運維的可持續改進
在管理領域，戴明推出的PDCA循環可以解釋運維體系需要具備的可持續改進的能力條件。PDCA循環為四個階段，即計劃（plan）、執行（do）、檢查（check）、調整（Action），即在實際工作開展過程中，把各項工作按照作出計劃、計劃實施、檢查實施效果，然後將成功的納入標準，並不斷循環改進的過程。
將這個思路引入到企業的運維體系中則是針對企業業務發展的需求，制定運維體系的整體發展目標，通過不斷改進的措施提高運維工作效率、控制風險，以達到高效、更優化的資源配置，進而推動業務的發展。要做到運維體系的可持續改進，需要做到以業務導向，整體佈局；組織、流程、工具三位一體；不斷審視優化。
1）P：以業務導向、整體佈局
運維的最根本作用是保障IT數據的連續性，這裡的IT數據包括業務，以及反映業務的數據，或者換句話可以表達為：網絡不斷、系統不癱、數據不丟。隨著業務對IT系統依賴程度越來越高，運維又會承擔更高的期望，也就是運維向運營的轉化，這就需要從業務角度去不斷完善運維，以促進業務為大目標，要明白“IT for IT”是為了更好的“IT for Business”。
有了這個目標，那我們的運維體系的構建就需要與企業業務的發展保持同步，要讓運維體系具備可持續改進的能力。
另外，可持續改進的過程不應該是大拐彎的方式進行改進，而應該不斷的小調整，這就需要確保首先要建立一個整體、全局的運維體系，對運維各項工作做一個整體的規劃，把眼光看得更遠，往往可以更好的把控當前。
2）D：組織、流程、工具的三位一體
可持續改進的運維體系需要讓運維的組織、流程、工具三位一體的作用，比方說：提高工作效率，需要組織的專業化分工、流程的標準化、工具的自動化配合作用；推動業務的發展，既需精細化運維分析、業務服務、運營等維度的工作資源投入，也需要有工具的建設來減少操作性的工作來釋放人力，需要工具提供更高效的數據來源。
這裡說的組織主要是從運維人力資源的分工、團隊建設、工作目標導向、運維KPI等；流程是指以成熟的運維方法論為主體，結合企業和外部監管的規章制度、企業業務發展需要，而落地的標準化工作方法；工具既包括狹義運維的“監、管、控”，也包括運營體系所需要數字化、智能化的工具平臺。
3）C+A : 不斷審視優化
在實際工作過程中，審視檢查的過程很容易被忽略，但實際上最大的收穫可能就來自於這個總結、歸納的過程中，這也是可持續改進的運維體系的關鍵所在。比方說，運維組織可以考慮在必要環節增加橫向的優化團隊；運維流程也需要定期對流程的落地進行分析，並對規章制度進行查漏補缺、刪減不合理的流程規範、調整無法執行的規範要求；工具的建設要不斷的分析工具的使用覆蓋率，如何提高覆蓋率，分析是否提高了運維的效率，還是帶來了反作用等分析，並不斷調整優化工具的建設。
1.4.2 轉型思路
在提出可持續的運維體系前，我們先歸納一下運維組織常見的運維痛點，以提出運維轉型的思路，再看看如何構建一個可持續改進的運維體系來支撐運維轉型。前面的運維之痛中提到了“救火”、“背鍋”、“低價值”、”重複操作“等標籤，我們歸納下己有特點再看轉型：
1）特點
被動救火式，以被動保障業務系統運行，日常計劃性工作容易被打斷、擱置；
問題驅動式，以系統可用性、可靠性、業務請求等問題驅動運維工作；
操作運維，重複性、操作類點主要工作量的運維模式；
經驗式運維，由人工經驗驅動的運維模式，尤其是一些經驗豐富的老員工的離職在短期內會對運維質量帶來一定的衝擊。
2）轉型
從被動救火式向主動精細化轉型，專業化分工、主動分析，主動優化，驅動開發，促進DEVOPS的落地；
從問題驅動向價值驅動轉型，以企業業務發展目標為主線，業務體驗、服務滿意度、促進業務更好發展；
從操作運維向運維開發轉型，通過為運維人員提供運維開發平臺，降低運維開發門檻，快速落地一些緊迫的運維工具，降低操作性、重複性的運維工作；
從依靠經驗向智能化驅動運維轉型，結合數據分析、知識庫、機器學習技術促進運維智能化。
1.4.3 構建運維體系
上二節提到運維體系以業務導向，整體佈局，組織、流程、工具三位一體，不斷審視優化的建設思路，也提出了”主動精細化“、”價值驅動“、”運維開發“、”智能化運維“的轉型目標，我們再將這些思路分解到組織、流程、工具的建設中，並歸納為：三大建設，十個文化的實踐方法：
組織建設：專業化、精細化、運營化
我們將運維實施主體運維組織理解為組織，理想情況下，優秀的組織應該具備有合適的工作、合適的時間、合適的人、合適的行為四個要素組成。即組織要結合企業實際發展方向，制定符合企業、運維組織、個人發展的工作內容，並選擇具備合適的知識、技能、認知、能力的人去完成工作，去實際個人的自我價值。
前面也提到，目前的運維織是一個被動保障業務系統運行，日常計劃性工作容易被打斷、擱置的工作，這種工作狀態下的運維組織往往工作效率不高、容易出現操作風險。為了讓運維組織具備可持續改進的能力，需要提高運維組織的工作效率，我們需要將運維工作專業化，整合通用性、操作性的工作，提高工作效率，在釋放運維人員工作量後，引導運維人員有計劃、可量化的去做更多分析類、優化類、業務運營的主動性工作。
流程建設：標準化、可視化、可量化
大部份運維組織會以內部企業積累的規章制度、外部監管機構的監管要求為基礎，依照ITIL、ISO20000、ITSS.1、DevOps的方法論中的一個或多個組合的方式開展運維工作。這些規章制度、監管要求、方法論的整合、落地、持續改進的過程即為流程建設的過程。
流程建設首先需要標準化流程，要先梳理好己有的流程制度，約定工作的流轉方式，再通過可視化將流程整合在日常工作中，最後通過流程落地數據的分析與工具建設，持續改善提高流程落地的效率，控制操作風險。
工具建設：自動化、數字化、智能化、服務化
工具的建設也以可持續改進的思路構建，以整合存量資源、引入成熟或開源技術為主，建立一體化的運維工具體系，通過體系化的思路實現運維工具（“監、管、控”）的互聯互通，有序建設，實現自動化運維，全面控制風險、提高工作效率、釋放人力；通過建立運維數據分析平臺，實現數字化運營，提供運維數據集中與治理、主動分析的能力；在數字化運營的基礎上通過運維數據挖掘、學習，優化運維或運營場景，向智能化發展；服務化則是以IT服務的方式將運維能力向處輸出。
CIO之家 www.ciozj.com 微信公眾號:imciow
"閱讀更多 CIO之家 的文章
