作者介紹：

張樂
DevOps時代聯合創始人，高效運維社群合夥人，DevOpsDays大會、GOPS全球運維大會金牌講師。國內首批DevOps Master，前百度資深敏捷教練、架構師。超過十四年敏捷轉型、工程效能提升和大型專案管理實踐經驗，曾主導數百人團隊實施DevOps轉型，在保證質量的前提下發布頻率提高數倍。

前言：

本文將介紹《DevOps Handbook》全書中的一部分：對 DevOps 常見誤區進行解讀。有些朋友對DevOps不熟悉或有一些不準確的理解，比如是不是隻有網際網路公司可以僅僅，是不是與ITIL不相容，是不是做DevOps就不能同時保證質量和效率等，我們會對這些常見誤區進行分析。

驅散謬見-常見DevOps誤區解讀

在DevOps推廣過程中有非常多的聲音，有人說 DevOps 只適合特定的公司、特定的企業、特定的文化，他們的公司很難去推廣 DevOps 活動。所以在《DevOps Handbook》中專門有一個章節來談一談常見的 DevOps 誤區，結合我的理解，我為大家做一下解讀。

1、誤區一

第一個常見的誤區：DevOps只適合於初創型的網際網路公司，這也是很多人經常會表達的一個觀點。

DevOps實踐確實是被那些網際網路獨角獸公司所倡導，包括優秀的公司比如谷歌、亞馬遜、Netflix、Etsy，這些公司都在倡導DevOps相關的方法實踐，雖然也許他們不把它稱為DevOps。

實際上，這些公司並不是生來如此的，每個公司成長過程都是一樣的，都會經歷很多問題、坎坷，也經歷過IT跟不上業務的發展導致業務停滯的風險。

我們把他們叫做獨角獸公司，因為在神話裡獨角獸是一種長著犄角和翅膀的白馬，這些公司都是從普通的”馬駒”公司進化成了獨角獸公司，他們也會遇到傳統公司所碰到的問題，包括高危程式碼導致的災難性的失敗、不能快速釋出功能、不能應對市場上競爭的變化、不能擴大規模，以及開發和運維相互對立而不能相互信任等。

但是這些公司採用了一些比較好的方法和實踐，促進他們成功完成了轉變。這裡我收集了一些資料，這些公司都或多或少都進行了很多架構上的、技術實踐上的，以及文化的轉型。

 - 亞馬遜在2001年時，他們那時的系統叫做奧比杜斯，奧比杜斯是亞馬遜流域下游一個很有名的城市，他們這個的系統就以此命名。這個系統是一個很大的單體應用，面臨很多系統的問題。2002年的轉型大家都非常熟悉了，他們CTO說我們必須要轉成SOA的架構，所有不按這個原則工作的人都要被fire掉，他們通過強力的轉型，開啟了SOA架構的路線。現在亞馬遜被認為是在技術領域非常成功的公司，因為他在很久之前就開始做這些技術轉型的工作。

 - 2009年推特也遇到了很複雜的情況，他們把前端巨石架構的Ruby on Rails系統花了一年多時間做重構。

 - Etsy是手工藝製品銷售網站，為了提升工程能力，公司在2009年花很大的代價，用兩年時間去解耦原來一個叫做Sprouter的系統。這個案例我們在第二期會進行詳細分析。

 - Facebook經歷了快速成長後，在2009年運維已經接近崩潰，無法跟上使用者的增長，到處救火，於是開始進行技術和文化上的變革。

- 2011年領英在IPO之後同樣面臨了很大的困境，技術已經無法完全跟上業務和使用者的發展，他們做了一個決策，整整兩個月時間，不做任何新功能的開發，而是去解決環境部署和技術架構的技術債。
 

類似的案例其實非常多，可以說這些成功的公司背後都經歷了很多也許不為人知的努力，他們因為改變了技術架構、技術實踐，改變了文化的氛圍，才有可能不斷走向成功。DevOps不僅是初創公司可以使用，它其實是一種普適技術，所有型別的公司都可以採用DevOps的方法和實踐幫助取得比較好的成果，後面會逐步看到這些方法和技術實踐是什麼。以上是第一個誤區。

2、誤區二

第二個誤區，DevOps Replaces Agile，有些人認為是不是DevOps就會替換掉Agile。

正確的說法應該是DevOps的方法和實踐是與敏捷相適應的，我們認為DevOps是敏捷之旅的一種邏輯延伸。

敏捷是DevOps的使能者，因為做了敏捷，具備小團隊快速釋出和持續交付的能力，才能進一步做好DevOps。

但是DevOps實際上是在超越敏捷的，大家讀過《敏捷宣言》，有一句是”可工作的軟體大於面面俱到的文件”，每個迭代結束之後它會得到一個潛在可交付的版本，但是我們認為DevOps已經在超越這個目標，把目標擴充套件為”讓程式碼一直處於可部署的狀態”。

通過每日頻繁的簽入程式碼到主幹上，經過一系列的構建、自動化測試，能夠很快在類生產環境甚至生產環境看到這次變更所帶來的影響。DevOps不是替換敏捷，而是敏捷之旅的延伸，把目標做進一步的擴充套件。

3、誤區三

第三個誤區，DevOps與ITIL不相容，這可能是很多做運維的朋友最大的困惑。1989年提出的ITIL是非常經典的方法論，影響了一代又一代運維實踐者。

有很多世界級IT運維流程橫跨整個服務的策略、設計和支援等很多方面，但是我們認為DevOps的實踐實際上可以與ITIL流程做相容。具體有三個方面：

• 第一，為了支援更短的前置週期和更高的部署效率，很多ITIL流程需要自動化，通過自動化的方式提升效率。
• 第二，為了解決配置和釋出管理流程方面的一些問題，我們強調DevOps需要保持配置管理資料庫以及軟體庫的及時更新。
• 第三，DevOps需要快速探測和恢復故障，在這個背景之下ITIL裡關於服務的設計、事故、問題管理的這些流程其實是仍然適用的。

ITIL與DevOps其實是可以相容的，之前有一個文件《企業級DevOps成功之路》，裡面談到DevOps裡有很多組成部分，包括敏捷、持續交付、精益，還有輕量級的ITSM，如何把ITIL流程做效率上的優化，與DevOps頻繁釋出變更的模式相匹配等，所以我們認為本質上二者是可以相容的。

4、誤區四

第四個誤區，DevOps和資訊保安、合規性之間不相容。

很多人覺得DevOps缺乏傳統的控制方式，比如職責隔離，不同人有不同許可權、做不同事情，DevOps講究跨界，鼓勵開發人員自服務的方式做環境申請、部署和釋出。

又比如說傳統的控制方式有很嚴格的變更審批的流程，以及在整個專案末尾人工進行非常完善的安全review的活動。

DevOps沒有這些活動，但是不代表沒有安全控制，反過來，很多做DevOps的公司的安全性、合規性甚至會超過原來傳統控制方式的公司。因為DevOps其實是把原來專案末尾做的安全和合規性的檢查注入到了每個階段，變成日常工作的一部分。

我們經常說在DevOps裡是沒有單獨的測試階段的，但是它把測試已經融入到每個階段，測試在DevOps場景裡是每個階段都要做的實踐，而不是一個單獨的階段。沒有傳統的控制方式，並不意味著DevOps沒有安全和合規性的要求，反而它會更強。

5、誤區五

第五個誤區，DevOps沒有Ops或者說排斥了IT運營。

誠然在DevOps場景裡IT運營或者運維的職責會發生一些變化，但是這種角色仍然是非常重要的。

我們的運維更早的會介入到軟體生命週期裡，可能會與開發一起工作。反過來，開發也會在程式碼部署到生產之後，與運維一起去持續工作。變化是我們更強調自動化，通過自動化替代原來手工處理工單的一些工作。

運維最大的變化是通過一系列自服務平臺的建立和開發，能夠把自己原來基於人工的環境的建設、維護、釋出、部署等等這些能力賦能給開發，通過賦能給開發的方式，提升流程生產效率。

從這個角度講，IT運營或運維其實更像是一種開發，開發的產品是一個平臺，讓開發人員可以快速、安全、可靠的用這個平臺去完成經常操作的場景，比如部署、環境分配等。從這個角度講，並不是說沒有運營或運維，反過來運維的職能會有些變化，更強調賦能給開發，提升自服務能力。

6、誤區六

第六個誤區，DevOps僅僅是基礎設施即程式碼。

因為很多人在談DevOps強調的是自動化，強調的是Puppet、Chef、Ansible這種工具，我們認為這遠遠不夠。

很多DevOps模式確實需要自動化，但是那些成功的公司不僅僅有技術範疇的改進，更有公司組織結構的調整、文化氛圍的調整，讓整個共享目標在IT的價值流裡快速交付，這已經遠遠超出了自動化的範疇。

這裡有一句很經典的話：”DevOps不僅是自動化，就像天文學不僅是望遠鏡那樣”。我們要超越技術的範疇去看更廣闊的改進空間。

7、誤區七

第七個誤區，DevOps只為開源軟體服務。

很多成功的故事都是用LAMP技術棧，比如Linux、Apache、MySQL、PHP，但是這些其實與取得DevOps的成果是無關的，我們看到很多成功案例可以用微軟.Net、大型機系統、SAP軟體，或者是一些嵌入式軟體等，都可以做DevOps轉型，在《DevOps Handbook》這本書裡也提到很多，包括ATM機這種複雜的嵌入式的系統也可以做DevOps轉型。

以上談到了七個誤區，希望大家通過我的解讀慢慢去理解，DevOps實際上是一個普適的概念，它不僅僅是自動化，不僅僅是一種流程，可以跟我們日常的工作場景相相容。

原文來自微信公眾號：DevOps時代