关于运维模式和方法的思考

    我之前在《智能化运维实践》中总结了运维方式的演进路线,如下:

  1. 业余运维

  2. 专职手工运维

  3. 半自动化和工具运维

  4. 平台化运维

  5. 智能化运维

  6. 无人化运维

    并判断,将来很长一段时间,我们都会处于 智能化运维 阶段。智能化会将运维的操作变得简单便捷,最终传统运维人员将会失业,剩下的都是智能运维开发人员。

    这里面最大的问题,其实是技术架构的快速发展以及多样化和复杂化,以前运维不外乎分为主机和网络、系统和应用、数据库几大类,但是随着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),王某觉得没必要操作,为降低风险,就仅仅开通的监控权限。

    这个案例中,王某自己的项目,自己去维护,有何不妥。他开通了某些生产服务器的运维权限,他对此负责,且他的所有操作,都是通过运维工具进行,都是有审计的。注意,这个案例中的系统没有涉及“严格安全”,所以上级领导和安全部门都同意了他的请求。


© 2009-2020 Zollty.com 版权所有。渝ICP备20008982号