內容來源：2018 年 05 月 05 日，英捷創軟 LEANSOFT 創始人兼首席架構師徐磊在“DevOpsDays Beijing 2018”進行《強監管環境下，傳統金融企業如何挑戰互聯網》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發佈。
閱讀字數：5740 | 15分鐘閱讀
獲取嘉賓演講視頻及PPT，請複製：http://t.cn/RsTpgnb，粘貼至瀏覽器即可。
摘要
金融企業，特別是傳統金融企業是這幾年DevOps運動的“重災區”，這是我的親身體會。在過去的5年裡，我持續為多家大型傳統金融企業提供了DevOps/敏捷/軟件工程諮詢服務，深深體會到的這個行業所面臨的互聯網挑戰和自身的掙扎。我希望為大家講述一些真實的用戶故事，從中總結一些我的心得，也是我這些年幫助客戶踐行DevOps的兩大法寶：粒度和解耦。
要生存就要挑戰
1995年比爾蓋茨曾寫過一本書《未來之路》，書中有這樣一句話“Banking is necessary，Bank is not”。對此相信很多人都深有體會，尤其是最近幾年，出現了很多非傳統銀行提供的金融服務，如日常使用的支付寶、微信支付等。
上圖是普華永道2017年的調研數據，數據顯示除零售業外、傳統金融是受互聯網影響最嚴重的行業。之所以近兩年金融業會成為DevOps“重災區”，很大一部分原因要歸於它目前所面臨的嚴峻挑戰。
需要提到的是雖然我們一直在談論敏捷，而敏捷從本質上就意味著要擁抱變化。但是實際上從人的本性來看，很少有人會主動去尋求改變。變革的契機一般都是由各種外部因素引起，比如不滿足現狀、受到外部壓力、遇到挑戰等。這同樣也是金融業對DevOps如此感興趣的外因，他們意識到如果再不進行改變整個行業就有可能會被顛覆掉。
BATJ在金融行業的佈局
BATJ基本上在所有的行業中都有佈局，其中金融領域尤為密集。造成這種情況的原因有兩個，一是金融行業中尚存大量未被挖掘的機會，二是金融行業中現有的從業者反應不夠快。BATJ這樣的公司能夠提供一些傳統金融業所沒有的更加便利的服務，這就是所謂的機會，而這些機會卻未被本行業的從業者發現。
注意這裡所說的是整個行業，而非行業中的單獨個體。因為儘管行業中的精英分子非常活躍，但是行業本身受到體制影響和多年的慣性已變成了集體無意識的狀態。這也是在金融業中實施DevOps的難點，即如何讓集體從無意識轉換成集體有意識，自主的發現缺點機會，然後改進。
傳統銀行的危機和挑戰
傳統銀行首要面臨的挑戰就是客戶脫媒，銀行正在失去同用戶的接觸機會，互聯網將中間的流程給隔開了，銀行所能獲悉的僅是資金的流入和流出，並不能明確的瞭解到用戶的行為。
第二個挑戰是解綁，比如現在我們所使用的很多金融產品其實都是由互聯網公司組合起來的，一些理財產品背後的基金有可能是來自多家銀行、多個渠道，而由單個銀行所提供的產品服務不再被青睞。這種情況的出現，造成銀行或傳統金融業對整個市場變化的認知越來越弱。
傳統組織中如何激活創新
如何挖掘傳統金融的巨大潛力
雖然所有的渠道都已被互聯網佔據，但實際上銀行的數據庫或交易系統中還是保留了大量有價值的信息資產。關鍵在於為何銀行沒有去挖掘這些資產，而是由外圍的互聯網金融創新企業去做這些事，這點是金融行業特別需要思考的問題。
上面是關於南航叫停第三方平臺（OTA）值機的相關文章，這整件事其實就是航空公司意識到了第三方平臺對自身所造成的衝擊而採取的應對措施。
OTA平臺在顛覆傳統行業方面比互聯網要早的多，大約在15年前就開始進行了。但現在主動權正慢慢的交回到了航空公司手上，因為提供價值的基礎在航空公司手裡。有一點我們要明確，雖然過去十幾年互聯網在經濟發展中佔據很重要的地位，但中國經濟體的佔比中互聯網其實並不高，我們的經濟仍然是傳統行業在支撐。
未來的中國或世界經濟中互聯網依然會快速發展，但它的真正價值在於探索，當探索到一定程度後，最後還是要由傳統行業來收網。
建立內部創新機制
傳統金融要想打破現有局面，除開要解決外因，還要突破內部因素，也就是前面提到過的集體無意識狀態。這裡有幾點關鍵要素，其中一點就是技術重塑和戰略手段，也就是常說的數字化轉型，這也是經常被傳統行業所提到的。
我一直認為金融行業是強力依賴IT的非IT行業。有趣的是金融企業的業務人員從來不覺得自己是幹IT的，而金融企業的IT人員也從來不覺得自己是幹金融的。
相信很多銀行的技術人員都有這樣的疑問，明明某個服務實現起來很簡單，但為什麼是由其他公司提出而不是銀行。其實如果真的將它放在現有的制度環境中你就發現實現的過程中會困難重重，這種情況類似於肌肉不受大腦指揮。
這種感覺就好似一個長期不做體育運動的人，突然拿起球拍的時候，大腦裡面還是自己的20歲左右的身體狀態。但是當球飛過來的時候才發現，大腦已經使用20歲的意識去指揮身體，無奈的時候身體已經是40歲的狀態。結果 … … 可想而知。
接收不確定性
要實現大腦和肌肉的協調，首要是能夠接受不確定性。反脆弱理論也告訴我們，如果希望在危機出現的時候能夠作出迅速有效的反應，就必須隨時應對危機，而不是避免和延遲危機的影響。
一般認為的軟件“生產製造”過程是從需求、設計、計劃到開發、測試、集成、發佈這一整套流程，但這樣的認知存在一定偏差。
我們類比下汽車的“生產製造”過程，首先製造原型車，然後到生產線生產。生產線的本質是不停的複製相同的產品。相對的，軟件的需求、設計、開發、測試、構建、交付其實是原型車的製造過程，真正的軟件生產製造過程是在僅僅把安裝包複製和粘貼的過程，因為只有這個過程中軟件不會發生任何變化。
簡單來說，所謂的“生產製造”過程是重複製造同樣的產品的過程。而軟件的開發過程是每次都製造不一樣的產品。問題在於，現在的軟件行業一直嘗試用管理重複製造過程的方法來管理軟件開發的不停創造的過程，這也是為什麼傳統的項目管理方法應用到軟件管理上會有諸多問題的根源。這個問題，是認知層面上的錯誤，也就是我們所說的“不確定性”的問題，大多數軟件行業從業者希望使用“確定性”過程的管理方法來管理這個“不確定性”過程；這種認知層面的錯位導致了基本上軟件開發中的所有問題。
這種情況在金融行業尤其嚴重，金融從業者不願意去理解軟件開發的實質，軟件從業者發現要為這些門外漢解釋清楚軟件開發的機制太困難，最終造成了二者認知的錯位。這其實也是很多企業實施DevOps過程中遇到的部門牆的根源性問題。
敏捷從認知層面的基礎就是要接受不確定性，由此延伸出來的管理思路異於傳統，是自下而上的，依賴知識工作者的探索和實踐形成管理流程，屬於經驗性管理思路。
而傳統的管理思路依賴於管理者的主觀意識定義管理流程，屬於預定義的管理思路。
這種管理思路上的轉變能夠幫助企業從根本上接受“不確定性”並構建內部適應機制和創新氛圍。
但是，它與傳統銀行的管理思路是大相徑庭，背道而馳；傳統管理思路下的管理人員會感覺失去對整個組織的控制，因此非常懼怕從認知層面推薦敏捷，這也是為什麼我們看到了很多所謂的偽敏捷，只使用了敏捷的形式而沒有貫徹敏捷的思維。而實際上，要實現真正意義上的敏捷，就必須經歷這個“放棄控制”造成“混亂”的過程，只有組織進入一定的“混亂”狀態，才能自己尋找到正確的方向，管理者的角色在這個過程中實際上是在進行“管理升級”，從事務性的控制變成機制的控制，這才是更高級別的管理形式。
某大型傳統金融企業的轉型歷程
1期實踐
這裡我們看一個實際的案例，它是2015年我參與的某國有四大銀行的行級項目，由行級領導直接管理，目的同樣是為了探索創新實踐。基於這樣的背景，整個項目第一次實現了端到端應用生命週期管理，真正做到用一個工具一種方式從需求的起點管理到終點，並且對整個過程進行了完整的跟蹤。第一次形成了跨部門的協作，第一次實現了全部代碼的集中構建發佈。
最終整個項目過程用到了很多與DevOps、敏捷相關的概念，但卻並沒有提到DevOps，參與到項目中的時候也沒有人告訴我這是在做DevOps轉型。
在這樣的背景中可以看出，如果想要做DevOps就先要拋棄大工程、大計劃，因為這本身就是確定性思維的體現。想做DevOps轉型，隨時可以開始，你要做的只是要允許事情發生，而不是計劃要發生什麼。作為領導要想團隊去創新，就要默許團隊去犯錯誤。
2期實踐
在第一期項目結束後大概1年後，在同一家銀行內我們又做了的一些嘗試，到目前為止（視頻演講時間）這個團隊共完成了15個迭代。
這裡，我想分享幾個團隊中的片段，希望通過這些片段幫助大家瞭解一個“真正”的敏捷/DevOps轉型項目是應該怎樣做的。我知道大家一定想聽到比如總體轉型規劃，企業級目標一類的內容；但我要說的是那隻能讓你失望了，因為這些在這個項目裡面都沒有。我們做的只是一些點點滴滴的改進。
最初因為團隊正在使用微軟的Team Foundation Server，所以想引入電子看板。不過考慮到整個團隊並沒有敏捷開發經驗，所以在我建議下使用了物理板代替，目的在於讓團隊先形成自己的一套機制。我當時的考慮也很簡單，以我對一個並不熟悉工具也不熟悉敏捷的團隊的瞭解，我覺得在一開始引入電子看板只會給團隊造成拖累，而且對於這個集中式開發的團隊而言，也沒有遠程協作的訴求，物理板可以允許團隊迅速低成本的進行改進，最適合一個敏捷小白用戶。
以上通過物理看板進行過程改進的過程持續到了第1輪投產結束，此時團隊又想進行一些新的改變，首先他們發現看板最右邊的測試列基本上每個月都會積壓一堆卡片然後又同時跳出，所以提出讓測試人員從間斷性介入變成持續性駐場。這一措施使得故事流動變得更快，進而引發了對代碼部署速度改進的需求，因此CI/CD也被逐步引入。
隨著CI/CD流水線逐步投入使用， code Review頻率從之前的每月變成了每天，使得傳統的流程化code Review機制無法滿足保證代碼的質量訴求。於是又引入了git編碼工作流，同時為了能夠對代碼訪問權限進行更細粒度的控制（因為git本身不具備文件級別的權限控制）將原有的配置庫從1個拆分為15個，每個git庫拉取分支，然後做pull Request，在pull Request上進行code Review。
傳統行業的開發團隊應該都有類似編碼規範的手冊，但可能很少有團隊去認真執行，直接原因是沒有充足的人力去監管檢查。然而更深層的原因可能是工具用的不對，或是流程限制了能力的發揮。隨著以上CI/CD + Git Pull Request流程的引入，對於編碼規範和代碼質量的檢查機制也逐步落實，通過使用靜態代碼檢查工具，為開發團隊提供更加頻繁，少量多次的反饋。
估計有朋友已經發現了，上面的迭代圖中還有個灰色的“其他團隊”。這個團隊其實先於現在的團隊嘗試了git。當時，我們發現git pull request雖滿足安全性和監管的要求，但需要改變現有人員的工作方式，會是一個比較大的挑戰，好在該團隊的負責人採納了這種方式。正是以此為突破點，才影響到了現有的團隊也來使用git。再往前追溯和第一期項目的實施，其實很多二期項目之所有能夠被管理團隊接受，很大程度上在於之前的第一期項目已經進行了一些嘗試。
以上所講述的幾個片段其實都是一些突破點，突破點的意思在於我們可在團隊需要的時候給出藥方，讓團隊真正體會到收益。
相比較於規劃式的各種最佳實踐的推廣，這種被動應激式的實施方式才真的能解決問題。而規劃式的敏捷DevOps實施其實大多數時候都會給團隊造成困擾。
這個過程中，我們能讓更多的人去嘗試不同的方式、工具、流程，這些不同的方式在設計的時候考慮到了必須滿足監管的要求，而且最終證明其實我們更好的滿足了監管的要求。很多團隊會以所謂的“監管要求”作為不願意接受改變的藉口，問題在於這些團隊其實將既定流程當做了監管，而監管其實只定義了目標，並不會關心你如何實現這個目標。如何平衡效率和滿足監管的天平，其實是非常考驗一個DevOps實施顧問能力的。
忘記DevOps 記住效率
上面的案例中的所有嘗試，從管理層面來看，都是在儘可能的減小粒度。工程層面則是在解耦，無論是微服務、CI/CD還是容器之所以能夠幫助團隊快速上線，是因為它們的代碼無耦合。
所以說要關注效率提升，完全可以忘記DevOps，關鍵在於牢記粒度和工程解耦。
對於效率的關注才是迴歸本質的過程，無論是敏捷，精益還是DevOps其實都是一些手段，我們不能因為手段而忽視了目標。牢記團隊需要些什麼，牢記我們的初心，才能真的提供價值。
以上為今天的分享內容，謝謝大家！
閱讀更多 IT大咖說 的文章
