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