当前位置：首页 > DevOps > 正文

DevOps建设的思考和实践

2020-03-02 来源：有赞技术

背景
众所周知，在丰田精益生产中，核心观念包含对人的尊重、消除浪费、持续改善，只有这样，企业才能保持良性运转，竞争力才会提升。而具体的浪费场景，被总结为「制造过剩、等待、搬运、库存、加工、额外动作、次品」七种，后来又增加了「管理」的浪费。

笔者所在效能改进团队，一直致力于精益的实践，从降本增效的角度，来提升有赞软件研发的效能，以应对这个充满不确定性时代的变化的冲击。而彼时的软件研发，从过程管理的角度，已将「项目制」普及到团队之中并持续发挥作用，但从工程实践的角度，虽然各部门都有一些基础设施，但仅为本部门服务，整体处于萌芽阶段，需要有一条主线将各独立的孤岛串接起来，发挥协同的价值。

一、工程实践的现状

1.1 技术债

有赞作为一家初创公司，首要任务是在市场竞争中活下来，所以在技术沉淀方面，于某段时期内处于被动局面，由业务裹挟着往前狂奔，是可以理解的，而且是必须经历的。但可以预见的是，长此以往，就会积累大量的技术债，而且会随着系统复杂度的上升，技术债所带来的研发成本会快速增加，直到它变成一堆无人敢碰的遗留功能。

从精益浪费的视角看，处理技术债就是一种「额外动作」，它是每次研发中一项绕不开的工作，但除了耗费大量人力物力和时间之外，并不产生任何价值。我们亟需掌握目前有多少技术债、风险如何、处理成本如何、在多少量级的范围里是合理和可控的。下图是有赞在 DevOps 建设过程中，某个应用通过 SonarQube 静态扫描得到的代码质量情况：

1.2 代码改动的影响

我们常说：输入的是垃圾，输出的也一定是垃圾（ garbage in, garbage out ）。在充满技术债和没有任何保护措施的代码上做增量开发，就好比行走在沼泽中，随时会出现意外。也许有代码注释来帮助你理解历史遗留业务，但经过多人之手增补过的代码文件，注释可能比代码更冗长。

在这样的技术环境中工作，很容易产生「次品」，也许大部分问题都能在上线前被扑灭，但流到线上就很可能成为故障，甚至成为未来新代码的故障源。下图是 DevOps 的布道之作《凤凰项目》的封面，就呈现

分享到:

免责声明：
　　1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
　　2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！

上一篇：
从微服务到人工智能：2019年DevOps的八大趋势
下一篇：
最后一页

延伸阅读：

more 会议活动

more 公开课

more PMO

微信扫一扫关注

DevOps建设的思考和实践

延伸阅读：

会议活动

公开课

PMO

IT项目管理界官方微信

PMO大会官方微信