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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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