最佳实践：DevOps 开发推广实践探索——由点及面，实践出真知丨IDCF

点这里👇星标关注，获取最新资讯！

朱庆兵，合肥晶合集成电路股份有限公司，技术副理，研发效能（DevOps）工程师（中级）认证学员

随着公司的产能逐渐增大， 公司的人员规模也随之增大，IT的人员规模由原来的三四十人增加到一百多人，但是交付的业务需求量确并没有多出多少。随着业务与数据的复杂，人员的负载越来越大，导致需求的交付数量不增反降。于此同时，业务部门对IT的需求交付满意度也在逐渐下降。IT软件研发陷入进退维谷两难境界。软件的研发鸿沟也越来越大。

从实际出发，从IT部门的研发模式以及需求的管理模式角度进行分析，总结以下原因：

• 技术债务积累： 随着时间的推移，没有及时重构和更新的代码库导致技术债务的积累，使得系统越来越难以维护和扩展。小功能修改导致线上生产事故的大风险。

• 系统扩展性差，缺乏模块化： 系统是传统的单体开发，模块之间耦合度比较高，一个需求的改动往往涉及到多个模块的功能受影响，开发时间短，但是测试时间长，上线人员每次功能上线都是一次钢丝绳上的跳舞。

• 数据一致性和可信任问题： 同一个业务逻辑，在不同系统中存在不同的业务逻辑，IT开发人员耗时开发，业务人员耗时核对，耗时耗力且在做重复无用功。数据源缺少统一规划和执行标准。

1、需求目标不明确，描述不清晰： 用户从自身业务角度出发，希望IT给于帮忙解决当前问题，但是从认知和沟通上存在一些问题：

• 缺少对业务需求的整体性和一致性的把控，导致需求只能解决局部问题，无法从业务整体出发，提出目标明确的需求。往往是头痛医头，脚痛医脚，这也经常导致需求的频繁变更，增加成本。

• 对系统用途定位不清晰，功能界限不明确，导致给A系统提B系统的业务需求，或者直接将可能涉及的系统单位都meeting讨论，导致人员时间成本增大。

• 业务数据的流转和处理逻辑不清楚，在进行功能描述时，无法清晰的确定详细规格，同时开发人员对业务情境和专业术语没有足够了解，导致开发人员和用户之间的沟通壁垒增大，需求洽谈周期变长，延长交付周期，降低产能。

2、用户故事地图不完整： 整个团队缺少对产品和功能都熟悉的产品经理或者项目经理，导致开发人员在整理用户故事地图时，无法覆盖全部的业务情境。用户在验收过程中无法复现全部的业务场景，导致IT交付质量无法保证。

3、需求变更频繁： 产能的增大，导致需求激增，业务发展的需求，无可厚还，但是需求目标不明确，缺少专业产品经理对需求把控，为了满足线上生产的需求，频繁新增需求，变更需求，导致IT开发人员往往一个需求没有完成， 业务需求已然发生了变更，IT人员和用户之前的努力也就被浪费了，只能从新出发，没有任何效益不说，还往往让人产生挫败感。

4、IT 需求交付效率低，交付质量无法保证： 软件架构的落后，代码没有得到有效的管理，导致需求虽然增大了，但是IT开发人员无法协同开发，无法有效的提升开发效率。另外，每次的更新都会伴随线上事故的MO风险，每次的MO事故，都强制review管理规范上的措施，导致上线的流程越来越复杂，上线的时间也越来越多，需求交付的质量也未必提升多大。

5、项目管理没有统一的规章流程，导致人员耗费大量时间在报告和会议上： 人员的增加，同时也带来了管理上的困难。一些核心的需求专案，高层往往比较关心，需要负责相关业务的人员进行汇报，随着需求增多，核心的需求专案也越来越多，结果导致很多人都耗费了很大的精力时间耗费在PPT的编写以及汇报上，无法抽出足够的精力，解决业务需求的交付。

6、系统没有统一监控方案：只能被动的等待用户发现问题，随时救火，耗费大量的人力和资源在没有效益的工作上。

7、IT人员技术能力良莠不齐，核心技术能力不能应对产线的复杂变化，交付困难，运维困难。

针对之前的问题，公司的领导层也就问题提出一些解决方案来提升开发效能，比如：

• 为了减少需求洽谈的困难和周期，明确需求的效益。制定了一系列管理措施：规范用户需求规格模版，效益计算等、规范负责人用户故事的梳理格式等。

• 为了提高需求交付质量，要求编写单元测试，编写上线测试文档，然后相互协同确认操作部署工作。

• 引入DevOps管理理念，参考敏捷迭代开发模式在公司内部进行推广。

由于没有完善的理论指导，单靠依葫芦画瓢的实施，并没有获取精髓，最终的结果就是效果甚微。有些僵化的管理措施，反而给IT开发人员增加的很大的负担，再加上领导未一直在重视这些事情，久而久之，就没有人再遵循相关规范了。

关于为什么一些推进开发效能提升的措施和规章制度，到最后都没有持久的坚持下去，没有形成IT人员的开发习惯。我进行了IT内部人员沟通访谈，总结了一下几点：

1.相关的制度没有从实际组织管理文化出发，浮于表面，流于形式。

2.开发规范制定者非IT工作人员，不符合IT人员的开发习惯，有时甚至出现反作用，增加了开发人员的Loading。

3. 制定的规章制度没有聚焦核心原因，没有解决IT开发人员的核心问题。

4.仅有规章制度，没有对应的工具平台支撑，IT开发人员操作繁琐，效益不明显。

总结起来一句话表达：没有从IT人员的实际工作出发，没有专业的理论指导，没有关联的效能平台工具来实际解决IT开发人员的痛点问题，那么提升研发效能也就不可能有明确的效益。

从上面的研发效能推广三角可以看到，实践的推广虽然重要程度最低，但是他的实施困难程度却是最低的。从我司的目前状况、组织文化以及IT人员的开发习惯来说，相对于从DevOps的文化推广，更倾向于使用便捷的工具来减轻他们的负载，提升他们的交付质量。

根本原因既然已经找到，那么DevOps推广的方法就应该从解决IT开发人员的痛点问题着手，从工具平台支撑配合规章制度的管理，实实在在的解决IT开发人员的困难点，提升需求交付效率的同时保证交付质量。

针对于此，我们推广的方向就很明确了。从平台工具出发，将重复工作自动化，减轻IT人员的工作Loading，让IT人员认可工具带来的便利。于此同时，通过工具的便捷快速，发现软件工程的代码质量问题，并且给出解决方案，让开发人员提升技能的同时，也保证代码的质量。

第一步：组建IT平台课，致力于为IT人员服务
作为一家制造行业的IT运维团队，除了需求的开发，大部分的IT人员的主要工作内容是运维工作，几乎很难全力去钻研技术。为了更好的支持IT人员的开发工作，同时也为了引进新技术来优化现有的软件架构，从技术的角度来促进软件效能的提升。公司决定召集一批技术能力强，对技术有浓厚兴趣的成员，成立IT平台课，为IT的开发排忧解难，保驾护航，其主要职责如下：

• 研发平台工具，支持产线系统的开发工作；

• 引进新技术，评估和优化既有代码架构，提升系统性能；

• 搭建监控平台，从系统硬件和软体两方面监控系统问题（硬件网络监控，系统响应监控、系统异常监控等）；

• 新技术、新方案培训，共性问题的解决方案以及培训推广；

明确了新课的职责，也确定了推广的方式想从实践出发，优先解决用户的痛点问题。

第二步：搭建自动化集成部署平台，实现一键部署
引进自动化集成部署功能，是DevOps实践中的关键环节，它通过自动化的方式将软件的构建、测试和部署流程标准化和简化，从而提高软件开发和发布的效率。推广的策略如下：

• 评估各系统的架构以及语言支持，选择合适的自动化集成部署工具：

鉴于大部分项目使用的是.Net framework语言，要想实现自动化编译，我们需要打通源码版控工具与集成功能之间的关联，所以我们使用GitLab替换SVN成为版控工具，并且使用Jenkins作为自动化编译工具；

• 制定清晰的流程，协助业务系统集成自动化集成部署功能：

从技术开发人员的部署操作流程出发，结合公司的规章制度要求，编制符合实际需求的操作SOP以及更新Check Point，确保新的上线部署流程在保证上线流程安全的前提下，减少开发人员的上线工作量。针对特殊系统定制自动化集成部署的流程。包括：代码提交、构建、测试部署和版本回滚等功能支持；

• 持续反馈，持续改进：

制度流程，操作SOP不再是确定就不变的产物，监控IT开发人员的上线需求以及数据度量，及时发现部署问题，梳理优化要点，总结经验，持续收集反馈，优化和改进自动化流程，定制适配各个业务系统的特性的自动化集成部署系统；
之所以第一步就做自动化集成部署功能，除了解决业务系统上线更新时间比较长之外，其次也是从困恼IT开发人员直接问题出发，让业务系统部门对我们IT平台课的平台支持认可，建立对IT平台课交付能力的信心，真真切切的为IT技术人员排忧解难。同时也是打响推广DevOps的第一步，让IT业务部门接受我们之后的推广。最后代码存储到GitLab上，也对我们接下来进行代码质量扫描提供基础。

成果：自动化部署功能上线后，首先是试点上线，然后是全面推广。上线之后，业务系统的部署时间大大缩短，16台server的上线更新时间由4H->0.5H，节省的上线时间很客观，原来需要两个人才能完成的部署，一个人就可以搞定了，而且也解决了人工部署带来的风险。

第三步：搭建代码质量扫描工具，建立在线评审机制，保证代码质量
有了自动化部署打下的基础，我们在此基础上继续搭建代码质量扫描平台。并且引进代码在线评审机制，确保编码从语法和业务两个维度保证交付质量。

• 基于Gitlab技术，选择SonarQube为代码质量扫描平台。选择的原因主要有三点：

  1、SonarQube是开源最广的代码质量扫描平台，与GitLab很方便集成，且支持很多语言，对于.Net framework也有特定的Scanner工具进行扫描，除了可以轻松的集成到大多数的CICD管道，对以后得扩展也非常方便。同时对目前的业务系统非常友好

  2、SonarQube提供了Sonar Quality Gates，这是一个清晰的指标，用于指示新/变更的代码是否符合预定的代码质量标准。如果代码通过了Sonar Quality Gates，可以有信心地认为它适合生产环境。

  3、SonarLint作为IDE工具的集成，对开发人员非常的友好；

• 整理详细的培训文档，对业务团队进行SonarQube 的功能和优势培训，确保他们理解如何使用SonarQube来提升代码质量；

• 针对各个业务系统进行扫描规则梳理完善，适配业务系统，在保证代码质量和规范的同时，减少业务部门的Loading；

• 从小规模的项目开始，逐步推广到更多的团队和项目中，以减少阻力和风险；

代码质量扫描让代码从语法上减少了上线的风险，但是对于业务逻辑是否合理就无能为力了，此时需要发挥人的主观能动力。为此我们和业务各系统负责人宣导了在线代码评审机制。同时为了适配该机制，结合GitLab的分支管理以及GitLab的合并请求功能，实现代码合并时，Team Leader可以针对代码的质量进行在线评审。审核主要的业务逻辑是否合规合逻辑，发挥精通业务和代码人员的优势，保证代码的业务质量。

此外，充分利用技术水平比较高的同仁的优势，将一些共性问题剥离，并且形成IT团队的知识库，在IT内部进行培训讲解，此举旨在避免类似问题的同时，也提升IT同仁的开发技能，包括但不限于以下方面：

• SQL优化（数据库原理、执行计划、常用优化技巧等，知其然，知其所以然）

• 接口调优（并发编程、缓存、线程池以及IO操作优化，各种不同情境下接口调优的方案）

• 软件设计模式（常用软件设计模式应用讲解、软件开闭原则的理解、应用架构了解等）

• 一些高性能的新技术引进（分布式、事件驱动数据流处理等）

第四步：建立系统监控平台，解决系统线上问题
保证了代码上线前的代码质量，对于已经上线的系统该如何保证平稳运行呢？

我们采用线上系统接口监控的机制来监控系统的健康程度（注意：已为系统系统定制zabbix系统运行环境监控，从CPU、线程、Memory方面来监控系统的运行环境）。

我们引入了OpenTelemetry这个开源组件来监控在线系统的健康程度。

1.选择OpenTelemetry，对系统的侵入性比较少，继承接入比较简单；

2.OpenTelemetry支持和三方可视化BI集成，提供美观的界面来展现接口响应情况；

3.制定详细的SOP，给业务系统负责人进行培训，提升接入的效率；

4.从小规模的项目开始，逐步推广到更多的团队和项目中，以减少阻力和风险；

成果：OpenTelemetry的功能还是很强大的，无论是界面接口的响应时间，还是功能SQL的执行时间，都可以监控到，为产线项目监控很多隐患风险，同时也让IT人员更深入的了解代码在线上运行的情况，提前预防可能存在的健康风险。

总结：以上就是目前DevOps推广的策略，我们的策略就是从实践出发，优先解决IT开发人员的痛点问题，在改动Loading最小的情况下，协助IT开发人员提升开发质量和效率。

当然DevOps的文化和实践的集合，然，我个人认为推广的核心是落地，核心目标是有可行的解决方案，再从实践出发，切实解决用户痛点问题，增强开发用户对我们的信任和信心，这样才能持续的正向激励下去。

还记得之前的研发效能推广三角么？实践推广是最简单的，我们从IT技术领域比较关心的代码质量扫描、自动化部署、系统健康监控等领域着手，让IT开发人员能专注于业务开发，提升开发效能。但是IT人员除了本身代码的开发之外，决定这个业务能否成功的还取决于对业务需求了解的是否足够详细，业务情境能否覆盖全面，系统设计能否支撑实际场景的需要，往往也是这部分最为耗时。在制造行业领域中，需求的提出到确认占据了整个需求交付周期的40-50%，比重非常大，所以把控需求交付周期变得尤为重要。

• 深入调研：

目标：分析需求交付周期中影响交付效率的影响因素；

方案：针对交付周期慢的项目，跟踪项目需求从创建、分析、产品设计、开发设计、编码、测试、发布上线、产品验收、业务验收等阶段进行跟踪定位每个阶段的时间，造成影响时间比较长的因素。用最真实的数据来反映需求交付整个周期。我们引入了DevOps效能平台，借助平台的一体化能力，方便统一规范IT管理流程，让管理数据真是反馈时间开发状况。

分析：从项目管理、需求管理、工时统计等方便分析，分析月需求流速率、需求等待时间、需求分析周期、开发测试时长、部署发布时长以及最终需求前置时间等。从各个阶段的统计结果，针对性的调研耗时阶段的主要影响因素，最终落地需求交付影响因素说明。

• 细究原因：

通过为期三个半月的需求监控，以及数据分析，我们分析出以下影响需求交付效率因素，跟我们之前预测的影响因素差不离，大致归类以下因素：

人员因素：

- 多部门协调配合，跨系统功能对接，由于各系统之间没有足够了解，以致各部门之间协商讨论耗时长，每次都Meeting都耗费很多系统负责人的时间，造成人力资源上的极大浪费；

- 需求讲解、功能分析、业务情境完善同样如此，每每在梳理各系统业务逻辑时，由于对其他系统的掌握不足，每每都陷入细节深坑中，偏离研讨的主题，导致耗费大量人力时间，却依旧没有输出结果；

这两个原因概括就是由于各部门、各系统负责人对系统的掌握不够，以致需求的大部分时间是无效讨论和过度讨论，浪费大量的人力Loading，却没有相应的产出。

管理因素：需求终于确定了，业务负责人提交需求申请单，此时进入了领导审批的环节，需求涉及的各部门领导，本着负责的态度，然后开始找系统负责人，了解需求详细情况，判断需求解决方案是否全面，合理。然后每个环境确认都要耗费半天以上时间才能出结果，嗯，这个时间不长，但是禁不住签核审批的流程长，而且是串行的。最终导致的结果是一个需求签核时间耗时比需求研讨和确认的时间还长，纯属于好心办坏事，越好心越坏事的那种。

沟通因素：各部门之间的沟通理解不一致的问题尤为普遍，最常见的场景主要有以下：

- IT技术人员对业务人员的描述和专业术语不明白，以致需要详细的解释，沟通耗时耗力且容易陷入争执；

- 需求涉及方与IT针对专业术语理解不一致，导致对同一描述有各自不同的理解，最终导致需求返工的现象；

技能因素：这主要是IT开发人员的能力因素，思维逻辑不够缜密，导致业务情境不够完整，功能上线后，有些业务场景不能满足需求，导致功能退版，需求延期的情况。主要的原因是没有一个对业务和技术都足够熟悉的负责人来统筹审核业务情境导致。

• 理论指导：

为了解决主要的影响因素，除了引入DevOps平台，还学习精益思想，引入了Scrum开发管理模式实践提升需求交付效率。

- 选举产品技术经理：各系统选取既精通项目技术又熟悉系统业务的人员作为产品技术经理，对其进行产品经理技能培训。每次的专案需求，由各产品技术经理进行技术和业务的评估，涉及多系统对接的，也由各产品技术经理对其进行评估。

通过这种方式，减少非必要人员的人力时间消耗，加快需求的沟通。

- 组建Scrum团队：从需求创建开始，纳入需求交付全生命周期管理，组建Scrum团队，建设Scrum项目管理模式，将一个大型专案分为多个迭代版本，选取产品技术经理为Scrum Master来协调整个迭代周期的Scrum管理。通过迭代计划会，确认每个迭代的用户故事点，然后通过每日站会来协调解决迭代过程中的问题，确保迭代周期内项目能如期进行。项目评审会由用户来确认本地迭代是否满足要求，是否调整。最后通过迭代回顾会总结本次迭代周期内持续保留的优点和需要改进的缺点，确保整个迭代团队是持续学习，持续进步，形成正反馈循环。

• 完善理论：

理论和解决方案的提出都是基于完美模型下的产物，实际操作过程中，很多理论并不能完美适配现行的管理情境，迫切的需要根据我司既有的管理模式和组织架构进行调整。在既有的Scrum管理模式中调整：管理方法、管理角色、管理流程，利用效能平台中的度量数据来分析原因，制定解决方案，然后指导效能实践，反过来，效能实践提供更多的效能度量数据，这些数据会反哺效能实践，组建一个正反馈的循环。在此过程中，务必要结合实际的项目组织架构，管理模式以及系统特性来不断改变，优化，保证DevOps的思想能顺利的运行下去。

组织架构的调整：组织架构的调整都是自上而下的，需要影响公司上层。在此，我们根据DevOps的指导思想，优化当前管理模式，通过变更需求管理模式和流程探讨，评估新的组织架构与各自利益的的平衡点，然后通过试点项目来论证管理模式和流程的可行性，在此基础上不断调整，以期获得最大需求交付效率，最后通过真实的数据，来向公司上层证明管理模式的可行性。

这条道路是艰难曲折的，切记需要跟各自的直属领导进行充分讨论论证确认， 否则很容易造成坏印象，从而导致DevOps推广胎死腹中。

复盘文化和工程师文化的推广：DevOps的推广是一个持续学习，持续改进的过程，核心还是人的管理，为了支撑人的总结和进度，在团队文化氛围上还需要下一番功夫：

项目积淀（知识+经验+复盘）：每次的迭代都有精华和缺点，遇到问题不可怕，事后的复盘尤为重要。通过总结和提炼过往发生的MO原因和措施，我们发现一些共性问题：

- 工程操作不规范，存在侥幸心理

- 业务情境不完整，造成交付需求不满足业务需求

- 常见的错误没有共享，导致不同的团队都犯了同样的错误

针对共性问题，提炼出一套管理机制，配合DevOps中的迭代评审会，提炼提升研发效能和质量的优良的经验和方法，然后沉淀到知识库中，对于典型或共性问题，在部门内部进行开展培训，避免类似的问题再犯。对于非技术性MO，则会针对性的进行复盘，需要明白：

1、故障是常态，无法完全避免：我们可以通过复盘的方式，让问题暴露出来，然后制定对应的措施，复盘机制能让团队深入思考，明白问题，同时集思广益，知道如何解决问题，是团队文化重要的一环（此处只是讨论和确认问题的原因，可以采取的措施，后续的预防方案等，切勿将问题者钉在耻辱柱上，会议组织者务必要避免这样做，否则复盘会将是每个人的心里阴影，对我们后续的工作推展造成十分不利的影响）。

2、故障是表象，背后技术管理上的问题才是根因：通过复盘，从技术、管理、需求上的知识和经验的积淀，不断地完善知识库，最终会形成公司知识资产，对后续人员接手、处理问题提供完善的资料库，加快成员的上手速度，最终加快项目的推进和管理。

工程师文化：关于工程师文化，我比较喜欢阿里的《阿里工程师的自我修养》，这本书，从个人的角度来阐述个人在技术发展方向上的一些必须要会的思维方式；关于技术规划、管理、架构的思考；如何自我学习；如何从计算机知识到落地的能力等。

为什么要推广工程师文化，其实说推广是不合适的，因为工程师文化是天然形成的，并收到管理者风格、员工素质、公司环境分为等因素的影响。文化可以成就一家公司，也可以破坏一家公司。“如果远景是你要去的地方，那么文化就是确保你能达到那里的东西”。

DevOps的推广致力于，或者最终需要形成持续学习的文化氛围，由于推广不是一蹴而就的固有模式，随着技术发展，环境变更而不断完善改进的机制，所以持续学习的工程文化就是推广的保驾护航的动力。团队离不开个体的，一个持续学习，持续进步的个体会带给团队在推进项目管理产生质的飞跃。

那么在形成工程师文化过程中，我们有持续优化以下几点：

- 去除繁文缛节：不要对每件小事强加流程；

- 降低复杂度：更小的团队和更简单的解决方案往往更具适用性和可维护性，能够极大的减少沟通和交流的成本；

- 高效沟通：鼓励”带上数据去辩论“，减少无谓的沟通；

- 允许错误：比起责备，更应该倡导工程师从错误中学习，只有在这种自由和包容的氛围ie下，工程师才能更没有包袱，在不断变化的市场环境中为公司创造有效的价值。

- 鼓励分享，鼓励质疑：团队的积累，积淀，鼓励大家进行分享，提高自己的总结、表达和临场能力。同时，也鼓励大家质疑，对问题提出不同的见解，让真理在讨论辨析中越来越清晰（请勿带着个人私怨进行质疑）。

最后，DevOps是文化和实践的集合，从一个传统的管理模式向DevOps管理模式转变，其中涉及到需求交付周期的各个领域，单独拎出来都是一个很广博的领域，虽然目前行业内都有完善的指导思想和理论基础，但是结合各自公司的管理模式进行合理的推广模式尤为重要。在本次的DevOps推广过程中，我们组织相关的成员，系统的学习了DevOps研发效能的课程，并且结合所学习到的知识，从实践出发，由点及面，用最小的影响来实现最大的价值，通过自下而上的方法，一步步的推进DevOps在我司的落地。过程中有挫折和争吵，也有理解和支持。当然，目前DevOps的推广也还在持续优化改进中，科技在进步，未来的道路还很长。最后想说，每次的实践，都是通过成功的阶梯，问题是你有没有走对方向，并且坚持下去。愿在DevOps推广的道路上，我们共勉。

IDCF