隨著企業(yè)信息化的深入，IT系統(tǒng)越來越多，企業(yè)IT運(yùn)維人員也越來越多。 許多企業(yè)信息部門成立了運(yùn)維團(tuán)隊，進(jìn)行IT系統(tǒng)運(yùn)維工作。內(nèi)部IT團(tuán)隊自然需要管理運(yùn)維人員的各種活動。ITIL為企業(yè)IT服務(wù)管理提供了一個客觀，嚴(yán)格，可量化的最佳實(shí)踐標(biāo)準(zhǔn)和規(guī)范。DevOps則是用于促進(jìn)開發(fā)，技術(shù)運(yùn)營和質(zhì)量保證部門之間的溝通，協(xié)作和集成的一組過程。那么在運(yùn)維體系中，DevOps的思想跟ITIL的區(qū)別有哪些？

　　開發(fā)與運(yùn)維的融合：

同時，ITIL背景下的分工也帶來許多負(fù)面問題。例如，運(yùn)維團(tuán)隊感知和認(rèn)同感很差。企業(yè)高層領(lǐng)導(dǎo)認(rèn)為運(yùn)維工作沒有亮點(diǎn)和價值，是一個成本部門;運(yùn)維團(tuán)隊也多半認(rèn)為自己是“背鍋俠”。以至于多年前做項(xiàng)目時曾聽到合作某甲方運(yùn)維團(tuán)隊核心成員的一句抱怨：“少壯不努力，老大干運(yùn)維”。

這可能也是大多數(shù)運(yùn)維者的心聲吧。誠然，這里面有運(yùn)維工作成果難以量化，企業(yè)高層不夠重視等因素，但是這種過于壁壘分明的開發(fā)與運(yùn)維的分工也是重要原因之一。

企業(yè)開發(fā)團(tuán)隊與運(yùn)維團(tuán)隊形成的鴻溝，使開發(fā)團(tuán)隊在規(guī)劃、設(shè)計和研發(fā)的過程中過于著重功能的實(shí)現(xiàn)，在一定程度上忽視了運(yùn)維團(tuán)隊所關(guān)心的穩(wěn)定性、性能、可用性等因素。

同時，運(yùn)維團(tuán)隊又無渠道將這些問題在開發(fā)前期予以反饋和修復(fù)。于是乎，運(yùn)維團(tuán)隊不斷淪為“救火隊員”和“背鍋俠”，團(tuán)隊士氣下降人才流失，運(yùn)維質(zhì)量下降形成了惡性循環(huán)。

所以，DevOps體系中強(qiáng)調(diào)的是開發(fā)與運(yùn)維的融合。

開發(fā)運(yùn)維一體化使開發(fā)和運(yùn)維的信息透明性，運(yùn)維過程中遇到的問題更有效地反饋到開發(fā)團(tuán)隊中。同時，運(yùn)維的責(zé)任主體從單一運(yùn)維團(tuán)隊變化開發(fā)、運(yùn)維團(tuán)隊共同承擔(dān)。這使得開發(fā)團(tuán)隊也需要為運(yùn)維中遇到的故障負(fù)責(zé)，讓開發(fā)團(tuán)隊也需要將部分的精力和資源投放到與穩(wěn)定性、性能和可用性等運(yùn)維相關(guān)的研發(fā)中去。

當(dāng)然，并非說ITIL這套體系就已經(jīng)完全過時，而是我們需要將兩者與企業(yè)中的開發(fā)運(yùn)維特點(diǎn)相結(jié)合，形成更有效的適合企業(yè)自身的開發(fā)運(yùn)維體系。只有適合自己的才是最好的。

流程壓縮，反應(yīng)敏捷，效率大幅提升：

ITIL強(qiáng)調(diào)流程，但是也帶來了效率的下降。在IOE時代，企業(yè)業(yè)務(wù)的變更還并不是那么的頻繁，這種效率的下降還并不明顯。但到了互聯(lián)網(wǎng)架構(gòu)下，這種負(fù)面效應(yīng)就會被無限放大。

舉個例子，某運(yùn)營商發(fā)布新的系統(tǒng)版本，往往會經(jīng)歷源代碼提交、編譯、打包、發(fā)布到測試環(huán)境、UAT測試、修改bug、再測試、最后上線發(fā)布的流程，這個流程往往會經(jīng)歷3-4天。因此，該運(yùn)營商的版本發(fā)布一般只能以月為單位，最快也只能以周為單位。相對于業(yè)務(wù)周期以天來計算的互聯(lián)網(wǎng)行業(yè)，這套體系對業(yè)務(wù)變更的反應(yīng)也就太遲鈍了。

所以，DevOps體系則更為強(qiáng)調(diào)效率，在持續(xù)集成、持續(xù)的自動化測試、持續(xù)部署平臺、立體化監(jiān)控、技術(shù)架構(gòu)優(yōu)化等多種自動化工具的加持下版本發(fā)布和運(yùn)維的過程被大大壓縮，效率被大幅提升。應(yīng)用版本發(fā)布頻率可以以天，甚至以小時為單位。這種為了效率有選擇性地放棄一些有點(diǎn)拖沓的流程管理，是IT運(yùn)維管理為適應(yīng)IT更好地按需而變，強(qiáng)調(diào)更敏捷地響應(yīng)業(yè)務(wù)需求的一種更好選擇。

　　自動化操作代替冗長流程控制下的規(guī)范性：

從另一個方面來說，ITIL強(qiáng)調(diào)了規(guī)范性，但是這種以建筑于流程之上的規(guī)范性仍然有很多缺陷。

再接著上面運(yùn)營商的例子來說，即使是有再完善的流程加以控制和規(guī)范，仍然沒有人能打包票說版本上線一定沒有問題。在每次版本上線前后，運(yùn)維團(tuán)隊成員仍然如臨大敵，戰(zhàn)戰(zhàn)兢兢。

原因在于，技術(shù)架構(gòu)復(fù)雜程度發(fā)展到一定階段，流程往往無濟(jì)于事甚至流于形式。在大規(guī)模、多類型軟硬件設(shè)施運(yùn)維情況下，單純依賴人的運(yùn)維體系終將成為整個IT運(yùn)維的瓶頸。在這種情況下，許多企業(yè)嘗試將規(guī)范性操作細(xì)化為各種自動化操作場景，例如，上文就提及過的持續(xù)集成、持續(xù)自動化測試、持續(xù)部署、自動化監(jiān)控和運(yùn)維等等的工具和平臺。這些高效率、規(guī)范化的自動化徹底解放了運(yùn)維人員的壓力，讓運(yùn)維人員的精力可以投入到真正有意義的工作中，而非總是在重復(fù)一些機(jī)械和重復(fù)的常規(guī)性事務(wù)當(dāng)中。

以谷歌為例，他們的SRE工程師強(qiáng)制規(guī)定他們只有30%的時間會花在on call這種事務(wù)型的工作當(dāng)中，而70%的時間則花在各種自動化工具的開發(fā)之中，比如自動化發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)、日志系統(tǒng)、服務(wù)器資源分配和編排等，這些工具需要他們自己完成開發(fā)和維護(hù)。這種以自動化工具下高效率的自動化操作代替冗長流程控制下的規(guī)范性，也是DevOps體系的一個比較明顯的特征。

以上就是關(guān)于在運(yùn)維體系中，DevOps的思想跟ITIL的區(qū)別有哪些的全部內(nèi)容介紹，想了解更多關(guān)于IT運(yùn)維的信息，請繼續(xù)關(guān)注中培偉業(yè)。