从作坊到工厂 — 传统企业 DevOps 改造历程 - JOYK Joy of Geek, Geek News, Link all geek

作者介绍：

洪烨
资深DBA、数据中心架构师，培训讲师，Oracle YEP成员，拥有DB2 V9 Advanced Administrator、Oracle 11g OCM，6sigma绿带、AIX CATE等多项国际认证。
出版著作《DB2数据库内部解析与性能调优》，在IBM developworks发表多篇关于数据库性能优化的文章。负责dbaplus newsletter DB2部分发布及审校。擅长高可用集群及双活数据中心设计，在论坛及数据库大会中多次分享数据库、一体机及双活数据中心等相关技术。
熟悉容器、kubernetes、openstack trove等PaaS及DBaaS技术，协助多家金融企业数据库进行深度数据库优化、运维体系建立。帮助多家企业完成极端场景数据库数据恢复，保障系统稳定性及数据安全。

DevOps理论的提出与发展，让软件开发模式从手工作坊式逐步向工厂流水线模式进行转变。对于一些互联网公司，DevOps并不陌生，并且由于互联网基因，DevOps很容易进行落地。

但对于传统行业，再逐步向互联网模式转变的过程中，由于原有产品开发大多数是基于外包厂商的模式，科技部门在实际的产品交付过程中，基本只承担项目管理职责。

在这种背景下，DevOps能否帮助传统行业中的企业加快交付速度，提高交付质量，能否在传统企业的科技部门真正落地生根？在这里我们讲下A银行在进行DevOps转型的过程，以及转型过程中遇到的问题。

一、A银行的过去

A银行的科技部门分为研发、运维两个团队，研发团队主要负责新系统建设，日常需求变更，新技术创新及数据需求分析等工作，项目以外包为主，行内人员主要是负责项目管理。

运维团队日常负责故障应急处理，对外服务台，物理设备采购，服务器、网络等硬件资源运行维护，资源分配及基础环境搭建等工作，实施工作主要也是通过项目外包。

具体到某一项目，我们简单的通过图表来展示该项目正常情况下所需要经过的流程及各个环节所涉及的团队：

在实际流程的执行过程中，如果遇到异常情况，只有测试和部署两个环节才能够发现问题，如果测试进行的不够充分，问题经常会再部署和运营阶段集中爆发，但由于很多原因与基础设施无关，所以最终导致很多问题都要再次反馈到研发团队去进行修复。当项目中发生异常的时候，实际情况如下图：

此外，由于近几年互联网类型业务增多，用户要求和业务响应需求也都在不断提要，导致业务部门对于需求变化的要求更加快速。往往变更后的第二天，也是研发和运维人员最忙碌的时候。

在此，我们整理下A银行目前的问题与期望：

1、跟不上业务部门需求的节奏，需要加快变更的频率

2、变更后部署及运维过程出现问题多，能否提高变更质量

为了解决这两个问题，A银行在原有的流程中增加了评审会议。但评审会议增加了额外的沟通成本，时间成本，从一定程度上降低了发布效率；并且由于参加评审会议的人员往往不是实际编写变更方案或者执行变更的人员，评审会议对实际的变更可靠性提高幅度有限。

可以看出，评审会议对于A银行的问题帮助有限，但又有什么方法可以帮助解决这两个问题呢？是否其他企业、或者其他行业都面临此类问题，有什么更好的解决办法吗？

IT流程协会在2007年评测了超过1500个IT组织结构之后，得出的结论是：相比较于一般的组织，在应用了DevOps实践的组织正表现出更快地快速部署和实施，而且相比于一般组织要快几个数量级。整体效率要高出5到7倍。

变更要多出14倍，变更故障率只有前者的1/2，第一次修复率要高出4倍，而且一级事故时间要短10倍。重复审计发现要少4倍，通过内部控制来检测漏洞方面要高出5倍左右。

我们还可以从以下表格中看到采用DevOps的公司与传统企业对于交付周期的数据对比：

可以看出，采用DevOps的互联网公司都很好的避免了A银行的问题，但是DevOps又需要怎么才能帮助A银行？

二、A银行DevOps改造过程

对于DevOps如何实践，在《凤凰项目》和《DevOps手册》的书里，提到了DevOps的支撑原则——“DevOps三个基本点”，所有的DevOps模式都可以源自这3个基本点。

1、决不传递一个已知缺陷至下游，决ß不因小失大，总是致力于改进流程，执着于深刻理解系统需求。

2、包括理解和回应所有内部和外部客户，缩短和放大所有的反馈回路，必要时，非常容易的嵌入客户需要的知识。

3、分配时间去改进每天的例行工作，培养一种奖励冒险精神的风气，同时主动引入故障到系统中，从而提高弹性。

对于这三个基本点的实践经验，我们采取四个步骤进行改进，分别是建立红灯反馈，建立单件流水线，创建反馈流程及流程自动化的改进。

1、提高发布质量

第一个基本点：决不传递一个已知缺陷至下游。最好的解决办法就是在IT生产流水线中建立红灯反馈机制，不将任何已知的缺陷传递下去。

对于目前A银行的现状而言，就是通过在生产环境已知的故障情况，建立反馈标准，将反馈标准注入到交付流水线中，建立红灯反馈机制。如图所示：

流程的改变通常会引发以下两个问题：

1）增加反馈流程会不会影响发布效率

红灯反馈流程的原则是在流程中的每个环节加入真实的质量控制，避免问题流入下一环节，单从某一步骤来看，是有可能增加额外的时间的。但实际的变更过程中，故障是难以避免的，因此避免故障流入到下一环节，及时在本环节内解决，从整体而言，发布速度肯定是提高的。

2）红灯反馈机制的标准从何而来

上面也提到了，红灯反馈机制的标准一定要基于经验及实际发生的生产故障，而不是虚构出来的信息，在这里我们简单地将一些常见生产问题、处理方法对应的预防措施以及对应流水线中的环节整理成表格。

基于表格，我们可以将预防方法进一步进行整理，反馈到对应环节的检查流程中，降低同类问题反复发生的可能性。经过调整后，交付流程大致如下：

2、提高发布效率

对于发布质量的提高，我们通过建立红灯反馈机制来解决，对于加快发布效率的问题，我们有需要如何解决？

DevOps其中一个重点就是减少在各个阶段之间流转的等待时间。等待是精益思想七种浪费中很关键的一种浪费，提升速度的关键措施就是减少等待。而标准产品发布流程是采取基于变更周期为最小调度单元的交付模式。

在同一周期内，即使某一需求完成后，也无法进入到下一环，而是等待变更周期内的需求统一完成后，进行集中部署发布，造成了大量的等待时间。

DevOps理论中，将传统的部门间合作模式改变成产品模式，将每一需求设定为最小调度单元。每次开发一个（或一个小的、固定批量的）需求，使得业务需求尽可能连续的通过一系列的加工步骤，并且每一步都刚刚在下一步需要的时候完成，从而减少了等待过程中消耗的时间，提高了发布效率。

3、建立持续优化

通过建立红灯反馈机制与单件流流水线的改造，发布质量和发布效率已经有了明显提升，但DevOps实践的第三个基本点是创建一个可不断优化的流水线，接下来我们将回到最初的两个问题上，讨论如何建立不断优化的流程。

1、如何更好地提高变更质量

我们建立红灯反馈机制的标准就是将生产问题进行标准化的反馈，但这并不是反馈机制建立的终点；相反，在不断的优化过程中，将日常新增生产问题、监管要求的标准不断增加到生产流水线中各个环节的审核标准里，将成为日后必不可少的一项工作。

2、通过自动化工具、平台，提高每个流程中的效率

提到DevOps或者搜索DevOps关键字，往往会提到DevOps的整套自动化工具链，例如jeklins,puppet,ansible等。自动化工具虽然并不能代表DevOps，但自动化工具是将手工流水线改造成工业流水线的基础，通过一系列自动化运维工具的使用及推广，对各个环节进行自动化，从而提高各个环节的执行效率，更好地将DevOps思想贯穿到持续发布的流水线中。