为何定制开发是DevOps工具链的最终归宿？| 践行者第18期

定制开发DevOps工具链的必要性是什么？DevOps工具链选型方面有哪些弯路值得我们反思？从规划到实施，DevOps工具链定制的一般流程是怎么样的？本期《践行者》，我们邀请到了资深规模化敏捷/DevOps咨询顾问刘晔老师，和大家一起聊聊DevOps工具链！

一、直播实录

Q1：定制开发DevOps工具链有什么优势？

主要原因是个性化管理需求客户化的诉求，最终导致自研这条路。特别是基础平台和基本功能具备后，客户对个性化和定制化的管理要求是长期的，自主掌控定制主动性最大，成本也最低。对于国内工具厂商而言，追求通用性更符合他们的利益。选择厂商时建议考虑其产品策略、服务团队规模、实施经验等，与本企业的发展诉求匹配为最佳。

Q2：银行在DevOps工具链选型方面走过哪些弯路？

分享两个实际案例，我们替换掉的两个平台基本代表了我们走过的弯路。

第一个平台在建成后必须下线并启动新平台替代的主要原因是服务商产品策略变更，不再提供升级服务。DevOps建设初期，客户按照我们的要求选择了已有资产，一个流程引擎，一个配置工具，在这个平台上不断定制化开发出DevOps从需求到投产的闭环非常丰富的功能，基于此平台我们当时的重大项目也成功投产，开发团队基于此平台形成了自己的研发管理模式，行内也启动了推广工作。

这个厂商在行业内是一个小众品牌，后来厂商（因为产品小众业绩不佳）不再支持流程引擎的升级改造，而银行的管理要求在迭代升级，因此不得不考虑选择新的平台。银行在替换流程引擎时，采用公开招标的形式，第一要国内厂商，不要国外厂商。第二要求了在本行内使用源代码，这样就具备了自研的基本条件。这样就引入了第二个平台，并把管理功能进行了迁移，第一个平台下线。

第二个平台之所以被替换掉，主要原因也是服务商的支持能力不足。一是因为敏捷、看板、燃尽图等这些新方法、新管理模式出来后，银行想要实现这些功能，产品不支持。二是服务厂商，大家在选型时也要注意，供应商需要有你这个行业的实施经验，服务规模要和企业的建设需要匹配。我们选择的第二个平台的服务商是个做军工企业项目管理的厂商，但他的整个实施团队包括咨询团队，对于银行软件开发的要求完全不了解，迁移功能抄得千疮百孔，因为项目时间限制，数据库表的设计从架构层面完全失控，这就导致我们在接手后发现按照规范几乎都要重新来过，而厂商的知识转移也不规范，文档不全，核心骨干离开公司等，导致想自研却没有技术支持。

因此给准备走自研这条路的朋友们以下建议：一是选择厂商时，我们要掌握源代码；二是厂商最好是了解你的行业特点的；另外关注知识转移。

Q3：刚起步的公司想要自研DevOps工具链，应该按照什么顺序进行或有其他实施路径可供选择吗？

刘晔老师：

建议做DevOps时要有确定的业务目标，不要仅仅局限于技术工具层面。

因为如果只是做一个技术工具层面的DevOps，会遇到一个问题：如何证明这个平台是成功的。这类新系统新上线，第一版的客户体验一定会很差。建议要有一个大的业务目标的实现，或者资质认证等，相当于做一个背书，这也算是一种佐证平台成功的策略。

平台如果是新搭建最好按照MVP的思路来实施，即先设一个短期目标，目标达成再逐步扩展。我们当初的实施都是按照这个方法开展的。

陈连生老师：

听起来像是把它当做一个项目或一个进化的产品在做？如果以这种形态去做，是否会更贴近您刚才的说法？

刘晔老师：

是的，DevOps平台本身就是一个重要IT产品，一定是按照产品的思路和资源配置来做。

建设DevOps平台与功能时，开始的需求是我们的DevOps团队提出的，最好的状态是使用者可以主动参与，后期由研发团队提出自己的使用需求（说明使用团队在主动根据平台功能适配自己的研发管理）。这样在建成投产后，研发团队基于我们的平台，将几百人的团队的研发模式、研发管理，以及研发的考核等已经完全固化在平台上，依赖平台来实现日常开发管理，这样实施结果必然是成功的。

因此，我认为DevOps平台建设要注重实效，建立基于DevOps平台上的研发与运维体系，我认为这才是真正的赋能，应该是我们建设DevOps要重要目标之一。

Q4：您有遇到过研发人员喜欢自己造轮子的情况吗？

DevOps的建设与推广需要组织级的推进，必须要整体确定目标、达成共识，「自上而下」推进。实际上，即使已经在某个核心团队成功实施了DevOps，在推广中对于另一个团队，是无法完全复制的，一定还存在个性化的内容，如代码质量门禁、构建脚本等。

往往平台通用性功能和团队个性化功能最终是既要兼容，又要妥协的，研发管理每个团队都不同，个性化部分需要整体上遵从组织级技术架构、组织架构、质量门禁等，CICD、代码质量配套迁移会大部分保留个性化。我们在推广的时候往往是要和研发团队充分沟通，制定一个专属迁移方案，研发团队研发管理过程基本要重塑。

科技研发/运维团队对于DevOps平台来说是主要用户。我们必须时刻关注着他们的痛点，目标是为他们赋能，提升整个团队的能力，减负的同时在保证质量的前提下加快交付速度，提升整个闭环各环节之间任务的流转效率。

Q5：在三个版本过程中，您在产品生死存亡的状态下有遇到过挑战吗？您是如何克服的？

最大的挑战来自于一线研发团队的用户体验反馈。我们做第一个版本普遍使用后的春节联欢晚会，每个部门会推选团队表演节目。那年春节晚会里有三个节目，他们用小品形式来吐槽我们新开发的工具（难用、任务计时可视化像紧箍咒、催工不近人情像“黄世仁”）。这些吐槽主要是组织级任务协同改变了各团队过去的工作模式，另外新功能刚投产各种细节不完善是不可避免的。

第二年的5月份，随着整体项目的投产，DevOps平台也得到了试点团队与领导的认可，用户体验改善依然是长期的工作，必须持续改进。

也就是说的，评判一个DevOps平台成功不能将短期的客户体验作为评判的唯一标准，必须辅助更大的业务价值目标的实现才更体现自身的意义。

第一，规划非常重要。根据我的实践经验，做DevOps不是一个人说要做DevOps或者照着信通院的三级认证指标，就可以做出来的。以System Thinking角度来说，不管是敏捷转型还是DevOps建设，这都是第三视角的盲人摸象。你处于第三视角，能够看到整个大象（即规划的系统整体目标），你要实施的DevOps、敏捷看板、CMMI等，只是整体目标中的某一部分。作为整体DevOps平台的设计者、产品经理或PO要具备这种视角，这样才能够相对客观地规划实施路径。

第二个是 关注 业务价值，以客户 （ 一线研发/运维团队 ） 为中心。大家一定要清楚，产品真正给用户或企业带来的价值是什么，以客户（一线研发/运维团队）为中心的原则之一：如何不给一线团队增加管理成本的前提下，提升自动化与质量管控能力。不能在实现业务价值的大旗下牺牲客户利益（如管理成本、用户体验等），一定要尽最大努力去兼顾、平衡。

Q6：在自研DevOps工具链时，面对老板如何表达DevOps工具链的作用并证明它能高效地解决问题？

第一期的成功很重要。举个例子，我绑定了一个大型项目，让整个一线研发团队使用并且成功上线。研发团队会替你说，这是成功且有用的。你做的工作一定需要说话管用的人帮你佐证。 因此，我的第一个建议是让客户来替你证明你做的是成功的。

第二个建议是先 实现 局部 目标 ， 再循序渐进 。我们的历程也是这样从开发管理、发版、测试管理、缺陷再回到开发，实现一个小闭环。那是整体项目进入测试阶段，这部分功能是需要的。完成并成功支持测试工作后，领导看到了效果以及各方反馈，随后指示对接业务需求，再对接投产部分，形成了整个DevOps的各环节打通。这就是MVP（最小可行性产品）的思想，即先做一部分，成功后再扩展。等整个项目成功上线后，就完成了平台建设0到1的阶段。之后，大家要注意引入度量，绩效提升等需要度量来体现DevOps平台的作用，比如：重要的一个度量是SAFe中Value Stream mapping方法，可以展现整个价值流各环节之间的等待时间与执行时间，识别了较长等待时间去分析原因与配套解决方案，这种方法就会引发一系列持续改进与提升效率的措施，DevOps作为数据源头自然也体现出它的价值。

这里举个度量的实际例子，我们在实施期间，研发团队开始使用DevOps时，(Java)代码全量构建至少需要2个小时，随着持续改进流水线与构建方法，投产时只需要几分钟，已经到了分钟级。这种一线用户团队提供的数字是很有说服力的。

但这不完全是DevOps工具团队的工作成果，它是一线用户团队持续进行代码解耦、构建方法优化等，这是大家协同工作的成果，并不完全是DevOps流程平台的功劳。只有一线用户知道该如何提升，并主动持续改进才会达到他们满意的效果，这样DevOps平台的达到的效率提升的效果才是最优的。

Q7：DevOps工具链的接受度因人而异，我们如何确保每位研发人员都在使用呢？

这需要组织进行推进 ， 一旦确定团队使用组织级研发工艺，对于每位成员都将是强制性的 。我们的样板团队做到这样的程度，编程人员完成自己工作提交以后全部是流水线自动完成，包括代码扫描、分支归并、构建、发版部署、制品出入库与晋级等，全部自动完成。这个阶段个人已经没有机会“置身渡外”了。

DevOps的推广是有一定周期的，对于尚未推广组织级研发工艺的团队，可以使用团队现有的CI/CD流水线，但组织级多系统协同交付必须遵循DevOps平台的统一调度，这是平台的基本功能，对于所有研发团队都是强制性的。 这种 统一 调度 的 原理 ， 类似 SAFe中的 ART（Agile Release Train） ， ART最重要功能就是交付时间对齐，尤其是多系统/多个团队一起完成一个功能时，部署启动测试以及投产要同步进行。

这种ART机制是我们从第一个版本里就已经实现了的，是规模化敏捷原理在DevOps平台中的实现，也是实践证明非常经典的功能之一。

Q8：DevOps工具一般用什么开发语言？

展示层主要是基于网页的语言，如HTML、JavaScript等，应用层Java为主，多数基于开源平台开发。

DevOps工具链目前以开源产品为主，如Git、Jenkins，也有部分采用第三方产品，如SonarQube、JFrog制品库等。

Q9：DevOps工具链可能与AI产生关联吗？

周围伙伴有在使用模型做类似ChatGPT的应用，知识库是实际工作中的各类管理素材，可以支持诸如“我该如何配置CI工具链”“标准分支策略应该怎样配置”“XXX步骤的后续操作有哪些”“XXXX报错，碰到这个问题该如何解决”等。我们只要训练好这个知识库，广大用户就可以求助并得到准确且标准的答案。

他们还致力于另一个项目：自动为你提供所需CI/CD流水线模板。这样就可以帮助大家快速搭建基于标准模板可定制的流水线。用户可以很方便地了解所需的配置细节，操作步骤、已有类似样例甚至脚本，用户可按需获取自己想要的内容直接配置就可以使用。

在我看来还有另外一种赋能比如需求的拆分、用户故事与测试案例框架的自动生成也是与DevOps平台比较相关的功能。

Q10：您所说的与业务结合具体指哪些方面？

我说的 “ 业务 ” 指的是研发 交付管理、增效付能等相关 的工作， 偏向 纯技术侧的 工作， 比如配置管理 、 质量管理。 DevOps平台是将这些管理工作，如 配置管理工作 ， 进行 标准化、自动化 的能力支撑 。

研发团队中的开发人员在完成开发工作任务提交后，全部自动完成（如构建、分支自动归并、制品自动入库与晋级等），一切事情基本都无人值守自动完成。尤其是到测试环境部署的时候，各种参数配置也是自动完成，这样环境会很干净，有利于问题定位与修复。

Q11：在DevOps工具链中，一方面要求是快，另一方面是刻意创建卡点，您是如何平衡这两点的？

卡点卡的是突破质量红线的问题，比如出现编译不通过、扫描出现BUG、脚本有问题、使用不被允许的指令等情况，必须退回修改，这种场景是不能强调快的，质量永远是最高优先级。

我们在定义组织级“质量门禁”规则的时候，有些规则是不允许打破，所有团队都必须遵守的，有些是可以审核确认后通过，所有“质量门禁”都是可定制的。

Q12：DevOps工具链的未来发展趋势是什么？

我不敢说太远， 我 个人 希望它能够 在微服务、容器等技术的加持下做到独立服务的解耦与组件化，以利于标准化能力可以通过配置就可以满足不同团队个性化的需要。一方面当前推广会更加高效，另一方面是将来再做DevOps平台时，服务可以尽可能复用，不需要重新再做一遍迁移。

我们在推广中发现，各个团队的研发管理还是非常个性化，初始建设的标准工序无法涵盖所有个性化要求，需要组织级与研发团队花费较大的成本去完成推广。实现标准化微服务组件化不仅在当前建设过程中可以低成本缩短迁移工期，还有一层考虑是在未来更换DevOps平台时，已完成的能力可以尽可能被复用。

Q13：有人认为银行企业文化死气沉沉，绝对不能犯一点点错。这似乎与所倡导的敏捷、DevOps不一致，您如何看待呢？

主持人谈到“企业文化对于DevOps建设的影响”，个人认为实施DevOps一定要采用Top-Down（自顶向下）的模式实施，先要在管理高层达成一致并得到主管领导的大力支持；采用MVP局部试行再扩展的策略，并不意味着调研与整体规划是在小范围进行“采样”的。注意这点企业文化对DevOps建设的影响就不大了，我理解这是实施策略的选择。

由于我在这个行业时间比较长， 我认为客户存在即合理。你所看到的问题可能背后是有一系列错综复杂的关联因素，不是仅靠个人方面就能快速改变的。因此，我们更多地考虑在这种驱动力下可以做哪些事情， 会尽量选最优的方案帮助他们实现，不花太多时间在苦恼上。换句话说，你苦恼也没用。

我 个人 体会， 不同行业在 追求新的技术方面 也会受到监管设定的 红线， 银行为例会涉及银监、人民银行等监管部门很多监管红线，是无法逾越的。DevOps开发运维一体化，按照教科书最理想的做法是让开发人员直接进行投产，管理生产环境，这样可以做到应对生产问题最高效。但这件模式是挑战银行行业监管红线，生搬硬套去做是行不通的。

我们只需要关注如何能够快速地、自动化地进行投产 ， 对于生产事件/问题快速响应 。换句话说，我们不要太注重概念与“教科书”标准动作的“形式”，而更注重其工作实质与工作目标/效果。

企业会按照她的生存环境与大背景下自主发展，在过去几年，银行追求新技术创新的步伐稳健提速，从其前瞻性与技术引进来看，有些规划建设已经比较超前了，比如敏捷、DevOps、大数据、容器、微服务等我所服务的银行已经实施了多年，现在的AI刚刚推出，已经由团队在训练自己的模型和知识库，横向与其他行业相比不算滞后了。

Q14：如何保证数据的安全性，即在DevOps工具链中如何保障整个代码系统的安全呢？

整个代码系统的安全这是一个“大课题”，DevOps平台是一个环节，但不是仅靠DevOps平台就可以保障的。

举个例子，我个人笔记本的GitHub里面有公司产品的源代码，一天工作结束后，回家一上网传到外网Git Server上去了，这属于严重的安全事故。虽然GIt工具是DevOps工具链的一环，但这种事故不是DevOps平台可以解决的，需要其他的安全保障措施，如：工作终端的办公区保管、工作终端网络安全策略以及配套监测等。银行这边人民银行有另一套安全监测系统能够发现这种代码泄露的情况发生，发现后会作为一个重大事件责成当事企业整改，全行业进行通报的。

小结一下， 一方面是从合规 要求在DevOps平台落地范畴 ， 可以在工具链中加入安全扫描等安全部分的内容； 另一方面从 保障整个代码系统的安全 的范畴目前也有比较成熟的方案，需要通盘考虑，以保证个人终端设备的数据安全。

这个问题的提出给我们DevOps项目经理一个提示，需要很清楚项目的边界，哪些是DevOps范畴可以解决的问题，哪些不是。不要过度承诺，也不要什么锅都背。

Q15：DevOps定制一步到位的投入成本比较大，发挥的价值不易直接体现。有没有渐进式的DevOps成功经验？

如果是0-1新建阶段建议采用MVP（最小可行性产品）的实施策略（上面已经提到），规划好完整的建设路径。建设规划目标需要 和企业领导、业务方达成一致，也就是 每阶段 要达成的目标 实现后 ， 企业 再进一步投资 才有信心 。

谈到整体规划这个话题，我引用“瞎子摸象”这个故事来做个比喻，“大象”是科技侧整体的科技系统（现在有个概念IT4IT），DevOps只是其中一部分。需要具备这个辨识能力，才可以成为一个合格的规划者。

第一，规划者心中一定要有一只完整的“大象”，明确DevOps实施范围的同时还要了解外部的边界与干系方；

第二，根据企业的实际情况就实施范围与实施规划达成一致，一定要让客户在每一步都看到成功和价值体现。

Q16：您有没有推荐的学习DevOps的书籍和学习资料？

DevOps的书籍已经很多，建议可以参考DevOps认证提供的参考材料，因为它把整个知识点框架都提炼出来，比较完整、实用且高效，其他认证SAFe推荐的书籍是 The DevOps Handbook by Gene Kim, Patrick Debois, John Willis, Jez Humbl，建议看看核心内容即可，更多的还是要在实践中问题导向去深入学习。

Q17：ＤevＯps从业人员的职业发展前景有哪些，可以成为CEO吗？

ＤevＯps不是全部，敏捷也不是全部。 大家一定要知道一点：没有任何东西是你拿到后，可以仰仗它一直往前走的。

DevOps从业人员可能只是你的技能与经历之一，一段时间后，“DevOps”这个名词可能会发生变化。随着IT的发展，你要不断地武装自己。所谓的职业前景，你把Devops 做好、做成功后，可能会出现一些新的机会。你要抓住这些新的机会，不断地发展。

可否成为CEO与你从事过DevOps没有任何必然性联系，自己创业可能马上成为CEO。

Q18：针对不同行业、领域和业务，DevOps工具链在实施过程中千人千面。对于实施DevOps或定制DevOps工具链，DevOps认证有什么样的帮助？

万变不离其宗。不管Devop、敏捷还是规模化敏捷，你一定要知道它解决什么问题，要把它应用在你平台体系里，必须先了解她的实质，然后再根据客户实际情况定制方案，解决问题最重要。能把“宗”提炼出来，才能较系统地适配个性化的需求。

无论是DevOps认证、敏捷认证还是SAFe认证，大家关注的是个人职业前景。 SAFe提到过T型人才，即 系统性思维 既要有广度也要有深度。 DevOps认证 帮助了解这个专题的核心框架和主要知识点 ， 还会帮你推荐书籍扩展一些知识需要自己去学习。也就是在DevOps实践的广度上帮助你梳理出主要知识点，知识的深度，需要大家按照自己的需要深入去钻研，有些必须通过实践来获得“真知”。

Q19：在DevOps体系中，工具链作用的占比和流程、组织结构的占比分别是多少？建设工具链需要多少人力和时间？

我就理解最终会全部体现在工具链上。DevOps体系是一个软件制造的流水线，无论是质量控制还是绩效展现，全部都是在这条流水线上。我们会有Git Hub、Jenkins、Sona等工具配套使用的，但一定是在主工具链的调度下使用。

我做了DevOps流水线后，会把我的管理流程和组织架构完全体现在流水线里。举个例子，我的组织架构中包括程序员、开发组长和质量经理，这是一个最简单的组织架构。通过我的流程，开发人员提交代码后，工具链会生成质量门禁报告。开发组长需要审查告警，确保其合规。在发布前，QA还需要再次审查。我们通过流程把组织结构和个人职责都定义明确的活动与产出。

这不仅仅是占比的问题，而是将流程里人员职责、管理职责等都体现在DevOps平台中，甚至有些职责不以人为意志为转移的，如硬性指标，不是任何一个职责的人员审批就能过的。这些全部都在这个平台上实现。

建设工具链需要多少人力和时间，这需要具体问题具体分析，但我建议是不要少于三个月。一方面要满足领导急迫的心情，另一方面也要保证有产出且达到预期，三个月到半年左右出个MVP。

君无戏言，你做的承诺和规划一定要按期实现与达到。在各方没有达成一致前，不要轻易承诺，确保第一个里程碑的成功非常重要。

二、写在最后

DevOps平台的赋能，加速开发与运维的交付效率为主，重点建设是生产环境问题的预防（涉及研发交付的质量以及测试过程发现问题）以及问题发生后的快速修复，这是以上沟通各话题的背景。实践表明，仅仅打通开发与运维是不够的，我们长期耕耘的是开发质量与交付速度的持续提升，以及投产发布技术的投入使用（容器化技术、蓝绿部署、热部署等）与持续改进。

上文中提到的客户，主要是指使用DevOps平台的用户，涉及我们产品运营团队、需求分析团队、架构与方案管理团队、开发团队、测试团队与运维团队等。

文中提到“业务价值”中的“业务”是指客户/市场需求管理、（技术）需求分析、架构与方案管理、产品需求管理、开发管理、测试管理、运维管理中涉及的各项技术管理，如开发管理中的配置管理、代码质量管理、代码质量度量与评价等，测试管理中的测试案例管理、缺陷管理、测试环境管理、测试部署管理等；运维管理中的生产事件管理/事故管理、生产问题管理、生产发布管理等。当然，每项管理专题可以划分出很多子专题，都属于本文“业务”的范畴。

“业务价值”中的“价值”是指的是相关管理专题的规划建设内容可以带来的价值，对团队、组织带来的效能提升等与给研发效能、变更管理、生产发布带来的直接价值；

业界从DevOps讨论中提出过道法术器的四层理论，作为本次交流的总结，我个人体会的如下：

• 道：以组织/客户为核心，可持续输出、可持续演进的价值供应链，专注于此虽然会有弯路，或局部的质疑，不过坚持后会深刻体会“人间正道是沧桑”的含义
• 法：“知己知彼百战不殆”，新的实践、新的技术潮流层出不穷，一方面我们要知彼，即新的实践提供了哪些新方法/技术方案，这些新方法/技术方案是用在什么地方；另一方面我们更要知己，即自己的管理有哪些欠缺，新方法/技术方案可以帮到我们哪些。
• 术：DevOps平台价值链中所涉及的管理及其业界先进实践，如开发管理中极限编程XP相关方法与实践及其适用场景，以及上文提到过的容器化管理、微服务架构、配置管理等技术或方法
• 器：DevOps平台技术栈相关工具链及其适用场景，如：CICD工具、制品库工具、配置管理工具、流程引擎等，以及配套基础设施环境管理等，如：网络、容器云平台等