一个运维工程师/运维开发工程师，因为经常要写一些运维工具和平台及自动化工具，所以经常会思考一些运维规范化问题，介绍我眼中运维人员的职责。

运维人员应该有以下职责：

• 制定规范，统一的规范才可以批量操作

• 提供基础设施，支撑业务系统的公共需求

• 故障定位和处理，快速发现问题，提前预知问题

• 为研发提供咨询服务，一起讨论，寻求最佳项目架构与实践

各方面细细道来~~~

制定规范

比如，操作系统的版本，必须要有统一规范，不能说项目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多项目，见识过的各种场景比较多，对项目而言百利而无一害。