【案例分享】小鹅通｜渐进式拥抱DevOps

作者：王梓城

前言/简介

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

一、背景：

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

这时，产研能力的建设得到了重视，成立了一个新的团队，专项解决产研交付效率的问题。
团队成立之初仅 3 人，一边忙着交接原有手上的业务，一边摸索能效提升的解法。在逐步解决一个个现实问题过程中，从不太了解 DevOps，渐渐深入了解并走上了 DevOps 实践的道路。

二、三个阶段

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

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

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

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