IT運維大牛萬字自述：道盡十多年血淚史與轉型自救路
時間：2022/5/26 14:30:30瀏覽次數：288
運維大牛萬字自述：道盡十多年血淚史與轉型自救路
與一個行業大牛的朋友交流時，在聽到他年輕時在大廠的一些關于將工作方法升華為方法論，比如“監、管、控”、“新網點”理念，并推動整個行業建設時為之一震。這個觸動讓我有了讓自己的運維知識體系建設做第一次飛躍的打算，即如何將知識體系通過一個主線串起來。
關于這個主線，找過一些朋友做了交流，比如“風險可控”、“一體化”、“更高效更優化的資源配置”、“可擴展性”。由于自己主要身處一線運維團隊，所以選了“可擴展性”的主線，接下來打算根據這條主線，不斷完善知識體系，目標是體系化的整理知識體系，主要從組織、流程、工具的可持續整合。
以下內容，主要是對運維整體的概覽，講講對運維的認識，以及一些轉型理念思考。
一、運維不簡單
前陣子，跟一個項目經理溝通能否提前半天將變更申請提交過來時，這位項目經理很不理解地問我：“你們運維不就是在生產環境部署個程序這么簡單的工作嗎？你們又不懂程序，評審不出什么吧？”
運維多年，對運維的這類認識聽過很多，它反映了企業里不同的組織團隊對運維的認識往往僅限于一些簡單操作性的工作，比如生產應用系統在故障時的重啟、應用變更時敲敲命令、平時增刪改查數據，或者是辦公室和電有關的所有軟硬件的使用問題等等。
那么如何理解運維呢？百度百科對運維的解釋為：企業IT部門采用相關的方法、手段、技術、制度、流程和文檔等，對IT軟硬運行環境（軟件環境、網絡環境等）、IT業務系統和IT運維人員進行的綜合管理。從百度百科的解釋看，運維崗位需要一個綜合性的技術與管理能力，需要掌握大量的方法論與技術棧。
運維狹義“運維技術與資源”可以定義為“監、管、控”，技術與資源主要是支撐運維/運營的質量、效率、成本的平衡。以下簡單摘錄了運維的一些能力要求：
圖1.1
圖1.2
講到這，肯定會有人說上述的技術棧的能力要求，通常是由于某個運維組織的仍處于專家式運維，自動化程度不夠高導致。
的確，理論上所有運維操作性、命令的工作都可以整合為經驗，并通過自動化落地實現，現在互聯網企業對外都宣稱自動化在運維工作覆蓋面很高，己經開始邁向智能化，AIOps，甚至提出了NoOps的解決方案。
關于這些互聯網企業的自動化對日常運維工作真實的覆蓋面暫時無法考究，但以我的經驗看，至少金融企業的自動化覆蓋面還有很長的路要走，且肯定還會很大一部分工作很難自動化，畢竟工作類型太多，在有限的投入上只能集中力氣去做投入產出比更高的運維自動化。這里再以一個運維工具思維導圖（圖1.3）簡單列示一些常規的運維操作，可以看出其實很難有一套能解決所有運維操作的工具平臺。
圖1.3
所以我覺得，隨著業務要求越來越高、規模越來越大、監管要求越來越高，縱使外部如何宣稱自動化、智能化對運維人員經驗、技術、管理能力替代，金融企業內的運維還需要認清實際情況，結合企業的整體戰略定位，強調運維團隊在運維管理與技術能力的廣度與深度，再有側重、有先后的實現自動化水平。
在未來一段時間里，金融企業的運維崗位仍是一個復雜的、綜合性技能的工作崗位。
二、運維之痛
近年來，隨著運維技術的快速發展，各行業的運維水平在得到了較大的提升同時，運維圈的分享也越來越開放，從國外Google的SRE理念，到國內新技術領跑者以及借助于各種運維專題的公眾號、運維大會有大量的互聯網、傳統企業的運維組織進行分享。
1、組織之痛
前面講過，在企業內部其它團隊對運維的認識通常是簡單操作，出故障時才會找的團隊，隨著信息技術的發展與業務的發展，運維組織痛點越來越明顯，企業內對運維組織的不滿的聲音越來越多，反思一下原因，分外部客觀因素和內部因素。
1）外部客觀因素
在當前大數據時代，金融企業的運維面臨業務規模的不斷擴大，業務競爭越來越激烈，監管要求越來越高，數據中心的規模也越來越高，大量新技術、開源架構的引入取代了傳統穩定的系統架構等等因素影響。
2）內部因素
網上有一個調查數據，在整個運維成本的分配中，軟硬件和網絡設備的維護成本占 30%，維護服務成本占30%，內部運維人力成本則占了40%。這里的人力成本包括現在維護、培訓、流失與引入等成本，如果將維護服務成本也納入到人力成本之上，則人力這一塊的成本將上升為70%，影響這個人力成本的因素主要有：
2、個體之痛
作為運維組織中的運維人員同樣面臨不少痛點，有來自工作時間、工作壓力、學習壓力、職業發展等等，以下簡單羅列：
三、自救
1、SRE
SRE這個名詞最早是從《Google SRE 運維解密》一書中獲得，全稱是Site Reliability Engineering，翻譯過來就是：站點可靠性工程師。Google對SRE的職責描述為：確保站點的可用，為了達到這個目的，一方面他需要對站點涉及的系統、組件熟悉，也要關注生產運行時的狀態。
為此，他需要自開發并維護很多工具和系統支撐系統的運行，比如自動化發布系統、監控系統、日志系統、服務器資源分配和編排等。SRE是一個綜合素質很高的全能手，如果對他的能力進行分解主要有三塊：
2、運維開發
關于運維開發的理解主要體現在運維工具層面，不同的組織有不同的理解，通常有三類：
總的來說，不管選用上面哪一種方式，運維開發團隊都應該有一個整體、統一的一體化工具建設規劃，并在建設過程中始終保持對運維工具體系的掌控能力，并在工具體系的上層為其它運維人員提供簡易的、可創造性的“開發能力”，比如所見即所得的工具可視化、可定制的運維報表、拖拉拽方式的流程及腳本組件的拼裝等運維開發方式。
3、DevOps
1）DevOps概述
DevOps一詞的來自于Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發布更加快捷、頻繁和可靠，他是一種方法論，包含一套基本原則和實踐，工具是為有效落實這套方法論提供支持。
在軟件全生命周期管理過程中，包括開發、構建、測試、發布、運營，在這個全生命周期管理過程中出現了開發組織與運維組織的部門墻，這是因為開發組織關注需求的實現，希望盡快實現變更；運維組織關注系統運行穩定，而變更又往往是生產應用不穩定的原因。
DevOps方法論的出現主要是為了解決這個協作問題，以讓軟件交付更加高效，質量更高，生產端更加敏捷，生產運行過程中的問題能更加高效的反饋到開發，形成一個全生命周期的閉環。隨著業務對運維交付能力的時效性要求越來越高，運維組織面臨“吃力不討好”的問題：
2）運維實踐中的DevOps
可以從工具鏈、組織文化、自動化、敏捷看板等角度講DevOps，比如在目前比較活躍的DevOps36計，基本覆蓋了運維領域很大的一塊：
圖1.4
從DevOps的落地效率來看，需要將DevOps進行聚焦，聚焦到交付能力上，這方面，行業里比較標準化的評估是去年底由中國信息通信研究院，聯合一些互聯網企業、運維社區，以及一些金融、傳統企業聯合進行編制的DevOps標準（券商行業中華泰參加了編制）。從這個能力模型公布出來的一些介紹看，標準對DevOps范圍比較克制主要以交付能力來分解敏捷開發、持續交付、技術運營、應用架構、組織架構，這和最早的DevOps能力環比較吻合：
圖1.5
從運維的交付場景看，主要是資源交付與應用交付，其中資源交付以IaaS、PaaS云的建設為主，通過云管平臺的工具鏈將基礎設施、網絡、硬件、虛擬化、容器、運行中間件等系統軟硬件交付能力自動化，并通過CMDB整合DevOps能力環之上的應用場景，實現資源的快速交付。
資源交付能力主要在于IaaS、PaaS層的云平臺標準化、自動化、平臺擴展性等方面的建設程度。應用的快速交付比資源交付更為復雜，應用交付涉及全鏈路的整合，鏈路上的節點越多落地的難度越大，因為它不僅涉及技術，還涉及理念的認同與聚焦。
應用交付能力要實現，最簡單的技術棧工具需要CMDB、應用發布工具、應用版本庫、監控工具，上述工具對內要與云平臺對接，對外要提供接口給開發、測試工具。當然如開發、測試也能和運維使用同一套發布工具、應用版本庫則效果更好，不過，實際實施過程中組織之間還是會有不少沖突，比如開發關注源代碼版本管理，測試、運維關注運行版本的管理，需各個組織共同付出共建技術鏈。
4、運營
關于運維圈里運營的概念，以轉型口號喊得比較多，我對運維當中的運營有業務運營與技術運營兩個維度的理解。業務運營是通過功能優化或工具開發等方式解決業務工作痛點，或通過運行分析發現影響業務開展的因素，并推動相關的優化，最終提升業務能力。技術運營則主要從技術角度去降低IT成本，提升IT服務質量與效率。具體的實施內容可以考慮如下：
圖1.6
從上述概括可以看出，當前運維里面的運營，與運維數據密切相關，需要基于運維大數據平臺來提升運營質量。
為了進一步說明運營，這里舉兩個例子：
1）理論
優锘科技CEO的陳傲寒在2016年寫過一篇文章《IT：從運維到運營》，仍是我讀過最好的一篇。全文從企業、運維組織角度出發分析什么是運維、什么是運營，再將運營分解到不同角色上的理解與落地的方向，全文均是干貨，值得通讀，這里只列出一個思維導圖。
圖1.7
2）實戰
參加過一場騰訊QQ關于DevOps的培訓，對于它們提到的一個自救方式的運營手段很有印象。那就是在騰訊QQ逐漸被微信團隊替代過程中，QQ技術運維團隊是如何通過各種方式去為企業帶來效益，比如他們通過運維分析，得到如何更加合理的使用帶寬、資源，大大減少了公司在基礎設施方面的投入。
在金融企業中，也同樣有很多空間可以去嘗試，比如分析業務痛點，為業務提供快速的策略性的工具來替代重復操作性的業務操作；通過運維數據分析，發現客戶體驗方面的痛點，推動業務功能的優化等等。
4、AIOps
AIOps這個詞最早是在2016年由Gartner提出（當然國內很多廠商也提出它們早幾年也提出了這個理念）。AIOps是Algorithmic IT Operations的縮寫，是基于算法的IT運維，即通過使用統計分析和機器學習的方法處理從各IT設備、業務應用、運維工具收集的數據，從而加強增強運維自動化能力，以便更快、更有效、更全面地自動化效果。以下是Gartner提出AIOps的一張圖：
圖1.8
Gartner通過使用圖1.9中的圖解釋了AIOps平臺的工作原理。AIOps有兩個主要組件：大數據和機器學習。它需要從孤立的IT數據中移除，以便將大量數據平臺內的觀察數據（例如監控系統和作業日志中發現的數據）與參與數據（通常在故障單，事件和事件記錄中找到）相結合。
AIO然后針對組合的IT數據實施全面的分析和機器學習（ML）策略。期望的結果是持續的見解，通過自動化產生持續的改進和修復。AIO可以被認為是核心IT功能的持續集成和部署（CI/CD）。
圖1.9
6、AIOps與自動化的關系
AIOps很火，所以對AIOps和自動化做了一些對比。暫以一句話作個區別：AIOps是基于對運維數據（日志類、指標類數據等）的機器學習，進一步解決自動化成本高或無法解決的問題，屬于運維自動化的優化，細化一下區別有：
雖然行業內的智能運維理念十分火熱，但實際落地成效上還主要處于研究階段。從運維工具技術解決方案的角度看，對于智能的解讀也有差別，如果將智能的特點解讀為具備“模擬人，具備自學習，能夠從數據中獲取知識，進而進行預測/決策”來判斷是否智能，智能是自動化的一個輔助手段，自動化才是終態。
建立在這個認識下，我們首先需要通過自動化手段解決痛點，提高工作效率，控制風險；利用運維數字化的建設為運維智能化提供數據、數據計算的能力；在自動化、數字化水平得到一定程度后，再通過人工智能的技術去解決自動化手段解決起來費力或無法解決的局部問題，讓自動化具備智能的水平。
四、體系
1、運維的可持續改進
在管理領域，戴明推出的PDCA循環可以解釋運維體系需要具備的可持續改進的能力條件。
PDCA循環為四個階段，即計劃（plan）、執行（do）、檢查（check）、調整（Action），即在實際工作開展過程中，把各項工作按照作出計劃、計劃實施、檢查實施效果，然后將成功的納入標準，并不斷循環改進的過程。
將這個思路引入到企業的運維體系中則是針對企業業務發展的需求，制定運維體系的整體發展目標，通過不斷改進的措施提高運維工作效率、控制風險，以達到更高效、更優化的資源配置，進而推動業務的發展。要做到運維體系的可持續改進，需要做到以業務導向，整體部局；組織、流程、工具三位一體；不斷審視優化。
1）P：以業務導向、整體部局
運維的最根本作用是保障IT數據的連續性，這里的IT數據包括業務，以及反映業務的數據，或者換句話可以表達為：網絡不斷、系統不癱、數據不丟。隨著業務對IT系統依賴程度越來越高，運維又會承擔更高的期望，也就是運維向運營的轉化，這就需要從業務角度去不斷完善運維，以促進業務為大目標，要明白“IT for IT”是為了更好的“IT for Business”。
有了這個目標，那我們的運維體系的構建就需要與企業業務的發展保持同步，要讓運維體系具備可持續改進的能力。
另外，可持續改進的過程不應該是大拐彎的方式進行改進，而應該不斷的小調整，這就需要確保首先要建立一個整體、全局的運維體系，對運維各項工作做一個整體的規劃，把眼光看得更遠，往往可以更好的把控當前。
2）D：組織、流程、工具的三位一體
可持續改進的運維體系需要讓運維的組織、流程、工具三位一體的作用，比方說：提高工作效率，需要組織的專業化分工、流程的標準化、工具的自動化配合作用；推動業務的發展，既需精細化運維分析、業務服務、運營等維度的工作資源投入，也需要有工具的建設來減少操作性的工作來釋放人力，需要工具提供更高效的數據來源。
這里說的組織主要是從運維人力資源的分工、團隊建設、工作目標導向、運維KPI等；流程是指以成熟的運維方法論為主體，結合企業和外部監管的規章制度、企業業務發展需要，而落地的標準化工作方法；工具既包括狹義運維的“監、管、控”，也包括運營體系所需要數字化、智能化的工具平臺。
3）C+A : 不斷審視優化
在實際工作過程中，審視檢查的過程很容易被忽略，但實際上最大的收獲可能就來自于這個總結、歸納的過程中，這也是可持續改進的運維體系的關鍵所在。
比方說，運維組織可以考慮在必要環節增加橫向的優化團隊；運維流程也需要定期對流程的落地進行分析，并對規章制度進行查漏補缺、刪減不合理的流程規范、調整無法執行的規范要求；工具的建設要不斷的分析工具的使用覆蓋率，如何提高覆蓋率，分析是否提高了運維的效率，還是帶來了反作用等分析，并不斷調整優化工具的建設。
2、轉型思路
在提出可持續的運維體系前，我們先歸納一下運維組織常見的運維痛點，以提出運維轉型的思路，再看看如何構建一個可持續改進的運維體系來支撐運維轉型。前面的運維之痛中提到了 “救火”、“背鍋”、“低價值”、”重復操作“等標簽，我們歸納下己有特點再看轉型：
1）特點
圖1.10
3、構建運維體系
上二節提到運維體系以業務導向，整體部局，組織、流程、工具三位一體，不斷審視優化的建設思路，也提出了“主動精細化”、“價值驅動”、“運維開發”、“智能化運維”的轉型目標，我們再將這些思路分解到組織、流程、工具的建設中，并歸納為：三大建設，十個文化的實踐方法：
1）組織建設：專業化、精細化、運營化
我們將運維實施主體運維組織理解為組織，理想情況下，優秀的組織應該具備有合適的工作、合適的時間、合適的人、合適的行為四個要素組成。即組織要結合企業實際發展方向，制定符合企業、運維組織、個人發展的工作內容，并選擇具備合適的知識、技能、認知、能力的人去完成工作，去實現個人的自我價值。
前面也提到，目前的運維織是一個被動保障業務系統運行，日常計劃性工作容易被打斷、擱置的工作，這種工作狀態下的運維組織往往工作效率不高、容易出現操作風險。
為了讓運維組織具備可持續改進的能力，需要提高運維組織的工作效率，我們需要將運維工作專業化，整合通用性、操作性的工作，提高工作效率，在釋放運維人員工作量后，引導運維人員有計劃、可量化的去做更多分析類、優化類、業務運營的主動性工作。
2）流程建設：標準化、可視化、可量化
大部分運維組織會以內部企業積累的規章制度、外部監管機構的監管要求為基礎，依照ITIL、ISO20000、ITSS.1、DevOps的方法論中的一個或多個組合的方式開展運維工作。這些規章制度、監管要求、方法論的整合、落地、持續改進的過程即為流程建設的過程。
流程建設首先需要標準化流程，要先梳理好己有的流程制度，約定工作的流轉方式，再通過可視化將流程整合在日常工作中，最后通過流程落地數據的分析與工具建設，持續改善提高流程落地的效率，控制操作風險。
3）工具建設：自動化、數字化、智能化、服務化
工具的建設也以可持續改進的思路構建，以整合存量資源、引入成熟或開源技術為主，建立一體化的運維工具體系。
通過體系化的思路實現運維工具（“監、管、控”）的互聯互通，有序建設，實現自動化運維，全面控制風險、提高工作效率、釋放人力；通過建立運維數據分析平臺，實現數字化運營，提供運維數據集中與治理、主動分析的能力；在數字化運營的基礎上通過運維數據挖掘、學習，優化運維或運營場景，向智能化發展；服務化則是以IT服務的方式將運維能力向外輸出。
與一個行業大牛的朋友交流時，在聽到他年輕時在大廠的一些關于將工作方法升華為方法論，比如“監、管、控”、“新網點”理念，并推動整個行業建設時為之一震。這個觸動讓我有了讓自己的運維知識體系建設做第一次飛躍的打算，即如何將知識體系通過一個主線串起來。
關于這個主線，找過一些朋友做了交流，比如“風險可控”、“一體化”、“更高效更優化的資源配置”、“可擴展性”。由于自己主要身處一線運維團隊，所以選了“可擴展性”的主線，接下來打算根據這條主線，不斷完善知識體系，目標是體系化的整理知識體系，主要從組織、流程、工具的可持續整合。
以下內容，主要是對運維整體的概覽，講講對運維的認識，以及一些轉型理念思考。
一、運維不簡單
前陣子，跟一個項目經理溝通能否提前半天將變更申請提交過來時，這位項目經理很不理解地問我：“你們運維不就是在生產環境部署個程序這么簡單的工作嗎？你們又不懂程序，評審不出什么吧？”
運維多年，對運維的這類認識聽過很多，它反映了企業里不同的組織團隊對運維的認識往往僅限于一些簡單操作性的工作，比如生產應用系統在故障時的重啟、應用變更時敲敲命令、平時增刪改查數據，或者是辦公室和電有關的所有軟硬件的使用問題等等。
那么如何理解運維呢？百度百科對運維的解釋為：企業IT部門采用相關的方法、手段、技術、制度、流程和文檔等，對IT軟硬運行環境（軟件環境、網絡環境等）、IT業務系統和IT運維人員進行的綜合管理。從百度百科的解釋看，運維崗位需要一個綜合性的技術與管理能力，需要掌握大量的方法論與技術棧。
運維狹義“運維技術與資源”可以定義為“監、管、控”，技術與資源主要是支撐運維/運營的質量、效率、成本的平衡。以下簡單摘錄了運維的一些能力要求：
- 運維規范的落地：以ITIL、ISO20000、ITSS.1等方法論，結合外部監管及內部規范的落地；
- 監管機構的要求落地：理解、快速響應、落地監管機構的管理要求；
- 基本保障：配置、監控、應用發布、資源擴容、事件、問題等；
- 基礎能力：網絡、服務器、操作系統、數據庫、中間件、JVM、應用等基本使用與調優；
- 業務服務能力：SLA，服務臺、業務咨詢、維護、經驗庫、等支持能力；
- 可用性管理能力：巡檢、業務系統連續性、可用性，基礎架構及應用系統的高可用、備件冗余資源；
- 風險、安全管理能力：操作、審計、監管風險，漏洞、攻擊管控；
- 故障管理能力：事件、問題管理水平與能力；
- 持續交付能力：應用變更、基礎資源、辦公服務交付能力；
- 主動優化能力：架構優化、性能響應效率、客戶體驗等；
- 應急演練：架構高可用、突發事件、業務故障的架構、方案、文檔、人員熟練程度等；
- 業務支撐：數據維護、數據提取、參數維護等；
- 運行分析能力：容量、性能、可用性分析等；
- 運營能力：促進業務痛點的發現與解決、客戶及業務業務體驗等；
- 成本控制：更好地評估人力、硬件、帶寬、軟件，節省成本；
- 運維開發：運維自動化工具的建設，運維開發能力的培養；
- 其它
圖1.1
圖1.2
講到這，肯定會有人說上述的技術棧的能力要求，通常是由于某個運維組織的仍處于專家式運維，自動化程度不夠高導致。
的確，理論上所有運維操作性、命令的工作都可以整合為經驗，并通過自動化落地實現，現在互聯網企業對外都宣稱自動化在運維工作覆蓋面很高，己經開始邁向智能化，AIOps，甚至提出了NoOps的解決方案。
關于這些互聯網企業的自動化對日常運維工作真實的覆蓋面暫時無法考究，但以我的經驗看，至少金融企業的自動化覆蓋面還有很長的路要走，且肯定還會很大一部分工作很難自動化，畢竟工作類型太多，在有限的投入上只能集中力氣去做投入產出比更高的運維自動化。這里再以一個運維工具思維導圖（圖1.3）簡單列示一些常規的運維操作，可以看出其實很難有一套能解決所有運維操作的工具平臺。
圖1.3
所以我覺得，隨著業務要求越來越高、規模越來越大、監管要求越來越高，縱使外部如何宣稱自動化、智能化對運維人員經驗、技術、管理能力替代，金融企業內的運維還需要認清實際情況，結合企業的整體戰略定位，強調運維團隊在運維管理與技術能力的廣度與深度，再有側重、有先后的實現自動化水平。
在未來一段時間里，金融企業的運維崗位仍是一個復雜的、綜合性技能的工作崗位。
二、運維之痛
近年來，隨著運維技術的快速發展，各行業的運維水平在得到了較大的提升同時，運維圈的分享也越來越開放，從國外Google的SRE理念，到國內新技術領跑者以及借助于各種運維專題的公眾號、運維大會有大量的互聯網、傳統企業的運維組織進行分享。
1、組織之痛
前面講過，在企業內部其它團隊對運維的認識通常是簡單操作，出故障時才會找的團隊，隨著信息技術的發展與業務的發展，運維組織痛點越來越明顯，企業內對運維組織的不滿的聲音越來越多，反思一下原因，分外部客觀因素和內部因素。
1）外部客觀因素
在當前大數據時代，金融企業的運維面臨業務規模的不斷擴大，業務競爭越來越激烈，監管要求越來越高，數據中心的規模也越來越高，大量新技術、開源架構的引入取代了傳統穩定的系統架構等等因素影響。
- 運維組織的角色
- 業務對運維服務質量的要求
- 外部監管要求
- 業務并發要求
- 數據中心規模增大
2）內部因素
網上有一個調查數據，在整個運維成本的分配中，軟硬件和網絡設備的維護成本占 30%，維護服務成本占30%，內部運維人力成本則占了40%。這里的人力成本包括現在維護、培訓、流失與引入等成本，如果將維護服務成本也納入到人力成本之上，則人力這一塊的成本將上升為70%，影響這個人力成本的因素主要有：
- 運維能力模型
- 運維規范化
- 運維精細化程度
- 運維目標
- 自動化能力
2、個體之痛
作為運維組織中的運維人員同樣面臨不少痛點，有來自工作時間、工作壓力、學習壓力、職業發展等等，以下簡單羅列：
- 7*24小時制的工作時間
- 高度壓力的工作
- 被動的工作
- 對工作的認識
- 職業壓力
三、自救
1、SRE
SRE這個名詞最早是從《Google SRE 運維解密》一書中獲得，全稱是Site Reliability Engineering，翻譯過來就是：站點可靠性工程師。Google對SRE的職責描述為：確保站點的可用，為了達到這個目的，一方面他需要對站點涉及的系統、組件熟悉，也要關注生產運行時的狀態。
為此，他需要自開發并維護很多工具和系統支撐系統的運行，比如自動化發布系統、監控系統、日志系統、服務器資源分配和編排等。SRE是一個綜合素質很高的全能手，如果對他的能力進行分解主要有三塊：
- 熟悉系統架構與運行狀態
- 熟悉運維涉及的管理方法
- 運維開發+產品經理
2、運維開發
關于運維開發的理解主要體現在運維工具層面，不同的組織有不同的理解，通常有三類：
- 完全自建
- 外購開發資源或工具產品
- 外購與自建相結合
總的來說，不管選用上面哪一種方式，運維開發團隊都應該有一個整體、統一的一體化工具建設規劃，并在建設過程中始終保持對運維工具體系的掌控能力，并在工具體系的上層為其它運維人員提供簡易的、可創造性的“開發能力”，比如所見即所得的工具可視化、可定制的運維報表、拖拉拽方式的流程及腳本組件的拼裝等運維開發方式。
3、DevOps
1）DevOps概述
DevOps一詞的來自于Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發布更加快捷、頻繁和可靠，他是一種方法論，包含一套基本原則和實踐，工具是為有效落實這套方法論提供支持。
在軟件全生命周期管理過程中，包括開發、構建、測試、發布、運營，在這個全生命周期管理過程中出現了開發組織與運維組織的部門墻，這是因為開發組織關注需求的實現，希望盡快實現變更；運維組織關注系統運行穩定，而變更又往往是生產應用不穩定的原因。
DevOps方法論的出現主要是為了解決這個協作問題，以讓軟件交付更加高效，質量更高，生產端更加敏捷，生產運行過程中的問題能更加高效的反饋到開發，形成一個全生命周期的閉環。隨著業務對運維交付能力的時效性要求越來越高，運維組織面臨“吃力不討好”的問題：
- 吃力： 花費大量時間在應用部署的操作性工作中。這部分部署變更包括新功能的上線以及修復功能BUG兩方法。
- 不討好： 操作性的工作越大，帶來的操作風險越大，有這樣一個統計，如果手工運行5條命令的情況下，成功部署的概率就已跌至86%；如需手工運行55條命令，成功部署的概率將跌至22%；如需手工運行100條命令，成功部署的概率將趨近于0（僅2%）。
2）運維實踐中的DevOps
可以從工具鏈、組織文化、自動化、敏捷看板等角度講DevOps，比如在目前比較活躍的DevOps36計，基本覆蓋了運維領域很大的一塊：
圖1.4
從DevOps的落地效率來看，需要將DevOps進行聚焦，聚焦到交付能力上，這方面，行業里比較標準化的評估是去年底由中國信息通信研究院，聯合一些互聯網企業、運維社區，以及一些金融、傳統企業聯合進行編制的DevOps標準（券商行業中華泰參加了編制）。從這個能力模型公布出來的一些介紹看，標準對DevOps范圍比較克制主要以交付能力來分解敏捷開發、持續交付、技術運營、應用架構、組織架構，這和最早的DevOps能力環比較吻合：
圖1.5
從運維的交付場景看，主要是資源交付與應用交付，其中資源交付以IaaS、PaaS云的建設為主，通過云管平臺的工具鏈將基礎設施、網絡、硬件、虛擬化、容器、運行中間件等系統軟硬件交付能力自動化，并通過CMDB整合DevOps能力環之上的應用場景，實現資源的快速交付。
資源交付能力主要在于IaaS、PaaS層的云平臺標準化、自動化、平臺擴展性等方面的建設程度。應用的快速交付比資源交付更為復雜，應用交付涉及全鏈路的整合，鏈路上的節點越多落地的難度越大，因為它不僅涉及技術，還涉及理念的認同與聚焦。
應用交付能力要實現，最簡單的技術棧工具需要CMDB、應用發布工具、應用版本庫、監控工具，上述工具對內要與云平臺對接，對外要提供接口給開發、測試工具。當然如開發、測試也能和運維使用同一套發布工具、應用版本庫則效果更好，不過，實際實施過程中組織之間還是會有不少沖突，比如開發關注源代碼版本管理，測試、運維關注運行版本的管理，需各個組織共同付出共建技術鏈。
4、運營
關于運維圈里運營的概念，以轉型口號喊得比較多，我對運維當中的運營有業務運營與技術運營兩個維度的理解。業務運營是通過功能優化或工具開發等方式解決業務工作痛點，或通過運行分析發現影響業務開展的因素，并推動相關的優化，最終提升業務能力。技術運營則主要從技術角度去降低IT成本，提升IT服務質量與效率。具體的實施內容可以考慮如下：
圖1.6
從上述概括可以看出，當前運維里面的運營，與運維數據密切相關，需要基于運維大數據平臺來提升運營質量。
為了進一步說明運營，這里舉兩個例子：
1）理論
優锘科技CEO的陳傲寒在2016年寫過一篇文章《IT：從運維到運營》，仍是我讀過最好的一篇。全文從企業、運維組織角度出發分析什么是運維、什么是運營，再將運營分解到不同角色上的理解與落地的方向，全文均是干貨，值得通讀，這里只列出一個思維導圖。
圖1.7
2）實戰
參加過一場騰訊QQ關于DevOps的培訓，對于它們提到的一個自救方式的運營手段很有印象。那就是在騰訊QQ逐漸被微信團隊替代過程中，QQ技術運維團隊是如何通過各種方式去為企業帶來效益，比如他們通過運維分析，得到如何更加合理的使用帶寬、資源，大大減少了公司在基礎設施方面的投入。
在金融企業中，也同樣有很多空間可以去嘗試，比如分析業務痛點，為業務提供快速的策略性的工具來替代重復操作性的業務操作；通過運維數據分析，發現客戶體驗方面的痛點，推動業務功能的優化等等。
4、AIOps
AIOps這個詞最早是在2016年由Gartner提出（當然國內很多廠商也提出它們早幾年也提出了這個理念）。AIOps是Algorithmic IT Operations的縮寫，是基于算法的IT運維，即通過使用統計分析和機器學習的方法處理從各IT設備、業務應用、運維工具收集的數據，從而加強增強運維自動化能力，以便更快、更有效、更全面地自動化效果。以下是Gartner提出AIOps的一張圖：
圖1.8
Gartner通過使用圖1.9中的圖解釋了AIOps平臺的工作原理。AIOps有兩個主要組件：大數據和機器學習。它需要從孤立的IT數據中移除，以便將大量數據平臺內的觀察數據（例如監控系統和作業日志中發現的數據）與參與數據（通常在故障單，事件和事件記錄中找到）相結合。
AIO然后針對組合的IT數據實施全面的分析和機器學習（ML）策略。期望的結果是持續的見解，通過自動化產生持續的改進和修復。AIO可以被認為是核心IT功能的持續集成和部署（CI/CD）。
- 廣泛和多樣化的IT數據源，如日志類的設備日志、系統日志，應用日志、運維操作日志；指標類的監控性能指標、事件。
- 具備針對海量數據處理與分析的運算平臺，能夠從現有的IT數據生成新的數據和元數據、計算和分析還消除噪音，識別模式或趨勢，隔離可能的原因，揭示潛在問題，并實現其他IT特定目標。
- 算法 ，充分利用IT領域的專業知識，更適當，高效地處理數據。
- 機器學習 ，從根據算法分析的輸出和引入系統的新數據自動更改或創建新的算法。
- 可視化 ，以易于消費的方式向IT行動提供洞察和建議，以促進理解和行動。
- 自動化 ，其使用分析和機器學習產生的結果自動創建和應用響應或改進已識別的問題。
圖1.9
6、AIOps與自動化的關系
AIOps很火，所以對AIOps和自動化做了一些對比。暫以一句話作個區別：AIOps是基于對運維數據（日志類、指標類數據等）的機器學習，進一步解決自動化成本高或無法解決的問題，屬于運維自動化的優化，細化一下區別有：
- 概念
- 實現思路
- 門檻高度
- 如何整合
雖然行業內的智能運維理念十分火熱，但實際落地成效上還主要處于研究階段。從運維工具技術解決方案的角度看，對于智能的解讀也有差別，如果將智能的特點解讀為具備“模擬人，具備自學習，能夠從數據中獲取知識，進而進行預測/決策”來判斷是否智能，智能是自動化的一個輔助手段，自動化才是終態。
建立在這個認識下，我們首先需要通過自動化手段解決痛點，提高工作效率，控制風險；利用運維數字化的建設為運維智能化提供數據、數據計算的能力；在自動化、數字化水平得到一定程度后，再通過人工智能的技術去解決自動化手段解決起來費力或無法解決的局部問題，讓自動化具備智能的水平。
四、體系
1、運維的可持續改進
在管理領域，戴明推出的PDCA循環可以解釋運維體系需要具備的可持續改進的能力條件。
PDCA循環為四個階段，即計劃（plan）、執行（do）、檢查（check）、調整（Action），即在實際工作開展過程中，把各項工作按照作出計劃、計劃實施、檢查實施效果，然后將成功的納入標準，并不斷循環改進的過程。
將這個思路引入到企業的運維體系中則是針對企業業務發展的需求，制定運維體系的整體發展目標，通過不斷改進的措施提高運維工作效率、控制風險，以達到更高效、更優化的資源配置，進而推動業務的發展。要做到運維體系的可持續改進，需要做到以業務導向，整體部局；組織、流程、工具三位一體；不斷審視優化。
1）P：以業務導向、整體部局
運維的最根本作用是保障IT數據的連續性，這里的IT數據包括業務，以及反映業務的數據，或者換句話可以表達為：網絡不斷、系統不癱、數據不丟。隨著業務對IT系統依賴程度越來越高，運維又會承擔更高的期望，也就是運維向運營的轉化，這就需要從業務角度去不斷完善運維，以促進業務為大目標，要明白“IT for IT”是為了更好的“IT for Business”。
有了這個目標，那我們的運維體系的構建就需要與企業業務的發展保持同步，要讓運維體系具備可持續改進的能力。
另外，可持續改進的過程不應該是大拐彎的方式進行改進，而應該不斷的小調整，這就需要確保首先要建立一個整體、全局的運維體系，對運維各項工作做一個整體的規劃，把眼光看得更遠，往往可以更好的把控當前。
2）D：組織、流程、工具的三位一體
可持續改進的運維體系需要讓運維的組織、流程、工具三位一體的作用，比方說：提高工作效率，需要組織的專業化分工、流程的標準化、工具的自動化配合作用；推動業務的發展，既需精細化運維分析、業務服務、運營等維度的工作資源投入，也需要有工具的建設來減少操作性的工作來釋放人力，需要工具提供更高效的數據來源。
這里說的組織主要是從運維人力資源的分工、團隊建設、工作目標導向、運維KPI等；流程是指以成熟的運維方法論為主體，結合企業和外部監管的規章制度、企業業務發展需要，而落地的標準化工作方法；工具既包括狹義運維的“監、管、控”，也包括運營體系所需要數字化、智能化的工具平臺。
3）C+A : 不斷審視優化
在實際工作過程中，審視檢查的過程很容易被忽略，但實際上最大的收獲可能就來自于這個總結、歸納的過程中，這也是可持續改進的運維體系的關鍵所在。
比方說，運維組織可以考慮在必要環節增加橫向的優化團隊；運維流程也需要定期對流程的落地進行分析，并對規章制度進行查漏補缺、刪減不合理的流程規范、調整無法執行的規范要求；工具的建設要不斷的分析工具的使用覆蓋率，如何提高覆蓋率，分析是否提高了運維的效率，還是帶來了反作用等分析，并不斷調整優化工具的建設。
2、轉型思路
在提出可持續的運維體系前，我們先歸納一下運維組織常見的運維痛點，以提出運維轉型的思路，再看看如何構建一個可持續改進的運維體系來支撐運維轉型。前面的運維之痛中提到了 “救火”、“背鍋”、“低價值”、”重復操作“等標簽，我們歸納下己有特點再看轉型：
1）特點
- 被動救火式，以被動保障業務系統運行，日常計劃性工作容易被打斷、擱置；
- 問題驅動式， 以系統可用性、可靠性、業務請求等問題驅動運維工作；
- 操作運維，重復性、操作類點主要工作量的運維模式；
- 經驗式運維，由人工經驗驅動的運維模式，尤其是一些經驗豐富的老員工的離職在短期內會對運維質量帶來一定的沖擊。
- 從被動救火式向主動精細化轉型，專業化分工、主動分析，主動優化，驅動開發，促進DEVOPS的落地；
- 從問題驅動向價值驅動轉型，以企業業務發展目標為主線，業務體驗、服務滿意度、促進業務更好發展；
- 從操作運維向運維開發轉型，通過為運維人員提供運維開發平臺，降低運維開發門檻，快速落地一些緊迫的運維工具，降低操作性、重復性的運維工作；
- 從依靠經驗向智能化驅動運維轉型，結合數據分析、知識庫、機器學習技術促進運維智能化。
圖1.103、構建運維體系
上二節提到運維體系以業務導向，整體部局，組織、流程、工具三位一體，不斷審視優化的建設思路，也提出了“主動精細化”、“價值驅動”、“運維開發”、“智能化運維”的轉型目標，我們再將這些思路分解到組織、流程、工具的建設中，并歸納為：三大建設，十個文化的實踐方法：
1）組織建設：專業化、精細化、運營化
我們將運維實施主體運維組織理解為組織，理想情況下，優秀的組織應該具備有合適的工作、合適的時間、合適的人、合適的行為四個要素組成。即組織要結合企業實際發展方向，制定符合企業、運維組織、個人發展的工作內容，并選擇具備合適的知識、技能、認知、能力的人去完成工作，去實現個人的自我價值。
前面也提到，目前的運維織是一個被動保障業務系統運行，日常計劃性工作容易被打斷、擱置的工作，這種工作狀態下的運維組織往往工作效率不高、容易出現操作風險。
為了讓運維組織具備可持續改進的能力，需要提高運維組織的工作效率，我們需要將運維工作專業化，整合通用性、操作性的工作，提高工作效率，在釋放運維人員工作量后，引導運維人員有計劃、可量化的去做更多分析類、優化類、業務運營的主動性工作。
2）流程建設：標準化、可視化、可量化
大部分運維組織會以內部企業積累的規章制度、外部監管機構的監管要求為基礎，依照ITIL、ISO20000、ITSS.1、DevOps的方法論中的一個或多個組合的方式開展運維工作。這些規章制度、監管要求、方法論的整合、落地、持續改進的過程即為流程建設的過程。
流程建設首先需要標準化流程，要先梳理好己有的流程制度，約定工作的流轉方式，再通過可視化將流程整合在日常工作中，最后通過流程落地數據的分析與工具建設，持續改善提高流程落地的效率，控制操作風險。
3）工具建設：自動化、數字化、智能化、服務化
工具的建設也以可持續改進的思路構建，以整合存量資源、引入成熟或開源技術為主，建立一體化的運維工具體系。
通過體系化的思路實現運維工具（“監、管、控”）的互聯互通，有序建設，實現自動化運維，全面控制風險、提高工作效率、釋放人力；通過建立運維數據分析平臺，實現數字化運營，提供運維數據集中與治理、主動分析的能力；在數字化運營的基礎上通過運維數據挖掘、學習，優化運維或運營場景，向智能化發展；服務化則是以IT服務的方式將運維能力向外輸出。
Copyright 2005-2023 逾仕科技（IT服務外包/系統集成）, All Rights Reserved 備案／許可證號：
滬ICP備09088264號-6