導讀：5月6日，優維科技與數人云主辦了【DevOps&SRE超越傳統運維之道 · 深圳站】，6月北京站敬請關注~本文是優維科技CEO王津銀關於DevOps與傳統的融合落地實踐的精彩分享

作者：王津銀／優維科技創始人&CEO

中國開放運維聯盟發起人，精益運維”理論提出者，中國第一批DevOps Master授權講師，持續交付專家，業內人稱“老王”。“網際網路運維雜談”公眾號創辦者。致力於網際網路運維整體解決方案的產品化能力提升，縮短企業到達網際網路運維的路徑。

一直覺得華南這一片技術沙龍太少了，在DevOps、SRE理念大熱的今天，我們希望能把一些先進的經驗分享出來，讓更多的企業能夠受益。華南有很多優秀的業界從業者，比如說今天邀請到的大梁，騰訊內部關於DevOps還是有很多的經驗值得分享的。

今天活動主題是DevOps&SRE，我來講DevOps，王璞分享SRE，SRE是谷歌的DevOps實踐，大梁把DevOps最後一棒——持續反饋跟大家分享，希望把這些鏈條全部的打通。

今天的演講主要分為以下三個部分：第一個是DevOps全域性的理解以及DevOps與ITIL的對比融合，第二個是DevOps落地經驗14則，第三個是案例的分析。

DevOps全域性的理解

其實講DevOps特別的多，官方里面給了一個框架圖，從計劃需求、設計、開發、部署、運營、宗旨，持續交付到IT運營管理、經營管理，後來擴充套件了一下，大家看到這個全景圖的時候的確有概念的認知，我覺得不夠。做了以下幾點改動：

第一：  IT運營管理

以前叫IT服務管理，因為IT服務管理帶來很多ITIL的認知，今天看IT運營範疇變得很多了。面向IT運營管理的實踐，ITIL延伸出來的IT服務管理只是其中一部分，還有運營管理、效能管理、監控管理、分析管理等等。

第二：  擴充套件上層的實踐和工具部分

同時給出一個從理念—工程與方法—過程—實踐—工具的轉換路徑圖。這樣讓我們更能清晰的看到DevOps的整體框架和落地實踐及工具的關係。

今天看DevOps整體框架，其實也是一連串工程實踐組合，包括敏捷工程、持續交付和IT運營管理及其精益實踐等等。在過去IT組織中，或多或少都有敏捷管理和IT運營管理的實踐，但IT的效率依然不高，為什麼？今天似乎在持續交付中可以找到答案——IT如何成為業務的核心競爭力。

DevOps與ITIL的對比融合

DevOps跟ITIL對比，其實兩個不屬於同一個範疇，DevOps是屬於IT全域性的，ITIL是屬於運維這塊的，IT服務管理的，其實聚焦的領域不一樣，但是還是有必要做一個對比。

因為我覺得在運維的行業，我覺得還是要把這兩個理念做一個清晰的劃分，比如說今天講的以DevOps整個理念做平臺，到底以ITIL做這個平臺有什麼樣的不同。這裡面是做一個對比。

首先ITIL是面向管理的過程，以這個目標規範優先，DevOps是面向IT運營過程，是執行的能力跟自動化，ITIL 是離線任務管理為主要特徵，而DevOps是以線上服務的。

可以看這裡面有關鍵的作用力，我自己的理解把雲端計算、上層的框架模式拆分出來之後你會發現越接近上層應用，其實ITIL 對它的作用力越來越小。

比如說之前大梁給我的資料，他的部門兩個星期釋出9000次，這個不可能針對每一次的釋出建立強流程，這樣流程太多帶來成本非常高，達不到那種的效率。

我們在底下可以看到，在底層基礎設施這塊的，硬體基礎能力還沒有達到軟體定義這種SDX化，它的作用力依然存在的，但是未來隨著軟體定義化的能力越來越強，這波浪潮也會改變。NetDevOps的興起就是一個極好的例子。

DevOps自動化與ITIL規範之間的融合

DevOps可以看到線上服務管理裡面，可以兼顧質量效率和成本規劃，上圖就是DevOps自動化與ITIL怎麼融合，極力避免形成OA流程在IT部門的應用。這是按照優維的實踐，在傳統的行業做交付的過程中我們的產品怎麼跟ITIL流程思想對接得出來的模式：

 第一種模式：申請ITIL流程的時候可以直接調動DevOps的工具

典型的特徵，比如說第一種線上服務開通流程，我要把我的防火牆開通了，這時候申請一個表單，稽核通過了立馬呼叫DevOps的工具執行。

但以前是離線的IT服務目錄，我提一個表單、需求單，這個需求單稽核通過同意之後，方案管理人員再跑去裝置去開通，今天不一樣，讓流程變成立即可以執行的模式。

今天舉例：資源申請流程，在CMDB整個資源申請裡，這是國信證券的典型案例，比如說以前資源申請，我從庫房拿一個裝置，這個裝置拿出來我要分配網路重組，以前是各個角色分配完了填寫回復，今天不是這樣的，把這個流程線上化，所有的資源通過CMDB資源層拿出來直接在表單裡執行。

第二種模式：重大變更的流程

這個流程在華南很大的銀行總結出來的案例，我們把所有的變更流程、審批流程做完之後，立馬啟動執行流，對於高穩定性服務保障流程非常的重要。

比如說對於銀行基礎設施的網路等等非常重要的，這裡有一個問題，這個流程我在審批的時候是A方案，到稽核之後方案有可能會被人為改變，怎麼辦？這種情形有改進的措施，我們把DevOps排程流作為審批流方案一部分，審批通過了這個流程可以去進行執行，這個保證了流程審批完了以後和線上的流程是一致的。

第三種模式：敏捷釋出的流程，或者是DevOps變更的流程

因為今天很多的流程不再依賴ITIL 完成的，比如說敏捷的釋出流程JIRA管理，這是一個新的研發管理工具，不可能再回到ITIL 提一個釋出單，這裡面我總結的是紅綠燈機制。當我進入到某一個環節，比如說測試環節不符合的時候，我看到基於什麼樣的狀態？如果通過了就開始的執行。

今天講的DevOps，還可以從另一個維度看，叫軟體研發的模式去看。我們經歷了幾種模式的變化，第一種是waterfall 的模式，比如說研發、測試、運維間彼此是割裂的，獨立的，中間有一個牆存在的，這裡面有嚴格的輸入輸出在進行傳遞。

往下面走就是敏捷研發的模式，這裡面講的TDD的測試研發，在每一次的版本可以做很多的小迭代，比如說今天我們做easyops平臺，我們規定兩個星期出一個小版本，這兩個星期出一個小版本的時候，內部還經歷一個小迭代，內部很多的小迭代做這個事情。

但是這裡面依然有問題，研發跟測試是一體化的，測試驅動研發，這塊運維、operation 還是被隔離在外了，但是隨著新的業務形態出現後，比如說網際網路的模式出現了之後，要強調端到端能力的整合。

DevOps軟體研發模式就出現了，在和客戶交流的時候，不斷的觸發思考一個點，實施了敏捷和IT服務管理，為什麼IT依然看成成本中心而不是業務的核心競爭力，為什麼還是對業務需求響應很慢？在前面講的持續交付就是來解決這個問題的。

可以看在幾種研發模式中，比如說這個Develop以前測試的時候佔的70%，詳細的設計佔比重越來越大，但是到小迭代、小設計的時候Design工作變得越來越小，研發居多了，再往下看測試的工作量變得越來越少，變成自動化的工具。這是我們總結的資料，可以看到隨著研發模式的變化，各個角色在裡面承擔了工作量的配比也在發生變化，研發越來越重要，很多工作也前置到研發階段。

DevOps落地經驗十四則（上）

第一則：理念與價值先行

第一、二點

這裡面一定不是簡單談文化的，一定談工程實踐落地的因素。

第三點：端到端持續服務交付流程的改革

這裡面不是講的結果而是講的過程，process不是過去講的IT服務流程，把過程的變革，一旦工具進來簡化我的流程或者是自動化的流程都帶來變革。

第四點：對新的應用和服務，加快且縮短實現價值交付的時間。

這裡面講的怎麼樣有一個想法，快速實現這個想法，把這個想法反饋回來，讓我持續的改進，不影響安全性和持續性，這一點我覺得蠻有意思的，比如說在國內講雙態運維的理念，雙態運維根源上有雙態IT形態的存在，

但是運維的本身沒有所謂的雙態的差別，你使用的方法論、工具自動化套路都是一致的，因為我管理的IT都是從本質上幹幾件事情，把命令傳過去、檔案傳過去、資料採集回來，就幹這三件事情，本質上這個流程該形成有效的設計，相容安全和效能的要素。

第二則：頂層設計、全域性規劃。

這個是之前給一個物流行業做諮詢的時候提出來一個模型，DevOps運維的體系分成6個維度＋一個文化，這裡麵包括組織、過程、架構、工具、基礎設施、度量＋文化。

第一點：組織

DevOps首先必須打破組織之間的隔閡，其實DevOps團隊建立面向產品而非專案的協作文化。

第二點：過程

過程不是流程，輕量級流程和自動化的工具完美結合，確保企業的高度敏捷性、自動化為先、而後再流程。

第三點：架構

架構是應用的架構、基礎的架構和資料的架構，資料的架構談起來虛一點，應用的架構和基礎的架構是比較明確的，應用的架構更多講微服務的架構，基礎架構是標準化的基礎設施，像Saas、paas平臺。

第四點：工具

強調的平臺層面上，怎麼樣把IT能力平臺化，從DevOps整個過程構建持續交付的平臺，到運營構建IT運營管理的平臺，都是很重要的，只有它們能夠把所有的質量成本和效率幾者維度兼顧起來，具備可落地化。

回到頂層設計和平臺層面來說，IT運營管理平臺到底應該怎麼樣的設計？這裡面講到的雲資料平臺和iaas平臺。在上面面向不同的IT管理過程，我做一些域設計的細分，比如說ITIL，分成基礎、高階的、運維服務平臺、研發的服務平臺。

第五點：基礎設施

對應的IaaS、PaaS部分，怎麼樣做持續反饋？監控，端到端的監控，從底層的基礎設施，到上層的應用服務組建，從基礎設施到介面、使用者測量的監控這個端到端的能力怎麼構建？這個構建成資料採集的基礎。

第六點：度量

今天看監控是面向資料化的思維做監控，今天資料的特徵發生了變化，不僅僅是結構化還有非結構化的資料。比如說日誌，怎麼樣把日誌當成流式資料的處理？

有了這樣的資料採集基礎，這裡面有分析的平臺，結合運維的場景，容量、可用性、業務連續性等等進行分析，結合IT的規模形態發生變化，所要看到的指標也會不一樣，比如說基於雲端要看成本和費用分析都不一樣的，需求也不一樣的。

IT服務中心是把整個IT服務能力怎麼樣的目錄化，同時結合自動化的工具兩者銜接起來。這個講的變更中心，有一個梳理的方法，現在的傳統企業，比如說國信證券，結合CMDB管理的物件，把這個管理的物件整理出來，通過IT服務中心給變更能力目錄化，同時表達標準化，最後對接工具自動化。

再往上可以提供各種的服務編排的能力，這種服務編排是跨越了各種工具的，再往上是構建運維的統一模庫。這是頂層設計和全域性規劃。

第三則：Start Small，從小做起。

DevOps這麼大的體系，大平臺上又有這麼多，是不是全都要落地？一定要Start Small，這個準則很好梳理，基於每個角色＋某個場景從小做起，一定要把IT部門的角色梳理出來，比如說到運維這邊，有業務運維、系統管理員，網路運營。

第二可以基於每個系統和每個功能實施匯入，比如說今天就做監控庫，我看傳統的企業很多做CMDB匯入，切忌貪大求全，給你畫的圖景是很美好的，很多人說DevOps很好，怎麼樣落地呢？一定要Start Small。

第四則：構建元資料基礎平臺CMDB

下一個階段要把它名字改為IT資源管理平臺，因為我覺得現在需要把CMDB的管理資源和職責範圍縮小，其實在不同的階段，我們管理也不能貪大求全，把所有的配置全部管理起來，最後發現自己轉不動了。上面的場景又起不來，現在很難把場景構建起來，場景起不來的時候，結果把CMDB做死了，我們一直講這個資料的鮮活性，結果做不起來。

今天我把範圍縮小了，只管基礎設施的資源和應用的資源，基礎設施是屬於目前應用的，這個資產狀況管理起來我從應用的角度看，到底用了哪些資源？

把這兩層的維度強關聯起來，然後在應用上層構建應用的各種的管理場景，比如說應用的釋出、應用的部署、應用的監控等等。應用的資料分析，由它來進行進一步的驅動CMDB的流轉，因為在應用的維度上，才符合以前講的高頻的特徵。

今天到任何一個組織，其變更的場景來說，應用是最頻繁的，比頂層基礎設施更頻繁。如果符合高頻的特徵可以理解場景化的能力最強的，場景化的能力強那驅動力就是最強的，今天把CMDB轉化成IT資源管理，以應用的視角看資源。這個平臺裡它的核心作用是毋庸置疑的，應用是CMDB平臺的元資料。

這裡面怎麼樣的上層聯動？CMDB這麼多的資料，其實就是一類的例項的資料。比如說這裡面到底有多少伺服器、伺服器有多少的虛擬機器？這是例項的資料，然後就是拓撲的資料。我的服務擺在機櫃上，介入的上面資料是什麼。同樣是根據頂層的資源拆出來的，一個基礎資源一個是應用的資源，分成例項管理和拓撲管理。

今天很多人講自動化，其實資源有生命週期的狀態，一定不能通過自動化來替代的。比如說這個IP地址從資源池裡面分配出來給業務池使用，一定要通過一個流程申請出來，無論是自動化的還是以前離線流程的，這是一個生命週期的狀態，IT地址退還不能保留業務使用，這個一定要有流程控制的，這裡面自動化不能代替人工的流程，流程是聚焦在事前的管理。

再往上是場景應用，要找各種的場景應用，構建出來這一層做的形象的比喻就相當於今天的地圖一樣的，比如說百度地圖，這個地圖可以在不同的場景用，大眾點評可以用，滴滴也可以用，今天的CMDB也起到這樣的作用。這麼多場景建設的時候，事件平臺是一個很好的入口。

因為今天看到傳統的行業太多的監控系統，這個監控系統都要進行收斂，怎麼收斂？把所有的監控實踐發到統一事件系統，由統一事件系統根據底層的IT物件關係自己來進行收斂，現在老的監控系統基於CMDB收斂是很難的，基本上找不到監控廠商來修改，提一個需求要帶來大量的成本。

為什麼一直在講CMDB核心的管理模型是應用的管理模型，IT形態發生變化了，這個模型不用改變的，不用調整的，比如說是公有云。CMDB模型的擴充套件力是把所有的資源管理起來，這個資源分成本地資源和第三方的資源，本地資源是應用部署在同一主機上的資源，比如說程式包、作業系統的版本，使用的記憶體，或者是這裡面的配置的版本等等，甚至在本機佔用了埠甚至是介面服務都是我們的資源。第三方資源如阿里雲，這些資源都可以通過應用管理維度集中起來。

第五則：痛苦的事情優先解決

基於角色和產品如何梳理管理能力？運維的複雜度為什麼複雜？在這兒，因為運維角色太多了，管理的物件太多了，產品太多了，最終出來的能力管理流程也可以太多。開發測試沒有如此複雜，開發就開發，測試就測試。這裡面一定要通過角色＋場景，最後匯出我應該構建什麼樣的能力管理的平臺出來，一定要有這樣的思路。

今天講的運維自動化，最後我變成配置管理或者是工具的自動化或者是排程的自動化，這個遠遠不夠，其實運維自動化瀰漫在每一個角色、每一個場景裡，今天說的基於容量的自動擴容不算自動化嗎？CMDB的自動發現不算自動化？基於監控事件故障自愈不算自動化嗎？都算。基於這個圖把自動化的場景收斂一樣，作業和排程的能力是底層平臺化的能力，在各個子系統使用。

第六則：工具也是一種文化

這裡面講的作業管理和排程的管理應該是平臺級的能力，不需要進行場景化的理解。在自動化的構成要素裡有一個原子化的事務，同時有排程編排原子化的事務，有兩個要素有夠了。再往上是面向角色的場景化收斂和歸類，工具可以把我們的能力拼裝起來，在各個場景下使用。工具是真正推動變革的有效手段，好的經驗一定是通過自動化的手段沉澱管理過程。

文章來自微信公眾號：優維科技EasyOps