你好，很高兴解答你。
作为一个运维狗有话说，经历了手动运维、脚本运维、自动化运维等各个阶段，运维工作也由非常忙、很忙、比较忙三个阶段，咱们每个阶段都说下：
1.手动运维
这个阶段一般是新手阶段，运维知识储备不足，思想意识也不够深，基本是通过手动操作来处理各种问题。兵来将挡，水来土掩。由于手动处理，工作效率不高。因此这个阶段随着各种问题的不断挤压，运维工程师将会非常忙，可能真的需要7*24小时工作哦。
2.脚本运维
这个阶段随着运维技能水平的提高、经验的不断积累，运维工程师已经可以熟练的运用工具以及相应的脚本开发，实现批量操作。最重要的还是思想意识的提高，能够主动考虑如何解决问题，这样驱动着运维不断的去接触新工具、新的解决方案。因此运维工程师从非常忙降级到很忙，有了一定的空闲时间去学习新知识。
3.自动化运维
这个阶段单纯的通过工具或脚本已经不能满足运维日益增长的技能需求，因此此时通过各种媒体渠道、经验交流，知道运维过程中不仅仅是处理问题那么简单，必须形成一定的制度规范，建立一套监控、故障响应、CI/CD机制，实现不同场景的自动化运维。此时的运维工程师将进入全新的比较忙甚至有足够的空闲时间，去学习总结，将新的知识点、理念应用到工作中。
最后，运维是一个相对比较复杂的岗位，需要了解的知识面比较广。当然随着互联网技术的不断更新，运维也需要不断进行知识的储备，以便更快速、高效的进行交付工作。
希望我的解答对你有帮助。
忙不忙看公司，小公司事情比较杂，相对要忙一点，大公司运维里面还分很多垂直领域，相对要轻松一点。
在互联网公司，运维岗是个占比很大的技术岗位，跟开发岗，测试岗并列。一个互联网产品的生成一般经历的过程是：产品经理、需求分析、研发部门开发、测试部门测试、运维部门部署发布以及长期的运行维护。一个产品的生命周期90%以上时间都在运维手中，所以运维的技术含量并不比开发低，甚至入门要高很多。
大公司有硬件运维，系统运维，数据运维，应用运维，安全运维等等，分的细自然要求也高，你要开发很多自动化系统来保证业务x个9的可靠性；小公司这些都是一个人包了，没有自动化解决方案，很多需要人肉，运维经验更重要，什么故障都能很快定位到。
目前运维工程师跟开发工程师的界限越来越模糊，什么运维开发岗，什么开发运维岗，都预示着未来不懂开发的运维在运维界很难立足。
忙不忙主要还是取决于公司，这里抛开公司不谈，说一下运维的3个阶段
- 手工运维
- 脚本运维
- 自动化运维
我们以一个例子说一下3个阶段。这里举一个例子，一个系统升级和简单故障处理的场景。
首先是手工运维，公司有3台服务器台，通过Nginx做的集群和负载均衡，跑的一样工程代码。那么每次服务器升级的时候，就需要人工把每台服务器都备份了，然后停止每台服务器的进程，把新的工程传到服务器上，再每台服务器启动项目。这样是不是很繁琐，同样的事情机械化做多次，而且全人工操作也有很大的风险。
在服务器不断增多的情况下，工作会越来越忙，那么这个时候就可以引入持续集成的框架，例如Jenkins，它可以很方便的通过我们写的shell脚本完成上述说的，写好shell后，只需点击按键，可以一件自动完成从代码服务器上拉取最新的代码，然后自动构建为工程，上传到目标服务器，自动停服备份，发布新工程启动。
这样就需要一次的脚步劳作，减少机械劳动和人为操作的风险，但是还有个问题就是随着业务的不断发展，可能我们需要关注的还有服务器的性能，弹性扩容等，如果我服务器超级多，工作就会越来越重。这个时候就有了新技术例如k8s＋docker＋Jenkins的组合，这里不太怎么具体搭建框架，介绍下能实现的效果，引入这一套服务器框架后可以实现，自动备份自动发版，除了上述的，最厉害的是可以实现自动扩容，当你设置一个服务器cpu性能值，例如50%，当我现在有3个服务，每个服务的cpu都到了设定值，k8s框架会根据我们之前设定的一些参数，自动启动新的服务，并加入集群，如果判断到某个节点故障了，也会启动新服务，然后干掉故障服务。
所以运维工程师忙不忙，除了公司的因数不谈，还要看自己是不是善用各种工具技术
原创文章，作者：普尔小编，如若转载，请注明出处：http://www.puerpx.cn/pxwd/8181.html
