開始之前做個自我介紹，我在招行工作快16年了，見證了招行研發從200人到快5000人的規模。我到招行第一件事情就是搭建源碼配置管理系統，然后是CMMI體系的二級三級評估，在幾年前開始參與敏捷、看板、精益的研究推廣。
我本人主要負責2017/11765.html">DevOps的研究、推廣和改進的相關工作。同時，除了實踐推廣，很重要的就是2017/11765.html">DevOps工具鏈，我們也是跟業界一起把工具鏈建設了出來。此外，現在正在參與招行的精益研發體系的建立和招行的數字化轉型。
今天我介紹的內容主要分這幾塊：一是業界對2017/11765.html">DevOps的理解；第二部分是我們招行對2017/11765.html">DevOps的理解；第三是分享招行2017/11765.html">DevOps實踐和規?；七M經驗；最后說一下我們參與2017/11765.html">DevOps標準評估情況的介紹。
第一部分是對2017/11765.html">DevOps的理解。相信大家都看過這一幅圖，所謂的盲人摸象，不同的人站在不同的角度說2017/11765.html">DevOps是什么，有各種不同的說法。相信大家都會有這個困惑，包括我在一開始接觸2017/11765.html">DevOps的時候也是這樣?，F在不同的人、不同的組織對2017/11765.html">DevOps都有不同的理解。維基百科中關于2017/11765.html">DevOps的定義說了很多，有幾個點可以著重給大家分享一下。2017/11765.html">DevOps的目標是縮短開發周期，提高部署頻率，更可靠地發布以及與業務目標一致。這一點最近我們特別有感受，就是你做的事情一定要跟業務目標一致，否則，你做的事情不是業務想要的，你做得再快，做得再多也沒有用，所以這一點非常重要。
招行有一個Fintech基金，從三年前開始，每年從稅前利潤中拿1%，大概8億元，作為Fintech基金，去年漲為營業收入的1%，大概25個億，今年大概到28個億。今天談到的工具鏈建設，很大一部分都是依靠這個基金支持。在這個過程中，非常強調一點，就是注重MVP，你可以有很好的想法，但是一開始不要想的太大。你可以從一個小處開始做技術驗證，如果OK繼續投錢，但是如果發現做下來并不是你想要的，馬上停止，這就是所謂的要跟業務目標一致。就是通過一些小的方式做試錯、試驗，確定是市場要的東西才往前走。
接下來給大家介紹一下結構方程式，這也是來自于《2017/11765.html">DevOps狀態報告2017》。這個方程式為什么我一定要拿出來說，領導一般會問一個問題，投入產出比如何？在推2017/11765.html">DevOps的過程中，收益其實是很難直接衡量的。這個方程式講了一件事情，就是首先企業要有變革領導力。我們的董事長、行長、總監都非常支持我們做這件事情，而且不是從口頭上說的，是有資金的支持，這是非常重要的，支持我們變革，支持我們做這件事情。第二個我們要做各種實踐，包括曉玲分享了很多體系里的實踐，都是能夠幫助我們做持續交付，把它做好。有什么好處呢，有一句話，當這件事讓你很痛苦，你就會想各種辦法減少它的痛苦。運維也一樣，當你一個系統每年只部署一次，也許每次部署需要兩天你也無所謂。但是如果一個系統要求你每天上線、上很多次線，再用以前的方法就不可行了。所以當你要減輕痛苦的時候，你就會做持續交付這件事了。做好持續交付這件事情以后，我們的電腦部就可以更好地響應業務的需求，更好地支持業務人員打市場，跟同業競爭。以前是跟各個銀行競爭，現在我們直接要跟互聯網企業競爭，怎么樣跟他們競爭，這個非常重要。做好了以后，對招行這個組織效能和商譽上也會有所提升。我覺得這個方程式對我來說是一個很好的證明，我拿它來說服領導，或者告訴大家你為什么要做這件事情。
這是2018年的報告，在剛才的基礎上加了一些新的東西，從運維的角度，從持續測試的角度加了一些內容。去年的報告里加了一個J型曲線，這個很像招行這幾年在推進2017/11765.html">DevOps過程中的心路歷程。一開始我們做了一些工具，讓大家整個效率有所提升，大家的感受都不錯，但是隨著技術往前走進入了一個低谷。因為進入了深水區，工具已經做了自動化，但是有很多東西是需要開發人員做的，比如說寫分層的自動化測試等等。這包括以前歷史的債務，因為你以前很久才部署一次，原來的債務不改無所謂，現在要求你越來越快的發布了，以前留下的債會影響你繼續往前走。也許看起來一個需求只要改一行代碼就行，但上線需要一兩天，或者一兩周，這可能是受以前債的影響，我們在經歷這樣的過程。但是當我們往前走，突破這個過程以后，就會進入到一個新的高度，所以這個J型曲線也是非常貼切、適合我們的現狀。
2017/11765.html">DevOps狀態報告設定了幾個指標去看企業里2017/11765.html">DevOps的水平到了哪里，這個比較簡單，沒有2017/11765.html">DevOps成熟度模型那么復雜，這是對我們一開始改進來說很重要的、跟世界所有企業對標的幾個指標。前面兩個指標更關注時間，后面兩個指標更關注質量。我們自己對標此時的水平在哪里，這個是比較簡單的對標。這幅圖是來自《精益企業》，他講到當我們發布頻次不一樣的時候，分支模型、測試方法、軟件架構都不一樣，這有點像DevOps標準里所謂的一級、二級、三級，比較抽象一點，讓大家有一個感受，這個也是非常重要的一個圖。剛才講到很多業界的，或者說這幾年對我們非常有影響的幾個圖。
