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

時間 2019-12-06

標籤轉載金融行業 devops 解決方案概述简体版

原文原文鏈接

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 上，顯然是不現實的，也是不可行的。在這個過程當中，一定會面臨必定的困難與挑戰。併發

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

國內金融企業主要的開發發佈模式運維

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

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

按固定版本排期的開發模式測試

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

在這種模式中，每一個項目都會安排好本身的測試和發佈到生產環境的日期，而後按照本身的開發計劃進行開發併發布。可是爲了不多個同時發佈的項目重複執行屢次發佈，而且爲了合併對於同一個產品在不一樣項目上所被修改的代碼，對於在同一時間發佈的項目，在發佈前，會將多個項目的代碼或者二進制碼進行合併，而後一塊兒發佈。這種開發方式下，能夠解決固定版本排期中，緊急需求沒法快速發佈的問題，可是同時所帶來的則是頻繁的生產環境發佈，以及多個項目間的代碼衝突合併。spa
敏捷開發模式

對於部分比較獨立的產品開發，因爲不存在與其餘產品之間的強關聯，能夠獨立開發、測試、發佈，所以對於這些產品，就能夠採用敏捷的方式進行開發，即對單個產品按照必定的節奏進行開發、測試、發佈等。這是最爲理想的開發模式，可是對於金融企業來講，可以知足這種特徵的產品只是微乎其微，大量的產品相互之間都仍是存在很是緊密的關聯的。

固然，如今也有部分大型金融企業在積極探索整個組織都採用敏捷的方式進行開發，並取得了積極的成果，可是畢竟尚未成熟到足以供其餘企業模仿照搬的程度。

面臨的主要挑戰

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

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

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

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

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

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

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

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

應對挑戰，推動 DevOps 實施

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

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

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

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

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

工具平臺建設總體方案

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

該平臺必定要與企業目前所具有的基礎設施相結合，而不能像一些初創企業，立刻就對整個基礎環境及設施進行更新。例如，目前你們都已經很是清楚雲平臺的優點以及對於 DevOps 推動的重要性，可是，對於一個大型金融企業來講，並非說立刻就能夠將全部的應用都移到雲平臺上的。
該平臺必定要考慮到企業 IT 組織目前的組織結構現狀、人才技能現狀以及存量產品特色。風險控制和穩定是金融企業 IT 系統須要考慮的首要問題，這些限制致使了他們沒法像一些小型的初創企業同樣，一晚上之間即進行重大的 IT 組織調整，甚至產品更換。他們只能是逐步的穩健的創新，在創新的同時，還須要保持已有組織、人才以及產品的相對穩定。
該平臺必定要與企業目前已有的流程控制系統相結合，而不能獨立於現有的流程控制系統。現有的開發測試發佈流程，是協調整個組織行爲的重要工具，也是控制產品發佈風險的有力工具，若是自動化交付平臺脫離了這些流程的監管，就有可能變成規避現有流程監控的新工具，從而帶來更大的風險。

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

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

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

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

實施思路討論

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

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

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

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

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

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

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

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

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

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

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

實施難點及經驗總結

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

短時間收益與長期收益的平衡

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

針對這種狀況，在具體實施時，咱們既須要必定的耐心，也須要有抓有放，對於部分時間暫時容許，也願意積極配合的團隊先行推動，而對於目前比較抵觸的團隊，則先放一放，等到先行實施的團隊顯示出收益，中間觀望團隊積極推動時，慢慢就會造成必定的氣候，從而可以比較好的進行推動。
習慣的改變

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

這種狀況下，咱們更多采用的是先適應，後改造的方式，即在一些不影響平臺實施關鍵的點上，先去適應開發發佈團隊當前的工做習慣，從平臺方面主動作出一些調整，等開發發佈團隊嚐到收益以後，再反過來影響他們，讓他們作出改變和調整，這個時候，每每就相對容易一些了。
解決方案如何同時兼容多樣化的部署環境、構建方式及發佈方式等

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