您的(de)當前位置：首頁媒體資訊公司新聞

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

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

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

圖1.1

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

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

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

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

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

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

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

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

咨詢電話(huà)：

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