传统金融企业践行DevOps的两大法宝

IT大咖说

发布于 2018-10-08 14:09:46

6910

发布于 2018-10-08 14:09:46

内容来源：2018 年 05 月 05 日，英捷创软 LEANSOFT 创始人兼首席架构师徐磊在“DevOpsDays Beijing 2018”进行《强监管环境下，传统金融企业如何挑战互联网》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：5740 | 15分钟阅读

摘要

金融企业，特别是传统金融企业是这几年DevOps运动的“重灾区”，这是我的亲身体会。在过去的5年里，我持续为多家大型传统金融企业提供了DevOps/敏捷/软件工程咨询服务，深深体会到的这个行业所面临的互联网挑战和自身的挣扎。我希望为大家讲述一些真实的用户故事，从中总结一些我的心得，也是我这些年帮助客户践行DevOps的两大法宝：粒度和解耦。

获取嘉宾演讲视频及PPT，扫一扫下方二维码即可。

要生存就要挑战

1995年比尔盖茨曾写过一本书《未来之路》，书中有这样一句话“Banking is necessary，Bank is not”。对此相信很多人都深有体会，尤其是最近几年，出现了很多非传统银行提供的金融服务，如日常使用的支付宝、微信支付等。

上图是普华永道2017年的调研数据，数据显示除零售业外、传统金融是受互联网影响最严重的行业。之所以近两年金融业会成为DevOps“重灾区”，很大一部分原因要归于它目前所面临的严峻挑战。

需要提到的是虽然我们一直在谈论敏捷，而敏捷从本质上就意味着要拥抱变化。但是实际上从人的本性来看，很少有人会主动去寻求改变。变革的契机一般都是由各种外部因素引起，比如不满足现状、受到外部压力、遇到挑战等。这同样也是金融业对DevOps如此感兴趣的外因，他们意识到如果再不进行改变整个行业就有可能会被颠覆掉。

BATJ在金融行业的布局

BATJ基本上在所有的行业中都有布局，其中金融领域尤为密集。造成这种情况的原因有两个，一是金融行业中尚存大量未被挖掘的机会，二是金融行业中现有的从业者反应不够快。BATJ这样的公司能够提供一些传统金融业所没有的更加便利的服务，这就是所谓的机会，而这些机会却未被本行业的从业者发现。

注意这里所说的是整个行业，而非行业中的单独个体。因为尽管行业中的精英分子非常活跃，但是行业本身受到体制影响和多年的惯性已变成了集体无意识的状态。这也是在金融业中实施DevOps的难点，即如何让集体从无意识转换成集体有意识，自主的发现缺点机会，然后改进。

传统银行的危机和挑战

传统银行首要面临的挑战就是客户脱媒，银行正在失去同用户的接触机会，互联网将中间的流程给隔开了，银行所能获悉的仅是资金的流入和流出，并不能明确的了解到用户的行为。

第二个挑战是解绑，比如现在我们所使用的很多金融产品其实都是由互联网公司组合起来的，一些理财产品背后的基金有可能是来自多家银行、多个渠道，而由单个银行所提供的产品服务不再被青睐。这种情况的出现，造成银行或传统金融业对整个市场变化的认知越来越弱。

传统组织中如何激活创新

如何挖掘传统金融的巨大潜力

虽然所有的渠道都已被互联网占据，但实际上银行的数据库或交易系统中还是保留了大量有价值的信息资产。关键在于为何银行没有去挖掘这些资产，而是由外围的互联网金融创新企业去做这些事，这点是金融行业特别需要思考的问题。

上面是关于南航叫停第三方平台（OTA）值机的相关文章，这整件事其实就是航空公司意识到了第三方平台对自身所造成的冲击而采取的应对措施。

OTA平台在颠覆传统行业方面比互联网要早的多，大约在15年前就开始进行了。但现在主动权正慢慢的交回到了航空公司手上，因为提供价值的基础在航空公司手里。有一点我们要明确，虽然过去十几年互联网在经济发展中占据很重要的地位，但中国经济体的占比中互联网其实并不高，我们的经济仍然是传统行业在支撑。

未来的中国或世界经济中互联网依然会快速发展，但它的真正价值在于探索，当探索到一定程度后，最后还是要由传统行业来收网。

建立内部创新机制

传统金融要想打破现有局面，除开要解决外因，还要突破内部因素，也就是前面提到过的集体无意识状态。这里有几点关键要素，其中一点就是技术重塑和战略手段，也就是常说的数字化转型，这也是经常被传统行业所提到的。

我一直认为金融行业是强力依赖IT的非IT行业。有趣的是金融企业的业务人员从来不觉得自己是干IT的，而金融企业的IT人员也从来不觉得自己是干金融的。

相信很多银行的技术人员都有这样的疑问，明明某个服务实现起来很简单，但为什么是由其他公司提出而不是银行。其实如果真的将它放在现有的制度环境中你就发现实现的过程中会困难重重，这种情况类似于肌肉不受大脑指挥。

这种感觉就好似一个长期不做体育运动的人，突然拿起球拍的时候，大脑里面还是自己的20岁左右的身体状态。但是当球飞过来的时候才发现，大脑已经使用20岁的意识去指挥身体，无奈的时候身体已经是40岁的状态。结果 … … 可想而知。

接收不确定性

要实现大脑和肌肉的协调，首要是能够接受不确定性。反脆弱理论也告诉我们，如果希望在危机出现的时候能够作出迅速有效的反应，就必须随时应对危机，而不是避免和延迟危机的影响。

一般认为的软件“生产制造”过程是从需求、设计、计划到开发、测试、集成、发布这一整套流程，但这样的认知存在一定偏差。

我们类比下汽车的“生产制造”过程，首先制造原型车，然后到生产线生产。生产线的本质是不停的复制相同的产品。相对的，软件的需求、设计、开发、测试、构建、交付其实是原型车的制造过程，真正的软件生产制造过程是在仅仅把安装包复制和粘贴的过程，因为只有这个过程中软件不会发生任何变化。

简单来说，所谓的“生产制造”过程是重复制造同样的产品的过程。而软件的开发过程是每次都制造不一样的产品。问题在于，现在的软件行业一直尝试用管理重复制造过程的方法来管理软件开发的不停创造的过程，这也是为什么传统的项目管理方法应用到软件管理上会有诸多问题的根源。这个问题，是认知层面上的错误，也就是我们所说的“不确定性”的问题，大多数软件行业从业者希望使用“确定性”过程的管理方法来管理这个“不确定性”过程；这种认知层面的错位导致了基本上软件开发中的所有问题。

这种情况在金融行业尤其严重，金融从业者不愿意去理解软件开发的实质，软件从业者发现要为这些门外汉解释清楚软件开发的机制太困难，最终造成了二者认知的错位。这其实也是很多企业实施DevOps过程中遇到的部门墙的根源性问题。

敏捷从认知层面的基础就是要接受不确定性，由此延伸出来的管理思路异于传统，是自下而上的，依赖知识工作者的探索和实践形成管理流程，属于经验性管理思路。

而传统的管理思路依赖于管理者的主观意识定义管理流程，属于预定义的管理思路。

这种管理思路上的转变能够帮助企业从根本上接受“不确定性”并构建内部适应机制和创新氛围。

但是，它与传统银行的管理思路是大相径庭，背道而驰；传统管理思路下的管理人员会感觉失去对整个组织的控制，因此非常惧怕从认知层面推荐敏捷，这也是为什么我们看到了很多所谓的伪敏捷，只使用了敏捷的形式而没有贯彻敏捷的思维。而实际上，要实现真正意义上的敏捷，就必须经历这个“放弃控制”造成“混乱”的过程，只有组织进入一定的“混乱”状态，才能自己寻找到正确的方向，管理者的角色在这个过程中实际上是在进行“管理升级”，从事务性的控制变成机制的控制，这才是更高级别的管理形式。

某大型传统金融企业的转型历程

1期实践

这里我们看一个实际的案例，它是2015年我参与的某国有四大银行的行级项目，由行级领导直接管理，目的同样是为了探索创新实践。基于这样的背景，整个项目第一次实现了端到端应用生命周期管理，真正做到用一个工具一种方式从需求的起点管理到终点，并且对整个过程进行了完整的跟踪。第一次形成了跨部门的协作，第一次实现了全部代码的集中构建发布。

最终整个项目过程用到了很多与DevOps、敏捷相关的概念，但却并没有提到DevOps，参与到项目中的时候也没有人告诉我这是在做DevOps转型。

在这样的背景中可以看出，如果想要做DevOps就先要抛弃大工程、大计划，因为这本身就是确定性思维的体现。想做DevOps转型，随时可以开始，你要做的只是要允许事情发生，而不是计划要发生什么。作为领导要想团队去创新，就要默许团队去犯错误。

2期实践

在第一期项目结束后大概1年后，在同一家银行内我们又做了的一些尝试，到目前为止（视频演讲时间）这个团队共完成了15个迭代。

这里，我想分享几个团队中的片段，希望通过这些片段帮助大家了解一个“真正”的敏捷/DevOps转型项目是应该怎样做的。我知道大家一定想听到比如总体转型规划，企业级目标一类的内容；但我要说的是那只能让你失望了，因为这些在这个项目里面都没有。我们做的只是一些点点滴滴的改进。

最初因为团队正在使用微软的Team Foundation Server，所以想引入电子看板。不过考虑到整个团队并没有敏捷开发经验，所以在我建议下使用了物理板代替，目的在于让团队先形成自己的一套机制。我当时的考虑也很简单，以我对一个并不熟悉工具也不熟悉敏捷的团队的了解，我觉得在一开始引入电子看板只会给团队造成拖累，而且对于这个集中式开发的团队而言，也没有远程协作的诉求，物理板可以允许团队迅速低成本的进行改进，最适合一个敏捷小白用户。

以上通过物理看板进行过程改进的过程持续到了第1轮投产结束，此时团队又想进行一些新的改变，首先他们发现看板最右边的测试列基本上每个月都会积压一堆卡片然后又同时跳出，所以提出让测试人员从间断性介入变成持续性驻场。这一措施使得故事流动变得更快，进而引发了对代码部署速度改进的需求，因此CI/CD也被逐步引入。

随着CI/CD流水线逐步投入使用， code Review频率从之前的每月变成了每天，使得传统的流程化code Review机制无法满足保证代码的质量诉求。于是又引入了git编码工作流，同时为了能够对代码访问权限进行更细粒度的控制（因为git本身不具备文件级别的权限控制）将原有的配置库从1个拆分为15个，每个git库拉取分支，然后做pull Request，在pull Request上进行code Review。

传统行业的开发团队应该都有类似编码规范的手册，但可能很少有团队去认真执行，直接原因是没有充足的人力去监管检查。然而更深层的原因可能是工具用的不对，或是流程限制了能力的发挥。随着以上CI/CD + Git Pull Request流程的引入，对于编码规范和代码质量的检查机制也逐步落实，通过使用静态代码检查工具，为开发团队提供更加频繁，少量多次的反馈。

估计有朋友已经发现了，上面的迭代图中还有个灰色的“其他团队”。这个团队其实先于现在的团队尝试了git。当时，我们发现git pull request虽满足安全性和监管的要求，但需要改变现有人员的工作方式，会是一个比较大的挑战，好在该团队的负责人采纳了这种方式。正是以此为突破点，才影响到了现有的团队也来使用git。再往前追溯和第一期项目的实施，其实很多二期项目之所有能够被管理团队接受，很大程度上在于之前的第一期项目已经进行了一些尝试。

以上所讲述的几个片段其实都是一些突破点，突破点的意思在于我们可在团队需要的时候给出药方，让团队真正体会到收益。

相比较于规划式的各种最佳实践的推广，这种被动应激式的实施方式才真的能解决问题。而规划式的敏捷DevOps实施其实大多数时候都会给团队造成困扰。

这个过程中，我们能让更多的人去尝试不同的方式、工具、流程，这些不同的方式在设计的时候考虑到了必须满足监管的要求，而且最终证明其实我们更好的满足了监管的要求。很多团队会以所谓的“监管要求”作为不愿意接受改变的借口，问题在于这些团队其实将既定流程当做了监管，而监管其实只定义了目标，并不会关心你如何实现这个目标。如何平衡效率和满足监管的天平，其实是非常考验一个DevOps实施顾问能力的。

忘记DevOps 记住效率