探索ITIL和DevOps的邊界
其實在今天的運維領(lǐng)域，ITIL和DevOps之間的沖突還是蠻明顯的，有些是表現(xiàn)在產(chǎn)品上，有些是表現(xiàn)在思維/理念上。ITIL在產(chǎn)品上以流程為核心目標的設(shè)計，很難滿足自動化的要求，DevOps極力推崇工具/平臺/自服務(wù)文化;理念也是如此，ITIL以流程為先介入到一個企業(yè)的IT過程。本質(zhì)上來說，這兩者不是同一個東西，但聚焦到運維領(lǐng)域，這個問題值得對比探討一下。
在EXIN官方給的DevOps***框架中，把很多因素糅合到了一起，對于整個產(chǎn)品生命周期來說，可以看到幾個典型的階段，如敏捷管理、持續(xù)交付、IT服務(wù)管理。
當然這篇文章不是簡單的從DevOps與ITIL的全/子集的關(guān)系來探討，那樣就可以直接下結(jié)論，退出討論作罷。
首先讓我們來看看持續(xù)交付所聲明的原則：
- 為軟件的發(fā)布創(chuàng)建一個可重復且可靠的過程
- 將幾乎所有事情自動化
- 把所有的東西都納入版本控制
- 提前并頻繁地做讓你感到痛苦的事情
- 內(nèi)建質(zhì)量
- “”DONE”意味著“已發(fā)布”
- 交付過程是每個成員的責任
- 持續(xù)改進
其中有一條講——“將幾乎所有事情自動化”，持續(xù)交付覆蓋了【部署】和【運營】兩個運維相關(guān)階段。在過去，我也一直強調(diào)運維其實也是在做交付，其實也是由此而來。那么什么是部署自動化?什么是運營自動化?自動化部署，就是通過部署平臺，把相應的變更推送到開發(fā)、測試和生產(chǎn)環(huán)境，不依賴某個人或角色來執(zhí)行。這里面就強調(diào)的部署平臺能力是針對所有環(huán)境——開發(fā)、測試、生產(chǎn)等等，并且要支持灰度部署、藍綠部署等等。運營是服務(wù)線上運行階段，這里面包含了監(jiān)控、服務(wù)變更、服務(wù)優(yōu)化、容量預測與規(guī)劃等等。
其實IT運營和產(chǎn)品運營有很多的類似之處，只是兩者看到了對象的不同，一個是IT對象，一個是產(chǎn)品對象。所謂運營都是在建立一套服務(wù)流程或過程(有ITIL部分)，整合公司內(nèi)外有限的資源所展開的一系列活動，以便更好的服務(wù)客戶。狹義的IT運營可以理解成維護，廣義的IT運營可以包含產(chǎn)品體驗優(yōu)化、用戶滿意度提升、應用性能管理、安全、質(zhì)量控制等等，質(zhì)量控制算是IT質(zhì)量運營的一個維度。
既然在前面講到了自動化的原則，那么針對運營過程的自動化到底該如何做?如下圖：
可以把流程或者過程分成兩部分：一部分面向管理過程的“離線任務(wù)”為主，一部分是面向“在線服務(wù)”的執(zhí)行過程，管理與執(zhí)行兼顧。從互聯(lián)網(wǎng)現(xiàn)狀來看，ITIL的作用力越靠近應用越弱，在傳統(tǒng)行業(yè)這樣的表現(xiàn)力到還沒體現(xiàn)差異。
兩種流程如何結(jié)合，有三種模式：
注意：左邊是管理流程，右邊是DevOps執(zhí)行流程。
模式一：每一個流程節(jié)點都需要調(diào)度一個執(zhí)行工具去作業(yè)。
優(yōu)點：流程效率大大提高，整合程度高。
適用場景：CMDB資源申請流程、一些配置變更流程等等。這個模式已經(jīng)不是從審核者的視角去看待，而是關(guān)注執(zhí)行者的視角。
例子：CMDB的主機上架流程片段(某證券)
Process是流程平臺，CMDB是配置管理平臺，RFID是主機管理平臺。流程平臺已經(jīng)開始直接去驅(qū)動相關(guān)平臺。這是當時設(shè)計流程的時候(對應【選擇機柜】環(huán)節(jié))，該環(huán)節(jié)和其他平臺之間交互的時候畫的交互圖。
模式二：審批流完成之后，執(zhí)行流程才得以進行。
優(yōu)點：流程規(guī)范優(yōu)先、兼顧流程自動化能力，但流程本身的效率沒有多大的改變。
適用場景：對于大規(guī)模的變更或者發(fā)布類工作，或者傳統(tǒng)企業(yè)的變更流程。該模式是從管理者視角出發(fā)，把效率與流程兼顧起來。
模式三：在執(zhí)行流程中設(shè)置一個節(jié)點，定時去check管理流程的審批狀況。
優(yōu)點：效率優(yōu)先、規(guī)范之后。
適用場景：互聯(lián)網(wǎng)化的變更發(fā)布流程、持續(xù)交付流程、運維變更流程等等。該模式是從執(zhí)行者的視角出發(fā)，以效率為***原則。
例子：這個模式遇到多個真實的客戶場景，我都推薦采用類似的方案。特別是一些流程不在ITIL中的情況，比如說他們使用JIRA系統(tǒng)做研發(fā)過程管理(如發(fā)布流程)，而運維部署平臺則是獨立一套，兩者如何打通和整合?JIRA系統(tǒng)中會有某次發(fā)布的流程，此時在以應用為維度的變更升級流程模板中，會有一個Check的節(jié)點，它主要用來查看ITIL流程的狀態(tài)，如果審批通過，部署工具中的執(zhí)行流程則往下執(zhí)行，稱之為“紅綠燈機制”。把ITIL比作馬路上的紅綠燈，把DevOps執(zhí)行工具當成馬路上的車子，有序、效率、安全等各方面都能兼顧。
紅綠燈的復雜度也是視道路復雜度、擁塞情況、車流情況等多方面因素決定，這也就如同企業(yè)的流程復雜也各不相同，不要一概而論。
今天思考DevOps，要用結(jié)果來定義你的IT模式是不是DevOps，比如說版本交付周期，故障恢復能力等等，這一定是效率優(yōu)先的。同樣我們思考ITIL流程實踐，也要兼顧效率，帶著工具思維去簡化流程。不可否定，他們有各自存在的價值和場景，用管理和執(zhí)行的方式來定位，至于流程的模式，我也總結(jié)了三種供參考。
- ITIL是面向管理過程的;DevOps是面向IT運營過程的。
- ITIL是規(guī)則引擎;DevOps是執(zhí)行引擎。
- ITIL是強調(diào)規(guī)范的;DevOps是強調(diào)敏捷的。
- ITIL是以離線任務(wù)管控為目標的;DevOps則以在線服務(wù)管理為目標的。
- ITIL不等于追求穩(wěn)定;DevOps更不是以犧牲穩(wěn)定而一味追求效率。
- ........
【本文是51CTO專欄作者“王津銀”的原創(chuàng)稿件，轉(zhuǎn)載請注明出處】
