一、项目背景
随着机队规模和各项业务的发展扩大，加上数字化转型工作的深入，以往依靠大量人员投入的人员密集型研发和维护体系的方式已经不堪重负，影响工作效率。DevOps研发运维一体化应运而生，简单地来说，就是更好的优化研发(DEV)、测试(QA)、运维(OPS)的流程，研发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠，提升IT效能（更高效的IT产品交付、更低的维护成本、更低的运行风险）。
二、问题分析
很多组织将开发和系统管理划分成不同的部门（开发与运维），开发部门的驱动力通常是“频繁交付新特性”，而运营部门则更关注IT服务的可靠性、稳定性、安全性及IT成本投入的效率；两者目标的不匹配，就在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度：主要体现在流程与自动化工具平台、人员的个体素质及协作意识、系统运行环境与标准。我们分析了当前研发与运维两者间的问题，并对这些问题做逐一剖析。
（一）环境因素
1、上线流程
以目前信息部系统研发测试发布上线的线上标准流程来说，具体流程如图1-1所示：
图1-1 系统研发产品测试运维流程图
根据图1-1可以看到，目前上线流程主要由开发人员、测试人员和运维人员组成，但是从流程的内在性特征来说，该流程是存在一定的问题的，具体原因如下：
上线前：主要由开发、产品、测试组成研发团队，运维基本上不参与整个活动；
上线中：主要以测试为主，开发、产品为辅，运维参与系统正式上线需要的硬件及软件的部署；
上线后：主要由开发、产品、测试组成研发团队对现有系统功能的不断迭代开发，使系统更加完善，增加用户体验，但运维团队则希望系统更应该需要的是稳定，而不能频繁的更新迭代。
2、工具平台
目前运维在系统发布过程中人工操作的比例过大，工具化活动节点使用比例过小，容易在流程中出现人为失误。
（二）个体因素
1、业务经验
IT设备种类繁多，错综复杂，UPS，基础网络，服务器，存储，系统，应用，从硬件到软件，从后台应用支撑到前台页面服务，每一项都需要掌握不同的知识。就算单独某一项的设备都会涉及众多厂商，以存储为例，有EMC、NETAPP、HPE、IBM等，管理不同的厂商产品，又需要学习不同的知识，那如果分工不明确，人兼数职，不但效率较低，还容易出现人为的操作失误。
2、团队分工
从产品策划到上线，一般为以下顺序：
（1）开发团队收集产品的需求，定下时间表并进行开发；
（2）开发完后，交由测试或质量团队进行测试；
（3）然后交给运维团队布署新产品或新版本；
（4）运维团队将运维过程中发现的代码缺陷反馈给开发团队进行修复。
每个阶段，对应团队都是各做各的，完成自己任务后就把球踢给下一个团队，如果下一个团队发现问题又会把球再踢回原来的团队，有些问题确实需要靠提高人员技能去解决，但如果团队能形成一股合力，同样的人员组合会产生更好的效果。
（三）职责目标
很多组织将研发和系统管理划分成不同的部门。研发部门的驱动力通常是“频繁交付新特性”，而运维部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，就在研发与运维部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。由于不同职责和分工导致目标存在不一致的情况，对于整个项目的研发运维一体化来说，在不同的职责前提下通过工具化流程化的方式实现目标统一尤为重要。
三、解决方案
（一）行业调研
根据2018年Dora（DevOps Research and Assessment）分析报告获得以下行业发展重要信息。
1、DevOps发展的行业与规模
科技与金融仍然撑起半壁江山，而零售、通信、教育、医疗、政务、健康、保险、制造等主要行业也达到30%左右，整体行业均有涵括，非盈利的组织数据占比明显提高，这也说明了DevOps在各个行业已全面展开。
2、实地调研
某中外合资汽车制造公司以打造领先豪华车企，传递高端客户体验为目标，不断像市场提供全球一流品质的产品和服务。近两年以数字化转型为目标，已在部分项目尝试落地了DevOps。
3、组织结构
根据调查结果，在DevOps实践中被采用的方式：研发中心方式、特定应用服务的跨职能团队方式、专职的DevOps团队。另外SRE团队方式是目前采用最少的方式，但是关于后续是否会尝试使用这种方式的调查上，意愿是很高。
4、DevOps实践成功的扩展
小规模的DevOps试行已经获得成功，但是成功地如何大规模的扩展开来是一个巨大的挑战。如何复制小规模的DevOps的成功，是当下实践的重点挑战之一。
5、融入安全的DevOps
将安全融入DevOps是一个主题，而安全策略的自动化配置又是重中之重。
（二）方案制定
通常，部署前置时间动辄需要好几个月。在大型、复杂的企业里，使用着紧藕合的单体应用，少有集成测试的环境，测试和生产环境的前置时间很长，并且严重依赖于手动测试，或者需要各种审批流程，情况更是如此。很可能是在项目结束前，将开发团队的变更合并到一起后，才发现整个系统根本无法正常工作，有时甚至会出现代码都无法通过编译和测试的情况。 每一个问题可能都需要几天甚至几周的时间来定位和修复，因此导致了极其糟糕的客户体验。
通过上述方式，能有效地将前置时间缩短至分钟级别；即便在最坏的情况下，也不会超过小时级别。 其价值流图如图所示。
我们把三步工作法作为基础的原则，并由此衍生出了 DevOps 的行为和模式：
第一步，实现开发到运维的工作快速地从左向右流动。
第二步，在从右向左的每个阶段中，应用持续、快速的工作反馈机制。
第三步，建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。
（三）将运维融入日常开发工作
我们的目标是能够以市场为导向，让小团队快速、独立地为客户提供价值。 但在以职能为导向的集中式运维团队里，实现该目标是有挑战的，因为运维团队不得不满足许多开发团队的各种迥然不同的需求。结果导致运维工作需要较长的交付周期，并且需要反复地调整工作的优先级，而且部署结果总是不尽人意。
以下是3个通用的策略：
1、构建自服务能力，帮助开发人员提高生产力；
2、将运维工程师融入服务团队；
3、如果运维工程师人数紧张， 则可以采用运维联络人模式。
（四）创建共享服务，提高开发生产力
在理想情况下，运维提供的所有平台和服务应该是全自动化的，并且能按需提供，不需要开发人员提交工单，然后再等待运维团队自动处理，这能保证运维不成为客户的瓶颈。这种方式使得产品团队能够及时地取得所需的资源，同时降低了沟通和协作成本”。
（五）将运维工程师融入服务团队
若想取得以市场为导向的成果，另一种做法是通过融入运维工程师使产品团队能自给自足，从而降低对集中式运维的依赖程度。这些产品团队可以完全负责服务的交付和支持。
（六）为每个服务团队分派运维联络人
由于各种原因（如成本或者资源不足），可能无法给每个产品团队都分派运维工程师，但可以给每个产品团队指定一位运维联络人，通过这种方式同样也能得到类似的好处。
（七）邀请运维工程师参加开发团队的会议
在融人运维工程师或分派运维联络人之后，可以邀请他们参与开发团队的各种会议。我们的目标是帮助运维工程师和其他非开发人员更好地了解目前开发团队的文化，并主动地参与规划工作和日常工作，从而使运维团队可以更好地为产品团队植入运维能力，并在产品上线以前就落实相关工作。
（八）为部署流水线奠定基础
为了使工作快速可靠地从开发流向运维，应当保证价值流的每个阶段都使用类生产环境。 此外，这些环境必须能用自动化的方式进行搭建。在理想情况下，应该使用脚本和存储在版本控制系统中的配置信息按需搭建，而不需要依赖运维团队进行手动操作。 部署流水线的目标就是能够基于版本控制系统中的信息重复搭建整套生产环境。
（九）实现快速可靠的自动化测试
1、对代码和环境估支持续构建、测试和集成
2、构建快速可靠的自动化测试套件
（十）自动化和低风险发布
1、自动化部署流程
2、应用自动化的自助式部署
3、在部署流水线中集成代码部署
（十一）建立能发现并解决问题的监控系统
1、建设集中式监控架构
2、建立生产环境的应用程序日志监控
3、使用监控指导问题的解决
（十二）将学习融入日常工作
1、建立公正和学习的文化
2、举行不指责的事后分析会议
3、尽可能广泛地公开事后分析会议结果
4、降低事故容忍度，寻找更弱的故障信号
5、在生产环境注入故障来恢复和学习
6、创建故障演练日
（十三）DevOps交付流水线平台
在DevOps实施阶段中，DevOps交付流水线平台的搭建是最基础也是非常关键的步骤，由于其对产品质量、运营风险的严格要求，以及自身产品的复杂性、特殊性，该平台的构建需要考虑如下问题：
1、 该平台一定要与企业目前所具备的基础设施相结合，而不能像一些初创企业，马上就对整个基础环境及设施进行更新。
2、该平台一定要考虑到企业IT组织目前的组织结构现状、人才技能现状以及存量产品特点。
3、该平台一定要与企业目前已有的流程控制系统相结合，而不能独立于现有的流程控制系统。
基于以上考虑，设计了如下图所示的DevOps流水线交付平台架构。
DevOps 流水线交付平台整体架构图
显然，在 DevOps 流水线工具平台实施的架构中，其核心是流水线工具平台层的搭建，对上，该工具平台需要通过流水线引擎与现有的流程管理系统对接，对下，则需要兼容现有的各种程序语言、研发发布模式、构建方式，以及存量硬件和云平台的基础设施。
