一、DevOps的由來和概念
1、由來
2009年6月：美國聖荷西，第二屆Velocity大會上最大的亮點是一個名為“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演講，可以作為DevOps萌發的标志。這個演講提出了DevOps的“一個中心，兩個基本點”——以業務靈活為中心，構造适應快速釋出軟體的工具（Tools）和文化（Culture）。
2009 年 10月，Patrick想通過 Twitter 召集開發工程師和運維工程師在比利時根特舉辦一個類似于Velocity的大會，會議名稱叫做DevOpsDays，取得了出乎意料的成功，然而， DevOpsDays的讨論仍在Twitter上繼續着。由于Twitter140個字元的限制，大家在Twitter 上去掉了DevOps中的Days，保留了DevOps。于是，DevOps這個稱謂正式誕生。
2010 年：在DevOpsDays之後，DevOps被越來越多的人所熟知并迅速得到了大多數人的認可。人們認為這正是IT部門的正确運作方式，DevOps成為了一種促成開發運維合作的運動。為了統一化DevOps的見解的需要，The Agile Admin部落格發表“What is DevOps”， 給出了詳細 DevOps 的定義，并且依據靈活的體系構造出了DevOps的體系: 它包括一系列價值觀、原則、方法、實踐以及對應的工具。并且梳理了DevOps的曆史和對DevOps 的一些誤解。
2010 年：《持續傳遞》的作者Jez Humble參加了第二屆的DevOpsDays并做了 “持續傳遞”的演講。“持續傳遞”是“持續內建”的延伸，而這點恰恰和2008年靈活大會中的觀念一緻。但由于發生時間的先後關系，“持續傳遞”被看作是靈活以及DevOps文化的産物。而今，持續傳遞仍然被作為DevOps的核心實踐之一被廣泛談及。
2、DevOps概念解析
來自不同管道和來源的定義：
（1）百度百科：DevOps是一組過程、方法與系統的統稱，用于促進開發（應用軟體和軟體工程等）、技術營運和品質保障（QA）部門之間的溝通、協作與整合。它的出現時由于軟體行業日益清晰地認識到，為了按時傳遞軟體産品和服務，開發團隊和營運團隊必須緊密合作。
（2）維基百科：DevOps是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。其通過對“軟體傳遞”和“架構變更”的流程進行自動化，使得建構、測試、釋出軟體更加快捷、頻繁和可靠。
（3）Wikipedia：DevOps是軟體開發、運維和品質保證三個部門之間的溝通、協作和內建所采用的流程、方法和體系的一個集合。它是人們為了及時生産軟體産品或服務，以滿足某個業務目标，對開發與運維之間互相依存關系的一種新的了解。 ......DevOps并不僅僅關注軟體部署，它是部門間溝通協作的一組流程和方法。
（4）IBM：DevOps是一種軟體傳遞方法，它基于精益和靈活的軟體開發，在需求人員、開發人員、測試人員、運維人員的協同下，保證軟體的傳遞能夠基于真實的使用者回報。
（5）CA：DevOps是通過文化、流程、工具的轉換和改進以加速軟體傳遞的。
（6）Gartner認為：DevOps代表一種文化的轉變，它通過靈活和精益實踐來進行IT服務的快速傳遞。DevOps尋求開發團隊和運維團隊進行合作，同時強調利用技術對軟體進行改善，尤其是使用工具對軟體的整個生命周期的自動化進行改善。
（7）DevOps是一種文化轉變，或者說是一個鼓勵更好地交流和協作（即團隊合作）以便于更快地建構可靠性更高、品質更好的軟體的運動。（CloudTechnology Partners公司的副總裁兼首席架構師Mike Kavis）
3、其他摘錄
（1）DevOps是軟體開發、運維和品質保證三個部門之間的溝通、協作和內建所采用的流程、方法和體系的一個結合，展現了精益管理中的客戶價值原則，即以客戶的觀點來确定企業從設計到生産傳遞的過程，實作客戶需要的最大滿足。實作的關鍵有兩點：一是全局觀，二是自動化。
（2）DevOps=Culture+Tools，DevOps是一個循環遞進的過程，通過文化的指引，打造符合目前組織和文化的相關工具鍊，固化協作的規範、流程；然後随着工具落地、實踐推廣，促使組織更快地發展和改進産品，進而進一步加強協作文化和方式。所有未通過工具/平台固化下來的流程規範，如果僅僅依靠文檔和意識，當團隊迅速擴大時，其腐化速度是超過想象的。
（3）DevOps是對靈活軟體開發和精益生産思想的演進，應用于IT端到端的價值鍊中，使得業務基于現代資訊技術，并通過文化、組織與技術變革來獲得更大的成功。實施DevOps可以：縮短市場響應事件、減少技術債務、消除脆弱性。
（4）SRE由Google提出，即Site Reliability Engineering網站可用性工程，SRE團隊通過雇傭軟體工程師，創造軟體系統來維護系統運作以替代傳統模型中的人工操作。SRE團隊中基本有兩類工程師：50%~60%是标準的軟體工程師，其他40%~50%是一些基本滿足Google軟體工程師标準（具備85%~99%所要求的技能），但是同時具有一定程度的其他技術能力的工程師，目前Google最看重的兩類額外技術能力是UNIX系統内部細節和1~3層網絡知識。
二、DevOps内容相關
正如在由來和概念中提到的，DevOps中非常重要的幾個詞：靈活/持續傳遞、工具、文化。
DevOps核心原則：（1）基礎架構即代碼（IaC）是企業級DevOps實踐的前提送出，即計算基礎架構（容器、虛拟機、實體機、代碼管理、軟體安裝等）的管理和供應，需要實作自動化，均可編碼并存儲至版本控制倉庫；（2）持續傳遞，確定團隊可以在任何時間釋出可靠的軟體，并以更快速度、更高頻率進行軟體的建構、測試和釋出，它包括3個關鍵實踐（度量一切、持續改進；實作自動化；頻繁部署）；（3）協同工作，解除開發與運維人員的隔閡，鼓勵開發與運維人員的協作，可以通過兩個C來實作，即協作（Collaboration）和溝通（Communication）。
支援DevOps運作的三個原理：（1）系統思考，對于開發驅動的組織，其主要責任不是制作軟體，而是持續地傳遞客戶價值，而整個價值流速并不依賴單個部門的傑出工作，而是受到整個價值鍊最薄弱環節的限制；（2）強化回報環，過程改進常常通過加強和縮短回報環來完成，沒有測量就沒有提升，回報要以測量和資料作為基礎，通過回報資料來優化和改進系統；（3）持續試驗和學習的文化，在企業文化層面強調勇于試錯和持續試驗的文化，讓企業内部自發湧現出更多創新和系統提升的回報環。
DevOps的三步工作法：第一工作法是關于從開發人員到IT運維人員再到客戶的整個自左向右的工作流，為了使流量最大化，我們需要較小的批量規模和工作間隔，防止缺陷流向下遊工作中心，并且為了整體目标不斷進行優化；第二工作法是關于價值流各階段自右向左的快速持續回報流，放大其收益以防止問題再次發生，或者更快地發現和修複問題，這樣就能在所需之處擷取或嵌入隻是，從源頭上保證品質；第三工作法是關于創造公司文化，該文化可以帶動兩種風氣的形成，不斷嘗試，這需要承擔風險并從成功和失敗中吸取經驗教訓，熟練掌握、了解、重複和練習是熟練掌握的前提。
持續傳遞1.0：持續傳遞是一種能力，能夠以可持續方式，安全快速地把代碼變更（包括特性、配置、缺陷和試驗）部署到生産環境上，讓使用者使用。持續傳遞2.0，将精益創業與持續傳遞1.0相結合，強調業務與IT間的快速閉環，以“精益思想”為指導，全面貫徹“識别和消除一切浪費”的理念，通過一系列工作原則和實踐，幫助企業以一種可持續方式，高品質、低成本、無風險地快速傳遞客戶價值。持續傳遞2.0的4個核心工作原則是：堅持少做、持續分解問題、堅持快速回報和持續改進并衡量。
靈活運維（DevOps）需要團隊之間高度的信任，建立信任的三個技巧：1、不要試圖使用技術解決方案來解決文化的問題，文化高于過程；2、當你處于防禦的姿态時，是不可能靈活的；3、很強的上司力是非常重要的，上司力不需要管理授權，你可以成為公司中任何級别的上司。
DevOps主要由三大支柱和一個基礎組成：規範靈活，一支訓練有素的靈活開發團隊是成功實施DevOps的關鍵，規範靈活意味着三個方面（速度穩定、适應變化、總是能釋出優質的無錯誤代碼）；持續傳遞，是應用程式的建構、部署、測試和釋出流程的自動化實施；IT服務管理，當技術成為大多數業務流程的核心環節時，IT服務的連續性和高可用性是業務存亡的關鍵因素；以TPS（精益管理Lean）理念為基礎，包括JIT和自動化，JIT意味着以單件流的方式建立一個流水線式的供應鍊，而自動化意味着盡可能實作自動化，并且當出現缺陷時能停止整個過程。
DevOps成熟度模型，分為5個階段：初始階段，初始狀态，手工作業較多，傳遞流程不穩定；基礎階段，流程标準化開始階段，部分自動化，結合手工能完成可重複的傳遞；可靠階段，整體标準有清晰定義，大部分作業可自動化進行，能夠較穩定地提供可預期的傳遞；成熟階段，整體過程可度量，結果可視，狀态可追蹤，資料可分析；優化階段，全生命周期統一平台管理，基本無手工操作，不斷優化完善。
DevOps是一種将同理心帶回到我們工作中的方法，而工具可以幫助你做到這一點。同理心指的是和所有的同僚建立同理心，而不是僅僅局限于DevOps裡的開發和運維兩種角色。在工程師和銷售人員之間，高管和員工之間同樣需要建立同理心，而且組織裡的所有部門都應該關注全局優化，而不是隻顧自身的局部優化。你需要意識到其他同僚可能面臨的問題，而不僅僅是那些影響你自己或你所在部門的問題。工具正是帶回同理心的一種途徑，這對工程師很有吸引力，因為工程師都喜愛工具。
SRE團隊要承擔以下幾類職責：可用性改進、延遲優化、性能優化、效率優化、變更管理、監控、緊急事務處理以及容量規劃和管理。SRE幾個核心方法論包括：確定長期關注研發工作、在保障服務SLO的前提下最大化疊代速度、監控系統、應急事件處理、變更管理、需求預測與容量規劃、效率與性能。
典型的SRE活動包括：（1）軟體工程，編寫或修改代碼，以及所有其他相關的設計和文檔工作；（2）系統工程，配置生産系統，修改現存配置，或者用一種通過一次性工作産生持久的改進的方法來書寫系統文檔；（3）瑣事，與運維服務相關的重複性的、手工的勞動；（4）流程負擔，與運維服務部直接相關的行政工作，如招聘、團隊/公司會議、工作總結、同行評價、教育訓練等。
三、DevOps與其他理論的關系
1、DevOps與微服務
微服務架構是一種基于DevOps的演進式架構，架構師的運維意識是演進式架構的關鍵；對于服務間的異步通信，複雜場景用消息隊列，簡單場景使用背景任務系統處理；每個服務都應該有一個内嵌在服務代碼庫中的自解釋文檔，包括服務開發與 運維過程的核心資訊；新人需要多長時間才能開始貢獻代碼，這個時間是檢驗服務粒度粗細與自解釋文檔完備與否的最好名額。
2、DevOps與ITIL/ITSM
ITSM相關：一個隻包含最少必要資訊（MRI）、嚴格聚焦于業務持續性管理（BCM）、可落地的輕量級ITSM，要遠遠好于貪大求全卻無法落地的重量級ITSM；IT要通過可視化、自動化、高可用、準時制（JIT）的單件流流水線持續向業務和客戶傳遞價值；一切自動化是運維的目标，自動化之後的目标是智能運維（AIOps），最終都服務于業務運維；軟體定義世界，今後沒有運維工程師，隻有運維開發工程師，再往後沒有運維開發工程師，隻有全棧工程師。
在DevOps與ITIL之間存在着根本對立的沖突。ITIL的兩個關鍵原則之一，是由IT以服務的方式來傳遞業務價值，服務模式中必不可少的一環是客戶與供應商之間的關系，這些關系要求記錄在服務級别協定SLA中，包含各方職責。DevOps的主張在很大程度上基于單一團隊的概念，包括IT與業務在内，各種角色一起工作，關注長期的成功，而不是短期的勝利，當然更不會關注書面上的協定。團隊對失敗早已達成一緻，一旦失敗，他們不會互相問責，而是從自身錯誤去學習。在極緻情況下，IT與業務之間的邊界完全消失。
DevOps和ITSM在小的方面也存在分歧：
（1）DevOps的資金以完全不同的方式設定：資金是配置設定給産品，而不是項目；
（2）長期以來，IT部門的原則是以成本優化為基本原則，DevOps則建議切換到以提高速度為原則；
（3）ITIL定義的變更管理關注于降低風險，通過相當緩慢并且嚴格的正式流程實作，包含諸多的控制、通知、協定以及審批；DevOps所倡導的變更，則是在伴随自動化測試以及日志自己錄的情況下，越快越好；
（4）由于大量通過繁重的手工操作來收集和更新配置資訊，ITIL中所描述的配置管理以及配置管理資料庫時間中很難實作，而DevOps的配置管理在很大程度上是自動化的并且是強制的；
（5）與ITIL相比，DevOps的釋出概念發生了變化，從“釋出是一個複雜的、有準備的、測試過的、實時執行的變更”到“新功能對客戶可用”
（6）事件管理實踐，包括支援業務線的分離以及問題的更新，被DevOps中的另一個原則所取代“誰建構，誰來運作”
（7）問題管理（處理事故根因）在DevOps實踐中顯得毫無意義：在ITSM中問題管理極具挑戰性，在DevOps實踐中卻并非必要；
（8）ITIL中的容量管理是基于容量計劃的極大延伸，應該涵蓋對IT資源的所有需求，并且通常與公司每年的預算周期綁定；在DevOps實踐中，容量必須在需要的那一刻就緒，不能因為找供應商、簽合同、等待傳遞等事宜而被延誤。
四、DevOps相關的工具
全鍊路全開源的自動化運維工具鍊：自動化安裝，實體伺服器上架後使用Cobbler實作作業系統的自動化安裝；配置管理，使用Saltstack進行作業系統層面的初始化部署、配置管理；自動化監控，服務上線後使用Zabbix企業級監控平台進行自動化的監控；持續傳遞，使用Jenkins進行端到端的部署；日志收集，使用ELK進行自動化日志收集、彙總和展示；CMDB，存儲所有配置資料；私有雲，基于OpenStack建構企業私有雲，也可使用salt-cloud進行虛拟機自動化管理；容器雲，使用Kubernetes實作企業内部容器雲。
實作自動化部署的部署服務工具鍊，分為三個層面：（1）引導BootStrapping，伺服器OS的配置及基于虛拟器的伺服器安裝自動化的相關工具，如Vagrant、Kickstart、WMWare等；（2）配置Configuration，伺服器及中間件的配置自動化工具，如Ansible、Puppet、Chef；（3）業務流程Orchestration，代碼部署及釋出相關的伺服器操作等自動化工具，如Capistrano、Fabric。
持續內建的反模式建議：（1）頻繁送出代碼，可以防止內建變得複雜；（2）在送出源代碼之前運作私有建構，可以避免許多失敗的建構；（3）使用各種回報機制避免開發人員忽視建構狀态資訊；（4）有針對性地向相關人員發送回報，這是将建構問題通知團隊成員的好方法；（5）購買更強大的建構機器，優化建構過程，進而加快向團隊成員提供回報的速度；（6）避免建構膨脹。
企業應該在工具平台建設方面改變一下思路，通過運用先進的生産技術，使得環境部署、資料統計這一類事務性操作不再依賴專家型人才，而是在每個人在其需要時都能夠自助服務，那麼每個人都可以流暢地工作，而且專家型人才被打斷的次數也會減少。而這也可以利用開發環節暫時過剩的人力來建設工具平台，提升下遊的基礎能力，使得在不增加測試人力的情況下，永久提升團隊整體産能。
參考書籍：
《Devops開發運維訓練營》
《DevOps三十六計》
《大規模組織DevOps實踐》
《智能運維》
《鳳凰項目》
《靈活無敵之DevOps時代》
《DEVOPS精要：業務視角》
《企業級DevOps技術與工具實戰》
《持續傳遞2.0：業務引領的DevOps精要》
《SRE Google運維揭秘》
《DevOps悖論》