近日，天旦就“数字化转型罗盘”的第三维度 -- “经营模式转型”发布 “DevOps 实践应用指南”，通过列举 DevOps 在金融行业中的实践案例，帮助运维在数字化转型的风口下轻松告别与业务的“龟兔赛跑”。

　　开创新时代的数字化转型

　　距约今5亿4千万年前，地球正处于寒武纪的地质历史时期。在接下来的2000多万年时间内，各种各样的生物突然涌现，迅速起源、分化，被称为“寒武纪生命大爆发”。5.4亿年后，与“寒武纪生命大爆发”如出一辙的现象再次出现在虚拟领域 -- 创业爆炸。2014年，经济学杂志《The Economist 经济学人》引用这个概念提出“寒武纪节点 Cambrian Moment”，用于表述借助数字化优势迅速崛起的初创科技公司爆发式的增长。

　　2015年，国家工商总局公布全国市场主体发展情况，报告称全国新登记企业已连续6个月保持高位增长，平均每天新登记企业1.16万户;截至2015年9月底，全国各类市场主体7511.3万户，而这个数值在今年3月16日突破了1亿。

　　以上这些数据的意义并不在于呈现市场多繁荣，而是竞争有多激烈。时代在发展，消费者求新求变，新业务需求不断高频提出，迅速变化;每一种需求都有无数的企业争先恐后地为其提供产品与服务。竞争意味着机会，同时意味着残酷的生存考验：到寒武纪末期，49%的生物属类已经灭亡。

　　当下被推上风口的“数字化转型”正是这样的节点：一些企业顺利推进数字化转型，赢得了新客户、新市场;而也一定会有企业无法应对竞争者成功转型带来的变化和危机而消亡：

　　战略转型带来的新客户、新需求，企业无法快速感知变化、响应变化;

　　竞争对手总能想到各种新合作关系，来不及追赶、没办法超越，错失市场机遇;

　　海量数据的积累不但没能发挥价值驱动商业决策，为企业带来收益，还压垮了生存基础 -- IT 系统，影响了企业核心业务的运行。

　　Gartner 早在2014年提出了双模 IT (Bimodal) 的理念。双模 IT 是指两种不同的 IT 工作模式：

　　模式1“稳态”：专注于可预测性，以维持稳定为目标，通过已知的知识经验优化 IT 环境，保证核心业务的可靠、可用，以及可预测领域的优化创新;

　　模式2“敏态”：侧重于探索性的工作，以响应变化为目标，通过试验解决新问题并针对不确定领域进行优化。因要满足的需求在开始阶段并不明确，所以需要高扩展性和高敏捷性，需要业务部门与 IT 部门共同探索。

　　企业需要坚守稳态模式，守护核心业务的稳定运行，同时，也需要采取灵活、敏捷的方式柔性地接受并应对变化。这里有一个非常成功的案例，便是世界十大汽车公司之一，也是日本最大的汽车公司 -- 丰田汽车公司。

　　20世纪50年代，朝鲜战争后经济复苏和蓬勃发展带来了爆发式的消费需求，借着来自美军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 是必经之路：以运维为核心打通业务流程，建立从业务到运维的数字化生态;通过敏捷开发的方法，打破竖井式组织架构，实现产品的持续交付，提高企业对行业变化的反应速度。只有这样，企业才能在快速变化的时代中拔得头筹，获得指数级的商业价值增长。