我之前在《智能化运维实践》中总结了运维方式的演进路线，如下：
业余运维
专职手工运维
半自动化和工具运维
平台化运维
智能化运维
无人化运维
并判断，将来很长一段时间，我们都会处于 智能化运维 阶段。智能化会将运维的操作变得简单便捷，最终传统运维人员将会失业，剩下的都是智能运维开发人员。
这里面最大的问题，其实是技术架构的快速发展以及多样化和复杂化，以前运维不外乎分为主机和网络、系统和应用、数据库几大类，但是随着IDC和硬件设备的成熟，以及容器云等技术的影响，传统的主机和网络运维需求越来越少，即硬件相关的技能越来越少，软件相关的技能越来越多。
随着技术发展，系统几乎不会要专业的人来管理了，系统运维会失业，你看阿里云的广告就说：使用他们的云服务器及控制台，什么都可以鼠标点点点，你可以节省招聘运维的钱。
而应用千奇百怪、架构复杂，也不是 不懂开发技术的运维 能hold住的，比如大数据项目、NodeJS项目、机器学习的项目，怎么运维，还有一堆中间件Kafka、MongoDB、TiDB、Hive、ElasticSearch，运维都不懂，怎么维护，如果只是维护机器和进程，抱歉，那不需要了，控制平台和监控平台已经帮我们做好了。
然后DBA，不想说了，以前懂Oracle、MySQL就能混得不错，不要忘了，那只是研发用到的一个存储中间件而已，而研发用到的重要中间件，何止数据库一种！需要的专业知识也不比MySQL少。如果MySQL要招一个DBA来专门维护，那么是不是Kafka、Ceph、RocketMQ等中间件都得招专门的人来维护？？我曾经做数据推送项目的时候，有1/5的时间都是在维护Kafka：集群参数怎么配置，容量怎么规划，日志报错是怎么回事，数据怎么会丢失和重复，怎么监控，怎么做数据同步等等。
好了，我想表达的是，未来的运维模式和方法，一定会有很大的改变。我来分析和预测一下。
运维工具和平台的能力越来越强，需要的人工运维越来越少。
运维开发的比例会上升，
一部分是做基础运维平台和工具的，包括AIOps相关；
另一部分是应用研发自己，根据基础运维平台提供的能力，做项目的定制运维工具。
有了运维平台，有了项目定制的运维工具，项目组就可以自己运维了。
系统和应用运维，最终会非常稀少，成为类似于系统安全管理员的角色，而一个组织的管理员通常不需要很多（可以理解为传统的运维人员大多都会失业）。
设想一下以上面这种方式，项目从测试到上线的运维流程：
首先准备部署到测试环境，如果需要用到中间件，而测试环境没有，则开发和架构师一起，首先将中间件部署起来，如果是公共组件（比如MySQL、Kafka）、基础平台（比如配置中心、注册中心），可以交由基础技术或中间件团队维护。
环境准备好之后，测试人员通过DevOps平台将应用的测试版本，一键发布到测试服务器上。
另外，项目可以部署定制的运维工具，同样，要经过测试验证。这个运维工具，通常集成了运维平台的强大监控能力，并加入了项目自己的业务监控逻辑，并且具备特定的运维能力（运维权限的大小，视角色而定）。
生产环境的准备也同上，不再多说。
几轮测试通过后，确定上线时间，具有权限的用户（可以是测试或开发人员），可以上线部署或发起变更，相关管理员只做审核。
注意到，这整个流程，可以没有一个运维参与。所有的操作步骤，没有任何的技术难点，没有任何方面是开发、测试、架构不能做到的。但是，通常需要有“系统安全管理员”，为了安全考虑，将权限最小化。
所谓的安全，需要特别澄清一下，一是不能只看安全，就像系统故障一样，“80%以上的故障都来源于系统变更，也就是说，稳定运行的系统，永远不做变更，就永远很少会出故障”，但是，我们会为了不出故障，而停止更新系统吗？所以，不能一味在意安全，该承担的风险，一定要勇于承担。第二，不能做“形式上”的安全且不懂变通，安全更应该关注“本源”，安全也不是没有灵活性。程序是由开发人员写的，你能限制他开后门吗，不让开发人员登录服务器和数据库，就意味着安全吗？这种做法如果变成了“形式主义”，而忘记了本源，则是相当愚蠢的。比如，为什么不给开发负责人登录生产服务器、重启生产应用的权限，难道怕开发负责人乱整？如果开发负责人想乱整，为何要用这么愚蠢的方式。所以，限制权限，不是为了怕开发乱操作，而是一种对开发人员的自我约束，如果这个项目不需要这种约束，完全可以把权限开放给他们。对于“自我约束”类型的安全，可以根据项目特点、人员岗位来考虑，由上级领导来定夺。
还有一种安全，我把它叫做“防御性安全”，防止误操作，就像点个删除按钮，要让你二次确认一样，对一些具有危险性、破坏性的操作，我们要想办法让这种操作更加安全。注意，我们不是要阻止这种操作！我们只是想让操作更加安全而已。
最后一种安全，我称之为“严格安全”。比如有些生产数据，是不能泄露的，哪怕是这个项目的开发人员，也不能拿到生产数据，例如公司的财务系统。这种系统，要将运维权限严格控制，只有这个系统的管理员等少数人，能接触到这个系统，甚至说要多人授权才能操作。另外，这种系统要进行程序审查和安全测试，阻止后门和安全缺陷。需要说明的是，“严格安全”是一种特殊的情况，可能需要针对不同的应用做不同的安全设计，可以由安全部门的人负责。
以上，其实说清楚了，整个运维的过程，其实没有“系统和应用运维”参与，全都是开发、测试人员自治的，开发人员和运维工具充当了“系统和应用运维”的角色。但是，根据项目、人员角色情况，可能会有一定的安全限制，安全限制可能引入系统安全管理员。
举个接近真实的案例：
王某是某项目团队的leader，这个团队有5套系统运行在生产环境，共15余个Server，由Tomcat服务器、Nginx、MySQL、Kafka、Redis、ZooKeeper、ELK等组成。
首先，除ELK外，其他组件都是公司的常用组件，基础技术团队已经接手维护。所有安装部署工作，都由基础技术团队的人来完成，开发人员只管用就行了。但是关于ELK，基础技术团队还没能力维护，由于是项目组牵头选型的，由项目组人员自己去安装和维护。
考虑到安全上的“自我约束”，项目leader王某觉得某些服务器没有必要（比如Tomcat、ELK），且为了操作方便（比如Kafka），在请示过上级领导并通过安全部门评估后，王某开通运维工具的全部权限，他可以随时操作这些生产系统，包括重启、查看进程、执行脚本等。而另一些服务器（比如Nginx、MySQL），王某觉得没必要操作，为降低风险，就仅仅开通的监控权限。
这个案例中，王某自己的项目，自己去维护，有何不妥。他开通了某些生产服务器的运维权限，他对此负责，且他的所有操作，都是通过运维工具进行，都是有审计的。注意，这个案例中的系统没有涉及“严格安全”，所以上级领导和安全部门都同意了他的请求。