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

　　開發與運維的融合：

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

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

企業開發團隊與運維團隊形成的鴻溝，使開發團隊在規劃、設計和研發的過程中過于著重功能的實現，在一定程度上忽視了運維團隊所關心的穩定性、性能、可用性等因素。

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

所以，DevOps體系中強調的是開發與運維的融合。

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

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

流程壓縮，反應敏捷，效率大幅提升：

ITIL強調流程，但是也帶來了效率的下降。在IOE時代，企業業務的變更還并不是那么的頻繁，這種效率的下降還并不明顯。但到了互聯網架構下，這種負面效應就會被無限放大。

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

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

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

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

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

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

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

以上就是關于在運維體系中，DevOps的思想跟ITIL的區別有哪些的全部內容介紹，想了解更多關于IT運維的信息，請繼續關注中培偉業。