《DevOps與傳統的融合落地實踐及案例分析（上）》要點：
本文介紹了DevOps與傳統的融合落地實踐及案例分析（上），希望對您有用。如果有疑問，可以聯系我們。

導讀：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

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4124.html