从毕业之后阴差阳错进入运维这个行当，已经三年时间了，对运维工作积累了一些认识，也产生了一些感情的。借此文章整理下自己之前的经历，反思下自己的工作，看看能否理清今后的发展思路。

    什么是运维？什么是开发？

14年毕业至今，前后换过三份工作，每一次都对运维工程师这个职位有一些新的认识。

第一份工作是在一家比较小的安全公司，大四实习之后直接转正，做工作有老员工带着，遇到问题可以直接请教老员工。那时候的工作就是跟着前辈部署一些程序，排查下性能问题，重启下服务器，每天最大的乐趣就是写一点小shell脚本，简化下繁琐的工作。所以，那时候的认知就是：在服务器上执行命令处理问题的就是运维，根据需求写代码完成功能和修复BUG的就是开发。

第二份工作呢，则是进了一家小型的创业公司。作为公司唯一的一名运维工程师，并没有人能指导我的工作，没人告诉我该干什么，怎么干，我只知道，如果应用系统出了问题，领导就会找我。 为了避免系统出现问题影响业务，我需要做负载均衡、高可用、监控、制定问题处理的流程规范。这时候的认知变成了：运维工程师是保障系统可以稳定的为业务提供服务，开发工程师是让系统更友好的给业务提供服务，研发创造价值，运维避免风险。

第三份工作，也就是目前的工作 则是就职于某大型电商集团中间件部门DevOps小组，重新做回了小小螺丝钉的角色。与之前工作不同的是，我们所有系统都是服务于集团内部的研发人员，而且很多系统和其它部门的系统之间相互依赖。为了完成工作，除了一些技术问题处理，更有一部分精力需要花在和各种同事沟通，寻求最优解或者双方都可以接受的妥协方案。 这时候对运维工作的理解就是：与开发人员一起配合，尽可能的给用户优质的体验。

So，区分运维和开发的并不是工作方式，并不是说研发就是一直在写代码，运维就是一直在插拔网线、部署程序、重启服务器；而是大家的职责不同，仅此而已。

    运维工作真的比研发low吗？

发现周围好多同事朋友，不过运维还是研发，包括HR，部门领导，猎头，都感觉运维比研发low，相应的，同等能力下运维工资貌似也普遍略低于研发（这里的运维包括具有一定开发能力的运维开发工程师）。认真想了下，出现这种现象的原因，可能有以下几个：

1、大部分运维工程师的时间充斥着琐碎事务，完全就是一个客服加打杂的工作

2、运维工作并不能直接的创造价值

3、运维普遍要求24小时on call。 凌晨接到电话时Fuck在心口难开

但是这些问题，其实并不是没有办法解决的。相信现在很少再有那种单纯的系统运维或者应用运维工程师了，大家多多少少都掌握着一两种开发语言。而大多琐碎的事务，都可以通过自动化来完成。

再有就是现在大多数系统都是分布式的高可用架构，只要系统避免到单点故障，真的很少有问题需要当晚立刻处理，完全可以等到第二天工作时间在进行操作。当然，具体操作起来还是有很大难度，会遇到各种各样的问题。比如工作被各种琐事填满，完全没有时间进行工程性的工作提高工作效率。部门间信息共享不够，比如服务器连通性报警，对于我们来说单台连通性报警并不是什么大问题，但是监控部门的同事会认为比较重要，不管几点都会电话通知我们。后来经过和监控部门沟通之后，监控部门同意类似问题只通过短信等发送报警不打电话叫醒我们之后，又会有部分研发恰巧没睡着看到报警信息之后打电话来咨询（这里指大型公司）。

但是办法总比困难多，不能因为这些困难就放弃以更优雅的方式处理运维问题，而是直接认定 运维工作比较low。

之前我们说了，运维只是要保障系统稳定性和可用性，和工作方式方法无关。这样看，Google的SRE说白了不也是运维工程师，虽然没有真正接触过，不过看《SRE Google运维解密》中写的，还是很有技术含量，很高大上的。 那50%的时间分配原则，真真让人羡慕。

如果排除上述那些因素，只看工作本身的话，其实运维的技术含量并不比研发低。要保证系统的稳定性、网络协议、操作系统、开发流程规范各种都需要有一定的了解，而且可以开发自己的运维平台简化工作，自己本身既是开发人员，又是最终用户，省去了和产品经理及业务方的各种扯皮，可以安安心心按着自己的心意创造产品，还是很美好的，不是吗。

    如何让我们的工作变得高大上？

既然有着光明的前途，那我们需要怎样做，才能过上美好的生活呢？

作为一个一线基层运维，我觉得，自身能做的就是学习，学习，学习。学习专业技能，学习如何沟通，学习通用技能（如英语能力，文档能力）。提高专业能力，你才能实现你想做的运维平台，解决你遇到的那些问题。 提高沟通能力，你才能让你的直属领导和同事支持你做你想做的事情，自动化也好，学新知识也罢，都需要时间。 提高英语能力可以让你更快的学习专业技能，提高文档能力可以让你的工作成果在不同部门之间推广，让你得到其它同事的认可。   并且不要放弃任何学习和练手的机会，如果同一份工作，手动解决和通过编写自动化脚本所需时间相差并不多，那一定要选择用脚本来实现，多动脑子少动手。

    自动化运维平台空想

没事儿的时候总喜欢瞎想，运维平台应该做成啥样，趁着这个机会，也顺便落到纸面上，说不定以后有机会真的付诸实践，别到时候再忘了。

一体化： 既然是叫做平台，就应该有完善的功能，从硬件资源申请，持续集成，到监控，到批量命令执行，failover都应当包括在内。后台可以分为不同的子系统，但是用户操作时，应该是统一的入口，各系统间数据应当共享，所有操作日志清晰可审计。

少量并多样的交互： 交互频率应当越少越好，只要有人参与到整个流程当中，那处理周期怎么也是分钟级的，如果涉及到多人操作，可能需要几个小时甚至几天。 理想状态下，最好是监控系统发现异常后，直接通知异常处理系统进行处理，流量迁移，故障判断一步到位，如果可能最好能直接恢复，如果是硬件故障，可以直接报修IDC或者硬件供应商。只需要在这一切完成之后，给运维人员一份记录即可。不用业务的异常处理流程可能有所不同，这一部分最好做成可配置的。有特殊需求的用户可以自行定义异常处理流程。  相反的，交互方式应当越多越好，手机APP,chatbot，WEB页面。

自主进化： 由于统一了所有操作的入口，而且有着完备的数据，所以应该能够通过机器学习等方式，让平台越来越智能。由最开始的我们指定平台应该怎么做，到平台根据实际情况给出处理意见，由运维人员确认是否可以进行该项操作，到运维人员制定约束，避免一些危险操作，其余的由系统通过自主的学习来判断应该如何去做故障处理，性能调优等工作并具体执行。用户要执行查询等操作时，也可以由最开始的命令模式，改变为自然语言。

（Ryan原创）

从毕业之后阴差阳错进入运维这个行当，已经三年时间了，对运维工作积累了一些认识，也产生了一些感情的。借此文章整理下自己之前的经历，反思下自己的工作，看看能否理清今后的发展思路。

    什么是运维？什么是开发？

14年毕业至今，前后换过三份工作，每一次都对运维工程师这个职位有一些新的认识。

第一份工作是在一家比较小的安全公司，大四实习之后直接转正，做工作有老员工带着，遇到问题可以直接请教老员工。那时候的工作就是跟着前辈部署一些程序，排查下性能问题，重启下服务器，每天最大的乐趣就是写一点小shell脚本，简化下繁琐的工作。所以，那时候的认知就是：在服务器上执行命令处理问题的就是运维，根据需求写代码完成功能和修复BUG的就是开发。

第二份工作呢，则是进了一家小型的创业公司。作为公司唯一的一名运维工程师，并没有人能指导我的工作，没人告诉我该干什么，怎么干，我只知道，如果应用系统出了问题，领导就会找我。 为了避免系统出现问题影响业务，我需要做负载均衡、高可用、监控、制定问题处理的流程规范。这时候的认知变成了：运维工程师是保障系统可以稳定的为业务提供服务，开发工程师是让系统更友好的给业务提供服务，研发创造价值，运维避免风险。

第三份工作，也就是目前的工作 则是就职于某大型电商集团中间件部门DevOps小组，重新做回了小小螺丝钉的角色。与之前工作不同的是，我们所有系统都是服务于集团内部的研发人员，而且很多系统和其它部门的系统之间相互依赖。为了完成工作，除了一些技术问题处理，更有一部分精力需要花在和各种同事沟通，寻求最优解或者双方都可以接受的妥协方案。 这时候对运维工作的理解就是：与开发人员一起配合，尽可能的给用户优质的体验。

So，区分运维和开发的并不是工作方式，并不是说研发就是一直在写代码，运维就是一直在插拔网线、部署程序、重启服务器；而是大家的职责不同，仅此而已。

    运维工作真的比研发low吗？

发现周围好多同事朋友，不过运维还是研发，包括HR，部门领导，猎头，都感觉运维比研发low，相应的，同等能力下运维工资貌似也普遍略低于研发（这里的运维包括具有一定开发能力的运维开发工程师）。认真想了下，出现这种现象的原因，可能有以下几个：

1、大部分运维工程师的时间充斥着琐碎事务，完全就是一个客服加打杂的工作

2、运维工作并不能直接的创造价值

3、运维普遍要求24小时on call。 凌晨接到电话时Fuck在心口难开

但是这些问题，其实并不是没有办法解决的。相信现在很少再有那种单纯的系统运维或者应用运维工程师了，大家多多少少都掌握着一两种开发语言。而大多琐碎的事务，都可以通过自动化来完成。

再有就是现在大多数系统都是分布式的高可用架构，只要系统避免到单点故障，真的很少有问题需要当晚立刻处理，完全可以等到第二天工作时间在进行操作。当然，具体操作起来还是有很大难度，会遇到各种各样的问题。比如工作被各种琐事填满，完全没有时间进行工程性的工作提高工作效率。部门间信息共享不够，比如服务器连通性报警，对于我们来说单台连通性报警并不是什么大问题，但是监控部门的同事会认为比较重要，不管几点都会电话通知我们。后来经过和监控部门沟通之后，监控部门同意类似问题只通过短信等发送报警不打电话叫醒我们之后，又会有部分研发恰巧没睡着看到报警信息之后打电话来咨询（这里指大型公司）。

但是办法总比困难多，不能因为这些困难就放弃以更优雅的方式处理运维问题，而是直接认定 运维工作比较low。

之前我们说了，运维只是要保障系统稳定性和可用性，和工作方式方法无关。这样看，Google的SRE说白了不也是运维工程师，虽然没有真正接触过，不过看《SRE Google运维解密》中写的，还是很有技术含量，很高大上的。 那50%的时间分配原则，真真让人羡慕。

如果排除上述那些因素，只看工作本身的话，其实运维的技术含量并不比研发低。要保证系统的稳定性、网络协议、操作系统、开发流程规范各种都需要有一定的了解，而且可以开发自己的运维平台简化工作，自己本身既是开发人员，又是最终用户，省去了和产品经理及业务方的各种扯皮，可以安安心心按着自己的心意创造产品，还是很美好的，不是吗。

    如何让我们的工作变得高大上？

既然有着光明的前途，那我们需要怎样做，才能过上美好的生活呢？

作为一个一线基层运维，我觉得，自身能做的就是学习，学习，学习。学习专业技能，学习如何沟通，学习通用技能（如英语能力，文档能力）。提高专业能力，你才能实现你想做的运维平台，解决你遇到的那些问题。 提高沟通能力，你才能让你的直属领导和同事支持你做你想做的事情，自动化也好，学新知识也罢，都需要时间。 提高英语能力可以让你更快的学习专业技能，提高文档能力可以让你的工作成果在不同部门之间推广，让你得到其它同事的认可。   并且不要放弃任何学习和练手的机会，如果同一份工作，手动解决和通过编写自动化脚本所需时间相差并不多，那一定要选择用脚本来实现，多动脑子少动手。

    自动化运维平台空想

没事儿的时候总喜欢瞎想，运维平台应该做成啥样，趁着这个机会，也顺便落到纸面上，说不定以后有机会真的付诸实践，别到时候再忘了。

一体化： 既然是叫做平台，就应该有完善的功能，从硬件资源申请，持续集成，到监控，到批量命令执行，failover都应当包括在内。后台可以分为不同的子系统，但是用户操作时，应该是统一的入口，各系统间数据应当共享，所有操作日志清晰可审计。

少量并多样的交互： 交互频率应当越少越好，只要有人参与到整个流程当中，那处理周期怎么也是分钟级的，如果涉及到多人操作，可能需要几个小时甚至几天。 理想状态下，最好是监控系统发现异常后，直接通知异常处理系统进行处理，流量迁移，故障判断一步到位，如果可能最好能直接恢复，如果是硬件故障，可以直接报修IDC或者硬件供应商。只需要在这一切完成之后，给运维人员一份记录即可。不用业务的异常处理流程可能有所不同，这一部分最好做成可配置的。有特殊需求的用户可以自行定义异常处理流程。  相反的，交互方式应当越多越好，手机APP,chatbot，WEB页面。

自主进化： 由于统一了所有操作的入口，而且有着完备的数据，所以应该能够通过机器学习等方式，让平台越来越智能。由最开始的我们指定平台应该怎么做，到平台根据实际情况给出处理意见，由运维人员确认是否可以进行该项操作，到运维人员制定约束，避免一些危险操作，其余的由系统通过自主的学习来判断应该如何去做故障处理，性能调优等工作并具体执行。用户要执行查询等操作时，也可以由最开始的命令模式，改变为自然语言。

（Ryan原创）