架構師講述：KeyBank如何將交付從3個月變成一周
Raffaele Spazzoli是紅帽PaaS和DevOps咨詢部架構師，在加入紅帽之前 ，他在KeyBank銀行擔任解決方案架構師。他所在的KeyBank銀行是一家擁有190年歷史、近兩萬名員工、遍布15個州、一千余分行的銀行，支撐全球多個國家和地區的業務。根據客戶的不同需求，IT團隊針對不同的項目進行開發，但由于在銀行內部存在著大量傳統的IT系統，產品化的敏捷交付難以實現，這些項目的交付周期往往以季度計算，交付周期長，風險大。后來，在Raffaele團隊的實踐下，KeyBank銀行實現了將交付周期變成一周，在本文中，他將以第一視角講述這段神奇的經歷。
起初的費時費力
這是超大型地區銀行KeyBank將每季度向生產環境部署縮短到每周部署的歷程。在這個過程中，我們全部采用開源軟件從WebSphere遷移到Tomcat，并使用OpenShift作為私有Linux容器云平臺。并且是在數字渠道現代化項目中做到這一點的，這是銀行在當時最重要的項目。
數字渠道現代化項目的基本訴求，是將以Servlet為基礎、在內部MVC框架之上開發完成，并在Java 1.6以及WebSphere 7.x上運行長達15年之久的Java Web應用程序遷移至更為現代的Web體驗，由此創建一款新的移動Web應用。
經過長久的發展擴張，KeyBank銀行原有Web應用程序的維護成本、特別是針對實際SLA要求的調整開銷越來越昂貴。這是一款典型的單體式應用程序，而我們的架構升級目標在于創建新的API層，借此將表示邏輯（Web或移動）與業務邏輯拆分開來。很明顯，要達成這項目標，我們首先需要實現持續集成與部署流程的全面現代化。
我們最初只能按季度發布新功能，整個發布過程費用昂貴、任務艱巨。之前的發布方式可以說充滿了“儀式感”——我們還專門整理出一份Excel電子表格，其中囊括約70項手動操作步驟。因為費時費力，工作只能在周末完成，搶在周一上午之前讓系統恢復在線狀態并進行常規業務處理，這給我們帶來了巨大的壓力。
為此，我開始研究像谷歌、亞馬遜、Facebook等科技巨頭是如何管理自己的功能發布工作。很幸運，我有機會參加Netflix的運營方法研討會。事實證明，從任何一項功能發布指標來看，如頻率、成本、代碼完成時間以及代碼生產部署時間等，這些組織的效率能比我們高兩到三個數量級。
于是，我決定把交付頻率從季度發布轉化為每周發布。坦率地講，我對這個目標沒有太認真地考慮，但我一直將它牢記在心。在我看來，銀行數字渠道有希望實現每周發布。這個速度還沒快到硅谷初創企業那種近乎荒謬的程度，但又已經足夠快，強迫我們必須擺脫以往會議、手動測試加手動發布那種老派的運作模式。換句話說，這樣的目標足以敦促我們做出改變。
我在項目中扮演的角色是解決方案架構師。為此，我推出了包含完全無狀態REST服務層與兩個前端的新架構：一個是基于AngularsJS的Web應用程序，另一個則是基于Ionic框架的移動應用（與Web應用大體基于相同的代碼）。
改革進行中
首先，我要求對JDK進行更新（由版本6升級到版本7）。只有JDK完成更新，我才能使用JAX-RS編寫REST服務。運營團隊起初比較抗拒，但在意識到當前版本的JDK即將壽終正寢時，他們果斷著手推進升級工作。整個過程大概用了6個月時間。
我還要求使用Liberty作為應用服務器。WebSphere在開發人員的筆記本電腦上啟動速度太慢，一般在5到10分鐘左右。考慮到即將開始實施的大項目，我們必須盡可能提高敏捷性與速度表現。有人提到，要想在筆記本電腦上使用Liberty，唯一的可行方案就是繼續在生產應用服務器上使用WebSphere。這樣的結論令我們難以接受，因為我們單憑直覺就知道提高產次對于加快運營速度的重要意義，否則任何對后續環境棧中的主要元素（IT、QA、生產等）做出變更時，必然會產生大量無法及時修復的bug。
為此，我需要一款分布式緩存工具，借此保證服務層始終保持完全無狀態（而且無會話）。另外，出于效率的考量，我們同樣需要緩存的加持。目前還沒有官方支持的分布式緩存平臺，但以后一定會有，我們得早點邁出這一步。
以上一切訴求，讓我意識到這條路在規劃階段就存在問題。開發團隊無法以正確的方式表達自己的需求，運營團隊則太過強調維持正常的運行狀態——而在這兩者之間，解決方案架構師也沒能組織起有效的對話，自然不可能以富有成效的方式做出領導與指引。
我覺得需要徹底改變這種模式，并且摒棄交付團隊以前采用的復雜服務請求流程，改為由運營團隊交付基礎架構。另一個需要設立全新基礎架構的團隊。在其中一項研究中，我們發現運營團隊要想建立一套全新的基礎設施，需要滿足大約四百項要求……不說要求本身能不能達成，光是溝通工作就足以拖垮兩邊的團隊。
于是我轉變了思路，覺得交付團隊不妨自行配置基礎設施。我得出的結論是，最好是選擇一套私有云基礎設施。為此，我開始獨立進行研究，探索哪些工具選項最適合這種需求。與此同時，一支小型運營團隊剛剛解決了一堆令人討厭而且長期存在的網絡問題。利用這批空閑勞動力，我們正好可以在KeyBank內部嘗試建立私有云。
根據研究，我們確定Kubernetes是目前最理想的容器私有云平臺。因為我們已經意識到容器在技術層面擁有遠超虛擬機的優勢，所以虛擬機云平臺這一選項被直接否決。我們尋找為Kubernetes提供專業支持的機構，最終發現紅帽及其OpenShift平臺是極為可靠的選擇。之后的工作開始順利推進。與紅帽合作之后，我們在4個月內就建立起了生產預覽，并在7個月內開始向第一批客戶提供生產支持。
我們將應用程序從WebSphere遷移到了Tomcat，將REST引擎由Wink轉換為更流行的Jersey（此前在WebSphere中無法使用），而后添加了Hystrix，并向可用性策略中引入了斷路器模式。最后，我們還使用Redis實現了分布式緩存。
但技術問題永遠不是最困難的部分。我們的目標是實現每周發布，因此必須實現基礎設施的自我配置能力與不變性。
持續交付管道實現全面自動化
為了達成這些目標，我們需要為部署在OpenShift中的應用程序定義所有權與支持模式。實際上，如果開發團隊希望以自助方式管理基礎設施，那又該由誰來提供技術支持？在觀察谷歌、Netflix以及Spotify的業務體系后，我們發布了一套模型，其中由交付團隊負責管理所需的基礎設施（即在容器中添加的內容），而運營團隊則負責保持OpenShift穩定可用——很明顯，一切業務服務的可用性，都將直接由底層OpenShift的可用性所決定。此外，為了保證所有權明確清晰，我們決定將特定項目的OpenShift配置文件同項目的其余源代碼統一起來。
我們采用以下邏輯在Jenkins中建立了一個流程：
• 每十分鐘，源代碼repo會接受一次輪詢；一旦出現任何變更，則觸發新的build。
• 此build將運行單元測試以及創建項目Docker鏡像所需要的其他一系列操作步驟。完成之后，此Docker鏡像永遠不會進行后續變更。這也是我們實現不變基礎設施的核心要點之一。
• 在解決方案的每個層上單獨進行一系列集成測試。通過隔離，我們可以模擬出依賴項。以此為基礎，我們即可脫離下游依賴項的可用性與測試數據質量，單獨運行一系列測試。這些測試將在臨時環境中運行，這一點在OpenShift中并不難做到。
• 在IT環境中運行一系列集成測試。
• 我們每天在QA環境上部署一次之前成功完成測試的build。QA環境用于手動探索性測試以及手動（后續計劃改為自動）負載測試。
• 最后一步則是每周在生產預覽環境中進行一次部署。這一步需要人工核準。
在生產環境中部署需要KeyBank的多次批準。這些批準以會議形式完成，即人們展示將部署的內容，而高級領導者簽署發布命令。這個過程不適合我們，因為我們沒有足夠的時間每周舉行三次會議（的確，這需要三個不同部門確信發布版本的合理性）。我們可以改變這樣的流程，并且同意：如果一個版本僅影響OpenShift內部的組件，我們就自動批準該版本的發布。
最后一部分工作，就是建立起完整的自動回歸測試套件。很快，我們從一系列痛苦的錯誤當中認識到，除非擁有完整的回歸測試覆蓋范圍，否則我們永遠不可能達到每周發布的目標。具體來講，手動測試團隊的處理速度，跟不上每周發布帶來的巨量更新內容。
為此，我們以行為驅動型開發（BDD）原則為指引建立起測試框架。我們選擇Cucumber作為DBB工具。Cucumber的最大優勢，在于允許用戶以自然語言（英語或其他語言）編寫測試用例。我們決定發揮這一優勢，由業務分析師團隊負責編寫測試用例。以此為基礎，我們得以并行推進業務代碼與測試代碼的開發，而不再像過去那樣必須先完成業務代碼、之后才能進行（手動或自動）測試。我們還使用Selenium對Web應用進行瀏覽器與操作系統版本測試，并通過Appium對移動應用進行設備型號及操作系統版本測試。
總結
現在，我們已經對自己的發布流程擁有更強的信心。每周四上午，我們都能拿出一些最新成果，并通過OpenShift開箱即用的滾動部署功能實現零宕機發布。困擾了我們很多年的問題就這樣被OpenShift的內置功能解決了……我們還啟用了自動規模伸縮功能。通過在負載測試期間對這項功能進行的深入測試，我們意識到現有系統，或者至少在OpenShift中部署的各系統層內，完全可以通過橫向擴展為負載峰值提供正確匹配的實例數量。
這在銀行內部被認為是一個優秀的成功故事。下一步，我們將把同樣的流程引入其他項目，逐步將更多工作負載遷移到OpenShift當中。
