荷兰 ING 银行从敏捷到 DevOps 的进阶之路

一、ING 介绍

ING 是一个总部位于欧洲荷兰的银行。我们有450多个运维开发的团队，全面服务于银行业。

在 ING，IT 的角色从服务转向到战略上，不仅仅做传统的银行。

战略驱动的四个支撑点：

1. 清晰和简单 这是对客户很重要的。我们希望客户明确我们的服务内容，并且让我们的客户非常简单地理解我们，方式很简单，同时快速地操作。
2. 随时随地 这对客户来说是很重要的。我们的客户需要掌控银行业务，能够在任何时候都能做出相关的建议。如果你们想极早地采取行动的话，那你们采取这个行动之后就可以采取其他的行动，这就是随时随地的意思。
3. 赋权 让客户有权利去根据金融形势做出相应的角色，不仅仅是老式的银行告诉你们什么方式是好的，我们自己可以决定什么样的决策方式是好的。因此我们需要相关的投资信息、CRM 等等来挖掘帮助我们。
4. 精益求精 每天都在求变，为了给客户提供和享受更好的服务，同时我们也在不断地改进自己的工作方法和模式。

我们有一些挑战，最开始的时候我们的基础设施是非常古老的。第二点我们的组织结构也是非常老旧的，不同的部门负责的业务是不同的，都有自己的经历，自己的职责，自己的语言，互相之间沟通也是困难的。

另一方面，我们有期望，我们想要生产什么样的东西呢？想要得到什么样的结果呢？技术应该是随着模式在变的，所以我们需要加入工程相关的概念。

作为 CIO，工程对于我们所做的所有事情来说是很关键的，只有通过好的工程方法才能成功。

敏捷的三个阶段：

• Agile
• DevOps
• BusDevOps

这个就是我要分享的主要内容。

二、 Agile

敏捷开发是从2011年开始，当时也就3到4个人员，后面慢慢扩大的整个团队。

在这个阶段我们学到了什么经验呢？

对于敏捷每一个人都是自我管控，自我地促进，并且利用自己的方式来进行工作。

那么决定用什么样的功能，将怎样往前走，怎样进行开发，然后怎样放到生产的环境当中？

当时还是一个小团体小组织，产生很多的不了解和困惑，并且速度也没有办法保证。就产生了有大量的事情要做，并且需要快速地把产品交付给客户，所以当时会有很多相关的移交的工作，因此我们想通过自动化来加快效率。

三、 DevOps

一个共同的质量管理部门是重要的。首先 Dev 这个团队必须要很好的满足业务需求，目标是要他们开发的东西交给业务去运维和运作。这样的话整个应用的工作是由 DevOps 的团队来掌握，就需要积极沟通，并进行协调。

想要把 DevOps 做成功就需要 CLAMS。首先来说说文化，要对成员很了解，协同协作。要精益，能够把这个价值非常精确的交付给客户。

对于开发团队来讲，是要把现有的问题解决掉，然后跨越到下一个阶段。但是对于运维团队解决这些小问题不是最大问题，要交付所以他们要协调，部署的脚本我们会进行回归的测试，持续地在做。

从2013年我们是持续交付的，产品当中有很多实现了自动化，如监控包括指标。这个不单单是构建，并且把这个软件成功地交付到生产环境当中，你要知道你的流程是怎么走的。那么就要知道他们不同的行为和不同的标准，这个还是比较难的。

其次是共享，你可以发觉一组或者一个人针对服务器进行操作或者负责，遇到相关问题需要组员之间相互的帮助，有了这样一个知识以后大家要进行分享。

另外基于我们工程的文化，包括高级工程师可以帮助初级的工程师来增长他们的知识，从而相互的解决问题，这是一个团队合作，并且咨询工程师也能够很好地在技术会议中传递相关的信息。

你可以看到很多人在一些技术大会上进行推广他们技术方面的知识，不管分享的内容是文化还是纯技术。

自动化是非常重要的，可以效率化额外的事情。如果能够把负担给分散开的话，真正的工程人员完全可以专注于他该专注的东西。

事实上开发团队和业务团队还是会有所不同的，比如说这个业务我要开发一种功能，有的时候开发团队表面上答应，但是开发还是会花时间，所以我们还是会有一些小的团队，来在不同的层级进行工作的。

其实，当我们开始工作的时候管理层是可以做出决定，到底是不是敏捷。我们需要去提升工程技巧，继续去深化。

我们希望，尤其是 DevOps 运维的相关人员需要去了解过程，处理不同的事件，不是说要特别了解相关的技术数据，但是至少需要找到技术方案。

最后，在应用的层面，我们需要改变应用。从2013年开始，我们在提高微服务方面花了很多的工夫，我们有非常多的应用，银行问题也越来越少。我们有信心我们所有的微服务系统都能得到优化的，而且系统也会越来越棒的。

还有一个就是绩效和考核，我们注重于工程文化，我们用驱动因素。工程师之间也是有级别的，初级和高级工程师之分，一步一步演进的过程，一年我们有两次的晋升机会。需要他的同事和他的经理来对他进行评估，看看是升级还是需要降一级。

四、 BusDevOps

运维和商业之间的关系是需要看不同的模型。比如 squad 文档模型：

在该种模型当中，种类这个组是有共同的目标的，竖着的这些队，来自不同的技能人群如研发、运维、商业操作、网页设计或者是沟通的人员，他们都在同样一个目标下工作。

从横面看，不同的组织间有不同的单位，如教练，他们是在自己擅长的领域能指导别人。每一个队都有一个领导。还有一个总领导来管理所有的人。

在过去的两年当中，我们非常辛苦地致力于模型的开发，同时学到了很多，在同样的基础进行工作并非一件容易的事情，它有非常多不同技术的要求。

比如一个贷款的市场，会有不同的规则，很多时候客户都在等着这些规则落地。因此需要专业的技术人员来帮助他们，但是技术人员也需要去等这些政策，这其实就是一个很大的挑战。在帮助客户的同时也提供了更多的工作任务。彼此之间的沟通和交流就显得尤其重要。

从中我们学到了什么呢？

我们彼此之间分享了非常多的问题，很明显我们在一起合作有同样的目标把我们聚集到一起，让我们更有力量一起去奋斗，更好的帮助我们去理解我们到底在做什么，更好的把控客户的需求。同时工程师还能够帮助我们得到更多的反馈，尤其是现场的反馈。

五、下一步

我们一直在改善工作方法，同时也推广到其他部门。敏捷是一个非常好的方法，不是要告诉别人怎么做，而是需要自己找到怎么解决的方法。

这有一点矛盾，我们既要有自己的方法，又需要考虑实际情形，怎样适应当地的情形。在其他部门我们也引进敏捷，比如财务部门有他们自己的标准，IT 是能够和他们紧密合作的。

我们是希望有一个全面的合作，也就是说与 DevOps 紧密合作，点个键就可以进行流程的触发。

比如说我们这个业务团队只负责交付，每个团队都会基于各自的目标去做，完成交付以后可以给下一个团队。因此我们在微服务方面持续的进行提高，把服务交付给第三方或者和第三方合作，通过 DevOps 的方式把技术交付给他们产生价值。