上海2018年9月10日電 /美通社/ -- 近日，天旦就“數(shù)字化轉(zhuǎn)型羅盤”的第三維度 -- “經(jīng)營模式轉(zhuǎn)型”發(fā)布 “DevOps 實踐應用指南”，通過列舉 DevOps 在金融行業(yè)中的實踐案例，幫助運維在數(shù)字化轉(zhuǎn)型的風口下輕松告別與業(yè)務的“龜兔賽跑”。
開創(chuàng)新時代的數(shù)字化轉(zhuǎn)型
距約今5億4千萬年前，地球正處于寒武紀的地質(zhì)歷史時期。在接下來的2000多萬年時間內(nèi)，各種各樣的生物突然涌現(xiàn)，迅速起源、分化，被稱為“寒武紀生命大爆發(fā)”。5.4億年后，與“寒武紀生命大爆發(fā)”如出一轍的現(xiàn)象再次出現(xiàn)在虛擬領域 -- 創(chuàng)業(yè)爆炸。2014年，經(jīng)濟學雜志《The Economist 經(jīng)濟學人》引用這個概念提出“寒武紀節(jié)點 Cambrian Moment”，用于表述借助數(shù)字化優(yōu)勢迅速崛起的初創(chuàng)科技公司爆發(fā)式的增長。
2015年，國家工商總局公布全國市場主體發(fā)展情況，報告稱全國新登記企業(yè)已連續(xù)6個月保持高位增長，平均每天新登記企業(yè)1.16萬戶；截至2015年9月底，全國各類市場主體7511.3萬戶，而這個數(shù)值在今年3月16日突破了1億。
以上這些數(shù)據(jù)的意義并不在于呈現(xiàn)市場多繁榮，而是競爭有多激烈。時代在發(fā)展，消費者求新求變，新業(yè)務需求不斷高頻提出，迅速變化；每一種需求都有無數(shù)的企業(yè)爭先恐后地為其提供產(chǎn)品與服務。競爭意味著機會，同時意味著殘酷的生存考驗：到寒武紀末期，49%的生物屬類已經(jīng)滅亡。
當下被推上風口的“數(shù)字化轉(zhuǎn)型”正是這樣的節(jié)點：一些企業(yè)順利推進數(shù)字化轉(zhuǎn)型，贏得了新客戶、新市場；而也一定會有企業(yè)無法應對競爭者成功轉(zhuǎn)型帶來的變化和危機而消亡：
Gartner 早在2014年提出了雙模 IT (Bimodal) 的理念。雙模 IT 是指兩種不同的 IT 工作模式：
企業(yè)需要堅守穩(wěn)態(tài)模式，守護核心業(yè)務的穩(wěn)定運行，同時，也需要采取靈活、敏捷的方式柔性地接受并應對變化。這里有一個非常成功的案例，便是世界十大汽車公司之一，也是日本較大的汽車公司 -- 豐田汽車公司。
20世紀50年代，朝鮮戰(zhàn)爭后經(jīng)濟復蘇和蓬勃發(fā)展帶來了爆發(fā)式的消費需求，借著來自美軍46億美元的巨額訂單，讓面臨經(jīng)營危機的豐田汽車得到迅速發(fā)展。這一段時期，豐田汽車改革了生產(chǎn)和管理理論，提出了“豐田模式TPS” (Toyota Production System)，使大規(guī)模定制模式下的敏捷產(chǎn)品開發(fā)和生產(chǎn)成為現(xiàn)實。這種豐田特色的柔性化管理方式成為了豐田公司的核心競爭力和高效率的源泉，造就了其舉世矚目的經(jīng)營業(yè)績。在今天，“豐田模式”被稱作是“精益管理”的先驅(qū)，并且進化為“即時生產(chǎn)”的理論。而在 IT 行業(yè)，“敏捷開發(fā)”和“DevOps”也是這一思想的最終體現(xiàn)。
豐田精益生產(chǎn)方式 TPS (Toyota management model) 是由日本豐田汽車公司的副社長大野耐一創(chuàng)建的，是豐田公司的一種獨具特色的現(xiàn)代化生產(chǎn)方式。它順應了時代的發(fā)展和市場的變化，期間經(jīng)歷了20多年的探索和完善，逐漸形成和發(fā)展成為一套完整的生產(chǎn)管理技術與方法體系。TPS 管理哲學的理論包含4大層面：
拋開這一系列專有名詞，所有這些管理方法的核心思想是相通的 -- 避免資源浪費。產(chǎn)品的開發(fā)要經(jīng)歷需求-設計-開發(fā)-調(diào)試-部署-監(jiān)控的一系列環(huán)節(jié)，每個環(huán)節(jié)都依賴前一環(huán)節(jié)的成果交付，因此各個職能部門浪費在等待上的時間和資源是巨大的。就像飯店后廚里洗菜、備菜、腌漬、烹飪、調(diào)味、擺盤的流程，如果所有人都在等前一個人完成才開工，那還會有客人愿意等到上菜嗎？洗菜工的10種食材只要有一種清洗完成就可以交付備菜，不需等所有材料清洗完畢再一起交付；擺盤工可以先準備好碗碟和裝飾的材料，不用等著料理出鍋再去尋找。通過將任務分解為更小更細的顆粒，每個環(huán)節(jié)上的人都可以提前融入、盡早啟動，避免無謂的等待。這就是敏捷開發(fā)的原理。而要實現(xiàn)這種高效的工作模式，就必須有一個角色可以統(tǒng)覽全局，對各個環(huán)節(jié)進行合理的調(diào)度，這就是 DevOps 的意義。DevOps 也恰恰是企業(yè)雙模 IT 的較佳實踐之一。
在數(shù)字化轉(zhuǎn)型中的諸多挑戰(zhàn)中，經(jīng)營模式轉(zhuǎn)型這個維度的基本矛盾，是業(yè)務需求頻繁變動和產(chǎn)品快速迭代上線對整個企業(yè)開發(fā)部署流程的要求，與企業(yè)現(xiàn)行的豎井式組織架構給跨部門高頻溝通造成拖累之間的矛盾。而要解決這一矛盾，何不從取得成功經(jīng)驗的企業(yè)案例中獲得啟發(fā)。
走在前列的銀行科技部
在解決這一矛盾的過程中，最能夠提供借鑒的就是銀行業(yè)了。隨著金融市場的開放，體量小、組織架構靈活的互聯(lián)網(wǎng)金融機構憑借其敏捷的產(chǎn)品策略和對流量變現(xiàn)的嫻熟應用搶占市場，對銀行形成強大競爭壓力。他們?nèi)碌淖鲬?zhàn)模式，不僅為傳統(tǒng)銀行帶來了新的轉(zhuǎn)型方向，也為各個行業(yè)打開了快速增長的大門。讓我們來看看傳統(tǒng)銀行是如何實踐 DevOps、并最終推動經(jīng)營模式轉(zhuǎn)型的。
案例一 南京銀行運維團隊3天構建實時流動性管理工具
若業(yè)務部門提出需求：以往 T+N 的報表式流動性管理方式過于滯后，無法及時感知、干預流動性風險，需要開發(fā)一款實時的流動性管理工具。就像一步接一步流程化做菜的方式，依賴過去傳統(tǒng)銀行的開發(fā)交付流程，從需求提出到工具交付上線，動輒幾月。
而南京銀行運維團隊的做法與眾不同。通過天旦業(yè)務性能管理產(chǎn)品 BPC（以下簡稱 BPC）特有的 SmartView 模塊，完成構建實時流動性管理應用，投入運行，僅需3天。通過 SmartView 的可視化界面，運維人員無需編寫代碼，只需鼠標拖拉，就能快速完成應用的自定義構建。同時，天旦 BPC 基于旁路的技術方式擁有跨業(yè)務條線實時監(jiān)控全業(yè)務流程的優(yōu)勢，為實時流動性管理應用的即刻上線、精準統(tǒng)計提供了天然基因。南京銀行通過實時流動性管理應用，面向高管層、業(yè)務管理人員實時呈現(xiàn)二代支付往來賬業(yè)務筆數(shù)、發(fā)生金額等重要業(yè)務指標。同時，面向會計結算部、資產(chǎn)負債管理部等業(yè)務部門及時準確反映全行大額資金流動情況，便于資金頭寸管理，控制流動性風險，讓流動性風險管理方式從 T+N 創(chuàng)新性地升級到了 T+0。
案例二 天旦某城市商業(yè)銀行用戶，自主開發(fā)業(yè)務實時監(jiān)控應用，運維與開發(fā)充分協(xié)作
銀行的 IT 系統(tǒng)龐大復雜，不同業(yè)務模塊構建技術原理不同、部署時間不同，無法用同一個工具面向所有業(yè)務統(tǒng)一評估交付質(zhì)量，也很難用同一個視圖匯總所有核心業(yè)務運行的實時指標。受到天旦 BPC 基于旁路方式能夠跨業(yè)務條線實時監(jiān)控全業(yè)務性能的啟發(fā)，該行運維人員創(chuàng)新構建了一個新核心應用性能監(jiān)控應用，區(qū)分交易類型，在統(tǒng)一的監(jiān)控界面中呈現(xiàn)核心 Top 交易的實時運行情況。一旦交易指標低于設定的閾值，立即觸發(fā)提示。運維手中有了精準的數(shù)據(jù)指標，對業(yè)務的運行質(zhì)量有客觀、實時、全面的數(shù)據(jù)統(tǒng)計。一旦業(yè)務性能低于預期，就能立即反推開發(fā)調(diào)優(yōu)，讓運維與開發(fā)無縫銜接。借助 BPC，產(chǎn)品所經(jīng)歷的研發(fā)、測試、部署、監(jiān)控全流程被無縫串聯(lián)，實現(xiàn)了開發(fā)、運維一體化。
而這一切都和天旦 BPC 的產(chǎn)品設計，從底層開始就賦予 DevOps 的思想脫不開關系。BPC 基于網(wǎng)絡旁路技術，無需對應用進行修改，所以獨立性高、依賴性小，滿足了敏捷開發(fā)和持續(xù)部署的快速落地要求；通過對真實網(wǎng)絡流量 (wire data) 進行自動解碼分析，SPVD 得以自動發(fā)現(xiàn)不同模塊之間的訪問關系，在產(chǎn)品推陳出新、業(yè)務不斷變更的情況下自動感知變化，為運維與業(yè)務建立起統(tǒng)一的視角。而 SmartView 則賦予了運維人員開發(fā)能力，無需代碼編寫 (no code) 就能快速構建場景化應用。過去動輒一年半載的開發(fā)周期被縮短為數(shù)日，促成 DevOps 的實現(xiàn)，以更敏捷的姿態(tài)及時響應業(yè)務部門的變化。
從龜兔賽跑到接力協(xié)作，DevOps 釋放科技潛力，助力企業(yè)數(shù)字化轉(zhuǎn)型
因為市場瞬息萬變，所以必須以用戶體驗為中心，及時滿足用戶需求；因為競爭殘酷激烈，所以必須不斷通過各種渠道產(chǎn)生新想法、建立新業(yè)務洞察，開拓新的生存空間；因為未來無法預測確定，所以唯一不變的只有“變化常在”。
很多的運維還在以為這是一場發(fā)生在部門之間的龜兔賽跑，可以放心等待開發(fā)部門趕來。事實上，企業(yè)雖然劃分了不同職能的不同部門，但正如生物是各個重要器官協(xié)同配合才能生存一樣，各個部門之間齊心協(xié)力、以終點為共同目標完成一棒又一棒的接力，才能讓企業(yè)整體順利度過數(shù)字化轉(zhuǎn)型。而要實現(xiàn)這一目標，DevOps 是必經(jīng)之路：以運維為核心打通業(yè)務流程，建立從業(yè)務到運維的數(shù)字化生態(tài)；通過敏捷開發(fā)的方法，打破豎井式組織架構，實現(xiàn)產(chǎn)品的持續(xù)交付，提高企業(yè)對行業(yè)變化的反應速度。只有這樣，企業(yè)才能在快速變化的時代中拔得頭籌，獲得指數(shù)級的商業(yè)價值增長。
