一位工作半年的运维工程师的自述（运维工程师的一天）

一位工作半年的运维工程师的自述（运维工程师的一天）

不知不觉已经从大学将近半年，一直在深圳**公司从事运维工程师的岗位。在上周部门同事的分享会上，讲到了许多关于运维方面的东西，特别是思想上，所以想对自己半年的运维工程的工作做一个小小的总结，本来是上周末就想写点什么，但是部门团建活动，所以就推迟了。总结以思想为主，大神勿喷，欢迎给小菜多一点点建议。

大学的时候，学习了运维方面的一些基础知识。一到公司被分配到云平台，不久部门组织架构就进行了调整，接到的第一次任务就是docker容器编排——kubernetes的使用。这东西以前从来没碰过，也没有见过，刚开始的时候反反复复的看了很多遍名词，组件是什么，有什么功能，说实话，看了一周都是云里雾里，kubernetes就是一条充满荆棘之路，因为kubernetes不是单单的一个东西，它涉及的东西太多，虚拟机技术，docker，cni网络，ceph存储等，如果单纯的kubernetes发挥的作用不大，说不来，不怕笑话，我们部门就我一个运维，所以熟悉，搭建kubernetes的任务就落到了我这个应届运维身上，当然还是要感谢导师的帮助，总之，走上kubernetes容器服务之后，我不是在踩坑，就是在坑里。最近公司的容器服务准备投入使用了，基础功能差不多，但是还是有许多地方值得去改善，对kubernetes的了解虽然多了很多，收获了很多，但是感觉还是很不够。

上周，听同事分享了运维的一些思想，运维和运营，DevOps。运维实际上就是技术运营，平时所叫的运营实际是业务运营，感觉现在的运维不想以前了，开机器，设置网络等等，现在好像都不需要怎么处理，现在只需要在网站上点点就行了，都觉得运维有一天会失业了，结果是是绝对的，运维不会失业，还是需要运维，只是从分享中了解到，现在的运维的要求更高了，比如：要学会去审核一些上线的代码，从正式的环境中去分析这些代码上线后，对业务的影响，用户的体验是怎么样的，变好了还是变差了；可以想一些办法让初次使用的用户在网络下载等方面有个更好的体验等等，这都需要，要求我们干运维的去学习更多的东西。DevOps感觉吧，更重要的是一种思想，开发要从运维角度去思考，代码对环境的影响，运维也要从开发的角度去考虑代码这些进程，线程的并发，异步等等。现在DevOps主要有三种，第一种是借助开源工作，如ansible，Puppet等；第二种是云平台，使用docker，拆分微服务；第三种那就是那些高大上，膜拜的AI运维了。