DevOpsDays活動隨後在Patrick DeBios等相關核心發起人的推動下，在全球範圍內蓬勃發展了起來。2010年在美國山景城(Mountain View) 舉辦的DevOpsDays 活動中，Damon Edwards先生使用“CAMS”這個縮寫，高度概括和詮釋了DevOps，即文化（Culture）、自動化（Automation）、度量（Measurement or Metrics）和分享（Sharing）。隨後Jez Humble先生將“L”精益 (Lean) 原則也加入其中，最終變成了CALMS。
? Culture（文化）- 是指擁抱變革，促進協作和溝通
? Automation（自動化）- 是指將人為幹預的環節從價值鏈中消除
? Lean（精益）- 是指通過使用精益原則促使高頻率循環周期
? Metrics（指標）- 是指衡量每壹個環節，並通過數據來改進循環周期
? Sharing（分享）- 是指與他人開放分享成功與失敗的經驗，並在錯誤中不斷學習改進
“CALMS”完全吻合Patrick DeBois先生所壹向倡導的“DevOps is a human problem” (DevOps 是關於人的問題) 的理念 。
從DevOps概念的產生，到如今它在全球範圍內的蔓延和認同，已經經歷了9個年頭的時間。它的火爆推廣也伴隨著IT行業的迅速變遷和發展，現在已經到了移動互聯網時代的後半場，國內的信息化建設已經完成了很多年；如今各行各業的企業也都亟待完成全方位的數字化轉型。IT信息技術的先進程度標誌著壹個企業的核心能力，任何壹個成功的企業，敏捷高效的軟件開發創新實力和IT管理綜合能力不只是門面而已，而是實實在在的市場競爭能力。DevOps倡導打敏捷、持續交付和ITIL三種實踐的組合拳，同時應用精益生產理念為基礎的管理思想，這正在逐漸地被廣泛的接受和認可。
在過去的幾年中，國內的各種IT大會也蓬勃發展，其中DevOps相關的專題和分會場也頗受人們的關註。各種雲計算、運維等IT技術的社交媒體也都非常重視DevOps這個話題的分享。壹個專屬於DevOps社群的、國際性的、有影響力的DevOps大會正呼之欲出。在這樣的時代背景下DevOpsDays大會北京站在2017年的3月18日來到中國，在同年的8月18日上海，還要舉辦DevOpsDays Shanghai站的大會。
下面列舉壹些DevOpsDays大會的相關數據，數據來源於DevOpsDays.org 網站。從2009年到2016年，已經在全球的61個城市/國家成功地舉辦了117場。
下圖是在過去九年中DevOpsDays大會在各個城市/國家的分布和舉辦次數。
今年也就是2017年預計舉辦30場，其中已經有18場確定了舉辦城市和日期；還有12個城市的召開日期待定；這不包括年內還可能會提出申辦的城市。以上數據的統計時間在2017年三月。
隨著國內BAT等互聯網巨頭的崛起，互聯網公司的開發運維經驗也越來越多的在國內的各種技術大會上傳播。從最近這兩年（2016年和2017年）的技術活動日程中可以看出，國內互聯網從業人員也不約而同的用DevOps來定位和分享自己的優勢和經驗。他們是傳播和分享運維側DevOps實踐的先頭部隊。
出了技術論壇的分享之外，很多線上線下的大會、論壇和討論組也都越來越熱議DevOps這壹專題。國內其它相關流派的人群，例如敏捷和精益等，也對DevOps的蓬勃發展表示比較驚訝，DevOps與老牌的敏捷和精益等陣營也產生過壹些爭論。但這壹切的發生也都增加了人們對於DevOps的更深入的興趣。
在培訓認證這方面，Exin DevOps Master是壹個國際認證的培訓；其它公司和組織也正在舉辦關於DevOps工具鏈的培訓，這些培訓則註重於技術實操，關註在構建端到端的流水線的搭建方面。從DevOps的職位招聘方面，可以看到DevOps工程師相關的職位越來越多了，在職位需求中DevOps這個技能成了加分項，DevOps相關工具的技能也或將成為簡歷的亮點。在IT行業內不管是開發還是運維團隊的人，都開始了學習和接受的過程。
據我觀察DevOps方面的廠商在最近3年呈現爆炸式的發展。我把他們分為三類：
目前國內大部分企業慢慢地開始關註了DevOps，大型傳統企業也開始逐漸地從各個角度做試點和嘗試。試點的角度和方向各不相同，有的從底層基礎架構的容器化開始，有的從交付部署流水線的自動化開始；總的來說還處於初級的嘗試階段，還沒有大規模成體系的推廣。
綜上所述，目前國內DevOps發展的階段還屬於起步階段。就像是ITIL/ITSM在2003年左右的狀態。由於DevOps是去中心化的，所以沒有唯壹、權威的上遊廠商的存在，各種理論實踐的爭執和PK都將終止與解決問題和提高效率的話題上，因此它具有百花齊放百家爭鳴的發展條件。個人認為DevOps的實施和落地也不會完全依賴於傳統的大型咨詢廠商的咨詢工作，由於它應該是在企業的內部，在內驅的作用下，自生長出來的；它必須是服務於企業的業務價值流的優化，加速業務價值產出的；而與之相關的工作和責任的擔當，外部力量是很難以等量替換和承擔的。
在談這個話題前先看壹下DevOps相關工具集的全貌，如下圖所示：
最上面的箭頭流程圖表示了壹個業務服務的全生命周期：開發協作、軟件構建、質量測試、交付部署和投產運維。前三個階段偏傳統開發組織的工作內容，後兩個階段基本可以和運維組織的工作對應上。在每個階段下可以看成是壹個大分類，這些分類中還包含若幹個小分類。這些工具可以粗放的劃分為商業軟件和開源軟件兩類；也可以分為SaaS服務類和企業內部部署型。大部分開源工具都有活躍的用戶社區和群眾基礎，這給企業入手這些工具帶來了很大的便利。在需要商業支持的場景裏還可以選擇使用這些開源軟件的企業版。
Docker容器技術在最近三年中異軍突起，持續交付的技術門檻因此被降到最低，軟件生產供應鏈的格局和效率被徹底提升；基於Docker的微服務架構實踐的熱度和成熟度也與日俱增。因此，國內的傳統企業紛紛試水DevOps和容器技術，在最近兩年的各種技術大會中，我們可以看到國內各個行業出現了在不同維度上的DevOps先行者。他們分享的主題大多集中在自動化運維、容器化和PaaS平臺的等項目經驗。
從國內眾多DevOps實踐中，我們能看到下面三個技術尤其重要和火熱：
以上三種技術相輔相成，有著比較深刻的關聯。首先微服務和持續部署各自解決了特別多的傳統IT的問題，這些問題都是長期以來制約企業業務發展的難題。容器技術由於它的快速、輕量、微服務化的天然特性，很好的從不同側面支持了持續交付和微服務架構。容器可以為持續交付提供彈性和高速的系統資源，環境管理和利用率提高了很多；容器的不可變性的特點也更好地支持了微服務架構。
我把DevOps的按照不同的技術特征做了從到1.0 到2.0的時代劃分，並盡量通過以下維度比較與傳統方式的差異。
我比較認可和接受的企業實踐DevOps參考框架如下，其中包含了所需的最佳實踐，如下圖所示。
（上圖來源於：Exin DevOps白皮書）
下面簡要描述壹下這四大支柱型最佳實踐：
由此可見DevOps在企業，特別是大規模傳統企業的落地和推廣還是比較復雜的。雖然相關的最佳實踐都是已經存在了很多年的；但是，通過DevOps的價值觀重構企業從研發到交付到運維的價值流談何容易。基於我的IT從業經驗，我似乎感覺到DevOps不能單獨依靠自頂向下的推廣，當然高層領導的支持依然是重要的和必備的支持條件之壹。 可能還需要中層的帶動和底層的創新；借鑒生產制造業已經久經考驗的精益制造實踐也是勢在必行。總之DevOps運動會在近幾年給IT行業帶來較大影響。