其實(shí)在今天的運(yùn)維領(lǐng)域，ITIL和DevOps之間的沖突還是蠻明顯的，有些是表現(xiàn)在產(chǎn)品上，有些是表現(xiàn)在思維/理念上。ITIL在產(chǎn)品上以流程為核心目標(biāo)的設(shè)計(jì)，很難滿(mǎn)足自動(dòng)化的要求，DevOps極力推崇工具/平臺(tái)/自服務(wù)文化;理念也是如此，ITIL以流程為先介入到一個(gè)企業(yè)的IT過(guò)程。本質(zhì)上來(lái)說(shuō)，這兩者不是同一個(gè)東西，但聚焦到運(yùn)維領(lǐng)域，這個(gè)問(wèn)題值得對(duì)比探討一下。

在EXIN官方給的DevOps***框架中，把很多因素糅合到了一起，對(duì)于整個(gè)產(chǎn)品生命周期來(lái)說(shuō)，可以看到幾個(gè)典型的階段，如敏捷管理、持續(xù)交付、IT服務(wù)管理。

當(dāng)然這篇文章不是簡(jiǎn)單的從DevOps與ITIL的全/子集的關(guān)系來(lái)探討，那樣就可以直接下結(jié)論，退出討論作罷。

首先讓我們來(lái)看看持續(xù)交付所聲明的原則：

• 為軟件的發(fā)布創(chuàng)建一個(gè)可重復(fù)且可靠的過(guò)程
• 將幾乎所有事情自動(dòng)化
• 把所有的東西都納入版本控制
• 提前并頻繁地做讓你感到痛苦的事情
• 內(nèi)建質(zhì)量
• “”DONE”意味著“已發(fā)布”
• 交付過(guò)程是每個(gè)成員的責(zé)任
• 持續(xù)改進(jìn)

其中有一條講——“將幾乎所有事情自動(dòng)化”，持續(xù)交付覆蓋了【部署】和【運(yùn)營(yíng)】?jī)蓚€(gè)運(yùn)維相關(guān)階段。在過(guò)去，我也一直強(qiáng)調(diào)運(yùn)維其實(shí)也是在做交付，其實(shí)也是由此而來(lái)。那么什么是部署自動(dòng)化?什么是運(yùn)營(yíng)自動(dòng)化?自動(dòng)化部署，就是通過(guò)部署平臺(tái)，把相應(yīng)的變更推送到開(kāi)發(fā)、測(cè)試和生產(chǎn)環(huán)境，不依賴(lài)某個(gè)人或角色來(lái)執(zhí)行。這里面就強(qiáng)調(diào)的部署平臺(tái)能力是針對(duì)所有環(huán)境——開(kāi)發(fā)、測(cè)試、生產(chǎn)等等，并且要支持灰度部署、藍(lán)綠部署等等。運(yùn)營(yíng)是服務(wù)線(xiàn)上運(yùn)行階段，這里面包含了監(jiān)控、服務(wù)變更、服務(wù)優(yōu)化、容量預(yù)測(cè)與規(guī)劃等等。

其實(shí)IT運(yùn)營(yíng)和產(chǎn)品運(yùn)營(yíng)有很多的類(lèi)似之處，只是兩者看到了對(duì)象的不同，一個(gè)是IT對(duì)象，一個(gè)是產(chǎn)品對(duì)象。所謂運(yùn)營(yíng)都是在建立一套服務(wù)流程或過(guò)程(有ITIL部分)，整合公司內(nèi)外有限的資源所展開(kāi)的一系列活動(dòng)，以便更好的服務(wù)客戶(hù)。狹義的IT運(yùn)營(yíng)可以理解成維護(hù)，廣義的IT運(yùn)營(yíng)可以包含產(chǎn)品體驗(yàn)優(yōu)化、用戶(hù)滿(mǎn)意度提升、應(yīng)用性能管理、安全、質(zhì)量控制等等，質(zhì)量控制算是IT質(zhì)量運(yùn)營(yíng)的一個(gè)維度。

既然在前面講到了自動(dòng)化的原則，那么針對(duì)運(yùn)營(yíng)過(guò)程的自動(dòng)化到底該如何做?如下圖：

可以把流程或者過(guò)程分成兩部分：一部分面向管理過(guò)程的“離線(xiàn)任務(wù)”為主，一部分是面向“在線(xiàn)服務(wù)”的執(zhí)行過(guò)程，管理與執(zhí)行兼顧。從互聯(lián)網(wǎng)現(xiàn)狀來(lái)看，ITIL的作用力越靠近應(yīng)用越弱，在傳統(tǒng)行業(yè)這樣的表現(xiàn)力到還沒(méi)體現(xiàn)差異。

兩種流程如何結(jié)合，有三種模式：

注意：左邊是管理流程，右邊是DevOps執(zhí)行流程。

模式一：每一個(gè)流程節(jié)點(diǎn)都需要調(diào)度一個(gè)執(zhí)行工具去作業(yè)。

優(yōu)點(diǎn)：流程效率大大提高，整合程度高。

適用場(chǎng)景：CMDB資源申請(qǐng)流程、一些配置變更流程等等。這個(gè)模式已經(jīng)不是從審核者的視角去看待，而是關(guān)注執(zhí)行者的視角。

例子：CMDB的主機(jī)上架流程片段(某證券)

Process是流程平臺(tái)，CMDB是配置管理平臺(tái)，RFID是主機(jī)管理平臺(tái)。流程平臺(tái)已經(jīng)開(kāi)始直接去驅(qū)動(dòng)相關(guān)平臺(tái)。這是當(dāng)時(shí)設(shè)計(jì)流程的時(shí)候(對(duì)應(yīng)【選擇機(jī)柜】環(huán)節(jié))，該環(huán)節(jié)和其他平臺(tái)之間交互的時(shí)候畫(huà)的交互圖。

模式二：審批流完成之后，執(zhí)行流程才得以進(jìn)行。

優(yōu)點(diǎn)：流程規(guī)范優(yōu)先、兼顧流程自動(dòng)化能力，但流程本身的效率沒(méi)有多大的改變。

適用場(chǎng)景：對(duì)于大規(guī)模的變更或者發(fā)布類(lèi)工作，或者傳統(tǒng)企業(yè)的變更流程。該模式是從管理者視角出發(fā)，把效率與流程兼顧起來(lái)。

模式三：在執(zhí)行流程中設(shè)置一個(gè)節(jié)點(diǎn)，定時(shí)去check管理流程的審批狀況。

優(yōu)點(diǎn)：效率優(yōu)先、規(guī)范之后。

適用場(chǎng)景：互聯(lián)網(wǎng)化的變更發(fā)布流程、持續(xù)交付流程、運(yùn)維變更流程等等。該模式是從執(zhí)行者的視角出發(fā)，以效率為***原則。

例子：這個(gè)模式遇到多個(gè)真實(shí)的客戶(hù)場(chǎng)景，我都推薦采用類(lèi)似的方案。特別是一些流程不在ITIL中的情況，比如說(shuō)他們使用JIRA系統(tǒng)做研發(fā)過(guò)程管理(如發(fā)布流程)，而運(yùn)維部署平臺(tái)則是獨(dú)立一套，兩者如何打通和整合?JIRA系統(tǒng)中會(huì)有某次發(fā)布的流程，此時(shí)在以應(yīng)用為維度的變更升級(jí)流程模板中，會(huì)有一個(gè)Check的節(jié)點(diǎn)，它主要用來(lái)查看ITIL流程的狀態(tài)，如果審批通過(guò)，部署工具中的執(zhí)行流程則往下執(zhí)行，稱(chēng)之為“紅綠燈機(jī)制”。把ITIL比作馬路上的紅綠燈，把DevOps執(zhí)行工具當(dāng)成馬路上的車(chē)子，有序、效率、安全等各方面都能兼顧。

[[184829]]

紅綠燈的復(fù)雜度也是視道路復(fù)雜度、擁塞情況、車(chē)流情況等多方面因素決定，這也就如同企業(yè)的流程復(fù)雜也各不相同，不要一概而論。

今天思考DevOps，要用結(jié)果來(lái)定義你的IT模式是不是DevOps，比如說(shuō)版本交付周期，故障恢復(fù)能力等等，這一定是效率優(yōu)先的。同樣我們思考ITIL流程實(shí)踐，也要兼顧效率，帶著工具思維去簡(jiǎn)化流程。不可否定，他們有各自存在的價(jià)值和場(chǎng)景，用管理和執(zhí)行的方式來(lái)定位，至于流程的模式，我也總結(jié)了三種供參考。

• ITIL是面向管理過(guò)程的;DevOps是面向IT運(yùn)營(yíng)過(guò)程的。
• ITIL是規(guī)則引擎;DevOps是執(zhí)行引擎。
• ITIL是強(qiáng)調(diào)規(guī)范的;DevOps是強(qiáng)調(diào)敏捷的。
• ITIL是以離線(xiàn)任務(wù)管控為目標(biāo)的;DevOps則以在線(xiàn)服務(wù)管理為目標(biāo)的。
• ITIL不等于追求穩(wěn)定;DevOps更不是以犧牲穩(wěn)定而一味追求效率。
• ........

【本文是51CTO專(zhuān)欄作者“王津銀”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)注明出處】

戳這里，看該作者更多好文