DevOps在銀行系統里的神秘事實
概括地說，我的職業生涯就是做為一名軟件工程師在四家全球投資銀行中度過的，工作內容也很錯綜復雜，主要是維護一個用來處理各種交易、風險管理和中間辦公的網絡系統。我花了大約五年左右的時間來研究在這個行業里的軟件開發和DevOps兩方面的進展。
自從DevOps轉型咨詢公司Contino成立之后，我的工作內容就變的豐富多樣化了，包括零售，媒體，保險，教育和制造業，我主要是給客戶提供一些在DevOps、持續交付和敏捷實踐方面的咨詢建議，主要目的當然是為了加快軟件交付和發布周期。作為一個觀察者，我所掌握的資料和信息都是一手的，當和銀行業以外的IT行業相比之余，只要跟DevOps有關的，銀行總是顯得那么與眾不同，或者說格格不入，但它們有自己的挑戰，也有獨一無二的機遇。雖然很多人會覺得這很不可思議，但是銀行在使用DevOps的很多方面都表現出較高的成熟度，而且有足夠的能力提高DevOps在更多方面的使用能力。
本文首先會講述和同行業相比，銀行在DevOps轉型方面有哪些高效的舉措，有哪些表現不錯的地方，或者說有哪些搶得先機的案例。然后我會重點講講銀行在DevOps轉型過程中有哪些低成熟度和需要改進的點。
這是一種工程協作文化
DevOps的核心思想就是打破開發、運營、架構團隊和測試團隊之間以往各自為營的孤島關系，并且讓這些部門里的工程師們在人與人的基礎上更有效的合作。
銀行的IT部門一般和別的部門在組織架構和工作匯報流程上完全不同，而且有的時候還會受到地理位置的限制，團隊成員的遠程辦公等方面的障礙。令人欣慰的是，在整體的公司文化推廣上還沒有出現太多的磕絆。
在我的開發團隊中，我們通常與測試人員保持積極的關系，在高度協同的發展環境中一起工作。我們理解他們的，他們也理解我們的工作內容和流程，為了提供高質量的軟件，我們互相激勵，而且擁有相關聯的目標和KPI。
開發者對產品的歸屬感
由于銀行系統的特殊重要性，一旦失敗后將承擔嚴重的后果，所以開發者必須具備對產品的高度理解能力和對產品的擁有意識。同時要了解產品的服務方式，代碼如何更科學的部署，代碼和基礎設施如何實時互動，如何執行系統，如何監控系統，以及會出現哪些故障模式，解決方案是什么。這些都要了然于心。
開發者一旦把產品當做是自己的孩子或者杰作來看待，那么就一定能能催生出更具操作性的軟件產品，因為他們更了解如何維護產品，他們的代碼和部署技巧直接影響著產品的使用結果。尤其是在出現問題的時候，解決問題的速率更體現他們的責任心。
正因為有這樣的優秀的DevOps基礎，在銀行工作的IT開發者一般都具備較高的責任感，所以他們能夠提供高質量、可靠和可信的產品系統，而不僅僅是敲代碼那么簡單。這也是DevOps得以實行的最佳理由。
對全棧的理解
傳統的銀行系統開發團隊通常考核一個開發者的技能，都是結合開發者的開發技能、UNIX技能、腳本編寫技能、對數據庫層的理解，以及考察架構元素的性能和可擴展性。只不過后來對這些所謂的“全棧”工程師進行了優化。銀行技術團隊的開發人員了解服務器環境中，熟悉代碼的調整部署，并知道如何從前端到應用程序服務器，再到數據庫上來管理和運行他們的系統。
在很多情況下，前端和后端代碼，中間層代碼和數據庫代碼都是由相同的開發者撰寫的，其實這也存在弊端的，因為這樣極其容易出現問題很難查找的問題。對全棧工程師最好的理解就是能夠熟練掌握代碼技能、系統管理理念和基礎設施運維，這才是對DevOps有利的，因為它固有的簡化溝通流程，支持協作，并降低在大的團隊越區切換人員的必要性。
應用和企業架構的模塊化
今年我接觸了很多銀行組織，他們想要打破以往的以“整體應用”為精衛的模式，并將進入微服務作為轉移到DevOps和持續交付的部分組織工作。但是，說起來簡單，做起來卻需要大量的時間成本。在一般的銀行系統環境中有很多大的、傳統的應用程序，但是，銀行的技術部門都比較鐘愛面向消息的中間件，這是一種罕見的銀行應用程序，因為它不是圍繞Tibco，WebSphere MQ或Informatica等類型中間件而構建的。
這就給銀行一個很好的契機，幫助他們打破原有的老舊的應用程序平臺，可以獨立開發，測試和部署組件。但這并不意味著可以拋棄舊有的精銳之師，但是構建一個比較緊耦合的整體架構也算是一個很好的開頭了。
矛盾重重的技術遺產
銀行算得上是從古至今都和數字有關的一類機構，固然存在很嚴重的技術遺產問題。他們的平臺已經發展了幾十年，在許多核心部位都和主流技術相結合，但是目前這樣的情形正在遭受到銀行業務和技術不斷擴張所帶來的威脅：過去將不同的技術部署在不同的環節，而很多應用程序是用不同的技術搭建的，可以說就是一個將現成的和定制的軟件混合在一起。銀行的技術遺產看上去就像是一根鏈子上有很多大大小小的球一樣，嚴重限制了銀行快速前進和靈活轉型的能力。
從協作和自動化的角度來看，技術遺產對DevOps的實施確實是一個不小的挑戰，例如，專家人員，遺留技能會對原有的關鍵人物產生較強的依賴關系，從而不利于我們正在創建的較為開放的開發合作環境，勢必也會影響到銀行系統的構建，測試和自動化部署和發布周期，違背了DevOps所倡導的快速、輕量級和可實驗的理念。
至關重要的開發者體驗
在銀行工作過的開發者體驗對DevOps來說是相當痛苦的，感覺就好像你是在不斷地跟你的工具、基礎設施和網絡進行斗爭一樣，而不是利用這些東西更好的完成工作。例如，Vagrant是一個DevOps工具，利用它可以創建可重復的開發環境來運行虛擬機桌面。最近我試圖在最后幾個銀行工具中使用Vagrant，但常被告知虛擬桌面系統沒有足夠的能力運行這個程序。臺式機也被阻止使用Vagrant的某些關鍵功能。最后，不得不拋棄這一工具，并轉移到其他的平臺上。
為了達到快速發展，高效利用現代自動化的DevOps工具，開發團隊和發布團隊需要從開發到產品的路徑來對桌面環境有更多的控制能力。通過開放的環境（同時保持必要的保障），可以允許開發者利用這些工具和方法，DevOps會讓優秀行為從底層突現出來，而不是自上而下地做出規定。
結論
當我跟客戶一起對DevOps進行探討交流的時候，我們談論一般都是改進的方法，流程的優化和技術的創新。我相信在一些更具挑戰性的領域——文化，架構準備，敏捷成熟度和最佳技術實踐上，銀行的評分都是比較高的。總之，銀行是現代DevOps軟件交付方式最好的實現場所。
關于作者
Benjamin Wootton 是英國咨詢公司Contino的聯合創始人兼首席顧問，幫助公司采用DevOps方法和持續交付工具。
來自： http://www.infoq.com/cn/articles/devops-in-banking