小鹅通｜渐进式拥抱 DevOps

在11月25日举办的中国 DevOps 社区广州峰会上，小鹅通效能平台负责人 王梓城 分享了其团队从 0 到 1 建设 DevOps 体系的实践经验，赢得了在场听众的共鸣。

一、背景：

疫情期间小鹅通响应“停课不停学”的号召，带着使命咬牙完成了产品交付。后续小鹅通在各行各业中被使用，随之而来的是幸福的烦恼——业务需求的爆炸式增长打乱了原本产研规划的所有节奏，同时产研交付效率的问题变得尤为突出，被用户和业务部门反复提及。这时，产研能力的建设得到了重视，成立了一个新的团队，专项解决产研交付效率的问题。

团队成立之初仅 3 人，一边忙着交接原有手上的业务，一边摸索能效提升的解法。在逐步解决一个个现实问题过程中，从不太了解 DevOps，渐渐深入了解并走上了 DevOps 实践的道路。

二、 三个阶段

小鹅通的 DevOps 实践分为三个阶段：

1.第一阶段：深入产研，初识 DevOps

效能团队从原本的业务中新成立，起初只有 3 人，对业务情况也不是很清楚。在完成原有业务交接的同时带着使命花了近两个月时间深入了解了当时全局产研状态。在开发 > 测试 > 运维、需求规划 > 开发迭代 > 最终测试 > 发布上线的整个过程中，了解到研发团队为了支持业务的快速迭代减少了测试验证轮次，在开发环境验证通过后，直接上线至预发布环境、验证后全网发版。在这种模式下各个角色之间相互吐槽，直观感受中被反馈最多的 2 个字 是“累”、“慢”；从产研侧听到最多的2个词则是“项目延期”与“四大金刚”：

• 项目延期：当时有100+系统，系统之间高度耦合，且只有一套可供灰度验证的环境，导致出现一个项目延期，后续全部延期。
• 四大金刚：迭代发版全靠 4 个运维兄弟手动支持，虽然当时运维有使用工具平台，将发布收归脚本操作，但不同业务线的部署脚本五花八门，导致运维仍需要做一些编排的工作，疲于应付频繁的发布操作。疫情期间开发同事可以轮班，但运维不行。

图片

于是，我们明确优先解决两个核心问题：一是让运维从频繁手动发布中解放出来；二是支持多灰度能力，解决单一链路的系统高耦合导致的连锁反应，毕竟架构上的事情并不能马上解决。 说干就干！

• 一方面，通过搭建发布平台要求开发人员提交变更清单，运维只需要在发布平台进行简单编排即可完成发布和回退操作。同时结合运维平台的能力，将服务粒度的部署脚本细化拆分成步骤和作业的方式。这样，一个类型的服务就可以通过组合指定的步骤形成一类的部署能力，发布平台只需进行绑定关联。
• 另一方面，通过 Nginx+Lua 的方式和目录形式，实现了业务的多灰度环境部署，同时结合多灰度的方式建立大小车的迭代模型。

在解决这两个问题的过程中，逐步意识到我们在做的事情和 DevOps 息息相关，开始深入去了解 DevOps 到底是什么，同时也开启了我们拥抱 Devops 的第二阶段。

2.第二阶段：引入工具，尝试 DevOps

实施第一阶段的同时，公司业务保持快速增长，团队进入快速扩张的阶段。原本迭代慢的问题，随着人员的扩张和发布能力建设，短暂的平静一段时间后，很快新的问题随之而来。产研人员增长在达到 800+ 时，我们发现人员的增长不但没能带来预期的迭代增速，反而让整个产研变更混乱——协调沟通的声音盖过了鼠标键盘的声音。

我们从每个产研角色那都听到了不同的声音——起初所有的问题似乎都被人力不足所替代，但当人力上来后，其他的问题也就被推到了台面。

由于业务架构的高耦合在迭代的过程中存在冲突，即使已支持多灰度，仍涉及较多的代码合并操作，最终导致业务沟通和测试验证工作激增。因此，大家希望业务重视架构设计，对已有不合理的耦合进行拆分解耦；而拆分后的新服务的重新部署调试仍然需要运维参与。新服务部署后问题较多，影响项目交付。

此外，产品规划、方案评审、线上应急流程的缺失，都会加剧迭代过程中的问题。

这时，我们开始尝试用 DevOps 的方式解决问题。结合当时现状，我们梳理了一个完整的 DevOps 架构图，确定从四个不同的阶段，结合建立标准化、流程化、自动化来解决现有的问题：

• 联合产研各部门，明确开发、测试、部署规范；
• 联合项管、应急、客满团队，建立迭代、应急、按灯流程；
• 业务侧开始对冲突严重的系统进行解耦拆分；
• 结合工具逐步完善自动化能力。

这样，就初步搭起了小鹅的 DevOps 架子：

• 规划阶段，使用单品项目管理工具建立需求管理、规划流程；
• 开发阶段，结合 Git flow 以及 gitlab ci-runner 的能力进行构建管理和代码质量的扫描，与原有的发布流程打通。

虽然通过基础能力的建设和流程机制的完善，让迭代和质量的问题有所改善，但最终的效果并没那么理想。主要体现在：由于工具割裂，不同的角色使用不同的工具，跨部门沟通效率仍然不高；而且多工具维护成本高；数据割裂，无法整体度量改进。

图片

3.第三阶段：全面容器，深入 DevOps

随着 DevOps 工具链的接入，我们发现多工具的维护成本较高，尤其是在大量并发的场景下，缺少经验丰富的人员，工具链的问题解决效率低。与此同时，原本一些免费的工具逐步走向收费模式。这时我们希望引入一些商业化的平台，来加快我们效果的产出，因此我们开始深入产品的调研。

另一方面，在基于 CVM 的部署架构上，环境管理、发布变更、应急维护以及成本方面都有较多的诉求，故全面容器化事项正式拉起。容器化本身对于产研团队来说是个较大的挑战，起初研发团队都不太了解容器、Kubernetes 相关的知识，而且容器声明式部署和以往CVM有很大的不同。但我们认为这可能会是一个比较好的机会，我们可以通过平台降低掉云原生相关技术的学习成本，让研发人员几乎可以像之前一样使用平台，而无须关注底层技术的实现；同时也将我们的 Devops 落地实践结合起来，完善整体能力建设。

与此同时，我们也重新回归到价值流的关注上。通过流程、平台的建设完善整个发布迭代的闭环。结合小鹅“客户第一”的宗旨，未来将客户也纳入到价值环中，通过客户对于交付的迭代进行评估价值点，以期望让整个假置换能步入正向循环，以持续解决客户问题为核心。

因此第三阶段的目标也逐渐清晰——结合容器化，彻底解决标准化的问题；同时深入实践 DevOps 价值流。在这个阶段，我们开始全面使用腾讯云 CODING DevOps：

• 整合原有小鹅社区、单品项目管理中的需求/缺陷，统一收口迁移至 CODING 项目协同，利用 CODING 项目协同进行业务需求管理；
• 基于 CODING 项目协同、代码仓库、代码扫描、持续集成、制品仓库的产品能力与小鹅通内部存量 Gitlab 仓库管理进行整合，融入 K8S 集群、Prometheus、CMDB 等企业内原有发布系统。

最终初步实现了需求全生命周期端到端的安全交付管理，极大提升了研发交付效率。未来也计划基于 CODING 生态和内部系统整合实现持续运营能力的建设。

图片

三、谈渐进式拥抱 DevOps

1.  为什么说要渐进式拥抱？

企业在高速发展中并不能快速像大厂一样，具备较为完善的基础建设以及专业人才。我们与各大厂商之间的沟通中发现一个问题，如果如同大厂一样依赖自顶向下的方式进行推进落地，但往往这种方式会较为强硬，容易与业务部门产生隔阂和冲突。

从组织和文化层面来看，其实 DevOps 是一种文化和流程的变革，如果直接在现有的流程框架下去推行，不能把相关团队之间的协作调动起来、不将整个过程贯通，最终无法推行下去。而实践推广过程往往周期较长，并非能够快速看到效果。

2.  如何渐进式拥抱

（1）寻找切入点。先解决单部门的问题，如需求、项目管理是研发管理中最核心的场景之一。由此引入项目协同的实践，完善工具、平台的能力；代码集成、构建，是日常开发接触的核心场景之一，由此引入 CI 流水线管理能力。

（2）DevOps 也好，工具能力也好，核心都是要为解决业务问题服务。与业务配合，给予能落地的解决方案。

（3）量体裁衣。由于 DevOps 会涉及到不同部门的协作，以及一些所谓 “ 最佳实践 ” 的引入，会带来一些具体工作方法、工具、习惯规约的变化等等，必然和旧秩序有很多不同的点，可能在框架和细节上产生变化，但未必是颠覆。所以如何适配、抛弃哪些、保留哪些、采纳哪些、都需要反复磨合。

（4）在考虑 DevOps 实践时，很容易陷入拿着锤子找钉子的困境中。尤其在和很多服务商沟通时，很多理念并不一定适合我们当前的团队综合能力。团队需要一个自主灵活的能力？还是需要不用过多思考的规范？都需要考量！这也是是一个动态变化的过程，需要不断平衡调整。

（5）在日常解决各个团队问题的过程中，需要建立信任感，合理宣导 DevOps 相关理念，例如告诉开发在 DevOps 的理念中是如何看或解决这个问题的。在推动解决的时候，要从全局层面出发，自顶向下推动落地。团队文化的建设是 DevOps 实践中相当重要的一环，也是作为开发程序员不太擅长的一点，但我们作为 DevOps 工程师，应该重视。

（6）DevOps 的核心理念是要关注价值流动，通过不断的实践、调整、迭代、循环往复完善，需要不断在践行中总结。

最后，在 DevOps 实践中没有拿来主义的【最佳实践】，我们要时刻关注业务，所有的实践都是为业务服务的。

四、一些思考

插拔式能力：DevOps 在国内发展的今天，也越来越被大家重视，特别是在这几年大环境的挑战下，降本增效一再被提及，行业内开始关注一站式的 DevOps 能力，渐渐有同质化的竞争。但每个企业各具差异，很难统一，大团队流程相对完善，牵一发动全身，决策成本高，其中有研发能力的团队，可能会做很多定制化；小团队对于价格敏感，且一站式的完整理念不一定适配其团队现状。在此建议厂商对某些场景或问题深入挖掘，具备插拔式能力来提供服务，从而降低实践 DevOps 的成本。

DevOps 的愿景：最近在读《埃隆马斯克传》，马斯克的想法让我也有一些思考，对于 DevOps 的理解希望不仅仅是在我们的企业、团队去时间落地，同时也希望通过社区的传播让 DevOps 的理念在国内能够更好的传播。目前大家都觉得国内的环境很卷，而且在创造价值的过程中因为各种问题产生大量的内耗，最终对整个社会的价值创造低于原有预期，DevOps 的普及是否能够去影响整体的环境呢？拭目以待！

图片