亚洲精品一区二区三区四区高清_国产精品久久久_国产精品久久久久久久9999_国产精品久久久久久_国产麻豆剧传媒精品国产AV_四虎永久在线精品无码

IT運(yùn)維大牛萬字自述：道盡十多年血淚史與轉(zhuǎn)型自救路

時(shí)間：2022/5/26 14:30:30瀏覽次數(shù)：944
運(yùn)維大牛萬字自述：道盡十多年血淚史與轉(zhuǎn)型自救路

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

圖1.1

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

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

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

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

圖1.6
從上述概括可以看出，當(dāng)前運(yùn)維里面的運(yùn)營，與運(yùn)維數(shù)據(jù)密切相關(guān)，需要基于運(yùn)維大數(shù)據(jù)平臺(tái)來提升運(yùn)營質(zhì)量。
為了進(jìn)一步說明運(yùn)營，這里舉兩個(gè)例子：
1）理論
優(yōu)锘科技CEO的陳傲寒在2016年寫過一篇文章《IT：從運(yùn)維到運(yùn)營》，仍是我讀過最好的一篇。全文從企業(yè)、運(yùn)維組織角度出發(fā)分析什么是運(yùn)維、什么是運(yùn)營，再將運(yùn)營分解到不同角色上的理解與落地的方向，全文均是干貨，值得通讀，這里只列出一個(gè)思維導(dǎo)圖。

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

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

圖1.9
6、AIOps與自動(dòng)化的關(guān)系
AIOps很火，所以對(duì)AIOps和自動(dòng)化做了一些對(duì)比。暫以一句話作個(gè)區(qū)別：AIOps是基于對(duì)運(yùn)維數(shù)據(jù)（日志類、指標(biāo)類數(shù)據(jù)等）的機(jī)器學(xué)習(xí)，進(jìn)一步解決自動(dòng)化成本高或無法解決的問題，屬于運(yùn)維自動(dòng)化的優(yōu)化，細(xì)化一下區(qū)別有：
  • 概念 
狹義的自動(dòng)化則提運(yùn)維“監(jiān)、管、控”的工具。AIOps是將AI技術(shù)應(yīng)用到IT運(yùn)維領(lǐng)域，需要有學(xué)習(xí)、類人交互、主動(dòng)決策的特征。
  • 實(shí)現(xiàn)思路 
自動(dòng)化往往以過程為導(dǎo)向，AIOps則以目標(biāo)為導(dǎo)向，通過對(duì)數(shù)據(jù)進(jìn)行學(xué)習(xí)，得到如何實(shí)現(xiàn)目標(biāo)。
  • 門檻高度 
自動(dòng)化手段有豐富的落地解決方案，適合作為替代標(biāo)準(zhǔn)化的運(yùn)維操作性工作，即“面”的問題。AIOps目前仍處起步階段，不是適合替代現(xiàn)有的自動(dòng)化，而是應(yīng)該用于解決自動(dòng)化不能解決或解決成本很高的問題，即“點(diǎn)”的問題。
  • 如何整合
AIOps并非是要取代現(xiàn)有的自動(dòng)化運(yùn)維體系，而是賦予現(xiàn)有體系智能。AIOps就要“學(xué)習(xí)，了解”自動(dòng)化工具 ，并且更好地“使用”這些工具，這個(gè)過程就是深度集成，它的核心是對(duì)這些工具API的自主認(rèn)知和自主使用。
雖然行業(yè)內(nèi)的智能運(yùn)維理念十分火熱，但實(shí)際落地成效上還主要處于研究階段。從運(yùn)維工具技術(shù)解決方案的角度看，對(duì)于智能的解讀也有差別，如果將智能的特點(diǎn)解讀為具備“模擬人，具備自學(xué)習(xí)，能夠從數(shù)據(jù)中獲取知識(shí)，進(jìn)而進(jìn)行預(yù)測/決策”來判斷是否智能，智能是自動(dòng)化的一個(gè)輔助手段，自動(dòng)化才是終態(tài)。
建立在這個(gè)認(rèn)識(shí)下，我們首先需要通過自動(dòng)化手段解決痛點(diǎn)，提高工作效率，控制風(fēng)險(xiǎn)；利用運(yùn)維數(shù)字化的建設(shè)為運(yùn)維智能化提供數(shù)據(jù)、數(shù)據(jù)計(jì)算的能力；在自動(dòng)化、數(shù)字化水平得到一定程度后，再通過人工智能的技術(shù)去解決自動(dòng)化手段解決起來費(fèi)力或無法解決的局部問題，讓自動(dòng)化具備智能的水平。
四、體系
1、運(yùn)維的可持續(xù)改進(jìn)
在管理領(lǐng)域，戴明推出的PDCA循環(huán)可以解釋運(yùn)維體系需要具備的可持續(xù)改進(jìn)的能力條件。
PDCA循環(huán)為四個(gè)階段，即計(jì)劃（plan）、執(zhí)行（do）、檢查（check）、調(diào)整（Action），即在實(shí)際工作開展過程中，把各項(xiàng)工作按照作出計(jì)劃、計(jì)劃實(shí)施、檢查實(shí)施效果，然后將成功的納入標(biāo)準(zhǔn)，并不斷循環(huán)改進(jìn)的過程。
將這個(gè)思路引入到企業(yè)的運(yùn)維體系中則是針對(duì)企業(yè)業(yè)務(wù)發(fā)展的需求，制定運(yùn)維體系的整體發(fā)展目標(biāo)，通過不斷改進(jìn)的措施提高運(yùn)維工作效率、控制風(fēng)險(xiǎn)，以達(dá)到更高效、更優(yōu)化的資源配置，進(jìn)而推動(dòng)業(yè)務(wù)的發(fā)展。要做到運(yùn)維體系的可持續(xù)改進(jìn)，需要做到以業(yè)務(wù)導(dǎo)向，整體部局；組織、流程、工具三位一體；不斷審視優(yōu)化。
1）P：以業(yè)務(wù)導(dǎo)向、整體部局
運(yùn)維的最根本作用是保障IT數(shù)據(jù)的連續(xù)性，這里的IT數(shù)據(jù)包括業(yè)務(wù)，以及反映業(yè)務(wù)的數(shù)據(jù)，或者換句話可以表達(dá)為：網(wǎng)絡(luò)不斷、系統(tǒng)不癱、數(shù)據(jù)不丟。隨著業(yè)務(wù)對(duì)IT系統(tǒng)依賴程度越來越高，運(yùn)維又會(huì)承擔(dān)更高的期望，也就是運(yùn)維向運(yùn)營的轉(zhuǎn)化，這就需要從業(yè)務(wù)角度去不斷完善運(yùn)維，以促進(jìn)業(yè)務(wù)為大目標(biāo)，要明白“IT for IT”是為了更好的“IT for Business”。
有了這個(gè)目標(biāo)，那我們的運(yùn)維體系的構(gòu)建就需要與企業(yè)業(yè)務(wù)的發(fā)展保持同步，要讓運(yùn)維體系具備可持續(xù)改進(jìn)的能力。
另外，可持續(xù)改進(jìn)的過程不應(yīng)該是大拐彎的方式進(jìn)行改進(jìn)，而應(yīng)該不斷的小調(diào)整，這就需要確保首先要建立一個(gè)整體、全局的運(yùn)維體系，對(duì)運(yùn)維各項(xiàng)工作做一個(gè)整體的規(guī)劃，把眼光看得更遠(yuǎn)，往往可以更好的把控當(dāng)前。
2）D：組織、流程、工具的三位一體
可持續(xù)改進(jìn)的運(yùn)維體系需要讓運(yùn)維的組織、流程、工具三位一體的作用，比方說：提高工作效率，需要組織的專業(yè)化分工、流程的標(biāo)準(zhǔn)化、工具的自動(dòng)化配合作用；推動(dòng)業(yè)務(wù)的發(fā)展，既需精細(xì)化運(yùn)維分析、業(yè)務(wù)服務(wù)、運(yùn)營等維度的工作資源投入，也需要有工具的建設(shè)來減少操作性的工作來釋放人力，需要工具提供更高效的數(shù)據(jù)來源。
這里說的組織主要是從運(yùn)維人力資源的分工、團(tuán)隊(duì)建設(shè)、工作目標(biāo)導(dǎo)向、運(yùn)維KPI等；流程是指以成熟的運(yùn)維方法論為主體，結(jié)合企業(yè)和外部監(jiān)管的規(guī)章制度、企業(yè)業(yè)務(wù)發(fā)展需要，而落地的標(biāo)準(zhǔn)化工作方法；工具既包括狹義運(yùn)維的“監(jiān)、管、控”，也包括運(yùn)營體系所需要數(shù)字化、智能化的工具平臺(tái)。
3）C+A : 不斷審視優(yōu)化
在實(shí)際工作過程中，審視檢查的過程很容易被忽略，但實(shí)際上最大的收獲可能就來自于這個(gè)總結(jié)、歸納的過程中，這也是可持續(xù)改進(jìn)的運(yùn)維體系的關(guān)鍵所在。
比方說，運(yùn)維組織可以考慮在必要環(huán)節(jié)增加橫向的優(yōu)化團(tuán)隊(duì)；運(yùn)維流程也需要定期對(duì)流程的落地進(jìn)行分析，并對(duì)規(guī)章制度進(jìn)行查漏補(bǔ)缺、刪減不合理的流程規(guī)范、調(diào)整無法執(zhí)行的規(guī)范要求；工具的建設(shè)要不斷的分析工具的使用覆蓋率，如何提高覆蓋率，分析是否提高了運(yùn)維的效率，還是帶來了反作用等分析，并不斷調(diào)整優(yōu)化工具的建設(shè)。
2、轉(zhuǎn)型思路
在提出可持續(xù)的運(yùn)維體系前，我們先歸納一下運(yùn)維組織常見的運(yùn)維痛點(diǎn)，以提出運(yùn)維轉(zhuǎn)型的思路，再看看如何構(gòu)建一個(gè)可持續(xù)改進(jìn)的運(yùn)維體系來支撐運(yùn)維轉(zhuǎn)型。前面的運(yùn)維之痛中提到了 “救火”、“背鍋”、“低價(jià)值”、”重復(fù)操作“等標(biāo)簽，我們歸納下己有特點(diǎn)再看轉(zhuǎn)型：
1）特點(diǎn)
  • 被動(dòng)救火式，以被動(dòng)保障業(yè)務(wù)系統(tǒng)運(yùn)行，日常計(jì)劃性工作容易被打斷、擱置；
  • 問題驅(qū)動(dòng)式， 以系統(tǒng)可用性、可靠性、業(yè)務(wù)請(qǐng)求等問題驅(qū)動(dòng)運(yùn)維工作；
  • 操作運(yùn)維，重復(fù)性、操作類點(diǎn)主要工作量的運(yùn)維模式；
  • 經(jīng)驗(yàn)式運(yùn)維，由人工經(jīng)驗(yàn)驅(qū)動(dòng)的運(yùn)維模式，尤其是一些經(jīng)驗(yàn)豐富的老員工的離職在短期內(nèi)會(huì)對(duì)運(yùn)維質(zhì)量帶來一定的沖擊。
2）轉(zhuǎn)型
  • 從被動(dòng)救火式向主動(dòng)精細(xì)化轉(zhuǎn)型，專業(yè)化分工、主動(dòng)分析，主動(dòng)優(yōu)化，驅(qū)動(dòng)開發(fā)，促進(jìn)DEVOPS的落地；
  • 從問題驅(qū)動(dòng)向價(jià)值驅(qū)動(dòng)轉(zhuǎn)型，以企業(yè)業(yè)務(wù)發(fā)展目標(biāo)為主線，業(yè)務(wù)體驗(yàn)、服務(wù)滿意度、促進(jìn)業(yè)務(wù)更好發(fā)展；
  • 從操作運(yùn)維向運(yùn)維開發(fā)轉(zhuǎn)型，通過為運(yùn)維人員提供運(yùn)維開發(fā)平臺(tái)，降低運(yùn)維開發(fā)門檻，快速落地一些緊迫的運(yùn)維工具，降低操作性、重復(fù)性的運(yùn)維工作；
  • 從依靠經(jīng)驗(yàn)向智能化驅(qū)動(dòng)運(yùn)維轉(zhuǎn)型，結(jié)合數(shù)據(jù)分析、知識(shí)庫、機(jī)器學(xué)習(xí)技術(shù)促進(jìn)運(yùn)維智能化。
圖1.10
3、構(gòu)建運(yùn)維體系
上二節(jié)提到運(yùn)維體系以業(yè)務(wù)導(dǎo)向，整體部局，組織、流程、工具三位一體，不斷審視優(yōu)化的建設(shè)思路，也提出了“主動(dòng)精細(xì)化”、“價(jià)值驅(qū)動(dòng)”、“運(yùn)維開發(fā)”、“智能化運(yùn)維”的轉(zhuǎn)型目標(biāo)，我們?cè)賹⑦@些思路分解到組織、流程、工具的建設(shè)中，并歸納為：三大建設(shè)，十個(gè)文化的實(shí)踐方法：
1）組織建設(shè)：專業(yè)化、精細(xì)化、運(yùn)營化
我們將運(yùn)維實(shí)施主體運(yùn)維組織理解為組織，理想情況下，優(yōu)秀的組織應(yīng)該具備有合適的工作、合適的時(shí)間、合適的人、合適的行為四個(gè)要素組成。即組織要結(jié)合企業(yè)實(shí)際發(fā)展方向，制定符合企業(yè)、運(yùn)維組織、個(gè)人發(fā)展的工作內(nèi)容，并選擇具備合適的知識(shí)、技能、認(rèn)知、能力的人去完成工作，去實(shí)現(xiàn)個(gè)人的自我價(jià)值。
前面也提到，目前的運(yùn)維織是一個(gè)被動(dòng)保障業(yè)務(wù)系統(tǒng)運(yùn)行，日常計(jì)劃性工作容易被打斷、擱置的工作，這種工作狀態(tài)下的運(yùn)維組織往往工作效率不高、容易出現(xiàn)操作風(fēng)險(xiǎn)。
為了讓運(yùn)維組織具備可持續(xù)改進(jìn)的能力，需要提高運(yùn)維組織的工作效率，我們需要將運(yùn)維工作專業(yè)化，整合通用性、操作性的工作，提高工作效率，在釋放運(yùn)維人員工作量后，引導(dǎo)運(yùn)維人員有計(jì)劃、可量化的去做更多分析類、優(yōu)化類、業(yè)務(wù)運(yùn)營的主動(dòng)性工作。
2）流程建設(shè)：標(biāo)準(zhǔn)化、可視化、可量化
大部分運(yùn)維組織會(huì)以內(nèi)部企業(yè)積累的規(guī)章制度、外部監(jiān)管機(jī)構(gòu)的監(jiān)管要求為基礎(chǔ)，依照ITIL、ISO20000、ITSS.1、DevOps的方法論中的一個(gè)或多個(gè)組合的方式開展運(yùn)維工作。這些規(guī)章制度、監(jiān)管要求、方法論的整合、落地、持續(xù)改進(jìn)的過程即為流程建設(shè)的過程。
流程建設(shè)首先需要標(biāo)準(zhǔn)化流程，要先梳理好己有的流程制度，約定工作的流轉(zhuǎn)方式，再通過可視化將流程整合在日常工作中，最后通過流程落地?cái)?shù)據(jù)的分析與工具建設(shè)，持續(xù)改善提高流程落地的效率，控制操作風(fēng)險(xiǎn)。
3）工具建設(shè)：自動(dòng)化、數(shù)字化、智能化、服務(wù)化
工具的建設(shè)也以可持續(xù)改進(jìn)的思路構(gòu)建，以整合存量資源、引入成熟或開源技術(shù)為主，建立一體化的運(yùn)維工具體系。
通過體系化的思路實(shí)現(xiàn)運(yùn)維工具（“監(jiān)、管、控”）的互聯(lián)互通，有序建設(shè)，實(shí)現(xiàn)自動(dòng)化運(yùn)維，全面控制風(fēng)險(xiǎn)、提高工作效率、釋放人力；通過建立運(yùn)維數(shù)據(jù)分析平臺(tái)，實(shí)現(xiàn)數(shù)字化運(yùn)營，提供運(yùn)維數(shù)據(jù)集中與治理、主動(dòng)分析的能力；在數(shù)字化運(yùn)營的基礎(chǔ)上通過運(yùn)維數(shù)據(jù)挖掘、學(xué)習(xí)，優(yōu)化運(yùn)維或運(yùn)營場景，向智能化發(fā)展；服務(wù)化則是以IT服務(wù)的方式將運(yùn)維能力向外輸出。
 
Copyright 2005-2025 逾仕科技（IT服務(wù)外包/系統(tǒng)集成）, All Rights Reserved 備案／許可證號(hào)： 滬ICP備09088264號(hào)-6
罗定市| 静乐县| 舒兰市| 衡南县| 项城市| 宁武县| 大埔县| 宁海县| 沾化县| 紫阳县| 镇原县| 咸阳市| 鄢陵县| 寿宁县| 普陀区| 乳山市| 沂水县| 青阳县| 江城| 宝丰县| 凤山市| 略阳县| 江西省| 镇康县| 淳安县| 宜川县| 黎城县| 库尔勒市| 天全县| 台南市| 杭锦后旗| 临海市| 鄂托克旗| 明水县| 冷水江市| 淅川县| 汪清县| 洪泽县| 佛学| 扶风县| 大渡口区|