一个运维工程师/运维开发工程师,因为经常要写一些运维工具和平台及自动化工具,所以经常会思考一些运维规范化问题,介绍我眼中运维人员的职责。
运维人员应该有以下职责:
各方面细细道来~~~
制定规范
比如,操作系统的版本,必须要有统一规范,不能说项目A用ubuntu,项目B用centos,项目C用redhat;只有使用了统一规范的操作系统版本,才可以做到后续自动化实践,才能统一打补丁,才能使用一套脚本通吃。
在比如,各种开源软件的版本,也要有统一规范,比如redis、nginx之类的,有的时候还需要为这些开源软件bugfix或者增加新feature,没有统一规范显然是不行的。
软件部署如,工作账号统一,log统一打到某个位置,应用部署位置/home/work,禁止root用户登录,多个版本之间用软链切换,进程统一用supervisor或god或eye管理。
线上端口范围划分是如:8000~9000,测试环境的端口范围必须是7000~8000,这样才能统一设置ACL
这些规范由运维和研发讨论决定,运维人员要严格按照这个实施,规范持续补充。都统一了,才能更好的方便运维及自动化。
提供基础设施
提供自动化部署工具,单纯对一个项目而言,怎么部署都行,只要能有个脚本可以做到一键上线就差不多了。但是对一个公司而言,项目成千上万,不能每个项目都造一次轮子,写一遍部署脚本,所以一个统一的自动化部署系统势在必行。而且这个部署工具可以做得很灵活并且功能丰富,是各个项目部署需求的超集。比如统一的编译打包、备份处理、灰度上线等等
有些公司是让运维人员来上线的,个人来看这个并不合理。产品需要快速迭代,每天上线几个版本都是正常,而通常一个运维人员应对了多条产品线N个项目,统一汇聚到运维这里来上线毫无必要。绝大部分上线都是小修小改,研发人员直接使用运维提供的自动化部署工具来发起上线即可。对于一些重大架构改变还是需要和运维人员沟通合理性,开发完了之后和运维人员一起上线。
另一个运维要提供的重要系统是监控系统,系统负载过高,机器挂了这些都要监控系统来发现,研发人员可以push一些数据给监控系统,比如qps之类的、latency之类的,要监控的数据有很多,比如各种开源软件本身的,用户自定义的,监控系统的开发人员显然不能了解所有要监控的数据的采集方法,所以只能提供接口让用户来push数据。
故障定位和处理
因故障可能是各方面的,比如网络问题,操作系统bug,应用程序bug,误操作,配置错误,等等,需要运维人员和开发人员一起定位处理。特定的故障可以合理的配置监控做到故障自愈(调用jenkins执行)当故障自愈无法完成时运维人员在介入处理,当然这需要建立在一套完善的运维体系之上。
为研发提供咨询服务
研发人员写一个项目,初期通常都不会去和运维人员沟通,只有要上线了准备交给运维人员来维护的时候才来找到运维人员。显然运维人员对这个项目一无所知的话那也无法运维,所以研发要和运维沟通,讲述整个项目相关的方方面面。此时运维人员可能会提出自己的看法,如果发现项目架构不合理就需要研发人员来调整。不过现实是即使发现项目架构不合理,仍然会先上线再说,后续就需要运维人员参与到研发的这个填坑过程了。
所以在项目设计阶段就可以找运维人员一起评估设计,站在运维角度及时发现问题及时修正,这样的代价相对小一些。毕竟运维人员面对的是N多项目,见识过的各种场景比较多,对项目而言百利而无一害。