非常高興有機會能跟大家一起交流學習，我是來自鄭州銀行信息科技部的劉婷，主要負責我們行的DevOps能力推廣，還有相關平臺的研發工作。

先簡單介紹一下我們行的情況。鄭州銀行是一個城商行，咱們國家的銀行分為國有銀行、股份制銀行和城商行等等，像寧波有寧波銀行、南京有南京銀行，我們鄭州也有自己的銀行，就是鄭州銀行。鄭州銀行目前已經在A股和H股上市，并且我們在城商行里也屬于第一梯隊，我們對科技這塊的投入也比較大，像我們在DevOps做持續交付能力建設的過程中，上到行級領導，下到部門總經理再到分管開發工作的副總都是非常支持的。

這個是我今天介紹的提綱，從四個方面給大家做簡單的交流。首先是開展持續交付工作的前提，我們為什么要做持續交付呢，2018年5月份我們銀行的新版核心業務系統剛上線，銀行的同事都知道這是一個非常大的項目，我們的核心一改，整個銀行可能有100多個系統都要跟著改造，改了以后我們積累的需求和開發、測試、運維工作量都變得特別大。在這個背景下，我們就啟動了一系列的工作，當時業務部門提出了非常多的需求，可能半年提交的需求比去年全年的1.5倍還要多，而且這些需求也都急著上線，在這種迫切需求的背景下我們怎么滿足業務部門的要求，是一件需要好好規劃的事情。首先我們把配置管理和環境管理做起來，之后我們又做了很多的自動化的工作，比如說自動化部署、自動化測試等等。像這里列舉到的困惑，就是核心剛上線的時候，某個系統遇到的實際問題。因為測試環境是受控的，有專門的環境管理員，當時某個開發人員為了解決測試遇到的問題，一個小時提了11個發版申請，不停地改缺陷，這就占了一個環境管理的人力，這一個人在這一小時內就為這一個系統服務，這是效率非常低的事情，由此可見自動化對我們來說有多么重要。

后來我們又接觸到了持續交付的概念，發現它和我們自己本身想做的事情非常相近。首先我們的項目管理已經非常規范，新核心以后，我們從配置到環境再到自動化測試、自動化部署都逐漸起步。然后我們的質量，當時自動化測試只做了接口級別的，對于想做快速交付來說是不夠的，因為接口級別從我們的代碼覆蓋率上來說，覆蓋的代碼行數比較少，邏輯也是比較少，而且想探測它的覆蓋率也不容易，所以后來我們看到持續交付標準，又做了一些單元測試，就是到函數或者方法級別的測試，還有靜態代碼質量和安全掃描的工作，把我們最關心的規范加入了進去。另外增加了測試頻率，原來自動化測試是在臨近上線前每晚定時運行，后來我們會在好幾個階段做，有的是提完代碼以后運行，有的就是新功能測試的時候，還有夜間的全量運行等等，根據不同的時機測試的范圍也不同。說到提升效率，必須要很多工作都自動化了，像部署這件事情，是有很強的通用性。我們原來發布一個版本，最快要15分鐘，做了自動化部署以后，編譯加上版本替換，包括配置文件和目標版本，加上程序的停止和啟動、執行等等，最快可能不到30秒就完成了。慢的話，像我們核心系統慢在全量編譯，比如說一百萬行代碼全量編譯就需要五分鐘，這個是無法節約的時間。另外關于測試，做了自動化以后，現在核心系統每天晚上可以跑一萬五千條案例。如果轉化成手工，我們做新核心項目的時候，整個核心才測了五萬條案例，我們現在一晚上可以跑一萬五千條，這個量級無法對比。另外就是度量反饋，原來很多指標可能是分散在各個平臺里的，只有項目管理平臺或者自動化測試平臺，誰負責這個平臺誰關注。現在我們把指標集中起來了，二是指標做的更豐富，更有助于我們做一些決策，后面也會看一些具體的指標示例。

關鍵要素，這里我想說幾點，一個就是標準化。可能在場有的朋友知道，我們也是參加了DevOps運營一體化成熟部的評估，并且從2018年9月份接觸到這個標準，到2019年3月份已經過級了，而且是三級，看似好像時間比較短，但實際上我們的項目管理是從2014年開始做。我們的配置管理是從2016年準備啟動新核心的時候開始規劃的，包括環境管理也是這樣，我們的部署發布，其實在2018年的5月份開始做，到9月份已經有將近20個系統已經實現了自動化的部署，我們自動化測試其實在沒有做新核心項目之前，對于老系統已經做了兩萬條的自動化案例，換了新核心以后，因為接口全部變了，所以我們重新做了，在我們去年評估之前我們的核心案例已經達到了八千條。另外，我們這次做的過程，遵循原來的流程，尤其像我們持續交付團隊或者測試團隊，甚至項目管理或者是架構團隊，在我們行被定義為服務支撐型的團隊，我們服務的對象可能是開發、測試、運維。我們不能去強推流程，我們要幫助他們節約時間，減輕他們的工作量，所以我們一定要因地制宜，不要造一些新流程，讓他們學習新流程，我們是根據現有流程，先找他們的痛點再改進的。另外管理模式這邊，我們是從上到下的支撐非常到位，像我們行的科技的規模大概一百多人，本來大家都比較熟，領導再鼎力支持，我們配合的非常好，所以也是很快能做好的一個關鍵點。