其實在今天的運維領域，ITIL和DevOps之間的沖突還是蠻明顯的，有些是表現(xiàn)在產品上，有些是表現(xiàn)在思維/理念上。ITIL在產品上以流程為核心目標的設計，很難滿足自動化的要求，DevOps極力推崇工具/平臺/自服務文化；理念也是如此，ITIL以流程為先介入到一個企業(yè)的IT過程。本質上來說，這兩者不是同一個東西，但聚焦到運維領域，這個問題值得對比探討一下。

在EXIN官方給的DevOps最新框架中，把很多因素糅合到了一起，對于整個產品生命周期來說，可以看到幾個典型的階段，如敏捷管理、持續(xù)交付、IT服務管理。

當然這篇文章不是簡單的從DevOps與ITIL的全/子集的關系來探討，那樣就可以直接下結論，退出討論作罷。

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

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

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

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

既然在前面講到了自動化的原則，那么針對運營過程的自動化到底該如何做？如下圖：

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

兩種流程如何結合，有三種模式：

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

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

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

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

例子：CMDB的主機上架流程片段（某證券）

Process是流程平臺，CMDB是配置管理平臺，RFID是主機管理平臺。流程平臺已經開始直接去驅動相關平臺。這是當時設計流程的時候（對應【選擇機柜】環(huán)節(jié)），該環(huán)節(jié)和其他平臺之間交互的時候畫的交互圖。

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

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

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

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

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

適用場景：互聯(lián)網化的變更發(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，要用結果來定義你的IT模式是不是DevOps，比如說版本交付周期，故障恢復能力等等，這一定是效率優(yōu)先的。同樣我們思考ITIL流程實踐，也要兼顧效率，帶著工具思維去簡化流程。不可否定，他們有各自存在的價值和場景，用管理和執(zhí)行的方式來定位，至于流程的模式，我也總結了三種供參考。

@ITIL是面向管理過程的；DevOps是面向IT運營過程的。

@ITIL是規(guī)則引擎；DevOps是執(zhí)行引擎。

@ITIL是強調規(guī)范的；DevOps是強調敏捷的。

@ITIL是以離線任務管控為目標的；DevOps則以在線服務管理為目標的。

@ITIL不等于追求穩(wěn)定；DevOps更不是以犧牲穩(wěn)定而一味追求效率。

標簽： 互聯(lián)網 云計算 DevOps ITIL 

版權申明：本站文章部分自網絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。