第一个，关于架构和运维的关系
早上第一个观点碰撞，是因为晓征总看到我专栏图书上写的：“软件架构的目的是将构建和维护的成本降到最低，以及软件架构的大部分工作都是为后续运维服务”的观点，感觉形成了强烈的共鸣。
其实，要说明的是，前半句是 Bob 大叔的《Clean Architecture》书中提到的，但是在这本书之前，我在专栏开篇词中也提到类似观点，也就是上面后半句的意思。
大家如果有兴趣可以看我的极客时间专栏开篇词。
第二个，运维与中间件的组织架构关系
如果按照第一个观点来讲，运维跟中间件团队之间是不可分割的，或者说是一件事情的两个阶段，硬生生地分割开，肯定是要出问题的。
特别是在技术体系上，引入了分布式架构，应用做了服务化拆分，两者之间必须要建立紧密的合作关系，相互支持，相互补位。
这两者的关系，从 DevOps 变革的技术角度看，我认为是组织架构建设中最关键的关系。
如果运维仍然是独立的，不能往前走，中间件团队又没有树立起全生命周期运维的意识，导致的后果必然是，工具体系不完善，效率跟不上，三天两头出问题。
国外，类似 Netflix 和 Amzon，就是有一个云平台架构部，或者平台技术部，下设架构团队（中间件）+工具研发团队（运维 or SRE）。
我们蘑菇街其实也是类似这样的体系，这几年走下来，还是取得了很不错的效果。
第三个，未来到底还需不需要 PE？
这其实是个很现实的问题，像阿里，工具平台足够完善之后，完全可以由开发自运维，而不是依赖 PE。
蘑菇街也有类似倾向，比如我们的持续交付足够完善后，现在发布环节完全不需要 PE 介入，开发自己发。
但是，跟晓征总讨论到，对于运营商这样关乎国计民生以及安全的企业，即使工具体系足够完备，也不会完全放开权限，非常核心的生产系统，该严格把控还是严格把控，PE 或运维的角色仍然非常关键。
这个观点，之前也提到过，传统行业，比如运营商和金融行业，双态运维，双轨模式运作。
所以，最终我们的碰撞出来的结论，PE 这个角色不会完全消失，需求数量会趋于平稳或者减少，但是作用会越来越关键。
特别是干了多年的老 PE，他们身上的专家经验和线上思维模式是最宝贵的，所以充分发挥自己的优势，同时找到一些新的方向突破，PE 们的空间应该还是很宽广的。
这个问题，再延伸一下，就是运维的事情不会没有，随时随刻都有，只不过是开发干，还是运维做的问题，这个就取决于工具体系的完善程度。
阿里不是想学就能学得来的。
第四个，关于对第一、二个观点的理解问题
我也跟晓征总提到，这个观点，对于很多人来讲，不一定能理解，即使能理解，也不一定能接受，这里面涉及到方方面面的问题，个中原因，只有经历过的人才能体会到。
同时，这个问题对于很多互联网公司来说，或许是顺其自然的过程，但是对于 IT 化程度很早，且很深的运营商来说，体制内的改革，就会显得更加异常的艰巨。
大家如果有兴趣可以关注下浙江移动的 DCOS 体系，晓征总领导的，在业界内都是非常好的先进案例，更不用说在运营商体制内了。
最后，我的观点能够鲜明的表达出来，并能够成为助力一个组织内部变革的理论支持，还是非常开心的。
本文转载自成哥的世界公众号。
原文链接：https://mp.weixin.qq.com/s/6LOcUqGkUtd4zJoQBJrVkA
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论