一、什麼是DevOps
DevOps，字面意思是Development &Operations的縮寫。DevOps是從實踐中逐步總結提煉出的方法論理念，近而創造了DevOps這個詞。
DevOps概念的萌芽階段
2008年敏捷大會上，來自比利時的Patrick Debois發表了題為 《Agile Infrastructure & Operations》 的演講，以自身專案經歷為藍本介紹開發和運維如何應用敏捷的方式進行溝通協作。
DevOps理念的形成階段
在加州舉辦的 O’Reilly Velocity 2009 上，Flickr 的工程師 John Allspaw 和 Paul Hammond 發表了題為《10+ Deploys per Day： Dev and Ops Cooperation at Flickr》的演講，體現了 DevOps 的思想精髓，開發和運維圍繞著共同目標緊密合作，實現1天之內完成10次以上的軟體釋出。這次演講也成為 DevOps 這一稱撥出現的契機。
DevOps方法論的提出階段
2009年Patrick Debois發起了名為「DevOpsDays」的活動，這也標誌著 DevOps 的正式提出，並開發普及推廣。
DevOps來源於敏捷開發的持續發展，是軟體開發管理領域繼敏捷開發之後的又一次升級。
敏捷開發方法的推廣和實施，使軟體交付過程中的開發和測試過程有效的整合，形成整體進行快速有效的迭代交付，但在軟體交付客戶使用之前，或者使用過程中，還包括整合、部署、運維等環節，需要進一步最佳化交付效率。
因此，DevOps的產生將敏捷的相關理念逐步擴充套件到運維側，俗稱解決軟體交付“最後一公里”的問題。
DevOps的理想是透過進一步簡化軟體在構建、驗證、部署和交付階段的移動，擴充套件了敏捷開發實踐，同時授權跨職能團隊擁有從設計到生產支援的軟體應用程式的全部所有權，形成全流程一站式流水線管道。
DevOps 強調開發人員和運維人員（IT人員）的合作，實現軟體交付和基礎設施變更的自動化。它旨在建立一種可以快速、頻繁、可靠地構建、測試和釋出軟體的文化。
核心詞彙分別為合作、自動化、文化。
● 合作
從各角色的獨立運作不斷向上彙報進行跨部門溝通，到打通部門牆實現跨職能團隊的建立，以事件觸發活動的推進，在跨職能團隊層面上進行事情的推進。提升了人員工作的高效性。
● 自動化
從拉取程式碼、編譯構建、驗證測試到生產部署，整個環節透過工具構建全流程流水線，自動化觸發相關活動，提升研發整體的交付效率和質量。從工具層面優化了執行效率和質量。
● 文化
有個合作的基礎，有個完善的工具，如何讓工具在企業內有效的落地和實施，需要文化來構建，透過流程規範來約束人員的行為，使人的行為統一符合組織預期，在企業範圍內形成共性的文化。
未來的DevOps，不僅打破研發與運維的邊界，還將進一步打破業務與IT的邊界，構建從業務-IT-運營全鏈路的Biz DevOps，能夠確保應用程式價值鏈中的所有核心成員都做到按業務價值和目標進行交付。對專案中需求優先順序可以達成一致，消除內部相互競爭的挑戰和目標。
二、為什麼DevOps落地難
近年來DevOps的熱度不斷攀升，各行各業都在進行DevOps轉型建設，對於大型傳統企業來說，不像網際網路企業有天生的DevOps土壤，可以更順利的進行DevOps落地實施，大型傳統企業想要實現DevOps落地需要從多個維度進行準備：
● 各領域的管理體系升級
傳統企業大多是職能型組織架構，各部門有自己的職責範圍和邊界，各自的工作也有一定的參考依據，相互之間的互動已有一定的規則和習慣。
而DevOps的匯入需要涉及端到端的全鏈路打通，覆蓋業務、產品、研發、測試、運維、運營等產品全生命週期活動，涉及各個部門之間的協同與打通，以及全領域的流程體系梳理。
良好的管理理念和方法論是管理體系的核心支撐。
DevOps落地過程中需要進行相關領域的流程體系梳理，涉及到的管理理念包括從DevOps核心理念中引入了敏捷管理、ITSM、精益思想等，還有基於客戶現場的落地訴求，可能涉及到產品管理、專案管理、需求管理，運維管理、運營管理等多維度的管理體系的梳理與完善，同時，在此基礎上還會涉及到客戶的組織架構、人員職責等相關的調整。
對客戶來說改變工作習慣，理解新的流程體系都是不小的挑戰。
因此DevOps的匯入對於企業來說是一次重大的組織變革，並不能從某一個部門或者某一個團隊開始實施，而是要從企業的整體戰略視角來審視DevOps轉型的目標和路徑，制定自頂向下的實施策略。同時，對於DevOps實施的團隊來說，要儲備足夠豐富的管理知識也是一項不小的挑戰。
● 軟體研發的新技術應用
最近幾年，有越來越多的技術支撐DevOps的落地和實踐。微服務架構理念、容器技術使得DevOps的實施變得更加容易，計算能力提升和雲環境的發展使得快速開發的產品可以立刻獲得更廣泛的使用。
IT團隊也需要做好自身技術升級的準備，微服務架構的引入，容器化部署的嘗試以及雲服務的運維方式，都是DevOps落地的一些充分的前提條件。
做好技術的提前準備，才能使DevOps落地更充分有效。
而傳統企業的技術轉型需要面對龐大的業務系統，複雜的業務場景，年代久遠的程式碼架構以及力求穩定的運營訴求，同樣給DevOps落地帶來了巨大的阻力。
來自紅帽總裁的一次新聞釋出會
應用系統的建設經過單體應用、SOA應用、逐步走向微服務應用。微服務的實施必然要具備需求管理、程式碼版本管理、質量管理、構建管理、測試管理、部署管理、環境管理等全流程自動化工具鏈，以及開發部門與運維部門的深度協作，為DevOps實施提供的充分的土壤。
微服務的應用使軟體系統拆分成更小的組織單元，服務數量的增長，給部署實施帶來了更大的挑戰，無論是用虛擬機器還是物理機，成本都比較高，而且擴容也不是很流暢。
容器技術可以讓一臺機器上的不同應用使用相互隔離的資源，以獨佔的方式執行在同一臺機器上。這些應用也可以擁有容器，因此能夠建立和管理屬於他們自己的子容器。容器化技術的應用可以實現在服務不中斷的情況下實現更新部署，提高了升級效率。
● 一體化的工具平臺需要建設
DevOps平臺工具的功能包含了從需求管理、需求開發、程式碼管理、基礎設施管理、持續整合、自動化測試、持續部署到應用運維管理全流程。
每個過程都需要DevOps平臺及各種工具的支撐。
比如我們需要Git來管理程式碼，需要根據企業的實際情況制定合適的分支策略；多種語言的程式碼規則檢查；需要靈活的流水線搭建來做實現持續整合持續部署；匹配多種自動化測試工具來執行自動化測試；匹配各種部署方式實現自動化部署；使用節點服務來管理基礎環境等等。
而統一的DevOps平臺不僅需要覆蓋大量的應用場景，還需要靈活的配置方式可以適應全場景模式下的差異化配置，並且提供良好的平臺延伸和擴充套件，來滿足發展需要，以及可能出現的場景延伸。
對DevOps工具的要求需要整合各流程環節的管理訴求和自動化訴求，同樣給DevOps落地提升了不小的難度。
基於以上三點的分析，識別了DevOps落地的難點，未來需要規劃DevOps落地時，僅供參考，避免踩坑。
