其實devops就是為了讓開發、運維和qa可以高效協作的流程。（可以把devops看作開發、技術營運和品質保障（qa）三者的交集。）
devops對應用程式釋出的影響
在很多企業中，應用程式釋出是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具備devops能力的組織中，應用程式釋出的風險很低，原因如下 [2] ：
（1）減少變更範圍
與傳統的瀑布模式模型相比，采用靈活或疊代式開發意味着更頻繁的釋出、每次釋出包含的變化更少。由于部署經常進行，是以每次部署不會對生産系統造成巨大影響，應用程式會以平滑的速率逐漸生長。
（2）加強釋出協調
靠強有力的釋出協調人來彌合開發與營運之間的技能鴻溝和溝通鴻溝；采用電子資料表、電子資料表、電話會議和企業門戶（wiki、sharepoint）等協作工具來確定所有相關人員了解變更的内容并全力合作。
（3）自動化
強大的部署自動化手段確定部署任務的可重複性、減少部署出錯的可能性。
與傳統開發方法那種大規模的、不頻繁的釋出（通常以“季度”或“年”為機關）相比，靈活方法大大提升了釋出頻率（通常以“天”或“周”為機關）。
實作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對工程師個人的要求也提高了，很多專家也認為招募到優秀的人才也是一個挑戰。
作者：給你一顆小瓜子
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。