《敏捷无敌之DevOps时代》读后感

╰+攻爆jí腚メ 2024-03-22 21:33 6阅读 0赞

## 背景： ##

**2020年**基于我司业务形态，我开始实行敏捷项目管理。以敏捷为道，Scrum为法，迭代为术，禅道作器，大张旗鼓的搞了2年敏捷开发。随着时间推移，问题出现在2022年，当时我们已经完全按照Scrum的模式在运作着10个项目，以及项目团队。我们基于禅道提炼了如：任务准期率、任务准交率、计划偏差率等指标。但是其中一项指标成了我们10个团队的核心痛点，即：需求交付周期。我们在2022年年底复盘的时候发现全年下来，需求交付的平均周期为40天，也就意味着一个需求从登记到禅道到关闭的平均周期是40天。这是我们无法接受的，也是业务部门（内部甲方）无法接受的。

问题出在我们的发布与迭代是**强关联**的，我们的迭代是2周一次，然后一个迭代就发布一次，也就是说一个需求在理论上最快发布周期是21天(3周)，这里说的是理论值如下图：

![9ba041edb6a0cd84a355229ddbd66e2e.png][]

除非刚好，提出需求的那天正好是迭代开启的头一天，那样可以做到14天，但是那种情况太极限了。另外也不是刚刚提出需求，下个迭代就可以安排开发。所以普遍性来说，算上排期，一个需求平均交付周期在这种模式下最快就只能做到21天。

但是，不可接受的事情是我们10支项目团队，平均需求交付周期是40天，甚至比21天还要多2周。一个经典的案例是用户需求增加一个Excel导入导出的功能，问我们要多久。我们开发人员评估的工时是2小时，但是客户问我们什么时候能用上，我们回答却是2周以后。用户不理解，我们也不理解。至此，如何将迭代与发布脱钩，就成了我研究的课题。

摆在我们面前的有两条路线可以选择一条是SAFe，一条是DevOps。 由于我们在2020~2022年期间先后取得了Scrum Master 和 PMI-ACP的认证。所以思维定式上会去靠拢SAFe， 完全实行SAFe对人员的要求很高，转型也很痛苦。因此，我只采用了SAFe中的“发布火车”这一重点实践。 固定每周2、4 为发布周期。 在试行2个月后，研发人员抱怨声音越来越大，抱怨的主要原因是开发人员根本跟不上。其实这里所谓的跟不上，经过我后面的调研不是指开发能力不行，而是对代码没有**基于需求**做主分支管理。至此，我开始研究另外一条路线：DevOps 。

写在前面：实施DevOps两个月之后，我将需求平均交付周期从原来的40天，成功的缩短到了**23天**，并且后续任然有信心降低到**15天内**。

--------------------

## 正文： ##

![e69adf52229623a3c9a9b42710b4252b.png][]

我入手的第一本书籍是《DevOps实践指南》。说实话，这本书把我整的有点懵逼。书中讲了很多运维人员和开发人员的实操案例。虽然我本身具备10年的.Net开发经验，但是我现在本职工作是项目经理，这对我来说并没有解决我的核心痛点。也可能是我们目的性太强，造成了我耐不住性子去读这本书。不过，这本书在我小白阶段的时候，至少跟我说清楚了什么是：DevOps？

早期在百度搜索DevOps，多数解释就是：开发运维一体化，打通开发与运维之间的部门墙之类的。其实，这只是狭义的DevOps的理解。通过潜伏到各种微信群中，听到各种大佬对DevOps的解释，有的说是**工具链****，**有的说是是**流水线****，**有的说是实现**自动化，**有的说是实现**CI/CD（**持续集成/持续部署）**。**

这种浑浑噩噩的阶段，直到读完《DevOps实践指南》才慢慢好转，那么究竟什么是DevOps?

我认为现在最好的定义是：**研发效能。** 特别是这个“效能”，不是研发效率，效率指的是团队的产能，速度。 而效能是这个“能”字是指的：**赋能**。 这样才解释清楚，在广义的DevOps是怎么适配到IT的研发场景。紧接着问题又来了，怎么个赋能法才叫DevOps？还是没说清楚什么是DevOps？我们先把这个问题先放一下，先来回答另外一个问题：什么是敏捷？

其实，在我入门敏捷的时候，也具有同样的困惑，什么是敏捷？是Scrum？是Xp？还是水晶？ 后来明白了，符合**敏捷宣言**的都是敏捷。

![f43875c79542870dae41cea938254797.png][]

再回到前面那个问题，什么是DevOps ？如何为研发效率赋能？是否也有类似敏捷宣言这样更具体的解释，答案是有的《DevOps实践指南》给出了DevOps 三大原则： **流动、反馈、持续学习**。 简单来说符合 流动、反馈、持续学习的就是DevOps，并且DevOps自身也在不断进化更新。

可是，还是有点抽象。这个持续学习还好理解，无论是理论指导实践，还是实践完善理论，持续学习始终是向上的攀升的正确途径。

那么剩下的两个问题：

1，流动是什么？

2，反馈是什么？

带着这两个问题我又分别入手了《价值流动》、《敏捷无敌之DevOps时代》这两本书。

![66df8d94988555d6f87038b9487ecce9.png][]

关于《价值流动》我之前写过另外一篇读后感，这里不做赘述，总之该书解释清楚了流动的是啥，如下图：

<table> 
 <tbody> 
 <tr> 
 <td></td> 
 <td> 描述 </td> 
 <td> 交付物 </td> 
 </tr> 
 <tr> 
 <td> 特性 </td> 
 <td> 为推动业务结果而增加的新价值；对客户可见 </td> 
 <td> 新的业务价值 </td> 
 </tr> 
 <tr> 
 <td> 缺陷 </td> 
 <td> 为修复影响客户体验的质量问题 </td> 
 <td> 质量 </td> 
 </tr> 
 <tr> 
 <td> 风险 </td> 
 <td> 致力于解决安全、隐私和合规风险 </td> 
 <td> 安全、治理、合规 </td> 
 </tr> 
 <tr> 
 <td> 债务 </td> 
 <td> 软件架构和运维架构的改进 </td> 
 <td> 消除未来交付的障碍 </td> 
 </tr> 
 </tbody> 
</table>

到这里我的问题更多了，前面我们要解决的问题是如何将迭代与发布脱钩？ 如何将需求交付周期从40天降下来？我们通常认为的需求就是上表中的**特性**，这里一看不但需求对应的特性没有 **透明化****，**另外的缺陷、风险 和债务也是不透明的。但是总而言之，一句话：当前我是看不见需求的流动， 这也就解释了为什么我潜伏微信群的时候，有大神解释DevOps 就是**流水线**，流动的东西就是上面的**四大流动项。**

上面解释清楚了什么是流动，以及流动的是什么。那么转换成为行动任务就是，打造一套体系让流水线，实现可视化、透明化。这让我们想起了考ACP的时候的 “价值流图” 有异曲同工之妙。

![8f3a989f1da105a09044b43bcb87ab7a.png][]

就像木桶定理一样，决定一个木桶能装多少水，取决于那么短板。 无论是特性、缺陷、风险、还是债务。对应的是四条处理流程（流水线），而将这个流程以进行**可视化**，就能发现过程中的短板，并加以改善。根据我浅薄的理解，我悟到这里，算是对“流动”有了一个较为具体的认知。

那么反馈又是什么？ 基于我对敏捷的认知，反馈就是以最小可行产品实现快速上线，获得用户反馈，并立即优化调整。通过阅读《敏捷无敌之DevOps时代》之后，我有新的理解。通过各种工具建设对 **观测指标** 进行提炼**，**对各项指标进行治理形成反馈**，**并利用这些反馈进行改进和优化，从而形成犹如**PDCA**的正向循环。

所以，这里又说明白了为什么我潜伏在微信群中，大佬说DevOps是 **工具链**。

![bb00e1249ebdf2d9569317050e45cd59.png][]

说到工具链，不得不说我们潜伏微信群时候，大佬的另外一个解释：**自动化****。**前面讲的基于四大流动项，可以打造四条流水线。那么流水线除了做价值流图分析过程短板以及等待浪费以外，还可以针对流程本身进行**提速**。 这里我们可以简单的映射一下现实生活中的工厂，**手动流水线** 和 **自动化流水线**。

至于怎么自动化，说来也简单。就是把重复劳动的事情交给机器去做，现实生活中的流水线不也是这样的吗？这里对于解决了哪些重复劳动不做篇幅（PS.前期在B站一搜DevOps，老是出来一堆工具的实操教程，一直给我整的挺懵逼。）

这里再回头说一下，发布与迭代怎么脱钩，通过我对这些DevOps工具的了解，接触到了**CI/CD**。

CI (Continuous Integration)：持续集成。它涉及将开发人员的代码频繁地集成到共享存储库中，并使用自动化构建和测试工具对代码进行验证。

CD (Continuous Delivery/Continuous Deployment)：持续交付/持续部署。它涉及自动化地构建、测试和部署应用程序以实现快速且可靠的交付。

本身，CI/CD 概念并不复杂，为什么我们前面用发布火车团队反应这么大呢？ 前文中也有描述，没有基于需求创建分支这是其一，创建分支缺乏管理，无法有效的实施持续集成、持续部署这是其二。

通过建设CI/CD，基于需求创建分支，配合工具使用。做好的功能通过测试，就发布。不再等到迭代结束再发布，一下子就把需求交付与迭代脱钩了，我们的交付周期也很快的从40天降低到了30天内。

写到这里，我再提炼几个关键词： **流动、反馈、持续学习、透明化、可视化、自动化、工具链、流水线，CI/CD。**

到这里，还不是DevOps建设的全貌，接下来就要大刀阔斧的动起来了~！

--------------------

## 感悟： ##

前面已经讲过，由于在团队内部实行“发布火车”，造成的团队各种抱怨。为了达成共识，这次我选择了外来和尚念经。由于市场上也有不少的成熟的DevOps解决方案，我先后组织了4场“解决方案供应商" 线上交流会，让团队对DevOps有了一致的认知，也成功勾起了大家对组织改善的意愿。

这里我规划了三条建设路线同步进行：

其一，是**工具链**。包括：禅道18.0、GitLab、SonarQube、Jenkins、Selenium、Jmeter、K8s、Docker、Zabbix、WebFunny

其二，是**流程与规范**，包括：项目管理流程、需求管理流程、缺陷管理流程、敏捷运作机制、禅道使用规范、.Net编码规范、JAVA编码规范、GtiLab使用规范、持续集成规范、持续部署规范、测试管理规范、制品管理规范、服务器监督管理规范、应用系统监督管理规范。

其三，是**过程性指标与结果性指标**。包括：需求总数、需求从登记到设计周期、需求从设计到评审周期、需求从开发到提测周期、需求从测试到发布周期、代码提交次数、部署频率、部署成功率 等指标。

紧接着趁热打铁，直接把DevOps转型当做项目来做，发起了对DevOps的立项：

项目背景：

数字运营中心是敏捷型交付组织，具有边设计边生产边实施、用户需求多且变更频繁、软件使用过程中需要快速响应等组织特性。随着部门业务量的倍速增长，管理复杂度不断增加，同时需要更精细化的观测指标进行管控，产品设计、项目管理、软件开发、质量测试等过程缺乏规范性，尤其对细节管理需要实现过程与结果透明化，需要一套适合自己的面向企业服务的**软件生产管理体系与工具**，同时拉通各个职能角色，使软件生产业务数据透明可视；缩短需求生产周期，降低开发成本，进而实现开发运维一体化，提升管理效率。

项目目标：

目标1：需求平均交付周期从40天降低至25天。

目标2：需求按期交付率从90%提升至95%。

目标3：人均需求交付数从1.5提升至1.8。

目标4：软件发布一次成功率实现透明化，并提升至80%

项目收益：

投入180人天，获得约14人编制的产能，计算如下：

数字运营中心以70人为基准，当前月度人均交付需求数为1.5。 通过建设DevOps研发效能体系，预计产能提升至月度人均交付需求1.8。

通过计算可知：

当前产能：70\*1.5=105

目标产能：70\*1.8=126

提升产能：126-105=21

释放同等人力：21/1.5=14人，以人均薪资1万元计算，约**每月降本14万元**，**全年降本168万**。

项目蓝图：

![720f2835581b096c2235bbbfa14f4cd3.png][]

## 成果： ##

再回到一开始的问题，我们通过建设蓝图里的一系列工具，成功实现了基于需求做代码版本的主分支管理，实现了一周2发布的频次。自此也完成了发布与迭代脱钩，虽然目前DevOps研发效能这个项目还没有完全结束。但是我们已经成功实现了交付周期从原来40天缩短到了23天。大致成果如下图：

![37007513b45bf050e5ab400359212878.png][]

![422d5df276b917ca388ebe9d6f108156.png][]

![1e5d60775024a9963e5b1a3ba39cb738.png][]

![44235c4e5f9c1c3e9bcddc03cd8b5e35.png][]

[9ba041edb6a0cd84a355229ddbd66e2e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/24f594a5fcf24a7eb01572643ead7ea1.png
[e69adf52229623a3c9a9b42710b4252b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/63e4104314604d92a816cd59f19248db.png
[f43875c79542870dae41cea938254797.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/a87cf51903b74e92a07aa780dd6b5e14.png
[66df8d94988555d6f87038b9487ecce9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/eaa2df213dab4325baf598191ba13850.png
[8f3a989f1da105a09044b43bcb87ab7a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/f85c386430a44ce49681d753041d1329.png
[bb00e1249ebdf2d9569317050e45cd59.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/01fe7bc931a54b5799b60d65a53f95ae.png
[720f2835581b096c2235bbbfa14f4cd3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/87525de846ee4193bb20495900af61ab.png
[37007513b45bf050e5ab400359212878.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/45e5cd457fed440cb2b62defde124305.png
[422d5df276b917ca388ebe9d6f108156.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/612ced49011b4f1e95d16a925f6c1ba4.png
[1e5d60775024a9963e5b1a3ba39cb738.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/1e411528e2ab43e0accaa6469d038337.png
[44235c4e5f9c1c3e9bcddc03cd8b5e35.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8bda6ef48c8b4dea9c2740e6cf269d8a.png