為了降低工具的成本和使用門檻，包括 CODING 在內的很多雲服務廠商都在做打通全流程的 DevOps 工具鏈的嘗試，希望可以做到讓企業開箱即用，低成本的踐行 DevOps 理念，不過目前產品仍處於迭代期，無法滿足所有企業的需求。

原文未完，完整內容可點擊：

CODING是一個面向開發者的雲端開發平臺，提供 Git/SVN 代碼託管、任務管理、Cloud Studio、開發協作、文件管理、Wiki 管理、提供個人服務及企業服務。

CODING實現了 DevOps 流程全自動化，為企業提供軟體研發全流程管理工具，打通了從團隊構建、產品策劃、開發測試到部署上線的全過程。「CODING 持續集成」集成了 Jenkins 等主流企業開發流程工具，如果您之前有使用過或者寫過 Jenkinsfile，相信您會很快上手。

同時CODING 的專欄 DevOps 實踐指南 持續分享敏捷開發、DevOps、持續集成/部署等領域優秀實踐，感興趣的同學可以瞭解一下，歡迎交流分享。

對大公司尤其困難，但是依託於工具恐怕無法保證DevOps的實施。我們推崇的是從流程，工具和組織文化以及人員素質四個方面整體考慮。

如果要說哪個工具有用，那就是我在下面文章中提到的 Agile/DevOps Maturity Matrix， 這是一個類似於KPI的工具，可以幫助企業以正確的方式有步驟的完成轉變。

我在知乎發表的文章《大型傳統企業IT的Agile/DevOps轉型之路》裡面有比較詳盡的解釋。

原文如下：

大約在幾個月前，我曾經發表過一篇文章 《企業什麼時候不應該採用敏捷開發(Agile)？》文中主要列出了若干條我在工作中總結出的一些經驗。我的目的主要是希望企業IT在轉型中要充分考慮除了IT技術之外的其他因素，Agile/DevOps本身確實和相對應的技術息息相關，但是隻有和其他因素結合在一起才能保證轉型的成功。

筆者自身就職於某跨國公司的IT戰略部，目前正在大刀闊斧的進行Agile/DevOps 轉型，在工作中我和我的同事們參考了國內外許多的實例，但遺憾的是沒有哪個公司可以展現出一個完全轉型成功的案例，我們最終意識到目前行業中關於這個部分還沒有一個達成共識的模型可供借鑒，許多Agile/DevOps相關產品或相關服務的公司根據自身的業務特點提出各種類似但又不太一致的建議，而DevOps之父本身似乎反對將DevOps理論化模型化，堅持DevOps的實踐性和靈活性。從Agile/DevOps的發展歷史上來看，我們可以得知這是一個基於個人經驗發展而逐步被大眾接受的理念，不同於ITSM, CMMI本身在誕生時背後的政府或科研組織的身影，Agile/DevOps並沒有什麼龐大的機構支持，所以在理念推廣和實際應用中都是自然靠近小規模企業和組織，相應的支持工具也以開源工具為主。

Agil/DevOps發展至今，由於理論的相對完善和工具的應用效率提高，最重要的是目前移動互聯網領頭的公司都在不斷宣講Agile/DevOps給公司帶來的業務優勢，這使得接受它的企業和組織越來越多，就連傳統企業也不斷在高喊著擁抱「Agile/DevOps」。嘴裡說起來容易，但是做起來就難了，這件事難度在於，並沒有一個清晰的模式來告訴企業該如何做，傳統大型企業和小型/互聯網公司的不同之處在於，當前的組織結構和文化還不足以支持以不斷試錯的方式進行轉變，由於體量的原因轉型所耗費的成本也是相當驚人的，在沒有一個能夠統帥全局的計劃下，傳統企業很難做出轉型的決定。

正式基於上面的原因，本文的目的是希望介紹一條相對清晰的轉型路線圖來幫助企業IT轉型的策劃者或管理者制定出和自己公司現狀，文化以及目標相符的實施計劃。

正如文章的題目所示，文章的適用的對象是「大型」和「傳統」的企業，「大型」指得是企業規模是上萬人數的跨國的公司。「傳統」指的是企業的歷史相對比較長，至少有三十年以上的時間。象IBM或HP這個的公司都在我所說的這個範圍內（不要以為他們是老牌IT公司就已經自然而然的轉型成功了）。但是象AWS，阿里巴巴這樣的公司則不再此列，因為他們雖體量巨大但是本身就是移動互聯起家慢慢發展起來的，從骨子裡本身就是從「Agile/DevOps」的文化中泡大的。

既然是傳統大型企業，自然做事風格也要遵從傳統企業的方式。一般來講轉型的就是一個change，只不過這是個大的change而已。

1. 轉型的目的是什麼？

無法明確的闡述出Agile/DevOps轉型帶來的業務價值，或者沒有把這種價值傳遞到公司的非IT業務部門以及全體的IT成員，將會給轉型之路帶來巨大的陰影。

從最直接的改變來看，就是軟體產品或IT服務的交付方式發生了變化。如果通常的情況下一個有十個功能的軟體產品需要十個月的時間交付，那麼在Agile/DevOps的交付模式下就變成了一個月交付一個功能總共交付了十次。

如下圖所示：

但是這樣的差別到底帶來了什麼樣的業務價值呢？這纔是驅動改變的核心因素。

首先，最大限度的解決了用戶需求描述和產品功能之間的信息不對稱問題。眾所周知的產品生命週期包括從產品需求確立到產品設計，開發，生產及售後。在傳統模式下直到產品生產完成後，我們才能確認產品提供的服務或應用是否能真正的滿足用戶的需求，但是由於各種無法克服的原因，信息在傳遞的過程中會不斷的被扭曲，被誤解，導致最終產品和用戶的期望總會有比較大的出入，如果需要重新改正的話，成本往往過於巨大導致用戶不得不長時間忍受著不符合自己期望的產品。

在新的（Agile/DevOps）迭代開發持續交付的模式下，用戶可以很早的就得到最終產品或服務的一部分進行實際體驗，從而可以儘快的把發聵傳遞迴需求管理團隊和產品研發團隊，這些極具價值的反饋信息將會成為隨後產品交付功能的重要參考。隨著一次又一次的不斷迭代開發和交付，最終產品的將會變得越來越完美。就如同沒人能用筆在紙上一筆畫出一個完美的圓。但是任何一個人都可以通過一次一次不間斷的畫，把一個個不完美的圓疊在一起，然後得到一個接近完美的圓。

簡單的說，這個業務價值就是在保持快速的交付條件下生產幾乎完美的產品，這纔是令人嚮往的商業價值體現，明白了這一點，其他的業務價值都不難理解，比如成本節約，資源高效利用等等。當然也可以從更高的地方戰略高度來看待Agile/DevOps的轉型，比如公司IT組織期望轉型成數字化IT組織，那麼Agile/DevOps就變成是其中的一個重要的組成部分。

2. 明確Agile/DevOps和ITIL的關係

傳統企業的IT服務大致遵循ITIL流程。

如下圖：

上圖是一張基於ITIL V3的一張流程框架圖，一般來講企業可以根據自身的情況進行調整。

用箭頭把各個流程鏈接起來，變成一個可以指導實際應用的圖例。比如下面這張:

用各個流程的輸入輸出作為各個流程階段關鍵銜接點，十分清晰的表明ITIL流程的商業價值產生的過程。

我參加過若干個Agile/DevOps研討會，非常遺憾的是有些演講者把ITIL作為Agile/DevOps的對立面來陳述，似乎ITIL是一個完全過時的IT服務管理理念。在我看來演講者大概並沒有在大型而且成熟的IT企業服務過，或者沒有使用過ITIL的整體服務流程，才會得出如此的結論。其實ITIL的流程框架可以完全把Agile/DevOps涵蓋進去。

如下圖所示：

你可以看到DevOps實際上是被五大ITIL流程階段service Stategy, Service Design, service Transition和ServiceOperation，以及Continual Service Improvement包含在一起的，並沒有超出傳統IT管理的範疇。

下面這張圖用更加直接的方式把ITIL和Agile/DevOps聯繫起來：

釐清DevOps和ITIL之間的關係對企業進行的下一步非常重要。澄清了DevOps只是在原有的ITIL基礎上進行改進和優化，而並不是推到全面重來。畢竟當前企業IT的組織架構和工作流程主要是依據ITIL的理論設計。如果公司領導層認為進行DevOps轉型就意味著企業組織架構需要馬上進行大規模重組，將會極大的動搖改變的決心。

3. 瞭解什麼是Agile/DevOps：從理論到實踐

Agile是一種迭代以及快速響應的思想理論適用於軟體產品開發和交付。迭代就是整個理論的核心，坦白的說迭代開發並不是新鮮辭彙，但是Agile理論大大完善了迭代開發的理論，使之能夠被廣大的軟體開發團隊認可,並開發了具體的實踐方法如：Scrum等等。

DevOps進一步的擴展了Agile的思想，它把開發團隊和運營團隊的合作看成是實現軟體產品持續交付的必要手段，因此合作就是DevOps理論的核心。

簡單的來講：

Agile/DevOps = 通過開發和運營團隊的合作來支持軟體產品（IT服務）的迭代開發和持續交付的能力。

下面的這張圖描述這個過程的流程實現方法。

為了更好的體現持續交付以及即時用戶反饋兩個重要的過程，我建議你用下面這張圖來具體表現：

Agile/DevOps比較特別的地方是它是組織文化，流程以及工具的結合體，我在做流程管理工作的時候經常掛在嘴邊的一句話就是：「流程不依賴於工具「，但是在Agile/DevOps介紹中我都會著重強調三者的同樣的重要而且缺一不可：「工具，流程，組織文化」。缺少工具支持的DevOps無法實現「高速」；缺少組織文化支持的DevOps會讓團隊成員之間無法團結一致完成共同的目標。

既然如此我們就需要把這三個要素一起標註出來，如下圖所示：三個要素之間的關係基本上可以一目瞭然了。

到了這一步我們就可以考慮如何計劃在公司實施Agile/DevOps了，企業通常習慣採用KPI來衡量事情的進度，我們自然也不會例外，我推薦大家使用Agile/DevOps成熟度指標來引領變革的方向和步驟。

3. Agile/DevOps成熟度指標模型

從文章的前面可知，Agile/DevOps模式的需要以往工作的各個部門在一種全新的公司文化下更加緊密的合作，這就需要相關的人員改變那種以個人部門利益為主的思維模式，在考慮到這個因素後，People和流程，工具，組織文化一起成為Agile/DevOps成熟度模型的組成部分。

我們這可以依照下圖的模式來制定一個大致的變革計劃，從流程的建立，工具的採用，組織機構的轉變以及人員素質的提高四個方面來保證變革的成功。

當然這個工具是一個比較High-level的描述，在實際使用時需要進一步的細化，結合自己公司的實際情況和預期結果來制定更詳細的計劃。

最後，希望文章中的想法能夠為從事傳統企業IT轉型工作的人給予一定的啟發，從而幫助企業在新的數字時代站穩腳跟。

P.S 如果可能的話，我希望能繼續寫一些有關Agile/DevOps轉型的具體工作指南，也許這可以幫助更多的人敢於實踐。歡迎大家和我多多交流 ：）

---

DevOps究竟是什麼？

DevOps 是一種軟體開發方法、一種文化或一組最佳實踐，強調以用戶為中心，通過部門間高效協作和自動化工具實現基於軟體的業務持續創新。

打贏DevOps之戰，你需要知道：

DevOps的應用價值

• 支持高效交付，縮短軟體開發週期
• 快速獲取反饋，提升軟體質量及穩定性
• 改善公司文化，促進持續學習與溝通

廣闊前景 ——DevOps產品市場規模持續增長

計世資訊認為，未來五年，DevOps市場將以39.6%的複合增長率保持高速增長，至2024年，市場規模將達到103億元。

DevOps 實現路徑

• 遵循三大原則：

基礎設施即代碼、持續交付、協同工作

• 執行五大關鍵步驟：

1、選擇合適的價值流；

2、組建專門的團隊並培養能力；

3、設定目標和考覈指標；

4、開發工具鏈；

5、擴展到組織的其它價值流

DevOps落地的最佳選擇——AWS DevOps

• AWS DevOps = 無法壓縮的經驗 + Amazon DNA

• AWS 位居 2019 年中國DevOps產品市場領導者位置

AWS DevOps 工具鏈

覆蓋 DevOps 整個過程：

• 持續集成和持續交付

—— AWS CodePipeline、AWS Build、AWS CodeDeploy、AWS CodeBuild

• 微服務

——Amazon Elastic Container Service、Amazon Elastic Kubernetes Service、AWS Fargate、AWS App Mesh、AWS Lambda

• 基礎設施即代碼

——AWS CloudFormation、AWS OpsWorks、AWS Systems Manager、AWS Config、AWS CDK–Cloud Development Kit、AWS Controllers for Kubernetes

• 監控和日誌記錄

—— Amazon CloudWatch、AWS X-Ray、AWS CloudTrail

• 平臺即服務

—— AWS Elastic Beanstalk

• 版本控制

—— AWS CodeCommit

AWS DevOps 產品優勢：

• 快速入門，完全託管服務
• 專為擴展而設計
• 可編程，自動化，安全
• 大型合作夥伴生態，按實際使用量付費

???AWS 優惠大禮包限時發放中，快點擊領取！

AWS DevOps 幫助 Coursera 無縫遷移微服務架構

Coursera 是一家教育科技公司，致力於每個人提供世界上最好的課程，通過微服務改造實現：

• 無需花時間管理集羣，專註業務創新
• 軟體變更部署時間從小時級縮短到分鐘級
• 資源隔離允許各團隊獨立開發

Lululemon 使用 AWS 快速推出新功能和應用

Lululemon 是以健康生活方式為靈感起源的體育休閑服品牌，依賴於多種 AWS DevOps 服務：

• 構建起一個完全自動化的持續集成與交付系統
• 可在數分鐘內構建起開發環境
• 實現部署管道的極簡、可視化

如果你喜歡今天的分享，請多多點贊分享給身邊的朋友～

??趁現在，開啟雲端之旅！??【一鍵註冊 AWS 海外賬戶，體驗免費套餐】

---

DevOps 是一個很大的概念，目前數字化創新、互聯網+的背景下，實施 DevOps 有一個很好的契機，就是針對新上線的互聯網業務，採用微服務架構，使用容器作為工具，從此走上 DevOps 的快車道。

DevOps 沒有標準的流程，應該是一個優化的過程 - 尋找更合理的架構、流程來提升交付速度和軟體質量，而微服務和容器平臺在實現層面為 DevOps 上提供了相應的理念和工具。微服務把大型系統拆分成很多相對獨立的小模塊，每一個小模塊由獨立的團隊負責，它們的迭代速度和質量可以提升，同時對相應團隊的要求也會降低。容器，確切地說應該是 Kubernetes + Docker，容器鏡像是封裝和運行的標準，但 Docker 只提供了標準化交付的工具，結合 Kubernetes ，就搞定微服務的很多事情。

當然，把大型系統拆分之後，微服務的管理是一個很大的問題，此時需要新的工具。網易雲最近發布的輕舟微服務PaaS產品，其設計就是希望基於微服務、容器和 DevOps 三位一體的統一，提供一套完整的微服務解決方案，包括 DevOps、容器服務、API 網關、微服務框架、測試平臺和 AIOps 等六大模塊，支持企業圍繞微服務解決軟體高質量快速迭代的問題。

輕舟微服務的形成，也是經過網易內部多個大規模業務的生產環境驗證的。網易內部業務經過了工程化--&>服務化--&>自動化三級跳的歷程，目前正在向自動化的高級階段——智能化進發。

---

我覺得你說devops是為了促進溝通這個說法就不太準確。促進溝通不是最終目的，而讓整個開發、測試、運維過程流暢、高效纔是最終目的。

說到要實現的話，一味強調組織、文化哪些東西反而會讓你毫無頭緒。以我的經驗來看，直接從devops想要達到的目的出發，梳理從開發到運維的整個流程，藉助工具來完成流程每一步的工作，確保每一步都能不中斷的進行下去。所以說，devops要做的實際上是通過一個平臺將開發、測試、運維各個階段涉及的相關工具連通，管理好過程中各種製品、資源、服務的完整生命週期。那麼devops的工作就很明確了：要開發一個平臺，一個能讓研發人員自助完成devops過程中各自角色的工作的這麼一個自助平臺。

這裡還要明確，devops工作肯定是由運維主導的。

我們從開發提交代碼開始，一步一步梳理整個流程（省略了測試環節）：

首先，開發接手一個新項目，寫代碼肯定需要代碼管理工具，subversion或gitlab都可以，這個是標配不用多說。接下來代碼寫得差不多要提測了，開發提交代碼，要構建打包，那就要藉助相應的工具，比如java的話一般用jenkins。這個過程要提供一些輸入，包括版本的修改說明、版本號等，也會輸出製品包的路徑等信息。到這裡就完成了構建打包。

接下來，構建好的應用要部署到測試環境，這裡就涉及幾個問題：1、部署到哪裡，2、怎麼部署，3、怎麼修改應用配置？前面兩個問題由運維來決定和解決：運維提前指定要部署的主機；部署過程無非是同步文件、重啟應用，實現方式有很多，比如jenkins調shell腳本、ansible都可以做到。第3個問題是開發人員要面對的很現實的問題，最理想的狀態就是開發人員能自助查詢所依賴的所有服務的訪問地址並自行修改配置。

部署到測試環境後，開發人員需要知道部署成功還是失敗，如果失敗瞭如何排查，這就涉及到日誌查看的問題。如果部署成功，服務的訪問地址是什麼？如果直接通過jenkins來部署，這些信息就比較難以管理，所以我一般不推薦直接用jenkins來部署。實際上部署過程還有一些細節，比如服務如何註冊生效等等。

接下來部署生產環境，與測試環境部署完全相同。

新版本部署上線後，開發需要查看日誌，這裡同樣涉及到日誌管理。比如有elk這種方案，這就要求日誌路徑和格式要規範，否則elk無法收集。另外一個很重要的問題就是監控，包括進程守護和服務監控，這些屬於運維的範疇。

最後，要高效地完成這一連串的工作，必須建立在統一的規範之上。包括命名、日誌路徑啟停腳本等等。所以在做這樣一個平臺前，必須規範先行。

總之，我所理解的devops的理想狀態是，通過一個平臺，研發人員能夠方便地自助獲取所需信息並完成devops過程中各自角色的工作。

---

推薦閱讀：