DevOps不是请客吃饭

今天承蒙老朋友们抬爱，去DevOps社区2020峰会成都站讲了个开场。在这么不寻常的一年，这样热闹的大会总是让人感觉很有希望的事。

我在演讲里说，DevOps（跟“规模化敏捷”一样），其实对大多数企业来说，无非就是一个立项的借口而已。软件开发的问题，从二十年前到现在，也并没有怎么变过，无非就是质量差速度慢。很多企业搞过敏捷，培训也做了，咨询也搞了，软件工具也买了，过两年一看，还是质量差速度慢，咋办呢，总不能再搞一轮敏捷，于是只好换个名目来立项，继续解决质量差速度慢的问题。

其实我这几年做的工作跟DevOps关系不大，也就2010年的时候翻译了Wikipedia的“DevOps”词条，代表ThoughtWorks中国区出去学习了DevOps和持续交付的概念，算是跟这个社区有一点交集。从旁观者的视角，DevOps本来应该是一个斗争非常激烈的领域。如今中国的DevOps社区这么一片其乐融融的景象，也算是难得。

用徐昊的话来说，DevOps运动从一开始就是个缝合怪，并且缝合的是几个强烈冲突的目标。一开始构成这个运动的主力，有一拨是软件开发者。从他们的优势技能出发，他们最关心的就是尽可能自动化，减少部署和运维过程中对人的依赖。他们说什么“infrastructure as code”之类漂亮话的时候，其实心里想的就是写个脚本把运维这帮人给取代了。

同时另一拨人呢，当然就是运维，不过是运维里面不甘于被写个脚本取代的那一拨。他们最关心的是运维的存在感——传统上运维这个岗位确实也不怎么有存在感，系统不出毛病谁也想不起还有这么一帮人在，有人想起他们的时候差不多就该挨骂了。所以这拨人最关心的是可视化，表现出自己有多少功劳，至于自动化么尚在其次，就算要自动化也得是先建个DevOps平台什么的。

第三拨人是IT管理者，他们站在IT投资回报的角度，关心的是IT创新多长时间能转化成业务绩效，所以他们眼里看到的DevOps是组织上、流程上的改变，加速IT建设的迭代速度、缩短反馈周期。这些人听说买工具、建平台，心里都在打鼓：原来的IT投资都已经被老板批了，现在还要增加新的IT投资……

然后呢，第三拨人心里打的鼓，又缝合进来了第四拨人：搞认证的。关于这一拨人的生意，我就不多点评了，感兴趣的读者可以参考我对另一个知名认证的态度：演讲实录丨软件工程跑偏，CMM全是骗子

所以呢，我每次参加DevOps的会，都挺期待看这几拨人能互相撕起来的……不过在国内还没如愿过，说明我们礼仪之邦真的就特别包容……

其实么，社区也好，做项目也好，如果正经要搞搞DevOps的话，你很快就会发现，这东西从一开始就是在同时面对软件生命周期几方面的挑战。这些挑战，很多时候已经跟组织、跟人融为一体，想解决问题，就会引起矛盾——自动化好不好？你可以去问被自动化脚本取代的那个人看看。DevOps不是请客吃饭，改进就一定会动到别人的山头，开发想要的改进和运维想要的改进根本就不是一个改进，所以我们才会看到今天这么一个缝合怪。

当然了，中国IT业有个老传统，把一切时尚潮流都变成采购软件加认证，于是谁也不会丢饭碗，反而创造出更多的饭碗，于是大家也就可以其乐融融请客吃饭了，明年换个时尚潮流再来采购软件加认证。这也未尝不是个内循环的路子。

看，我一开始就说了吧，