devops
devops 是一個完整的面向it運維的工作流，以 it 自動化以及持續內建（ci）、持續部署（cd）為基礎，來優化程式開發、測試、系統運維等所有環節。
devops的概念
devops一詞的來自于development和operations的組合，突出重視軟體開發人員和運維人員的溝通合作，通過自動化流程來使得軟體建構、測試、釋出更加快捷、頻繁和可靠。
devops是為了填補開發端和運維端之間的資訊鴻溝，改善團隊之間的協作關系。不過需要澄清的一點是，從開發到運維，中間還有測試環節。devops其實包含了三個部分：開發、測試和運維。
換句話說，devops希望做到的是軟體産品傳遞過程中it工具鍊的打通，使得各個團隊減少時間損耗，更加高效地協同工作。專家們總結出了下面這個devops能力圖，良好的閉環可以大大增加整體的産出。
曆史變革
由上所述，相信大家對devops有了一定的了解。但是除了觸及工具鍊之外，作為文化和技術的方法論，devops還需要公司在組織文化上的變革。回顧軟體行業的研發模式，可以發現大緻有三個階段：瀑布式開發、靈活開發、devops。
devops早在九年前就有人提出來，但是，為什麼這兩年才開始受到越來越多的企業重視和實踐呢？因為devops的發展是獨木不成林的，現在有越來越多的技術支撐。微服務架構理念、容器技術使得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行業，這反而可能錯失了軟體的釋出時機
為什麼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）
實作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對工程師個人的要求也提高了，很多專家也認為招募到優秀的人才也是一個挑戰。
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%。