最近老是碰到這個名詞，所以想了解一下這個到底是撒玩意？
DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。
它是一種重視“軟件開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發佈軟件能夠更加地快捷、頻繁和可靠。
它的出現是由於軟件行業日益清晰地認識到：爲了按時交付軟件產品和服務，開發和運營工作必須緊密合作。
從定義來看，其實devops就是爲了讓開發、運維和QA可以高效協作的流程。（可以把DevOps看作開發、技術運營和質量保障（QA）三者的交集。）
DevOps
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對工程師個人的要求也提高了，很多專家也認爲招募到優秀的人才也是一個挑戰。