第一个，关于架构和运维的关系

早上第一个观点碰撞，是因为晓征总看到我专栏图书上写的：“软件架构的目的是将构建和维护的成本降到最低，以及软件架构的大部分工作都是为后续运维服务”的观点，感觉形成了强烈的共鸣。

其实，要说明的是，前半句是Bob大叔的《Clean Architecture》书中提到的，但是在这本书之前，我在专栏开篇词中也提到类似观点，也就是上面后半句的意思。

大家如果有兴趣可以看我的极客时间专栏开篇词。

第二个，运维与中间件的组织架构关系

如果按照第一个观点来讲，运维跟中间件团队之间是不可分割的，或者说是一件事情的两个阶段，硬生生地分割开，肯定是要出问题的。

特别是在技术体系上，引入了分布式架构，应用做了服务化拆分，两者之间必须要建立紧密的合作关系，相互支持，相互补位。

这两者的关系，从DevOps变革的技术角度看，我认为是组织架构建设中最关键的关系。

如果运维仍然是独立的，不能往前走，中间件团队又没有树立起全生命周期运维的意识，导致的后果必然是，工具体系不完善，效率跟不上，三天两头出问题。

国外，类似Netflix和Amzon，就是有一个云平台架构部，或者平台技术部，下设架构团队（中间件）+工具研发团队（运维 or SRE）。

我们蘑菇街其实也是类似这样的体系，这几年走下来，还是取得了很不错的效果。

这其实是个很现实的问题，像阿里，工具平台足够完善之后，完全可以由开发自运维，而不是依赖PE。

蘑菇街也有类似倾向，比如我们的持续交付足够完善后，现在发布环节完全不需要PE介入，开发自己发。

但是，跟晓征总讨论到，对于运营商这样关乎国计民生以及安全的企业，即使工具体系足够完备，也不会完全放开权限，非常核心的生产系统，该严格把控还是严格把控，PE或运维的角色仍然非常关键。

这个观点，之前也提到过，传统行业，比如运营商和金融行业，双态运维，双轨模式运作。

所以，最终我们的碰撞出来的结论，PE这个角色不会完全消失，需求数量会趋于平稳或者减少，但是作用会越来越关键。

特别是干了多年的老PE，他们身上的专家经验和线上思维模式是最宝贵的，所以充分发挥自己的优势，同时找到一些新的方向突破，PE们的空间应该还是很宽广的。

这个问题，再延伸一下，就是运维的事情不会没有，随时随刻都有，只不过是开发干，还是运维做的问题，这个就取决于工具体系的完善程度。

阿里不是想学就能学得来的。

我也跟晓征总提到，这个观点，对于很多人来讲，不一定能理解，即使能理解，也不一定能接受，这里面涉及到方方面面的问题，个中原因，只有经历过的人才能体会到。

同时，这个问题对于很多互联网公司来说，或许是顺其自然的过程，但是对于IT化程度很早，且很深的运营商来说，体制内的改革，就会显得更加异常的艰巨。

大家如果有兴趣可以关注下浙江移动的DCOS体系，晓征总领导的，在业界内都是非常好的先进案例，更不用说在运营商体制内了。

最后，我的观点能够鲜明的表达出来，并能够成为助力一个组织内部变革的理论支持，还是非常开心的。

本文转载自成哥的世界公众号。

原文链接：https://mp.weixin.qq.com/s/6LOcUqGkUtd4zJoQBJrVkA