想要进入运维行业？先来看看这个！

运维这个岗位对于大多数人来说，不是太苦了，而是太难了。运维不仅对于女生不友好，对于大多数的人来说都不够友好。

从运维的工作职责上来看，定义非常的抽象和宽泛，开发就是写业务逻辑的，测试就是测开发写的那一坨的，职责非常的清晰。而运维是做什么的，把开发写的那一坨发布出去，然后天天看着？坏了换个机器，服务出翔了，看看日志，重启重启？

上述应该是90%以上人的理解了，而且这90%里绝壁也混着一大堆的运维从业者，见过有的人运维干了10来年，还是不清楚运维是干嘛的，对于业务自然也输出不了多大价值。然后经常对外宣扬的就是运维工作简单，只要能吃苦，就能上手做，荼毒天下。

当然，我们讨论的运维是互联网的系统运维，不包括IDC和桌面运维以及跑现场做实施的那种。

那么互联网的系统运维能对业务输出什么不可替代的核心价值？总结起来就是，通过各种手段1）保证业务高质量不间断对外服务；2）既要服务的好又要运营成本最低；3）又稳又快又安全的让业务进行自我更新

所以，相对开发和测试而言，运维面对的是一个更加开放的命题，这些目标有些看上去甚至互相冲突，一个好的运维要知道怎么去权衡和折中它们，一定要着眼于整个团队才可以做好。

业务刚起步阶段，整个团队要的是快速迭代功能，快速发布，这时运维的工作重点应该是快速。帮助团队搭建更好更敏捷的研发，测试环境，以及制定偏向敏捷高效的生产环境管理与发布流程。

业务高速成长阶段，整个团队要的是应对每天飞速上涨的业务量，前期快速堆功能生产出的代码质量一般比较差，在高速成长阶段，开发可能无法及时的去优化代码的，这个时期就需要运维保证充足的资源供应，用硬件弥补软件的性能不足，以及各种监控报警，救火预案，和开发一道维护线上的服务质量，后台开发和运维最辛苦的阶段。

业务成熟阶段，前期打造出的这个赚钱机器已经开始蠕动着赚钱了，这时更加关注的是稳定稳定还是稳定，还有就是成本。线上90%的故障都是有变更引起，这时运维会对严控变更流程，审批手段，变更时间，灰度时长，打分制度等都会一 一出台，除了卡着开发以外，还会去挖掘线上服务的性能问题，推动开发去优化改造以降低运营成本。

业务衰落期，此时在保证业务正常的前提下进一步的压缩运营成本，对于次要模块推动下线。

运维需要有着眼于整个团队的大局观，要和业务紧密结合，更主动的参与到整个流程里去，评估架构和技术方案，提早发现一些不合理的技术方案，从运营的视角给出意见和建议，尽可能的提早干涉，与开发密切配合做好性能，容灾，监控和预案，切合开发和测试的需求搭建更高效的运营平台等等。

上述这些要求其实是不低的，单说主动这一点，就可以淘汰掉一半以上的人，更别说其他。所以大多数运维人员的苦逼是有根源的，晕晕乎乎的接受一大堆自己也不理解的东西，在出现问题后骂骂咧咧的说开发太坑，自己背锅，然后日复一日的被这样的怪圈所折磨。如果没有能力hold住这些，还是建议不要入坑，否则等着自己的就是一个又没钱又没时间又自我评价低的火坑。