IT運維大(dà)牛萬字自述：道盡十多年血淚史與轉型自救路

時間：2022/5/26 14:30:30浏覽次數：524
運維大(dà)牛萬字自述：道盡十多年血淚史與轉型自救路

與一(yī)個行業大(dà)牛的朋友交流時，在聽(tīng)到他年輕時在大(dà)廠的一(yī)些關于将工(gōng)作方法升華爲方法論，比如“監、管、控”、“新網點”理念，并推動整個行業建設時爲之一(yī)震。這個觸動讓我(wǒ)(wǒ)有了讓自己的運維知(zhī)識體(tǐ)系建設做第一(yī)次飛躍的打算，即如何将知(zhī)識體(tǐ)系通過一(yī)個主線串起來。
關于這個主線，找過一(yī)些朋友做了交流，比如“風險可控”、“一(yī)體(tǐ)化”、“更高效更優化的資(zī)源配置”、“可擴展性”。由于自己主要身處一(yī)線運維團隊，所以選了“可擴展性”的主線，接下(xià)來打算根據這條主線，不斷完善知(zhī)識體(tǐ)系，目标是體(tǐ)系化的整理知(zhī)識體(tǐ)系，主要從組織、流程、工(gōng)具的可持續整合。
以下(xià)内容，主要是對運維整體(tǐ)的概覽，講講對運維的認識，以及一(yī)些轉型理念思考。
一(yī)、運維不簡單
前陣子，跟一(yī)個項目經理溝通能否提前半天将變更申請提交過來時，這位項目經理很不理解地問我(wǒ)(wǒ)：“你們運維不就是在生(shēng)産環境部署個程序這麽簡單的工(gōng)作嗎(ma)？你們又(yòu)不懂程序，評審不出什麽吧？”
運維多年，對運維的這類認識聽(tīng)過很多，它反映了企業裏不同的組織團隊對運維的認識往往僅限于一(yī)些簡單操作性的工(gōng)作，比如生(shēng)産應用系統在故障時的重啓、應用變更時敲敲命令、平時增删改查數據，或者是辦公室和電(diàn)有關的所有軟硬件的使用問題等等。
那麽如何理解運維呢？百度百科對運維的解釋爲：企業IT部門采用相關的方法、手段、技術、制度、流程和文檔等，對IT軟硬運行環境（軟件環境、網絡環境等）、IT業務系統和IT運維人員(yuán)進行的綜合管理。從百度百科的解釋看，運維崗位需要一(yī)個綜合性的技術與管理能力，需要掌握大(dà)量的方法論與技術棧。
運維狹義“運維技術與資(zī)源”可以定義爲“監、管、控”，技術與資(zī)源主要是支撐運維/運營的質量、效率、成本的平衡。以下(xià)簡單摘錄了運維的一(yī)些能力要求：
  • 運維規範的落地：以ITIL、ISO20000、ITSS.1等方法論，結合外(wài)部監管及内部規範的落地；
  • 監管機構的要求落地：理解、快速響應、落地監管機構的管理要求；
  • 基本保障：配置、監控、應用發布、資(zī)源擴容、事件、問題等；
  • 基礎能力：網絡、服務器、操作系統、數據庫、中(zhōng)間件、JVM、應用等基本使用與調優；
  • 業務服務能力：SLA，服務台、業務咨詢、維護、經驗庫、等支持能力；
  • 可用性管理能力：巡檢、業務系統連續性、可用性，基礎架構及應用系統的高可用、備件冗餘資(zī)源；
  • 風險、安全管理能力：操作、審計、監管風險，漏洞、攻擊管控；
  • 故障管理能力：事件、問題管理水平與能力；
  • 持續交付能力：應用變更、基礎資(zī)源、辦公服務交付能力；
  • 主動優化能力：架構優化、性能響應效率、客戶體(tǐ)驗等；
  • 應急演練：架構高可用、突發事件、業務故障的架構、方案、文檔、人員(yuán)熟練程度等；
  • 業務支撐：數據維護、數據提取、參數維護等；
  • 運行分(fēn)析能力：容量、性能、可用性分(fēn)析等；
  • 運營能力：促進業務痛點的發現與解決、客戶及業務業務體(tǐ)驗等；
  • 成本控制：更好地評估人力、硬件、帶寬、軟件，節省成本；
  • 運維開(kāi)發：運維自動化工(gōng)具的建設，運維開(kāi)發能力的培養；
  • 其它
不同的企業需要運維的能力會有不同的擴展，同進上述能力要求每一(yī)點擴散出來都将是一(yī)個複雜(zá)的技術棧，比如“基礎能力”中(zhōng)的Linux操作系統的内核關系圖（摘自互聯網，圖1.1），或再深入一(yī)些關于MySQL優化（摘自互聯網，圖1.2），需要運維人員(yuán)對技術能力深度的要求。

圖1.1

圖1.2
講到這，肯定會有人說上述的技術棧的能力要求，通常是由于某個運維組織的仍處于專家式運維，自動化程度不夠高導緻。
的确，理論上所有運維操作性、命令的工(gōng)作都可以整合爲經驗，并通過自動化落地實現，現在互聯網企業對外(wài)都宣稱自動化在運維工(gōng)作覆蓋面很高，己經開(kāi)始邁向智能化，AIOps，甚至提出了NoOps的解決方案。
關于這些互聯網企業的自動化對日常運維工(gōng)作真實的覆蓋面暫時無法考究，但以我(wǒ)(wǒ)的經驗看，至少金融企業的自動化覆蓋面還有很長的路要走，且肯定還會很大(dà)一(yī)部分(fēn)工(gōng)作很難自動化，畢竟工(gōng)作類型太多，在有限的投入上隻能集中(zhōng)力氣去(qù)做投入産出比更高的運維自動化。這裏再以一(yī)個運維工(gōng)具思維導圖（圖1.3）簡單列示一(yī)些常規的運維操作，可以看出其實很難有一(yī)套能解決所有運維操作的工(gōng)具平台。

圖1.3
所以我(wǒ)(wǒ)覺得，随着業務要求越來越高、規模越來越大(dà)、監管要求越來越高，縱使外(wài)部如何宣稱自動化、智能化對運維人員(yuán)經驗、技術、管理能力替代，金融企業内的運維還需要認清實際情況，結合企業的整體(tǐ)戰略定位，強調運維團隊在運維管理與技術能力的廣度與深度，再有側重、有先後的實現自動化水平。
在未來一(yī)段時間裏，金融企業的運維崗位仍是一(yī)個複雜(zá)的、綜合性技能的工(gōng)作崗位。
二、運維之痛
近年來，随着運維技術的快速發展，各行業的運維水平在得到了較大(dà)的提升同時，運維圈的分(fēn)享也越來越開(kāi)放(fàng)，從國外(wài)Google的SRE理念，到國内新技術領跑者以及借助于各種運維專題的公衆号、運維大(dà)會有大(dà)量的互聯網、傳統企業的運維組織進行分(fēn)享。
1、組織之痛
前面講過，在企業内部其它團隊對運維的認識通常是簡單操作，出故障時才會找的團隊，随着信息技術的發展與業務的發展，運維組織痛點越來越明顯，企業内對運維組織的不滿的聲音越來越多，反思一(yī)下(xià)原因，分(fēn)外(wài)部客觀因素和内部因素。
1）外(wài)部客觀因素
在當前大(dà)數據時代，金融企業的運維面臨業務規模的不斷擴大(dà)，業務競争越來越激烈，監管要求越來越高，數據中(zhōng)心的規模也越來越高，大(dà)量新技術、開(kāi)源架構的引入取代了傳統穩定的系統架構等等因素影響。
  • 運維組織的角色
絕大(dà)部分(fēn)運維組織都是一(yī)個成本部門，企業對運維組織的重視程度通常不如開(kāi)發組織，更不用說是前台業務部門。這方面造成了運維部門的規模通常增長很慢(màn)，以Google爲例，在《Google SRE運維解密》一(yī)書(shū)中(zhōng)提到，由于Google的數據中(zhōng)心規模急劇擴大(dà)，系統越來越複雜(zá)，而運維人員(yuán)規模又(yòu)跟不上，所以他們的運維組織采用組建SRE的運維開(kāi)發團隊實現自救。
  • 業務對運維服務質量的要求 
越來越多的金融業務己從線下(xià)走到線上， 爲了赢得更多用戶的青睐，一(yī)方面，業務要求更多、體(tǐ)驗更佳的業務性能；另一(yī)方面業務對應用發布的交付速度有了更高的要求。前者會産生(shēng)更複雜(zá)的系統設計，後者需要更高效的應用發布支持，兩者都會對系統響應效率、穩定性帶來影響。
  • 外(wài)部監管要求
長期以來，爲了防範金融風險，監管機構對金融企業保持強監管的方式，十九大(dà)之後，監管對金融企業的信息技術的穩定性、規範性有增無減。在強監管下(xià)，信息系統的穩定性有了進一(yī)步保證，但也給運維組織帶來更高的要求，客觀上也加大(dà)了工(gōng)作量，并由于規範流程帶來的工(gōng)作效率的下(xià)降。
  • 業務并發要求
用戶量的增加，營銷活動不斷推出，需要系統具備更高的并發處理能力要求，企業不斷引入大(dà)量分(fēn)布式、開(kāi)源架構替代傳統相對成熟穩定的架構來滿足業務需要，這些變化都給運維能力帶來挑戰。
  • 數據中(zhōng)心規模增大(dà)
數據中(zhōng)心的多中(zhōng)心建設，雲化，去(qù)IOE，分(fēn)布式架構的引入使得應用系統規模成倍地增大(dà)。
2）内部因素
網上有一(yī)個調查數據，在整個運維成本的分(fēn)配中(zhōng)，軟硬件和網絡設備的維護成本占 30%，維護服務成本占30%，内部運維人力成本則占了40%。這裏的人力成本包括現在維護、培訓、流失與引入等成本，如果将維護服務成本也納入到人力成本之上，則人力這一(yī)塊的成本将上升爲70%，影響這個人力成本的因素主要有：
  • 運維能力模型
ITIL、ISO20000、ITSS.1是運維領域中(zhōng)比較成體(tǐ)系化的方法論（目前更爲火(huǒ)爆的DevOps更傾向于是一(yī)種思路），其中(zhōng)隻有ITSS.1提出了運維能力模型的概念，但在量化運維人員(yuán)具體(tǐ)能力的實際操作上也比較難落地。也就是說你很難評價一(yī)個運維人員(yuán)如何做才是做得優，如何是中(zhōng)，如何差，這些評價通常比較主觀，這也客戶觀影響了運維人員(yuán)不斷增加技能、優化工(gōng)作效率的動力。
  • 運維規範化
組織擴大(dà)到一(yī)定規模，以口口相傳的傳授，結合個體(tǐ)責任心、工(gōng)作習慣爲主的方式容易出現操作風險，且無法進行量化績效管理，管理規範無法落地。
  • 運維精細化程度
組織通常是從縱向職能型的方式形成，這種方式能培養全能型、經驗豐富的專家式人才，這些專家式人才利用經驗能快速解決職責下(xià)的常規問題，且效率比較高，适合小(xiǎo)型的組織。随着組織的不斷壯大(dà)，面對的問題越來越複雜(zá)，技術要求越來越多，一(yī)方面很多人不能滿足這種專家式人才的要求；一(yī)方面也會産生(shēng)很多重複性的工(gōng)作；同時對于人員(yuán)流失帶來的影響比較大(dà)。這時候就需要将縱向工(gōng)作精細化，再輔助橫向人員(yuán)對工(gōng)作進行持續的優化。
  • 運維目标
運維的目标往往以被動式的目标爲主，被動處理故障、被動解決問題、被動提供應用交付、被動節省成本等，這種被動式的運維目标導緻計劃性工(gōng)作不夠，缺乏持續不斷的自我(wǒ)(wǒ)優化，主動提高效率、質量，降低成本，并由運維向主動運營目标去(qù)轉變。
  • 自動化能力
IT軟硬件體(tǐ)量龐大(dà)，且增長迅速，手工(gōng)操作的機器任務太多；運維數據越來越多；故障定位越來越難，人工(gōng)經驗依賴高；監控手段不夠及時、全面；應用發布、資(zī)源交付效率低下(xià)；沒有主動的容量、性能分(fēn)析、體(tǐ)驗分(fēn)析能力……這些都是常見的一(yī)些痛點。
2、個體(tǐ)之痛
作爲運維組織中(zhōng)的運維人員(yuán)同樣面臨不少痛點，有來自工(gōng)作時間、工(gōng)作壓力、學習壓力、職業發展等等，以下(xià)簡單羅列：
  • 7*24小(xiǎo)時制的工(gōng)作時間
運維人員(yuán)的節假日是不完整的，通常節假日需要運維值班保障或在家通過VPN遠程操作、或和家人團聚時還遠程指導進行故障應急；運維人員(yuán)上班時間不同普通工(gōng)作，爲了不影響業務，應用發布、基礎設施變更、演練等工(gōng)作都會放(fàng)到晚上，對客的業務系統還可能要安排到深夜。這種随時可能發生(shēng)，随處理可能要處理的工(gōng)作狀态是其它行業所不具備的痛點。
  • 高度壓力的工(gōng)作
“如履薄冰”很好的形容了運維的工(gōng)作狀态，因爲任務一(yī)個生(shēng)産操作都可能對業務帶來影響，所以運維的操作必須十分(fēn)謹慎。同時在運維故障處理過程中(zhōng)，運維人員(yuán)需要面臨着來自業務、客戶、開(kāi)發、領導的各層的壓力下(xià)，冷靜地完成故障處理，是一(yī)個高壓的工(gōng)作狀态。
  • 被動的工(gōng)作
經常會有人形容運維就是一(yī)個“消防員(yuán)”的工(gōng)作，也就是被動救火(huǒ)的工(gōng)作，這個形容很貼切，在缺乏一(yī)些主動分(fēn)析、優化、預測性的工(gōng)作的背景下(xià)，運維組織的大(dà)部分(fēn)工(gōng)作是以被動爲主，是負責應急救火(huǒ)、打掃戰場、負責收尾的那群默默的人。
  • 對工(gōng)作的認識
運維的人通常會認爲自己就是一(yī)個背鍋的角色，開(kāi)發程序問題、硬件問題、系統軟件問題、業務需求問題都需要運維去(qù)解決，而且這些問題對可用性的影響還要運維來承擔，這是運維特有的痛點。
  • 職業壓力
運維工(gōng)作一(yī)方面主要是和機器或系統軟件打交道，所以相對于開(kāi)發、項目管理等IT崗位，轉型機會的面比較窄；同時，運維崗位中(zhōng)重複操作性的工(gōng)作占比多，如缺乏引導容易讓運維人員(yuán)産生(shēng)麻木的狀态，失去(qù)持續改善的動力；另外(wài)，前面也提到運維需要掌握的技能和管理理念很多，對于運維人員(yuán)的學習能力要求很高。
三、自救
1、SRE
SRE這個名詞最早是從《Google SRE 運維解密》一(yī)書(shū)中(zhōng)獲得，全稱是Site Reliability Engineering，翻譯過來就是：站點可靠性工(gōng)程師。Google對SRE的職責描述爲：确保站點的可用，爲了達到這個目的，一(yī)方面他需要對站點涉及的系統、組件熟悉，也要關注生(shēng)産運行時的狀态。
爲此，他需要自開(kāi)發并維護很多工(gōng)具和系統支撐系統的運行，比如自動化發布系統、監控系統、日志(zhì)系統、服務器資(zī)源分(fēn)配和編排等。SRE是一(yī)個綜合素質很高的全能手，如果對他的能力進行分(fēn)解主要有三塊：
  • 熟悉系統架構與運行狀态
SRE需要懂服務器基礎架構、操作系統、網絡、中(zhōng)間件容器、常用編程語言、全局的架構意識、非常強的問題分(fēn)析能力、極高的抗壓能力（以便沉着高效地排障），他們還需要懂性能調優理論。爲了保證系統架構的高可用，SRE甚至會有意識地破壞自己的系統，以提高系統可用性。
  • 熟悉運維涉及的管理方法
SRE需根據企業自身發展需要，清楚運維涉及的各項工(gōng)作的流程方法論，比如故障處理、應用發布、可用性管理等等，SRE十分(fēn)重視運維流程的持續改善，比如對故障的追丁溯源，懷疑一(yī)切的方式持續改進。
  • 運維開(kāi)發+産品經理
SRE在運行保障過程中(zhōng)的手段更加自動化，更高效，這種高效來源于自動化工(gōng)具、監控工(gōng)具的支撐，且他們還需要是這些工(gōng)具的主要開(kāi)發者，他們要不斷優化和調整，使整個工(gōng)具箱使起來更加得心應手。爲此SRE有一(yī)個50%的理念，就是50%用于日常保障，50%用于項目性的工(gōng)作，這個項目性的工(gōng)作主要體(tǐ)現在運維開(kāi)發與運維産品經理的角色。
2、運維開(kāi)發
關于運維開(kāi)發的理解主要體(tǐ)現在運維工(gōng)具層面，不同的組織有不同的理解，通常有三類：
  • 完全自建
運維開(kāi)發團隊利用開(kāi)源技術結合自身需要進行一(yī)定的二次開(kāi)發，這種方式在互聯網企業比較流行，具體(tǐ)的成效大(dà)小(xiǎo)與何時能起來收效與對這個運維開(kāi)發團隊的整體(tǐ)規劃或資(zī)源投入有關；
  • 外(wài)購開(kāi)發資(zī)源或工(gōng)具産品
運維開(kāi)發團隊主要是結合企業痛點承擔産品經理的角色，設計、跟進、推廣工(gōng)具，這種方式常出現在傳統的企業，尤其适用于投入運維開(kāi)發人員(yuán)比較少的企業，這種方式是投入收效快，但是對外(wài)部資(zī)源依賴比較大(dà)，不利于後續持續建設；
  • 外(wài)購與自建相結合
運維開(kāi)發團隊在整個工(gōng)具體(tǐ)系下(xià)，針對部分(fēn)組件選擇性的引入一(yī)些成熟的工(gōng)具體(tǐ)系，同時要求這類成熟的工(gōng)具需要開(kāi)放(fàng)一(yī)定的接口或源碼支持，對于一(yī)些與公司個性強的環節采用自研的方式。這種方式目前逐漸被一(yī)些傳統企業，比如金融企業所接受。
總的來說，不管選用上面哪一(yī)種方式，運維開(kāi)發團隊都應該有一(yī)個整體(tǐ)、統一(yī)的一(yī)體(tǐ)化工(gōng)具建設規劃，并在建設過程中(zhōng)始終保持對運維工(gōng)具體(tǐ)系的掌控能力，并在工(gōng)具體(tǐ)系的上層爲其它運維人員(yuán)提供簡易的、可創造性的“開(kāi)發能力”，比如所見即所得的工(gōng)具可視化、可定制的運維報表、拖拉拽方式的流程及腳本組件的拼裝等運維開(kāi)發方式。
3、DevOps
1）DevOps概述
DevOps一(yī)詞的來自于Development和Operations的組合，突出重視軟件開(kāi)發人員(yuán)和運維人員(yuán)的溝通合作，通過自動化流程來使得軟件構建、測試、發布更加快捷、頻(pín)繁和可靠，他是一(yī)種方法論，包含一(yī)套基本原則和實踐，工(gōng)具是爲有效落實這套方法論提供支持。
在軟件全生(shēng)命周期管理過程中(zhōng)，包括開(kāi)發、構建、測試、發布、運營，在這個全生(shēng)命周期管理過程中(zhōng)出現了開(kāi)發組織與運維組織的部門牆，這是因爲開(kāi)發組織關注需求的實現，希望盡快實現變更；運維組織關注系統運行穩定，而變更又(yòu)往往是生(shēng)産應用不穩定的原因。
DevOps方法論的出現主要是爲了解決這個協作問題，以讓軟件交付更加高效，質量更高，生(shēng)産端更加敏捷，生(shēng)産運行過程中(zhōng)的問題能更加高效的反饋到開(kāi)發，形成一(yī)個全生(shēng)命周期的閉環。随着業務對運維交付能力的時效性要求越來越高，運維組織面臨“吃力不讨好”的問題：
  • 吃力： 花費(fèi)大(dà)量時間在應用部署的操作性工(gōng)作中(zhōng)。這部分(fēn)部署變更包括新功能的上線以及修複功能BUG兩方法。
  • 不讨好： 操作性的工(gōng)作越大(dà)，帶來的操作風險越大(dà)，有這樣一(yī)個統計，如果手工(gōng)運行5條命令的情況下(xià)，成功部署的概率就已跌至86%；如需手工(gōng)運行55條命令，成功部署的概率将跌至22%；如需手工(gōng)運行100條命令，成功部署的概率将趨近于0（僅2%）。
DevOps鼓勵軟件開(kāi)發者和IT運維人員(yuán)之間所進行的溝通、協作、集成和自動化，借此有助于改善雙方在交付軟件過程中(zhōng)的速度和質量。側重于通過标準化開(kāi)發環境和自動化交付流程改善交付工(gōng)作的可預測性、效率、安全性，以及可維護性。
2）運維實踐中(zhōng)的DevOps
可以從工(gōng)具鏈、組織文化、自動化、敏捷看闆等角度講DevOps，比如在目前比較活躍的DevOps36計，基本覆蓋了運維領域很大(dà)的一(yī)塊：

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

圖1.5
從運維的交付場景看，主要是資(zī)源交付與應用交付，其中(zhōng)資(zī)源交付以IaaS、PaaS雲的建設爲主，通過雲管平台的工(gōng)具鏈将基礎設施、網絡、硬件、虛拟化、容器、運行中(zhōng)間件等系統軟硬件交付能力自動化，并通過CMDB整合DevOps能力環之上的應用場景，實現資(zī)源的快速交付。
資(zī)源交付能力主要在于IaaS、PaaS層的雲平台标準化、自動化、平台擴展性等方面的建設程度。應用的快速交付比資(zī)源交付更爲複雜(zá)，應用交付涉及全鏈路的整合，鏈路上的節點越多落地的難度越大(dà)，因爲它不僅涉及技術，還涉及理念的認同與聚焦。
應用交付能力要實現，最簡單的技術棧工(gōng)具需要CMDB、應用發布工(gōng)具、應用版本庫、監控工(gōng)具，上述工(gōng)具對内要與雲平台對接，對外(wài)要提供接口給開(kāi)發、測試工(gōng)具。當然如開(kāi)發、測試也能和運維使用同一(yī)套發布工(gōng)具、應用版本庫則效果更好，不過，實際實施過程中(zhōng)組織之間還是會有不少沖突，比如開(kāi)發關注源代碼版本管理，測試、運維關注運行版本的管理，需各個組織共同付出共建技術鏈。
4、運營
關于運維圈裏運營的概念，以轉型口号喊得比較多，我(wǒ)(wǒ)對運維當中(zhōng)的運營有業務運營與技術運營兩個維度的理解。業務運營是通過功能優化或工(gōng)具開(kāi)發等方式解決業務工(gōng)作痛點，或通過運行分(fēn)析發現影響業務開(kāi)展的因素，并推動相關的優化，最終提升業務能力。技術運營則主要從技術角度去(qù)降低IT成本，提升IT服務質量與效率。具體(tǐ)的實施内容可以考慮如下(xià)：

圖1.6
從上述概括可以看出，當前運維裏面的運營，與運維數據密切相關，需要基于運維大(dà)數據平台來提升運營質量。
爲了進一(yī)步說明運營，這裏舉兩個例子：
1）理論
優锘科技CEO的陳傲寒在2016年寫過一(yī)篇文章《IT：從運維到運營》，仍是我(wǒ)(wǒ)讀過最好的一(yī)篇。全文從企業、運維組織角度出發分(fēn)析什麽是運維、什麽是運營，再将運營分(fēn)解到不同角色上的理解與落地的方向，全文均是幹貨，值得通讀，這裏隻列出一(yī)個思維導圖。

圖1.7
2）實戰
參加過一(yī)場騰訊QQ關于DevOps的培訓，對于它們提到的一(yī)個自救方式的運營手段很有印象。那就是在騰訊QQ逐漸被微信團隊替代過程中(zhōng)，QQ技術運維團隊是如何通過各種方式去(qù)爲企業帶來效益，比如他們通過運維分(fēn)析，得到如何更加合理的使用帶寬、資(zī)源，大(dà)大(dà)減少了公司在基礎設施方面的投入。
在金融企業中(zhōng)，也同樣有很多空間可以去(qù)嘗試，比如分(fēn)析業務痛點，爲業務提供快速的策略性的工(gōng)具來替代重複操作性的業務操作；通過運維數據分(fēn)析，發現客戶體(tǐ)驗方面的痛點，推動業務功能的優化等等。
4、AIOps
AIOps這個詞最早是在2016年由Gartner提出（當然國内很多廠商(shāng)也提出它們早幾年也提出了這個理念）。AIOps是Algorithmic IT Operations的縮寫，是基于算法的IT運維，即通過使用統計分(fēn)析和機器學習的方法處理從各IT設備、業務應用、運維工(gōng)具收集的數據，從而加強增強運維自動化能力，以便更快、更有效、更全面地自動化效果。以下(xià)是Gartner提出AIOps的一(yī)張圖：

圖1.8
Gartner通過使用圖1.9中(zhōng)的圖解釋了AIOps平台的工(gōng)作原理。AIOps有兩個主要組件：大(dà)數據和機器學習。它需要從孤立的IT數據中(zhōng)移除，以便将大(dà)量數據平台内的觀察數據（例如監控系統和作業日志(zhì)中(zhōng)發現的數據）與參與數據（通常在故障單，事件和事件記錄中(zhōng)找到）相結合。
AIO然後針對組合的IT數據實施全面的分(fēn)析和機器學習（ML）策略。期望的結果是持續的見解，通過自動化産生(shēng)持續的改進和修複。AIO可以被認爲是核心IT功能的持續集成和部署（CI/CD）。
  • 廣泛和多樣化的IT數據源，如日志(zhì)類的設備日志(zhì)、系統日志(zhì)，應用日志(zhì)、運維操作日志(zhì)；指标類的監控性能指标、事件。
  • 具備針對海量數據處理與分(fēn)析的運算平台，能夠從現有的IT數據生(shēng)成新的數據和元數據、計算和分(fēn)析還消除噪音，識别模式或趨勢，隔離(lí)可能的原因，揭示潛在問題，并實現其他IT特定目标。
  • 算法 ，充分(fēn)利用IT領域的專業知(zhī)識，更适當，高效地處理數據。
  • 機器學習 ，從根據算法分(fēn)析的輸出和引入系統的新數據自動更改或創建新的算法。
  • 可視化 ，以易于消費(fèi)的方式向IT行動提供洞察和建議，以促進理解和行動。
  • 自動化 ，其使用分(fēn)析和機器學習産生(shēng)的結果自動創建和應用響應或改進已識别的問題。
關于分(fēn)層的思路，Gartner這樣理解：

圖1.9
6、AIOps與自動化的關系
AIOps很火(huǒ)，所以對AIOps和自動化做了一(yī)些對比。暫以一(yī)句話(huà)作個區别：AIOps是基于對運維數據（日志(zhì)類、指标類數據等）的機器學習，進一(yī)步解決自動化成本高或無法解決的問題，屬于運維自動化的優化，細化一(yī)下(xià)區别有：
  • 概念 
狹義的自動化則提運維“監、管、控”的工(gōng)具。AIOps是将AI技術應用到IT運維領域，需要有學習、類人交互、主動決策的特征。
  • 實現思路 
自動化往往以過程爲導向，AIOps則以目标爲導向，通過對數據進行學習，得到如何實現目标。
  • 門檻高度 
自動化手段有豐富的落地解決方案，适合作爲替代标準化的運維操作性工(gōng)作，即“面”的問題。AIOps目前仍處起步階段，不是适合替代現有的自動化，而是應該用于解決自動化不能解決或解決成本很高的問題，即“點”的問題。
  • 如何整合
AIOps并非是要取代現有的自動化運維體(tǐ)系，而是賦予現有體(tǐ)系智能。AIOps就要“學習，了解”自動化工(gōng)具 ，并且更好地“使用”這些工(gōng)具，這個過程就是深度集成，它的核心是對這些工(gōng)具API的自主認知(zhī)和自主使用。
雖然行業内的智能運維理念十分(fēn)火(huǒ)熱，但實際落地成效上還主要處于研究階段。從運維工(gōng)具技術解決方案的角度看，對于智能的解讀也有差别，如果将智能的特點解讀爲具備“模拟人，具備自學習，能夠從數據中(zhōng)獲取知(zhī)識，進而進行預測/決策”來判斷是否智能，智能是自動化的一(yī)個輔助手段，自動化才是終态。
建立在這個認識下(xià)，我(wǒ)(wǒ)們首先需要通過自動化手段解決痛點，提高工(gōng)作效率，控制風險；利用運維數字化的建設爲運維智能化提供數據、數據計算的能力；在自動化、數字化水平得到一(yī)定程度後，再通過人工(gōng)智能的技術去(qù)解決自動化手段解決起來費(fèi)力或無法解決的局部問題，讓自動化具備智能的水平。
四、體(tǐ)系
1、運維的可持續改進
在管理領域，戴明推出的PDCA循環可以解釋運維體(tǐ)系需要具備的可持續改進的能力條件。
PDCA循環爲四個階段，即計劃（plan）、執行（do）、檢查（check）、調整（Action），即在實際工(gōng)作開(kāi)展過程中(zhōng)，把各項工(gōng)作按照作出計劃、計劃實施、檢查實施效果，然後将成功的納入标準，并不斷循環改進的過程。
将這個思路引入到企業的運維體(tǐ)系中(zhōng)則是針對企業業務發展的需求，制定運維體(tǐ)系的整體(tǐ)發展目标，通過不斷改進的措施提高運維工(gōng)作效率、控制風險，以達到更高效、更優化的資(zī)源配置，進而推動業務的發展。要做到運維體(tǐ)系的可持續改進，需要做到以業務導向，整體(tǐ)部局；組織、流程、工(gōng)具三位一(yī)體(tǐ)；不斷審視優化。
1）P：以業務導向、整體(tǐ)部局
運維的最根本作用是保障IT數據的連續性，這裏的IT數據包括業務，以及反映業務的數據，或者換句話(huà)可以表達爲：網絡不斷、系統不癱、數據不丢。随着業務對IT系統依賴程度越來越高，運維又(yòu)會承擔更高的期望，也就是運維向運營的轉化，這就需要從業務角度去(qù)不斷完善運維，以促進業務爲大(dà)目标，要明白(bái)“IT for IT”是爲了更好的“IT for Business”。
有了這個目标，那我(wǒ)(wǒ)們的運維體(tǐ)系的構建就需要與企業業務的發展保持同步，要讓運維體(tǐ)系具備可持續改進的能力。
另外(wài)，可持續改進的過程不應該是大(dà)拐彎的方式進行改進，而應該不斷的小(xiǎo)調整，這就需要确保首先要建立一(yī)個整體(tǐ)、全局的運維體(tǐ)系，對運維各項工(gōng)作做一(yī)個整體(tǐ)的規劃，把眼光看得更遠，往往可以更好的把控當前。
2）D：組織、流程、工(gōng)具的三位一(yī)體(tǐ)
可持續改進的運維體(tǐ)系需要讓運維的組織、流程、工(gōng)具三位一(yī)體(tǐ)的作用，比方說：提高工(gōng)作效率，需要組織的專業化分(fēn)工(gōng)、流程的标準化、工(gōng)具的自動化配合作用；推動業務的發展，既需精細化運維分(fēn)析、業務服務、運營等維度的工(gōng)作資(zī)源投入，也需要有工(gōng)具的建設來減少操作性的工(gōng)作來釋放(fàng)人力，需要工(gōng)具提供更高效的數據來源。
這裏說的組織主要是從運維人力資(zī)源的分(fēn)工(gōng)、團隊建設、工(gōng)作目标導向、運維KPI等；流程是指以成熟的運維方法論爲主體(tǐ)，結合企業和外(wài)部監管的規章制度、企業業務發展需要，而落地的标準化工(gōng)作方法；工(gōng)具既包括狹義運維的“監、管、控”，也包括運營體(tǐ)系所需要數字化、智能化的工(gōng)具平台。
3）C+A : 不斷審視優化
在實際工(gōng)作過程中(zhōng)，審視檢查的過程很容易被忽略，但實際上最大(dà)的收獲可能就來自于這個總結、歸納的過程中(zhōng)，這也是可持續改進的運維體(tǐ)系的關鍵所在。
比方說，運維組織可以考慮在必要環節增加橫向的優化團隊；運維流程也需要定期對流程的落地進行分(fēn)析，并對規章制度進行查漏補缺、删減不合理的流程規範、調整無法執行的規範要求；工(gōng)具的建設要不斷的分(fēn)析工(gōng)具的使用覆蓋率，如何提高覆蓋率，分(fēn)析是否提高了運維的效率，還是帶來了反作用等分(fēn)析，并不斷調整優化工(gōng)具的建設。
2、轉型思路
在提出可持續的運維體(tǐ)系前，我(wǒ)(wǒ)們先歸納一(yī)下(xià)運維組織常見的運維痛點，以提出運維轉型的思路，再看看如何構建一(yī)個可持續改進的運維體(tǐ)系來支撐運維轉型。前面的運維之痛中(zhōng)提到了 “救火(huǒ)”、“背鍋”、“低價值”、”重複操作“等标簽，我(wǒ)(wǒ)們歸納下(xià)己有特點再看轉型：
1）特點
  • 被動救火(huǒ)式，以被動保障業務系統運行，日常計劃性工(gōng)作容易被打斷、擱置；
  • 問題驅動式， 以系統可用性、可靠性、業務請求等問題驅動運維工(gōng)作；
  • 操作運維，重複性、操作類點主要工(gōng)作量的運維模式；
  • 經驗式運維，由人工(gōng)經驗驅動的運維模式，尤其是一(yī)些經驗豐富的老員(yuán)工(gōng)的離(lí)職在短期内會對運維質量帶來一(yī)定的沖擊。
2）轉型
  • 從被動救火(huǒ)式向主動精細化轉型，專業化分(fēn)工(gōng)、主動分(fēn)析，主動優化，驅動開(kāi)發，促進DEVOPS的落地；
  • 從問題驅動向價值驅動轉型，以企業業務發展目标爲主線，業務體(tǐ)驗、服務滿意度、促進業務更好發展；
  • 從操作運維向運維開(kāi)發轉型，通過爲運維人員(yuán)提供運維開(kāi)發平台，降低運維開(kāi)發門檻，快速落地一(yī)些緊迫的運維工(gōng)具，降低操作性、重複性的運維工(gōng)作；
  • 從依靠經驗向智能化驅動運維轉型，結合數據分(fēn)析、知(zhī)識庫、機器學習技術促進運維智能化。
圖1.10
3、構建運維體(tǐ)系
上二節提到運維體(tǐ)系以業務導向，整體(tǐ)部局，組織、流程、工(gōng)具三位一(yī)體(tǐ)，不斷審視優化的建設思路，也提出了“主動精細化”、“價值驅動”、“運維開(kāi)發”、“智能化運維”的轉型目标，我(wǒ)(wǒ)們再将這些思路分(fēn)解到組織、流程、工(gōng)具的建設中(zhōng)，并歸納爲：三大(dà)建設，十個文化的實踐方法：
1）組織建設：專業化、精細化、運營化
我(wǒ)(wǒ)們将運維實施主體(tǐ)運維組織理解爲組織，理想情況下(xià)，優秀的組織應該具備有合适的工(gōng)作、合适的時間、合适的人、合适的行爲四個要素組成。即組織要結合企業實際發展方向，制定符合企業、運維組織、個人發展的工(gōng)作内容，并選擇具備合适的知(zhī)識、技能、認知(zhī)、能力的人去(qù)完成工(gōng)作，去(qù)實現個人的自我(wǒ)(wǒ)價值。
前面也提到，目前的運維織是一(yī)個被動保障業務系統運行，日常計劃性工(gōng)作容易被打斷、擱置的工(gōng)作，這種工(gōng)作狀态下(xià)的運維組織往往工(gōng)作效率不高、容易出現操作風險。
爲了讓運維組織具備可持續改進的能力，需要提高運維組織的工(gōng)作效率，我(wǒ)(wǒ)們需要将運維工(gōng)作專業化，整合通用性、操作性的工(gōng)作，提高工(gōng)作效率，在釋放(fàng)運維人員(yuán)工(gōng)作量後，引導運維人員(yuán)有計劃、可量化的去(qù)做更多分(fēn)析類、優化類、業務運營的主動性工(gōng)作。
2）流程建設：标準化、可視化、可量化
大(dà)部分(fēn)運維組織會以内部企業積累的規章制度、外(wài)部監管機構的監管要求爲基礎，依照ITIL、ISO20000、ITSS.1、DevOps的方法論中(zhōng)的一(yī)個或多個組合的方式開(kāi)展運維工(gōng)作。這些規章制度、監管要求、方法論的整合、落地、持續改進的過程即爲流程建設的過程。
流程建設首先需要标準化流程，要先梳理好己有的流程制度，約定工(gōng)作的流轉方式，再通過可視化将流程整合在日常工(gōng)作中(zhōng)，最後通過流程落地數據的分(fēn)析與工(gōng)具建設，持續改善提高流程落地的效率，控制操作風險。
3）工(gōng)具建設：自動化、數字化、智能化、服務化
工(gōng)具的建設也以可持續改進的思路構建，以整合存量資(zī)源、引入成熟或開(kāi)源技術爲主，建立一(yī)體(tǐ)化的運維工(gōng)具體(tǐ)系。
通過體(tǐ)系化的思路實現運維工(gōng)具（“監、管、控”）的互聯互通，有序建設，實現自動化運維，全面控制風險、提高工(gōng)作效率、釋放(fàng)人力；通過建立運維數據分(fēn)析平台，實現數字化運營，提供運維數據集中(zhōng)與治理、主動分(fēn)析的能力；在數字化運營的基礎上通過運維數據挖掘、學習，優化運維或運營場景，向智能化發展；服務化則是以IT服務的方式将運維能力向外(wài)輸出。
 
IT服務外(wài)包
應急服務
遠程支持
駐場服務
專項運維
IT采購
服務器
終端電(diàn)腦
操作系統
應用軟件
網絡設備
外(wài)設設備
多媒體(tǐ)設備
企業郵箱
工(gōng)具軟件
存儲備份設備
企業雲
弱電(diàn)工(gōng)程
綜合布線
機房建設
視頻(pín)監控
多媒體(tǐ)會議室
門禁考勤
安防報警
一(yī)卡通
拼接屏
視頻(pín)會議
系統集成
桌面虛拟化
服務器虛拟化
應用虛拟化
數據存儲備份
VPN專網
數據共享
服務器托管
網絡改造
數據加密
應用系統集成
網絡安全
邊界安全
終端安全
數據安全
威脅檢測
訪問安全
等級保護

咨詢電(diàn)話(huà)：

021-51697581
掃一(yī)掃，關注官方微信
實時掌握逾仕最新動态
Copyright 2005-2024 逾仕科技（IT服務外(wài)包/系統集成）, All Rights Reserved 備案／許可證号：