2.1.3 技術

隨著企業IT信息化、數字化的進程不斷推進，企業對IT系統的依賴程度與日俱增。面對越來越多的IT系統，IT運維對象倍增，各種異構的IT資源的管理成為企業運維的挑戰，IT運維領域的技術發展也隨之發生翻天覆地的變化，如何在日常IT運維管理工作中使用新一代的運維技術成為新的命題。本節將從IT運維技術的演進出發，講述運維模式、工具、協作、管理等的變化。

1.IT技術架構的演進

（1）IOE架構

技術架構是IT架構的地基。隨著技術架構的演進，業務使用的IT資源對象也隨之變化。在十年前，企業大多數仍采用IOE的傳統架構，以IBM為代表的商用小型機、Oracle為代表的商用數據庫、EMC為代表的高端存儲設計是各個企業IT體系的標配，機房里清一色的IBM小型機，業務應用系統數據庫千篇一律都是Oracle企業級數據庫。回過頭細想一番，為什么當時的企業都傾向于采用這種IOE架構呢？其實就當時而言，企業采用IOE是迫不得已，即使“去IOE”較早的阿里巴巴，最初的技術架構也是采用IOE。當時連分布式技術都未誕生，IOE這種國外商用產品確實比同期其他廠商的產品成熟得多，其單機穩定性和性能非常高。通常情況下，一臺IBM小型機可以正常運行多年，即使不停機，也不會出現任務故障，其穩定性是保障業務服務非常核心的價值。

此外，從技術因素考慮，在當時IT系統運維模式基本還屬于人肉運維的年代，系統技術棧構成的單一也便于運維團隊的組建和培養。在當時，幾乎每個中大型企業的運維團隊都會有專門運維Oracle的技術專家，負責企業數據庫的日常運維問題的處理。

隨著企業的高速發展，IOE這種傳統集中式系統架構達到性能瓶頸時往往只能垂直擴展，基本已無法適應業務的需求。近年來，互聯網企業在技術架構上不斷深入研究，為IT行業帶來了全新的技術模式變革。互聯網企業掀起這場轟轟烈烈的技術革命，無非出于以下幾個因素的考慮。

1）成本。成本是企業不得不考慮的重要因素，一臺小型機的價格相當于多臺x86服務器，這對于企業的成本投入來說是非常高的。

2）靈活性。行業競爭對敏態業務的需求，要求技術架構能快速響應業務需求變更的落地，傳統IOE集中式架構已難以實現。

3）擴展性。因只能垂直擴展，傳統的IOE架構已無法滿足激增的業務資源容量的需求。敏態業務需要更為彈性、更易于擴展的水平式擴展的云化技術架構。

4）自主可控。傳統IOE廠商是閉源商用軟硬件設備，無法響應企業自主可控的持續運營發展需求。在國家安全可控的一系列政策推動作用下，企業需要更為開放的技術環境或平臺為其不同的業務需求生成各式各樣的場景工具。

（2）互聯網架構

隨著技術的快速發展，新一代的云化、分布式、開源等技術架構開始進入傳統企業的視線。同時，在國家政策的強有力推動下，各行各業開始意識到新一代互聯網架構的重要性，紛紛開始采用新的技術進行試點改造，其中互聯網行業在技術的應用上也走在前沿。互聯網的技術架構特點歸納如下。

1）采用x86服務器和開源軟件。基本思路都是用大量的國產x86服務器代替昂貴的IBM小型機和EMC存儲，用開源的軟件代替閉源的商用軟件，如用開源數據庫MySQL代替Oracle，節省大量采購、取得許可證以及原廠維護所帶來的成本。

2）分布式。應用部署架構采用分布式集群架構分擔單機的計算壓力，通過分布式任務合理利用多臺機器性能，使其可以匹配上單臺小型機的處理能力。

3）系統穩定性。由于x86服務器在系統穩定性上比小型機差，因此在應用部署架構上通常會增加必要的冗余設計，以集群的方式提供服務，在單個設備或組件不可用的情況下，業務服務仍保持可用，避免了單點故障。

4）高度可擴展。為適應業務的高速發展、用戶量的數量級倍增，在架構設計上采用橫向的擴展方式，可以隨時增加資源以達成更大容量、更高支撐的用戶并發量。

因此，在云計算、大數據、區塊鏈、AI、物聯網等新興技術的沖擊下，企業的IT技術架構也逐漸開始一系列的變革，從傳統單一的IOE架構，逐步向x86、云化架構以及開源技術方案等領域轉變（見圖2-4）。技術架構的快速演進必然帶來運維領域的創新發展，一體化運維平臺隨之提上議程。

2.運維理論體系的演進

（1）ITIL

我們先來看一下ITIL的演進過程。ITIL最早是在1980提出的，但當時并沒有引起人們的關注，也沒有被太多人認可。2000年，ITIL發布了第二版，重點講流程建設。2007年ITIL第三版問世，經過4年的修正和完善，于2011年推出ITIL v3 2011版本。2019年，ITIL發布第四版，并在2020—2021年間將第四版的內容逐步補充完畢，形成較為完整的ITIL框架體系。ITIL的思想隨著技術的發展也經歷了多個版本的變化，每個版本關注的重點也有區別。

?ITIL v1：對IT任務進行職能化的拆解，每個部門和每個崗位有專業的分工，存在基本的工作流程，部門之間的聯系較弱。

?ITIL v2：在原有專業化分工的基礎上，把流程規范化。

?ITIL v3 2007：強調IT整體作為一個服務存在，圍繞服務目錄和SLA以及服務的整個生命周期開展相關工作。

?ITIL v3 2011：與2007版本相差不多，只是把服務內容從IT服務擴展到了企業內服務，如人力資源服務、財務服務等。

?ITIL 4：建設重心開始轉向價值驅動，以價值鏈和價值流為中心，面向IT數字化轉型。

ITIL 4的核心框架與概念包含四大維度：組織和人員、信息和技術、價值流和流程、合作伙伴與供應商。這是在原有ITIL v3的PPT（價值與流程、信息與技術、組織與人員）基礎上進行了完善和升華，所有的運維活動都應兼顧這四大維度，保證運維管理在各個維度都是均衡和合理的。

基于以上四大維度，ITIL 4提出了服務價值系統（SVS），從用戶的機會/需求出發，去梳理能夠實現機會/需求的完整的端到端價值鏈，并基于價值鏈交付價值。價值鏈外部包含IT治理和實踐，最外側是指導原則和持續改進。這樣解釋起來可能有點抽象，簡單來說就是要圍繞某一個價值展開具體的IT活動，包括運維和研發活動。

（2）DevOps

DevOps是從實踐中逐步總結提煉出的方法論理念，來源于敏捷開發的持續發展，是軟件開發管理領域繼敏捷開發之后的又一次升級。

敏捷開發方法的推廣和實施，使軟件交付過程中的開發和測試過程有效整合，進行快速有效的迭代交付，但在軟件交付客戶使用之前，或者使用過程中，還包括集成、部署、運維等環節，需要進一步優化交付效率。因此，DevOps的產生將敏捷的相關理念逐步擴展到運維側，俗稱解決軟件交付“最后一公里”的問題。

DevOps的目的是通過進一步簡化軟件在構建、驗證、部署和交付階段的移動，擴展敏捷開發實踐，同時授權跨職能團隊擁有從設計到生產支持的軟件應用程序的全部所有權，形成全流程一站式流水線管道。DevOps強調開發人員和運維人員（IT人員）合作，實現軟件交付和基礎設施變更的自動化，它旨在建立一種可以快速、頻繁、可靠地構建、測試和發布軟件的文化。DevOps核心詞匯為合作、自動化、文化。

DevOps落地過程中需要進行相關領域的流程體系梳理，涉及的管理理念包括從DevOps核心理念中引入的敏捷管理、ITSM、精益思想等，還有基于客戶現場的落地訴求，可能涉及產品管理、項目管理、需求管理、運維管理、運營管理等多維度管理體系的梳理與完善，同時還涉及客戶的組織架構、人員職責等相關的調整。

因此，DevOps的導入對企業來說是一次重大的組織變革，不能從某一個部門或某一個團隊開始實施，而要從企業的整體戰略視角來審視DevOps轉型的目標和路徑，制定自頂向下的實施策略。同時，對于DevOps實施團隊來說，要儲備足夠豐富的管理知識，也是一項不小的挑戰。

3.運維模式的演進

運維部門作為企業科技部門的一部分，在信息化時代的今天，所承受的壓力日益增加。傳統的運維模式越來越難以適應業務和IT架構的擴張，運維團隊需要尋求突破來跟上企業變化的步伐。通常來說，企業的運維管理體系分為規范化運維、自動化運維、敏捷化運維和智能化運維4個階段，其中規范化運維到自動化運維的過渡階段是大多數企業所在的階段。

所謂規范化運維，指的是運維的基本要素都具備，比如操作、流程、數據等，但還比較雜亂，沒有形成一定的規范。此時，可以通過引入運維PaaS平臺、建設自動化場景和自動化運維流程，進入自動化運維階段。如果企業處在規范化運維階段，并在逐步建設自動化運維，建設周期是1～3年。

什么是自動化運維？隨著近年各類運維市場活動的火熱舉辦，自動化運維達到了前所未有的熱度。自動化運維并不是炒作的概念，而是信息技術發展的必然趨勢。“大數據”“容器”“DevOps”“微服務”等不斷涌現的新技術大大增加了運維管理的操作單元數量，并對系統的可用性提出了更高的要求。從IBM、BMC、HP等傳統廠商的各類工具產品紛紛面市，到Puppet、Ansible、SaltStack等開源解決方案風起云涌，自動化運維已經勢不可擋。很多人嘗試給自動化運維下定義，如“數據中心自動化”（DCA）、“開發運營一體化”（DevOps）等，始終無法形成被統一認可的概念。通過運維工具或平臺，實現IT基礎設施及業務應用日常任務處理和運維流程的自動化，從而提高效率和降低風險，促進運維組織的成熟和各種能力的升級。

1）日常任務處理：包括設備發現、腳本執行、操作系統安裝、配置備份、配置檢查、配置變更、補丁分析和分發、作業調度等。

2）運維流程：包括應用發布流程、應用部署流程、變更流程、故障處理流程、災備切換流程、資源交付流程等。

3）能力升級：包括變化適應能力、風險應對能力、合規遵從能力、業務運營能力、事件應對能力等。

如何進入敏捷化運維階段？當企業能夠實現運維端到端的自動化、流程敏捷化、數據融合和全局度量，就可以認為該企業已經進入敏捷化運維階段。其實，要建設敏捷化運維存在一定的難度，因為敏捷化運維不再是各個部門割裂，而是通過運維整體融合來發揮價值，所以一般來說在自動化運維的基礎上要實現敏捷化運維需要3～5年。

最后，處在敏捷化運維階段的企業各個方面條件都已經充分，只需等待AI模型和算法等各方面時機成熟后，方能進入智能化運維階段。AIOps的前景十分廣闊，但是在做到AIOps之前，我們需要做一些鋪墊，包括構建端到端自動化的運維管理體系，將運營效能通過數字化的方式進行度量，最后才是運維數據體系的建設。運維數據體系的建設又包含運維數據的治理、運維平臺工具的建設以及運維場景的建設。建設完成后的企業已經基本實現敏捷運維管理體系，踏入國內運維第一梯隊，為向AIOps演進打下堅實的基礎。