上一篇文章《深入思考軟體工程，開啟 DevOps 之旅》，詳細闡述了我們對軟體工程和 DevOps 的了解，并且明确 DevOps 已是軟體工程領域集大成者的結論。
那麼，作為企業的 CIO，身處資訊化浪潮中，面對 DevOps 的命題應該如何應對：
企業能從 DevOps 中擷取什麼收益？
企業應該如何規劃 DevOps 體系并選擇合适的切入點？
企業應該選擇什麼樣的 DevOps 平台、方案、廠商？
希望閱讀完本篇文章，能給您一些啟發。
一、企業 DevOps 體系建設背景
在 “VUCA” 的數字化時代，企業的生産經營由原來的“完全按照規劃完成工作計劃、部署執行、跟蹤”的過程，開始向“在行進過程中不斷探索和調整，用最小代價逼近戰略目标”演變。因而，更快的生産、銷售、傳遞客戶價值、擷取回報、持續改進，自然成為企業緻勝的法寶。
而對于企業來說，無論處在什麼行業，要想擷取客戶并向客戶傳遞價值，都離不開 IT 技術與軟體。如何通過 IT 技術與軟體，達成“更快的生産、銷售、傳遞客戶價值、擷取回報、持續改進”的價值傳遞體系？DevOps 作為目前軟體工程界的集大成者，無疑是現在最佳的選擇。
2018 年 7 月 26 日，工信部中國資訊通信研究院牽頭《DevOps 标準：研發營運一體化成熟度模型》在聯合國 ITU-T 正式立項。成為全球首個 DevOps 國際标準。DevOps 标準評估體系主要包括靈活開發管理、持續傳遞、技術營運、應用設計、安全及風險管理、系統和工具等部分。
《研發營運一體化（DevOps）能力成熟度模型》系列标準是由中國資訊通信研究院牽頭，雲計算開源産業聯盟、高效運維社群、BATJ 等頂級網際網路公司以及各大金融、通信企業共同制定的國内外首個 DevOps 系列标準。
2017 年 7 月釋出的《中國金融業資訊技術“十三五”發展規劃》提出：“優化金融資訊技術治理體系，提升資訊技術服務水準”。
2016 年 7 月銀監會釋出的《中國銀行業資訊科技“十三五”發展規劃監管指導意見》中提出：完善銀行研發管理體系，并要求自主研發團隊超過 100 人的銀行應達到中等以上的軟體過程能力成熟度。
在國内外先進科技企業的 DevOps 實踐影響下，很多國内大中型傳統企業也開始同步接收、嘗試，推行 DevOps 實踐。以信通院 DevOps 能力成熟度評估認證為緯度統計，截止 2021 年 Q3，通過信通院 DevOps 能力成熟度評估的組織及項目累計已超過 100 餘個。
艾瑞咨詢 2020 年的“中國 DevOps 應用發展研究報告”，将企業對于 DevOps 的訴求做了總結和歸納，按照“傳統行業”和“科技行業”的分類方法做了如下闡述：
傳統行業的主營業務并非軟體的研發與營運，IT 上的人才和基礎設施相對薄弱，是以這類組織的數字化水準整體相對較低。在數字化轉型的大趨勢下，找到适合企業的高效數字化轉型道路将意味着在市場競争中取得先機；
在傳統行業中，金融和能源等行業由于資金充足、技術實力相對領先，且對于各類軟體和線上應用的需求較高，在傳統行業中走在數字化更新的前列，也是率先引入 DevOps 方法和工具的行業。
另外，對于政府部門而言，将能夠更好地建構數字政府和數字政府服務體系，提高地區乃至全國的資訊化基礎設施水準。而新零售、智能制造等近年來逐漸興起的網際網路+行業也正在積極拓展網際網路能力建構管道以及市場優勢。
相較于傳統行業以及公共事業機構，包括軟體、電商和電信營運商在内的資訊科技行業一直以來是 IT 科技創新的領跑者。軟體開發和運維架構是支撐上述企業業務營運的核心能力，但也因為其 IT 架構複雜、團隊龐大，在管理和協同優化上面臨諸多困難。
DevOps 理念和工具的有助于科技類企業更快地響應客戶需求、傳遞客戶價值、統一 IT 環境、提高團隊反映能力和研發品質，是企業提高市場競争力的核心助力。目前我國的頭部科技類企業的軟體部門大都是 DevOps 的主要踐行者。
企業在進行軟體研發與管理時，内部環境典型反映出的問題與痛點如下：
以 DevOps 價值流的視角來看，從業務部門提出需求，到 IT 部門收到需求、分解需求、計劃排期、開發測試到上線，中間會經曆多個部門、多個團隊、多種角色的協作。在這一過程中，會存在着很多可優化的地方（對于産生價值沒有幫助的活動或投入、等待時間都是浪費）。
DevOps（平台）和（平台内嵌的）靈活實踐方法可以解決從需求到傳遞過程中的協同反模式：重文檔輕交流、圍繞文檔的低頻重型交流/大型需求澄清會、需求澄清不清晰難以了解、需求跟蹤困難。通過 Scrum 及其他方法和工具去完成更靈活化、精益化的需求開發協作過程。
在沒有實施 DevOp 和流水線的情況下，團隊需要花費大量時間在編譯建構和測試上。缺乏自動化編譯建構、自動化測試的方法和有效工程實踐、沒有工具去支撐重複的、可自動化的、占用大量人工時間的必要工作，都是在研發測試過程中存在的浪費。
通過 DevOps（平台）和（平台内嵌的）流水線的建設，團隊可以節省大量的編譯建構及測試時間。比如可以通過自動化的編譯能力，實踐每日建構、基于分之合并的建構等實踐方法，讓代碼內建的時間提前，以控制代碼的品質、降低內建的風險；通過可以與流水線內建的自動化的測試能力，實踐自動化（功能）單元測試、自動化接口測試、自動化業務場景測試等實踐方法。
代碼是軟體開發活動産生價值的初步成果物。而在目前複雜的業務需求和系統架構環境下，大規模并行開發是很常見的場景。進而很容易産生代碼管理混亂、 SCM 工具管理混亂等問題。具體表現如：沒有統一的代碼管理工具、缺乏有效的分支管理政策、代碼分支政策混亂、團隊對 SCM 工具掌握程度深淺不一、缺乏從需求到代碼的跟蹤等。
通過 DevOps（平台）和（平台内嵌的）代碼管理方法，可以幫助企業建立組織級的代碼管理規範和方法，統一代碼管理工具，有效降低因代碼管理混亂而導緻的各種風險。
軟體制品的釋出是軟體傳遞到使用者手中并展現價值的最後一步。對于承載着複雜場景、關鍵業務的應用系統來說，傳統的全人工釋出存在諸多缺點，雖然我們可以通過部署指導文檔來輔助，但仍然有着各種無法避免的問題，比如：釋出過程易出錯、無法跟蹤釋出過程、每個應用有自己單獨的釋出工具和釋出規範、組織級釋出管理規範和執行流程難以執行和跟蹤等等。
DevOps（平台）和（平台内嵌的）自動化釋出能力，不僅可以幫助團隊将應用的複雜釋出過程自動化、可視化、可重制性，同時還能實作組織内部統一的應用釋出規範、應用制品規範、制品晉級流程等，将釋出标準流程融入到系統中，降低合規檢查的成本和人工部署的風險。
傳統研發作業模式下，缺乏有效的研發過程基礎資料、研發過程資料散落在各處沒有統一歸集無法整體綜合分析，過程改進無從下手。
DevOps（平台）和（平台内嵌的）度量分析能力，可以幫助組織和團隊将散落在研發工具鍊中的各種資料統一歸集，積累整理有效的研發過程基礎資料，整體綜合分析。結合研發效能實踐的整體優化理念，在有效資料的基礎上逐漸改進研發能效。
無論是傳統行業還是科技行業，随着企業經營向上發展，對 IT 的要求必然會越來越高。這展現在 IT 團隊規模、應用數量、基礎設施數量的增長，數量的增長又帶來了管理複雜度和技術複雜度的增長。是以除非是非常小的創業團隊，企業必然會産生通過“建立研發管理規範、方法”來向 IT 要效能内在需求。
但中小型的組織往往缺乏組織級研發管理規範，而中大型組織的規範就算制定出來，往往也難以充分跟蹤、貫徹執行，最後成為挂在牆上的智語。
通過 DevOps（平台）的建設和 DevOps 實踐的應用，可以将組織級的研發管理規範貫徹到項目中的“最後一公裡”，從需求流程、協同作業、代碼管理、制品管理、制品晉級、釋出流程、資源配置等研發過程中核心場景和周邊場景涉及的流程規範标準化、系統化、規範化、可視化。
二、企業 DevOps 體系知識精要
DevOps 的本質是一種以更快傳遞價值為目标的優秀軟體工程方法合集。了解 DevOps 的本質，并不能讓你獲得某些訣竅或者具體的工作方法，而是給你一把鑰匙，幫助你思考事物的原理，并且在發生新的情況時讓我們有所準備，能夠找到如何去處理的方法。
靈活宣言創始人之一 Ron Jeffries 在他的《軟體開發本質論》一書的封面上，對軟體開發給出的總結是：“追求簡約、展現價值、逐漸建構”。而這一目标的實作，則依賴“Ron 金字塔”來完成。
《軟體開發本質論》第 1 章節選：
價值：所謂價值，就是“那些我們想要的東西”。
我們會自下而上從金字塔的底部開始，在将産品劃分為小塊的基礎上讨論如何指導、組織、計劃和建構産品，同時重點關注産品的品質。我們将以此為基礎,最終創造價值。
指導：通過組建以創造價值為己任的團隊來實作價值的創造，是以需要確定團隊成員知道客戶需要什麼，以及客戶留給我們的開發時間。我們通過觀察實際建構出的産品來對團隊的工作進行指導。
組織：我們需要圍繞産品的功能特性來進行組織，因為這些功能特性可以使我們更好地計劃，并更快地創造出價值。我們選賢任能,并幫助他們提高技能。
計劃：根據所需功能特性的前後順序來對其進行選擇，以此來控制項目的進展，這樣就能夠及時創造價值。
建構：通過逐個實作功能特性來建構産品。這樣就能夠頻繁地進行價值的傳遞，同時能夠盡早、經常地看到項目的進展。
劃分：将功能特性劃分為小塊，使每一塊盡可能小，前提是它們仍然有價值。這樣就能夠盡早地建構出有用的産品,并在傳遞日期到來之前對産品進行優化與提升。我們時刻準備傳遞産品。
品質：采取必要的措施，以確定生産出來的産品設計優秀、品質精良。這樣就能夠不斷、持續、永久地創造價值。
我們根據《DevOps 實踐指南》（DevOps Handbook）一書的描述，整理了 DevOps 的核心原則。
如果我們把價值從生産到生效的過程用流水線來比喻的話，那第一個原則就是要“流動起來”，并且在品質成本等限制條件下越快越好。軟體隻有在傳遞給客戶/投入使用時，才開始産生價值。是以針對整個工作流程的優化，要圍繞全局目标，而不是局部目标。
由于軟體本身具備的“隐匿性（invisibility）”，軟體研發的成果（可運作的軟體）很難在完成前被看清楚。再加上工作項的流轉非常容易，可能就是滑鼠點點，不同團隊很容易因為各種原因而将工作項“踢來踢去”，存在的問題也自然被傳遞到下遊。這些問題都是很難被察覺的，直到工作計劃中的檢查點、客戶傳遞産品的那一刻、生産環境出現故障。
是以為了能夠識别工作在哪裡流動、排隊或停滞，就需要講工作盡可能地可視化。通常看闆（SprintBan、Kanban 等）是比較好的實作方式。通過 Ban 将各種工作展現出來。
通過将工作項都放進容器（SprintBan），并可視化地展現出來，利益幹系人更容易從整體（所有工作項）出發，确認優先級。對團隊來說，也能夠更聚焦重要的工作，增加工作項吞吐量。
軟體開發語境下的在制品，指的是未開發完成/傳遞完成的軟體成果物“制品”，又可以進一步泛指為進行中的工作項。
制造業的日常工作是由生産計劃預定義好的，生産計劃的變更、打斷非常顯眼，而且代價極高。但軟體開發工作卻是另一番景象，工作計劃安排通常是動态的，或者說經常出現臨時的安排打斷已有計劃。更糟糕的是，軟體開發工作被打斷的後果和代價似乎并不可見，即便它對生産效率的影響相比制造業更甚。
使用看闆管理工作項時，可以非常容易的識别并管理在制品的狀态和數量。通過管理并行的工作項，還能更容易發現工作中的阻礙。通常來說，軟體開發中相當一部分優先級的沖突是同時給一個人在同一時間段配置設定了很多工作項導緻的；另外就是沒有管理好并行工作項間的複雜依賴關系。
建立平滑而快速的工作流的另一個關鍵點，是通過小批量的模式完成工作。降低單個批次工作項的數量，以小批量的模式推進，也是精益中一個非常重要的經驗，目的是縮短前置時間和提高傳遞物品質。
對于（軟體開發）技術價值流而言，大批量的副作用和制造業一樣。越是偏向瀑布的開發模型，開發成果按照計劃時間一次性地內建、測試、釋出，會導緻問題的集中爆發，引起下遊工作環節的大規模混亂。
在技術價值流流轉的整個過程中，會經曆不同部門、不同角色的不同人員互相協同才能完成相關的工作，包括需求的流轉、代碼的流轉、制品的流轉、環境的配置以及各種支撐的流程和工具。而一項工作在團隊建設交接時都需要投入大量的工作，包括溝通協調、不同團隊的工作優先級排序、沖突處理等等。在這些過程當中不可避免地會存在資訊的丢失、失真和工作項的延時、等待。
為了縮短前置時間、提高吞吐量，我們需要不斷地識别系統中的限制點，提高工作産能。反之，如果優化限制點之後的工作重心，那麼這種優化就是無效甚至負面的，會讓下遊的工作重心倒逼上遊而産生更大的問題。這也是在 DevOps 和精益理論中的所謂“全局優化”和“局部優化”的差別。
在 DevOps 實踐中，常見的限制點可能包括但不限于：需求審批、環境準備、代碼內建編譯、制品部署、測試準備與執行、不合理的架構等。
精益中對浪費的定義是“使用了超出客戶需求和他們願意支付範圍的任何材料或資源的行為”。TPS 先驅之一的新鄉重夫定義了制造業裡的 7 中浪費類型：庫存、過量生産、過度加工、運輸、等待、移動和缺陷。
如果映射到 DevOps 的領域中，我們大緻可以如下對應：
庫存。未傳遞的在進行中的需求；
過量生産：需求蔓延、傳遞了非必要的需求等；
過度加工：過度設計；
等待：資源協同過程中存在的人員等待；
運輸、移動：過多的流程環節、不合理的協作模式等；
我們的目标是建立安全可靠的軟體工程體系，這對業務複雜的系統來說尤其重要。正常情況下我們發現問題和糾正問題的時機，是生産過程中發現軟體缺陷或阻塞點時候，或是軟體投産後在生産環境發生故障時等等。
通過在價值流群組織中建立起快速、頻繁、高品質的資訊流和回報機制，可以讓系統更安全。在更早的時間，以更小的代價發現并修複問題，在災難發生之前解決問題，并營造團隊的學習氛圍。利用問題和失敗在實踐中學習，而不是懲罰和責備。
我們必須承認，複雜系統是客觀存在的，複雜系統中的故障也是客觀存在且無法避免的。是以實事求是地說，我們的目标是建立一套工程體系，讓團隊能夠無所畏懼地工作，敢于發現并提出問題，確定在災難性後果發生之前，能夠快速發現錯誤并修複錯誤，并從中學習提升的機制和文化。
軟體研發過程中，經常會出現由于缺少快速回報機制而導緻不好的工作結果。比如典型瀑布模型下的測試工作，要等到代碼開發完成以後開始，而在這之前得不到任何需求準确性和軟體品質回報。
回報回路不但讓問題的快速探測和修複成為可能，還能輔助我們分析如何防止問題本身或類似問題的再度發生。在這個過程中，不僅價值傳遞着得到了保障，團隊也得以向學習型組織演進。
群策群力的邏輯源于豐田生産系統中的“安燈繩”。當安燈繩被拉動時，團隊上司就能第一時間得知并着手解決問題。如果問題不能在很快的時間内解決，就會停掉生産線，調動整個團隊一起協作，找到問題并解決問題。
讓所有人參與的原因有二：
複雜系統出現的問題，很難完全通過某個個人或者外部工具将問題完整、準确、清晰地呈現出來，特别随着時間的推移。再次面對問題時的資訊讀取、了解等等都是代價非常大的。隻有靠群策群力才能最大程度的消除遺漏。
讓所有人都參與，能夠讓團隊得到更加深入的實踐和知識，把問題處理過程轉化為學習過程，有助于提升長期團隊價值傳遞的品質和問題處理效率。③組織開展新工作有助于實作持續內建和部署，這就是技術價值流中的單件流。
我們需要價值流中的每個人在他們控制的領域裡發現問題并解決問題。通過這種方式，可以把品質控制、安全責任和決策機制都置于開展工作的場景裡，而不過分依賴外圍高層管理者的審批。“讓一線呼喚炮火”。
品質無效的例子：
需要其他團隊完成一系列本可以需求方自己用自動化可以完成的工作；
編寫大量含有可以細節，且在寫後不久就過時了的文檔；
……；
精益定義了我們必須為兩類客戶而設計：外部客戶，為軟體價值付費的人；内部客戶，接收我們目前工作輸出并進行下一步處理的人。
在技術價值流中，我們不僅應該為外部客戶做好功能設計與實作，也應該為内部客戶做好非功能性的設計（可測試性、可配置性等）。
在複雜系統中工作時，精确地預測往往是不現實的，總會有意外發生。當發生意外時，如果組織的做法是傾向于點名、責罰，甚至羞辱，那結果隻會更壞：
流程會變得更加複雜以杜絕問題發生；
組織會變得更加官僚（而非細緻）、資訊更閉塞，甚至發生逃避問題責任、滋生自我保全意識等問題。
在技術價值流中，努力打造安全的工作系統，追求健康、充滿活力、具備競争優勢的團隊和文化，才可能避免這些問題。消除職責，能夠有效促進學習型組織的建立。
如果團隊沒有能力或醫院去改進現有流程，那就會持續飽受困擾和折磨，甚至痛苦指數還會與日俱增。因為當團隊花費很多精力去實施臨時解決方案以應對突發情況時，會産生比平時更多的隐患（技術債務）。
更好的做法是：通過明确預留的時間來改善日常工作，包括預留時間來償還技術債務、修複缺陷、重構和優化代碼和環境、優化工作流程等。通過持續改進，幫助組織更好地完成價值傳遞、在市場上擷取更大的競争優勢。
一旦在局部範圍内取得了成果，就應當把它分享給組織内的其他人，讓更多的人受益。特别是将隐性知識（很難通過文檔或溝通傳遞出來的知識）轉化為顯性知識，進而幫助團隊吸取這些專業知識并在實踐中應用。
低績效組織的日常是想方設法環節問題，疲于應付問題。高績效組織則通過改善日常營運，持續地引入張麗提高生産效率，同時在系統中注入更大的彈性，來實作或達到更加的效果。
在技術價值流中，通過縮生産部署的前置時間、提高測試覆寫率、縮短測試執行時間，甚至在必要時結構架構，都屬于在系統中引入類似張麗的做法，也都能提高開發人員的生産效率和應用可靠性。
上司者幫助一線工作和在日常工作中發現并解決問題，這種方式實際上就是豐田生産系統的核心，也是學習型組織、改善套路和高可靠性組織的核心。
在技術價值流中，這種實驗和疊代改進的方法，不但能指導我們改進内部流程，而且還能指導我們不斷地進行實驗，保證建構的産品能為内部（下遊）和外部客戶帶來價值。
我們試圖從全景業務流程、知識技能圖譜兩個部分，來概況 DevOps 體系的整體内容。DevOps 全景業務流程，是我們根據自身的了解、産品與客戶需求所所繪制的。而 DevOps 知識技能圖譜引用了來自 IDCF 組織整理的 DevOps 技能樹，發表于其官方網站上。
三、企業 DevOps 體系實踐規劃
從中短期規劃目标來說：宏觀上，我們希望通過 DevOps 體系的規劃和建設能夠幫助企業提升 IT 效能、更快的業務響應速度、更優質的業務連續性。微觀上，我們希望通過可以“平台化、可視化、自動化、資料化”的各種工程實踐，幫助技術價值流上的各個工作中心提升工作品質、效率和體驗。
從長期規劃目标：我們希望借助 DevOps 體系持續改進提升組織流程和工程實踐的流動性、回報效率，并建立學習型組織。逐漸從傳統管理模式向 IT 靈活轉變，最終達到業務靈活的目标。
每個企業對于軟體研發的組織模式都是有所不同，在不同的組織結構下， DevOps 的規劃的内容也會有所不同，其中最大的差異還是由于組織文化、曆史沿革、行業特性等因素造成的自身在組織架構和部門間工作邊界的差異，具體到工程實踐上時，差異反而會小一些。
本小節我們将以一個沒有實施過 DevOps 的組織為限定條件，按照 DevOps 體系的業務領域子域作為劃分邊界，羅列出在做規劃時針對不同領域的工作要點清單。
工作要點如下：
展現需求從最初提出到完成的全過程；
展現需求的拆分情況；
展現需求的分析、協作、流轉情況；
展現需求的回報及狀态跟蹤過程；
需求工件指的得是需求活動的輸出物，包括需求檔案、測試用例檔案。
需求工件的形式采用 Backlog、User Story 等方法作為核心的溝通媒體;
需求工件的内容最好要有恰當（足夠小）的粒度，以便做到清晰、有效、便于溝通、可協商、可估算;
需求及需求工件是有一定彈性的，同時彈性有恰當的邊界，能與組織的需求變更流程相适配。
展現靈活開發方法中利用疊代、看闆等方法與方法與工具的能力;
展現開發過程中對于不同類型需求的分類管理能力。
展現測試用例的完整結構。包括用例名稱、類型、步驟、附件等關鍵要素，并具備用例分組能力；
展現測試計劃的完整結構，包括計劃名稱、關聯版本、關聯疊代、計劃周期、涉及用例集等關鍵要素；
展現缺陷管理能力。包括缺陷的錄入、修複、跟蹤；
測試用例有完整的編寫、驗證、管理機制。
測試用例在設計結束時即可完成大部分内容，最終在開發結束前全部完成。
測試用例在上線前應全部驗證通過，并且單元測試等基礎類測試用例可以自動化完成。
測試用例在其生命周期中應一直保持更新與釋出軟體版本的需求一緻。
具備組織級的現代 SCM 工具，并通過工具實作組織内代碼的統一管理及工具運維，實作單一可信資料源。
代碼分支政策管理。根據具體代碼工程的實際情況，可以使用 SCM 工具實作恰當的分支政策。必要場景如能與 DevOps 平台/開發管理平台內建以降低開發工程師使用成本，則更佳。
代碼版本政策管理。根據具體代碼工程的實際情況，可以使用 SCM 工具實作恰當的版本管理能力。必要場景如能與 DevOps 平台/開發管理平台內建以降低開發工程師使用成本，則更佳。
具備體系化的代碼管理工具運維政策。包括備份與恢複機制、完整性與一緻性保障政策。
編譯建構采用流水線而不是手工方式執行。
流水線的實踐可以與代碼分支管理政策密切配合，最好是通過 DevOps 平台完成可視化的流水線編排、執行、跟蹤。
有明确的建構規則和管理計劃。
流水線的日常運作由團隊自身負責。
具備組織級的現代制品管理工具，并通過工具實作組織内代碼的統一管理，實作單一可信資料源；
基于制品管理工具，具備有效的組織級制品庫空間規劃及使用規範；
基于對應的場景，制品的上傳、下發、晉級與 DevOps 平台/流水線可以實作自動化的流轉；
具備體系化的制品管理工具運維政策。包括備份與恢複機制、完整性與一緻性保障政策。
使用自動化部署工具，而非通過人工部署；
自動化部署工具展現面向應用、服務的自動化部署與編排；
自動化部署工具具備腳本自定義能力、腳本參數定義能力、服務部署測了能力；
曆史部署情況可追溯。
在需求、資源申請/釋放、部署等與組織内部周邊系統有銜接的業務領域，能夠平滑對接，滿足企業流程要求；
對于金融業等存在監管的場景，能夠根據具體情況滿足其合規要求。
羅馬不是一天建成的，DevOps 是作為研發管理之重器，也并非一朝一夕就可以建設好、運用好。對于大多數的組織來說，完整 DevOps 體系的建設和應用之路也需要做好規劃，特别是有一些企業對于 DevOps 除了實踐應用之外還有過信通院能力成熟度模型的需求，還要為過級評估工作留出充分的時間。在目前很多企業年度預算制的開支架構下，DevOps 項目需要做好規劃與路徑，做到有明确的短期、場景的目标與實作路徑，才能更好地完成項目，達成預期。
四、博雲 DevOps 解決方案概覽
對于向落地 DevOps 的團隊群組織來說，所處行業、組織文化、軟體形态、團隊現狀、内部環境等等因素的不同，都會導緻其研發管理和工程實踐的不同。而如何在充分考慮現實因素（目标、時間、成本、資源）的情況下，去選擇一個切實有效的路徑和方案，是落地 DevOps 項目成功的關鍵。是以對于一個 DevOps 項目來說，并非買一套産品就萬事大吉。
站在企業視角，需要一個什麼樣的 DevOps 服務商？
我們認為，DevOps 是軟體研發/腦力創造領域相關工作的 “ERP” ，需要的不僅僅是一套平台，而是包含業務咨詢服務、統一平台産品、工具鍊産品、內建開發服務等等一系列持續的服務。
博雲基于自身在金融、工業、企業、政務等行業的經驗，總結了一套可以為不同行業客戶落地的傳遞方案，願意與各個行業的朋友持續交流切磋。
參考資料：
1. 《中國金融業資訊技術“十三五”發展規劃》（中國人民銀行印發）；
2. 《中國銀行業資訊科技“十三五”發展規劃監管指導意見（征求意見稿）》（銀監會印發）；
3. 《艾瑞咨詢：2020 中國 DevOps 應用發展研究報告》；
4. 工信部信通院微信公衆号：中國信通院 CAICT；
5. 高維社群微信公衆号：高效運維；
6. 《軟體開發本質論》（Ron Jeffries）；
7. 《DevOps 實踐指南》（Gene Kim, Jez Humble, Patrick Debois, John Willis）；
8. 《No Silver Bullet》（Brooks, 1986)；
9. https://idcf.org.cn/Home/；
（參考資料按在本文正文中引用的先後順序排序）
博雲 BeyondDevOps 平台開放試用，歡迎掃描下方二維碼或點選文末閱讀原文申請試用。