什麼是DevOps
DevOps是一種文化轉變，鼓勵團隊間更好的交流和協作，進而建構可靠性更高、品質更好的軟體。
1、DevOps是靈活的延伸，靈活依靠開發和業務部門的緊密協作，通過增量傳遞的方式來解決需求多變的難題。
2、下一步是找到一個将靈活應用于生産的方法：連接配接開發和運維，這就産生了DevOps，通過DevOps進一步延伸到IT運維，通過開發和運維的緊密協作提高軟體傳遞的品質和頻率。
3、DevOps也可以幫助開發和資訊安全團隊更有效地一起工作。
DevOps價值
1、産品快速推向市場，比如縮短開發周期時間，更高的部署頻率等
2、提高品質，比如提高可用性、提高變更成功率、減少故障等
3、提高組織的有效性，将時間花在價值增加活動中，減少浪費，傳遞更多的價值至客戶手中
devOps絕不僅僅是工具
人的重要性大于流程，流程的重要性大于工具。工具帶來的影響是短期的和片面的，流程和人 所産生的影響是長期的和全面的。
建設DevOps正确步驟：應該是充分了解 DevOps 的原則，認真分析自身需求和條件，選擇正确的方法和流程，最後才是選擇或建構适當的工具。
靈活管理發展
靈活自靈活宣言的誕生到現在17年過去了，自靈活1.0應用最廣泛的是Scrum方法，就在于他解決了開發管理的問題，但從一個企業視角來看，也是僅僅解決了開發端管理的問題。那麼下面簡要看一下各方向的概述。
SCRUM：全球應用超過70%，SCRUM是一種疊代的增量化過程，用于産品開發或工作管理。它是一種可以集合各種開發實踐的經驗化過程架構。SCRUM中釋出産品的重要性高于一切。該方法由Ken Schwaber和 Jeff Sutherland 提出，旨在尋求充分發揮面向對象和構件技術的開發方法，是對疊代式面向對象方法的改進。
XP（極限程式設計）的思想源自 Kent Beck和Ward Cunningham在軟體項目中的合作經曆。XP注重的核心是溝通、簡明、回報和勇氣。因為知道計劃永遠趕不上變化，XP無需開發人員在軟體開始初期做 出很多的文檔。XP提倡測試先行，為了将以後出現bug的幾率降到最低。
Crystal Methods（水晶方法族）：由Alistair Cockburn在20實際90年代末提出。之是以是個系列，是因為他相信不同類型的項目需要不同的方法。雖然水晶系列不如XP那樣的産出效率，但會有更多的人能夠接受并遵循它。
FDD （Feature-Driven Development，特性驅動開發）：由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發，是一套針對中小型軟體開發項目的開發模式。此外，FDD是一個模型驅動的快速疊代開發過程，它強調的是簡化、實用、 易于被開發團隊接受，适用于需求經常變動的項目。
ASD（Adaptive Software Development，自适應軟體開發）：由Jim Highsmith在1999年正式提出。ASD強調開發方法的适應性（Adaptive），這一思想來源于複雜系統的混沌理論。ASD不象其他方法那樣 有很多具體的實踐做法，它更側重為ASD的重要性提供最根本的基礎，并從更高的組織和管理層次來闡述開發方法為什麼要具備适應性。
DSDM（動态系統開發方法）：是衆多靈活開發方法中的一種，它倡導以業務為核心，快速而有效地進行系統開發。實踐證明DSDM是成功的靈活開發方法之一。在英國，由于其在各種規模的軟體組織中的成功，它已成為應用最為廣泛的快速應用開發方法。DSDM不但遵循了靈活方法的原理，而且也适合那些成熟的傳統開發方法有堅實基礎的軟體組織。
輕量型RUP：其實是個過程的架構，它可以包容許多不同類型的過程， Craig Larman 極力主張以靈活型方式來使用RUP。他的觀點是:目前如此衆多的努力以推進靈活型方法，隻不過是在接受能被視為RUP 的主流OO開發方法而已。
靈活1.0之後從傳統觀點應該是迎來靈活2.0，但随着各家流派的興起，以及靈活陣營的分家，靈活應來的是多家靈活方法之應用。
開發營運一體化模型
DevOps的特點在于企業全局通過引入精益、靈活、持續傳遞實作了企業全局的管理優化工作，并且以價值流為驅動，實作了業務價值傳遞。
DevOps：由Patrick Debois發起，IT咨詢師，DevOps的目标就是把Development和Operations整合在一起，提升全局優化效能，因為Dev和Ops中間存在工作牆，需要把開發（Dev）和Ops(運維)整合起來。
不同的階段patrick debois提出了不同的想法。DevOps1.0的核心是為了解決開發與運維一同玩耍，但到了DevOps2.0,要解決端到端的價值流快速傳遞 。最新Devops2.0定義為：
DevOps是一個軟體工程實踐。通過開發、品質、IT營運和資訊安全人員的協作，朝着一個共同的目标努力，使技術價值流通過計劃工作快速投産用于滿足業務群組織的成功，實作每天多次部署、達到世界級的穩定性、可靠性、可用性和安全性。
基礎架構自動化
- 隻需手工運作5條指令的情況下，成功部署的機率就已跌至86%。
- 如需手工運作55條指令，成功部署的機率将跌至22%。
- 如需手工運作100條指令，成功部署的機率将趨近于0（僅2%）！
成功部署意味着軟體能夠按照預期在生産環境中運作。未能成功部署意味着有東西出錯，可能需要進行必要的分析才能了解部署過程中哪裡出錯，是否需要應用某種更新檔，或需要修改某些配置。
是以讓這一切實作自動化并不惜一切代價避免手工操作似乎是個好主意，對吧？
然而這也可以讓我們明确的知道，在基礎架構自動化方面我們還有多遠的路要走，并且DevOps的基本原則和實踐依然是那麼的重要。
網絡巨頭們當然會通過新的方法和實踐及時滿足自己的需求，他們早已開始建構自己的工程業務，而正是他們所确立的實踐逐漸衍生出當今我們所熟悉的DevOps。
看看這些網絡巨頭們在這方面目前所處的位置吧，舉幾個例子：
- Facebook有數千名開發和運維人員，成千上萬台伺服器。平均來說一位運維人員負責500台伺服器（還認為自動化是可選的嗎？）他們每天部署兩次（環式部署，Deployment ring的概念）。
- Flickr每天部署10次。
- Netflix明确針對失敗進行各種設計！他們的軟體按照設計從最底層即可容忍系統失敗，他們會在生産環境中進行全面的測試：每天通過随機關閉虛拟機的方式在生産環境中執行65000次失敗測試…… 并確定這種情況下一切依然可以正常工作。
工具鍊
工具類型及對應的不完全列舉整理如下：
代碼管理（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
在工具的選擇上，需要結合公司業務需求和技術團隊情況而定。
DevOps：僅此一次，一顆神奇的銀子彈
DevOps的共存主要是為了擴充靈活開發實踐，進一步完善軟體變更在建構、驗證、部署、傳遞等階段中的流動，同時通過軟體應用程式的全面所有權予力跨職能團隊完成從設計到生産支援等各環節的工作。
DevOps鼓勵軟體開發者和IT運維人員之間所進行的溝通、協作、內建和自動化，借此有助于改善雙方在傳遞軟體過程中的速度和品質。
DevOps團隊更側重于通過标準化開發環境和自動化傳遞流程改善傳遞工作的可預測性、效率、安全性，以及可維護性。理想情況下，DevOps可以為開發者提供更可控的生産環境，幫助他們更好地了解生産基礎架構。
DevOps鼓勵團隊自主進行自己應用程式的建構、驗證、傳遞和支援。