2009 年 6 月份，John Allspaw 及 Paul Hammond 在速度大會 (Velocity) 上分享了在 Flickr 中如何通過加強 Dev（開發團隊）和 Ops（運維團隊）之間的協作，從而加快應用部署頻率的演講 。隨後，關於 Dev 和 Ops 之間協作的討論一直在 Twitter 上持續進行，當年的 10 月份，在 Twitter 上首次出現了 DevOps( 開發運維一體化 ) 一詞 。在隨後的幾年裏，DevOps 不僅引起了工程界的大量關註和實踐，同時，也吸引了大量學術界人士的興趣。Gartner 2015 年所做的調查結果表明，目前已有 29% 的企業在使用 DevOps。圖一所示為 Gartner 對各 IT 技術發展熱度預測的研究，根據其研究，目前 DevOps 正處於其發展階段的高潮期。

圖 1. Gartner 關於各 IT 技術發展熱度的預測

DevOps，其主要目的就是通過消除開發部門與運維部門之間的壁壘，從而使得一個企業的 IT 組織能夠在敏捷地適應市場變化的同時，將一個企業的業務能力通過創新性的解決方案快速地從 IT 部門的開發過程推向用戶。它主要利用了精益的思想，通過消除 IT 部門整個產品交付流中所存在的浪費及障礙，從而達到快速交付的目的。

對於一個較大的組織或者企業來說，其 IT 部門有其多年形成的固有組織結構、文化氛圍、開發及發布流程、基礎架構及產品體系等，在這種情況下，試圖像新創的公司一樣，很快就將整個企業的 IT 組織轉型到 DevOps 上，顯然是不現實的，也是不可行的。在這個過程中，必定會面臨一定的困難與挑戰。

大型金融企業在軟件交付上通常面臨的挑戰

國內金融企業主要的開發發布模式

對於國內主要的金融企業，雖然有部分企業已經或者正在推行敏捷的開發方法，但是目前普遍采用的仍然是瀑布的開發方法（從立項、開發、測試到發布幾個階段順次執行），並且主要是以項目為單位進行人力資源的組織和開發過程管理。

一個項目主要是實現一個或者若幹個需求，由項目經理主導，組織若幹開發人員進行開發（對於大的項目，則可能還會跨越多個大的開發部門，包含多個小的開發小組）。需求主要是由業務單位提出的。在具體執行時，不同的業務單位都會提出不同的業務需求（不同的業務需求會成立不同的項目），而且從每個業務單位的角度來說，都會要求其所提出的需求具有絕對的優先級，因此，在開發階段，就不可避免地需要並行進行多個項目的開發。項目雖然是多個，但是其背後所修改到的代碼及產品則可能是同一個，故而整個產品的交付過程自然而然就被分裂成了兩個階段：開發測試階段和投產階段。在開發測試階段，最主要的是以項目為單位進行開發測試以及部署（每個項目的代碼獨立部署），而在投產階段，雖然也是以項目為單位進行相關的流程管理，但是在具體發布時，則是以產品為單位進行部署安裝（不同項目中涉及到同一個產品的代碼合並到一起發布）。由於項目與產品兩個管理維度的切換，在實際的開發發布模式上，就主要演變出了如下三種模式：

1. 按固定版本排期的開發模式

   這是模式是按照一定的固定時間周期，統一將在此期間開發的所有項目代碼合並到一個版本中進行測試並集中發布到生產環境，按照時間周期的不同，有的稱為月度版本（即一個月度一個版本），有的稱為季度版本（即一個季度一個版本）。在這種模式之下，雖然開發過程是以項目為單位進行，但在真正的投產階段卻是以集中方式進行的，對於需要快速反饋響應的需求，也必須等到整個版本發布的時候才能統一發布。

2. 按項目排期的開發模式

   在這種模式中，每個項目都會安排好自己的測試和發布到生產環境的日期，然後按照自己的開發計劃進行開發並發布。但是為了避免多個同時發布的項目重復執行多次發布，並且為了合並對於同一個產品在不同項目上所被修改的代碼，對於在同一時間發布的項目，在發布前，會將多個項目的代碼或者二進制碼進行合並，然後一起發布。這種開發方式下，可以解決固定版本排期中，緊急需求無法快速發布的問題，但是同時所帶來的則是頻繁的生產環境發布，以及多個項目間的代碼沖突合並。

3. 敏捷開發模式

   對於部分比較獨立的產品開發，由於不存在與其他產品之間的強關聯，可以獨立開發、測試、發布，因此對於這些產品，就可以采用敏捷的方式進行開發，即對單個產品按照一定的節奏進行開發、測試、發布等。這是最為理想的開發模式，但是對於金融企業來說，能夠滿足這種特征的產品只是微乎其微，大量的產品相互之間都還是存在非常緊密的關聯的。

當然，現在也有部分大型金融企業在積極探索整個組織都采用敏捷的方式進行開發，並取得了積極的成果，但是畢竟還沒有成熟到足以供其他企業模仿照搬的程度。

面臨的主要挑戰

長期以來，固定版本排期及項目排期的開發模式，為大型金融企業業務的快速發展提供了強有力的 IT 保障，同時也確保了產品的質量和運行風險。但是，近年來，隨著大量互聯網企業，特別是移動互聯網企業的沖擊，大型金融企業也不得不面臨在業務模式加快創新的同時，需要 IT 團隊加快開發節奏，快速推出滿足業務發展需求的產品。而這種需求正對金融企業現有的 IT 開發模式提出緊迫的挑戰，根據我們的研究，這些挑戰主要體現在如下的三個矛盾中（圖 2）。

圖 2. 主要的開發發布模式及面臨的主要挑戰

1. 為保證產品質量而設定的過長的開發測試流程與快速叠代交付的迫切業務需求之間的矛盾

   在傳統的產品開發過程中，哪怕一個再小的需求的開發上線都必須經過立項、測試以及生產發布幾個階段（如圖 2 所示），特別是測試階段，更是需要至少一個測試輪次的時間。在固定版本排期的開發模式中，則再急迫的需求也必須等待大版本的集中上線才能夠發布到生產環境中。而從業務的角度，為了適應快速的市場變化，對於部分與用戶交互比較頻繁的需求，特別是生產環境中發現的亟待修復的缺陷，則需要其能夠快速發布，而不是等待冗長的開發測試流程。所以，這種一般化的冗長的開發測試發布流程已經無法適應互聯網時代產品快速叠代交付的現實需求。

2. 大量手工操作與金融企業對於產品質量一致性、穩定性嚴苛要求之間的矛盾

隨著業務的發展，目前對大型的金融企業來說，對於與用戶交互頻繁的產品，單個產品只部署在一個或者少量幾個服務器節點上是遠遠無法滿足大量的並發訪問需求的，因此，一個產品往往都會部署在多個服務器節點，甚至是幾十個服務器節點上。盡管部署節點多，對於企業本身來說，最基本的要求就是不同節點在所部署產品的版本、配置等等上必須是保持一致的。 而由於 IT 發展時間的限制，目前整個開發發布過程中，還存在大量的手工操作環節，特別是產品的構建以及到生產環境的部署，對於手工操作來說，每次發布包的構建以及每個節點的發布都是一次全新的操作，很容易出現失誤或者不一致的地方。故而，大量的手工操作已經無法適應面對大量節點部署時的一致性以及穩定性要求。

3. 開發團隊對於流程簡單性、快速性的現實要求與風險管控之間的矛盾。

從開發團隊的角度，其根本目的就是滿足業務方的需求，能夠快速的將開發完成的功能發布到生產環境中，特別是在業務部門對發布頻率加快的需求與日俱增的壓力下，他們對於開發測試發布流程中所存在的各個管控點就往往頗具怨言，認為有些把控環節不僅延緩了發布時間，而且還浪費了他們的時間，他們希望流程越簡單越好。而從項目管理及運維的角度，在每年發布的幾千甚至上萬個版本中，只要其中有一個版本存在問題或者發布失誤，就是難以容忍的，因此，為了防止可能存在的風險，在現有大量依靠手工操作的現實下，他們必須千方百計挖掘可能存在的風險點，並設置各種嚴格的評審點進行把關，以防止可能的風險流入到生產環境中。因此，現有由於風險管控所疊加上來的流程管控已經無法滿足開發團隊對於流程簡單性及快速性的需求。

應對挑戰，推進 DevOps 實施

顯然，目前大型金融企業所面臨的挑戰既有技術層面上的，也有開發模式以及流程管理上的，試圖采用單一的方法進行應對是不可能的，當然也無法一蹴而就進行解決。本文認為，為應對這些挑戰，從整個 DevOps 實施的角度，需要通過圖 3 所示的三個階段逐步進行實施。

作為實施的第一步，顯然，消除大量的手工操作，構建一個持續交付的流水線平臺是最基礎也是最迫切的，只有通過流水線平臺的自動化和持續流動，才能保證在不同階段、不同節點上產品發布的一致性和穩定性，同時，也才能消除由於人工操作所引入的人為風險，同時提高效率。

圖 3. 推進 DevOps 實施的三個主要階段

作為實施的第二步，則需要對現有的開發模式及產品架構做進一步的優化，否則，整個流水線是很難順暢地流動起來的。例如，如果不調整固定版本排期的開發模式，則即使自動化程度再高，緊急需求的上線仍然需要等待整個版本的上線；而對於項目排期的開發模式，在上線前，多個項目代碼或者構建包的手工合並也是必不可少的；在傳統緊耦合的產品架構下，想要做到自動化的增量叠代發布，也是非常困難的，而每次都將整個產品的所有代碼進行發布也是極不現實的，這些其實都是實現整個 DevOps 持續交付過程全自動化的障礙。因此，在構建好持續交付的流水線平臺後，其第二步就是開發模式及產品架構的優化。當然，如果沒有第一步的自動化的持續交付平臺作為基礎，則由開發模式調整所帶來的發布次數增多也是無法完全用手工完成的。

在通過工具自動化的方式實現產品的持續交付後，由於人工操作的減少，自動化及流水線操作的提高，包括操作過程可追蹤性的實現，快速自動回滾操作的實施等，這個時候，在完整的開發測試交付流程中，有些管控步驟可能就是多余的，是可以優化的。因此，實施的第三步就是對整體開發測試發布流程進行優化，去掉冗余的人工評審步驟，從而實現企業級的 DevOps 持續交付流水線。

工具平臺建設整體方案

在 DevOps 實施的三個階段中，第一個階段，DevOps 交付流水線平臺的搭建是最基礎也是非常關鍵的步驟，對於金融企業來說 ，由於其對產品質量、運營風險的嚴格要求，以及自身產品的復雜性、特殊性，該平臺的構建需要考慮如下問題：

1. 該平臺一定要與企業目前所具備的基礎設施相結合，而不能像一些初創企業，馬上就對整個基礎環境及設施進行更新。例如，目前大家都已經非常清楚雲平臺的優勢以及對於 DevOps 推進的重要性，但是，對於一個大型金融企業來說，並不是說馬上就可以將所有的應用都移到雲平臺上的。

2. 該平臺一定要考慮到企業 IT 組織目前的組織結構現狀、人才技能現狀以及存量產品特點。風險控制和穩定是金融企業 IT 系統需要考慮的首要問題，這些限制導致了他們無法像一些小型的初創企業一樣，一夜之間即進行重大的 IT 組織調整，甚至產品更換。他們只能是逐步的穩健的創新，在創新的同時，還需要保持已有組織、人才以及產品的相對穩定。

3. 該平臺一定要與企業目前已有的流程控制系統相結合，而不能獨立於現有的流程控制系統。現有的開發測試發布流程，是協調整個組織行為的重要工具，也是控制產品發布風險的有力工具，如果自動化交付平臺脫離了這些流程的監管，就有可能變成規避現有流程監控的新工具，從而帶來更大的風險。

基於以上考慮，本文設計了如圖 4 所示的 DevOps 流水線交付平臺架構。在該架構中，我們將整體的流水線交付平臺分成了四層：基礎架構層、流水線工具平臺層、流水線引擎層以及流程管控層。

基礎架構層是一個企業最基本的基礎設施，既包含了存量的硬件平臺，也包含了雲計算平臺，首先，只有在基礎實施上實現彈性可伸縮、消除開發測試環境的差異，才能實現真正的 DevOps。而流水線工具平臺則是為企業的代碼開發、測試及發布提供了一個端到端的工具平臺，通過該工具平臺的自動化和相互間的無縫對接，實現了從軟件代碼配置管理、自動化構建、測試到快速的自動化發布。流水線工具分布在整個開發測試發布過程的各個階段，需要不同的角色在不同的階段進行配合操作，而且這個操作過程需要置於企業現有流程管控系統的管控之下，因此，我們還需要流水線引擎層，用於根據整體開發測試發布不同階段的需要，驅動底層的工具平臺進行產品的代碼管理、構建及部署，同時對上又與企業的流程管控系統對接，使得整個操作過程置於流程監控之下。

圖 4. DevOps 流水線交付平臺整體架構圖

顯然，在 DevOps 流水線工具平臺實施的四層架構中，其核心是流水線工具平臺層的搭建，對上，該工具平臺需要通過流水線引擎與現有的流程管理系統對接，對下，則需要兼容現有的各種程序語言、開發發布模式、構建方式，以及存量硬件和雲平臺的基礎設施。在本系列文章的後續各篇中，我們將重點圍繞流水線工具平臺的搭建進行闡述。

實施思路討論

流水線交付平臺各層實施順序

對於第四節所述工具平臺的實施，不同的企業具體的實際情況可能會略有差別，因此，不可能對所有的企業都采用同樣的思路進行實施；同時，對於大型企業來說，由於產品形態的多樣化，開發語言的廣泛性，各開發團隊情況的差異性，該工具平臺的完整實施也是不可能一蹴而就的。在具體實施時，需要根據具體情況選擇制定相應的策略進行實施。總結而言，有兩個維度的問題需要考慮，一個是這四層的實施順序，另一個則是對於流水線工具平臺層中，各個具體工具的實施思路。

從上到下的四層中，根據邏輯上的耦合性，我們將其分成了三組，流程管控層自成一組，稱為第一組，流水線執行引擎及流水線工具平臺層作為一組，稱為第二組，基礎架構自成一組，稱為第三組。

對於目前大多數的金融企業來說，現在基本都已經存在相應的開發測試發布管控流程，不同的只是成熟度不同而已。因此，流水線管控這一層更多的應該是考慮如何對已有流程進行優化。開發測試發布流程中各個階段的劃分和銜接肯定會影響到流水線執行引擎的實施，因此，這一層的實施可與第二組同時進行，或者在第二組實施之前，但不能在第二組之後。

基礎架構層中如果存在雲平臺，則對流水線工具平臺層的影響是流水線工具平臺需要擴展到對雲平臺的兼容，因此，第三組與第二組之間既可同時實施，也可先後實施，只不過，如果是第二組先實施之後再實施第三組的雲平臺，則第三組實施後，需要對第二組進行擴展。

第二組的兩層中，流水線引擎是基於流水線工具平臺進行的，因此，流水線執行引擎一定得在流水線工具平臺之後實施。因此，完整的實施順序如圖 5 所示。

圖 5. DevOps 流水線各層實施順序

流水線工具平臺層實施思路

在流水線工具平臺層中，對於開發測試發布過程的不同階段，相應的存在配置管理、代碼構建、靜態分析、自動化測試、構建包管理、自動化部署、監控等眾多工具，其實施過程相對較長，也比較復雜。在具體實施時，存在兩種可能的思路，一種為逐點突破，然後再全部連接成一個完整的工具平臺。這種思路下，會對企業整體的交付流水線進行分析，找出其中最大的痛點（如配置管理、構建管理或者自動化部署等），然後重點實施，並推廣至全公司，接著再繼續實施下一個痛點，通過一個一個痛點的實施，最後再連接成一個完整的 DevOps 交付流水線工具平臺。

第二種則是從項目突破，先找一個比較典型的項目或者產品作為試點，在該項目或者產品上構建完整的工具平臺，並進行深入實施，在實施成功後，再推廣至其他的項目或者產品。這種方法的特點是，先考慮比較小的範圍和需求，在獲取到好的收益後，再考慮更廣的範圍和需求，對原有工具平臺做優化。

當然，具體企業有具體企業的固有特點，包括文化、組織結構、現有技術水平等等，真正的實施思路還需要具體根據具體的情況進行更具個性化的制定。

實施難點及經驗總結

過去的幾年中，本文作者所在團隊一直在某些金融企業實施本文所述的 DevOps 流水線工具平臺，根據實施過程的經驗，我們認為，在實施過程中，主要存在如下幾大難點：

1. 短期收益與長期收益的平衡

   對於開發人員和運維人員來說，每天的工作任務都非常重，其最關心的是眼前的問題能不能解決，當前的效率能不能馬上提高。而任何一個新工具，新方法的實施都不可避免地需要投入一定的時間進行學習、適應，會對當前的工作造成影響，甚至短期內反而會降低效率。故而在實施初期會引起部分團隊成員的抵觸和反對，這個時候，如何將開發人員及發布人員當前迫切關心的短期收益與整個平臺實施後的長期收益結合起來就成為實施推進的難點之一。

   針對這種情況，在具體實施時，我們既需要一定的耐心，也需要有抓有放，對於部分時間暫時允許，也願意積極配合的團隊先行推進，而對於目前比較抵觸的團隊，則先放一放，等到先行實施的團隊顯示出收益，中間觀望團隊積極推進時，慢慢就會形成一定的氣候，從而能夠比較好的進行推進。

2. 習慣的改變

   任何一個人，都會有其熟悉的行為習慣和方式，當需要其作出改變，適應新的方式時，誰都會作出抵觸，都會不願意。而任何工具和方法的實施，都不可能避免地會對團隊成員原先的習慣、方式產生影響，需要他們作出改變。盡管從原則上，也許團隊成員是認同新工具、新方法的理念的，也是願意改變的，但是在具體作出改變的，則仍然是會產生各種各樣的擔心、顧慮，從而影響實施的進度。

   這種情況下，我們更多采用的是先適應，後改造的方式，即在一些不影響平臺實施關鍵的點上，先去適應開發發布團隊當前的工作習慣，從平臺方面主動做出一些調整，等開發發布團隊嘗到收益之後，再反過來影響他們，讓他們做出改變和調整，這個時候，往往就相對容易一些了。

3. 解決方案如何同時兼容多樣化的部署環境、構建方式及發布方式等

   任何一個新平臺的實施，其最理想的方式就是在試點之後，即可馬上進行大面積的推廣和實施，但實際上，對一個大型的 IT 組織來說，不可能所有的團隊都采用相同的方式進行開發，也都采用相同的程序語言，相同的構建方式等，同時，開發測試及運行環境也肯定會存在一定的差異，這些都影響了平臺實施的推進進度。在後續的系列文章中，我們將從技術的角度，具體闡述我們如何去應對這樣的挑戰。

總結

本文作為系列文章的第一篇，主要講述了作者在過去幾年的 DevOps 實施歷程中，所經歷過的大型金融企業所面臨的共同挑戰，以及在應對這些挑戰時所采取的思路和 DevOps 實施方案。後續的系列文章將就具體的方案進行詳細敘述。

文章出自：《金融行業 DevOps 解決方案概述》

[轉載]金融行業 DevOps 解決方案概述