对落地DevOps理念的一些反思

https://mp.weixin.qq.com/s?__biz=MzIzNjUxMzk2NQ==&mid=2247485655&idx=1&sn=227ace14488e844ffe5bd434f9c81bdf

作者｜杜屹东编辑｜郭蕾

在 ThoughtWorks 的一篇题为《DevOps 团队之殇》的文章中，ThoughtWorks 软件工程师杜屹东反思了 DevOps 的价值以及挑战。DevOps 理念从诞生到现在已经有近 10 年的时间，然而社区对于它的争论却未停止过。DevOps 希望能够消除开发与运维之间存在的信息“鸿沟”，缩短从设计开发到生产交付的全过程周期，虽然这一看法深得人心，但这些年推进起来却是步履蹒跚。

杜屹东认为目前国内大部分项目的现状是开发不具备运维技能和意识，也不愿意做“背锅侠”，因为要求开发做运维其实一定程度上牺牲了开发的利益，比如亚马逊的开发每隔一周会被要求 24 小时 On-call。

基于这样的情况，一些公司选择了在项目中先成立一个 “DevOps 团队” 作为过渡，再慢慢将 CI/CD 的理念和技能扩散到其他团队，但是这种方式稍不注意就会变成“换了个名字的 Ops ”，因为工作内容相似，写脚本、做高可用，这些是传统运维也会做的事情，这种形式非常不利于团队思维的转变，“团队整体对最终交付物负责”才是 DevOps 的精华，而不是把团队按职责划分（只对流程负责）。

这样的要求无疑是给项目成员增加了工作量和负担，对他们提出了更高的要求。然而很多人不愿意无回报地多背负一些责任，比如说开发，谁不愿意每天写点代码一提交就早早回家，DevOps 要求他们得看着新功能上线，确保无误之后才能离开；所以 DevOps 的推行在产品团队中是有阻力的。DevOps 的成功不光需要团队内部努力，也需要得到高层支持并扫除障碍。

对于现状的反思，杜屹东这样说道：“如果有一种自上而下的方式让开发团队基于已有业务基础之上去优化交付流程，并对每一个提交的最终价值负责，将产品思维真正植入到开发团队，从而达到全局优化的效果，这种做法才更符合真正的 DevOps 精神。”