概要

互联网自诞生之日起到今天，一直保持着高速发展的状态，每一次互联网的革新，都会带来一大批的机遇，而现在我会在这里讲的是2024年，作为一个it运维，该怎么应对当下的变革来更好地抓住机遇。

写作背景

在正式开始分享之前，首先需要介绍下我自己，2023届毕业生，现在在一家小公司为运营商做操作系统维护，也就是传统意义上处理故障的运维。
写这篇文章是因为最近想从公司离职，在某招聘网站投递200+简历，面试过几家公司之后，对当下运维这个行业有了一些浅薄的认知，单纯的作为自己心路历程，如果诸位不认同，还请手下留情，如果对你有帮助，只希望你能点个免费的赞。

当下运维行业现状

近几年，由于云平台等管理模式的发展，Devops技术在运维行业大范围的推广，还有Docker，K8s等容器技术的大规模应用，头部大厂已经完成业务上云（公有云和私有云）的替换，而更多的应用也实现了容器化，像nginx这样的应用，由于容器平台的更高的可拓展性和简单的维护特性，已经逐渐摒弃了传统的集群部署理念，转向更加轻便的容器，也更加适应当前互联网时代人们对网站访问量突增的现状。传统的部署方式已经不再是主流，这就意味着我们运维人需要技术的革新，尽快投入到容器运维的怀抱。
而更多的公司招聘，也开始要求会k8s这些技能，不再是传统的技能，这就意味着在不久的将来，如果不会容器技术，将会被时代抛弃，转而可能就是被裁员。
传统的运维方式是应用部署在操作系统上，使用人力或者一些自动化的平台，如ansible等去做管理，这样的方式显然在之前很常见，然而现在更多的是虚拟化技术，应用部署在虚拟机或者容器中，维护当然不能按之前的方式去做。
传统的故障大多是人为配置导致的操作系统故障，会直接影响到系统本身，为了提高系统的可用性，使用集群部署，主备机等方式来提高业务的稳定性。然而在虚拟机出现之后，操作系统在做变更之前做一个快照，在修改导致出现宕机或其他不可恢复的故障之后，可以采用快照一键恢复，这就不需要传统运维去解决故障来恢复系统，大大的缩短了故障恢复的时效，也提高了系统的稳定性。
在业务应用迁移到容器和云平台之后，主机的安装方式变为了制作模板然后下发，省去了传统运维安装操作系统的过程，缩短了服务时长，对底层硬件出现的故障，可以直接将系统飘移到冗余的节点继续运行，避免了因为硬件导致的业务中断，容器带来的影响就是应用的可扩展性和更好的稳定性，在node节点故障之后，可以直接将pod漂移到其他node节点。这两种方式来讲的话，显然容器的资源利用和容灾更加完善，所以应用容器化是不可避免的趋势。
举例来说，以前，我们的车坏了，我们会去修车店修理，修好了才能不耽误我们出行。这放在it行业，主机系统就可以看作车，修车店就好比运维部门，我们正常出行的需求就是服务，服务和主机发生了故障，以前就是运维去修，修好了才能满足你出行的服务。为了保障你出行的需求，你可以搞两辆车，避免耽误你出行，这就是主备。现在上私有云就是把我们小区所有的自己的车统一管理，谁用那就谁开，哪个坏了那就换一个，你先开正常的车出行。容器就是将所有的车都配备专门的司机并且统一管理，你需要的时候那就叫坐车就行，假如出门路上车坏了，叫下一辆车过来送你就好，这时候你的出行需求就更加有保障，不会因为车的原因或者司机的原因导致你的出行被影响。

未来的个人提升

讲了这么多容器的优势，那未来，我们需要掌握的技能就是容器的能力，还有云平台的能力，大规模的运维，必然是脚本或者自动作业任务模板的方式，所以，shell脚本和python等能够帮助我们做大规模运维的技能也是必不可少的。
当然，也可以更高级，拥有开发运维管理平台的能力，像当前主流的go语言，或者未来可能会出现的其他语言。

小结

互联网注定是一个紧跟技术的行业，技术在不断发展，我们也需要不断更新技能包，才能不被行业所淘汰。
居安思危，努力爬上改革浪潮的高点才能做互联网时代的弄潮儿。
最后：祝各位升职加薪！！！