在Puppet、RightScale分別DevOps出版的調查報告基礎上，整理本文，以期爲讀者理清思路。另外，中國正在開展了一份自己的調查問卷，由南京大學發起，歡迎大家戳閱讀原文投票參與。
本文主要結構如下，讀完大概需要 10 分鐘
DevOps是什麼？從哪裏來？
DevOps的幾個關鍵問題
爲什麼DevOps會興起？爲什麼會繼續火下去？
實現DevOps需要什麼？
DevOps的採用現狀
1
DevOps是什麼？從哪裏來？
DevOps的概念
DevOps一詞的來自於Development和Operations的組合，突出重視軟件開發人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。
DevOps概念早先升溫於2009年的歐洲，因傳統模式的運維之痛而生。
DevOps是爲了填補開發端和運維端之間的信息鴻溝，改善團隊之間的協作關係。不過需要澄清的一點是，從開發到運維，中間還有測試環節。DevOps其實包含了三個部分：開發、測試和運維。
換句話說，DevOps希望做到的是軟件產品交付過程中IT工具鏈的打通，使得各個團隊減少時間損耗，更加高效地協同工作。專家們總結出了下面這個DevOps能力圖，良好的閉環可以大大增加整體的產出。
歷史變革
由上所述，相信大家對DevOps有了一定的瞭解。但是除了觸及工具鏈之外，作爲文化和技術的方法論，DevOps還需要公司在組織文化上的變革。回顧軟件行業的研發模式，可以發現大致有三個階段：瀑布式開發、敏捷開發、DevOps。
DevOps早在九年前就有人提出來，但是，爲什麼這兩年纔開始受到越來越多的企業重視和實踐呢？因爲DevOps的發展是獨木不成林的，現在有越來越多的技術支撐。微服務架構理念、容器技術使得DevOps的實施變得更加容易，計算能力提升和雲環境的發展使得快速開發的產品可以立刻獲得更廣泛的使用。
（注：上圖摘自上月紅帽副總裁Ashesh Badani的一次新聞分享會）
2
DevOps的幾個關鍵問題
好處是什麼？
DevOps的一個巨大好處就是可以高效交付，這也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主辦了2016年DevOps調查報告，根據全球4600位各IT公司的技術工作者的提交數據統計，得出高效公司平均每年可以完成1460次部署。
與低效組織相比，高效組織的部署頻繁200倍，產品投入使用速度快2555倍，服務恢復速度快24倍。在工作內容的時間分配上，低效者要多花22%的時間用在爲規劃好或者重複工作上，而高效者卻可以多花29%的時間用在新的工作上。所以這裏的高效不僅僅指公司產出的效率提高，還指員工的工作質量得到提升。
DevOps另外一個好處就是會改善公司組織文化、提高員工的參與感。員工們變得更高效，也更有滿足和成就感；調查顯示高效員工的僱員淨推薦值（eNPS:employee Net Promoter Score）更高，即對公司更加認同。
快速部署同時提高IT穩定性。這難道不矛盾嗎？
快速的部署其實可以幫助更快地發現問題，產品被更快地交付到用戶手中，團隊可以更快地得到用戶的反饋，從而進行更快地響應。而且，DevOps小步快跑的形式帶來的變化是比較小的，出現問題的偏差每次都不會太大，修復起來也會相對容易一些。
因此，認爲速度就意味着危險是一種偏見。此外，滯後軟件服務的發佈也並不一定會完全地避免問題，在競爭日益激烈的IT行業，這反而可能錯失了軟件的發佈時機。
3
爲什麼DevOps會興起？
爲什麼會繼續火下去？
條件成熟：技術配套發展
技術的發展使得DevOps有了更多的配合。早期時，大家雖然意識到了這個問題的，但是苦於當時沒有完善豐富的技術工具，是一種“理想很豐滿，但是現實很骨感”的情況。DevOps的實現可以基於新興的容器技術；也可以在自動化運維工具Puppet、SaltStack、Ansible之後的延伸；還可以構建在傳統的Cloud Foundry、OpenShift等PaaS廠商之上。
來自市場的外部需求：這世界變化太快
IT行業已經越來越與市場的經濟發展緊密掛鉤，專家們認爲IT將會有支持中心變成利潤驅動中心。事實上，這個變化已經開始了，這不僅體現在Google、蘋果這些大企業中，而且也發生在傳統行業中，比如出租車業務中的Uber、酒店連鎖行業中的Airbnb、圖書經銷商Amazon等等。能否讓公司的IT配套方案及時跟上市場需求的步伐，在今天顯得至關重要。
DevOps 2016年度報告給出了一個運維成本的計算公式：
停機費用成本 = 部署頻率 * 版本迭代失敗概率 * 平均修復時間 * 斷電的金錢損失
來自團隊的內在動力：工程師也需要
對於工程師而言，他們也是DevOps的受益者。微軟資深工程師Scott Hanselman說過“對於開發者而言，最有力的工具就是自動化工具”（The most powerful tool we have as developers is automation）。
工具鏈的打通使得開發者們在交付軟件時可以完成生產環境的構建、測試和運行；正如Amazon的VP兼CTO Werner Vogels那句讓人印象深刻的話：“誰開發誰運行”。（You build it, you run it）
4
實現DevOps需要什麼？
硬性要求：工具上的準備
上文提到了工具鏈的打通，那麼工具自然就需要做好準備。現將工具類型及對應的不完全列舉整理如下：
代碼管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
構建工具：Ant、Gradle、maven
自動部署：Capistrano、CodeDeploy
持續集成（CI）：Bamboo、Hudson、Jenkins
配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
容器：Docker、LXC、第三方廠商如AWS
編排：Kubernetes、Core、Apache Mesos、DC/OS
服務註冊與發現：Zookeeper、etcd、Consul
腳本語言：python、ruby、shell
日誌管理：ELK、Logentries
系統監控：Datadog、Graphite、Icinga、Nagios
性能監控：AppDynamics、New Relic、Splunk
壓力測試：JMeter、Blaze Meter、loader.io
預警：PagerDuty、pingdom、廠商自帶如AWS SNS
HTTP加速器：Varnish
消息總線：ActiveMQ、SQS
應用服務器：Tomcat、JBoss
Web服務器：Apache、Nginx、IIS
數據庫：MySQL、Oracle、PostgreSQL等關係型數據庫；cassandra、mongoDB、redis等NoSQL數據庫
項目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
在工具的選擇上，需要結合公司業務需求和技術團隊情況而定。（注：更多關於工具的詳細介紹可以參見此文：51 Best DevOps Tools for #DevOps Engineers）
軟性需求：文化和人
DevOps成功與否，公司組織是否利於協作是關鍵。開發人員和運維人員可以良好溝通互相學習，從而擁有高生產力。並且協作也存在於業務人員與開發人員之間。
出席了2016年倫敦企業級DevOps峯會的ITV公司在2012年就開始落地DevOps，其通用平臺主管Clark在接受了InfoQ的採訪，在談及成功時表示，業務人員非常清楚他們希望在最小化可行產品中實現什麼，工程師們就按需交付，不做多餘工作。
這樣，工程師們使用通用的平臺（即打通的工具鏈）得到更好的一致性和更高的質量。此外，DevOps對工程師個人的要求也提高了，很多專家也認爲招募到優秀的人才也是一個挑戰。
5
DevOps的採用現狀
哪些公司在用？
DevOps正在增長，尤其是在大企業中：調查發現，DevOps的接受度有了顯著提高。74%的受訪者已經接受了DevOps，而去年這一比例爲66%。目前，在81%的大企業開始接受DevOps，中小企業的接受度僅爲70%。
那麼具體而言都有些公司在採用DevOps呢？Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target（泛歐實時全額自動清算系統）、Walmart、Sony等等。
他們怎麼實施的？
首先，大企業正在自下而上接受DevOps，其中業務單位或部門（31%）以及項目和團隊（29%）已經實施DevOps。不過，只有21%的大企業在整個公司範圍內採用了DevOps。
其次，在工具層面上，DevOps工具的用量大幅激增。Chef和Puppet依然是最常用的DevOps工具，使用率均爲32%。Docker是年增長率最快的工具，用量增長一倍以上。Ansible的用量也有顯著增加，使用率從10%翻倍至20%。
並且調查還發現不到半數（43%）的公司在使用諸如Chef、Puppet、Ansible或Salt等配置工具；然而使用配置工具的公司更有可能同時使用多個工具。25%的受訪者使用兩種或更多配置工具，只使用一種工具的比例爲18%。其中Chef和Puppet是最常用的組合：使用Chef的組織中有67%同時也使用Puppet，類似的，使用Puppet的組織中也有67%同時使用了Chef。
中國也在準備一份DevOps的報告
文中的統計數據來自於國外的DevOps調研報告。其中由Puppet發起的DevOps年度國際調查報告已經連續出版五年，先後收集了2.5萬技術人員的答卷；2016年收集的有效答卷爲4600份，不過僅有10%來自於亞洲。我們並不認爲這樣的採樣率和採樣數量可以充分地反映中國的DevOps行業現狀。
目前，依託DevOps中國社區成員的積極參與支持，由南京大學發起開展《DevOps中國2016年度調查》活動。期望通過本次問卷調查，收集DevOps的率先實踐者們關於DevOps實踐及經驗的相關信息，從而瞭解DevOps在中國推廣應用的狀況，並彙總在DevOps實踐中可能遇到的障礙、挑戰和最佳實踐，最終通過調查報告進一步促進DevOps在中國的認知和推廣，同時爲DevOps的每一位實踐者提供有價值的參考信息和幫助。
調查問卷的設計主要參考了國際上2014-2016年度的《State of DevOps Report》及《State of Agile Report》的調查問卷設計，以實現信息數據在國內和國際之間的可比性，並根據業內專家意見經過多輪修改。目前問卷中英文版已上線，點此可進行中文版調查。本次問卷調查爲學術公益性質，所形成的年度調查報告將免費公開。
期待大家能「戳閱讀原文」填寫調查問卷，支持中國DevOps的發展！
本文首發於InfoQ垂直號「高效開發運維」
關注常規運維、
亦或是正在崛起的DevOps；
探討怎樣穩定地提高產品迭代，
讓運維有效地交付並實現IT價值。
高效開發運維，
在後方爲你提供運維補給，
願看你屢立戰功，
願祝你成爲中流砥柱！