时不时会有用户打电话或者发钉钉来。询问哪哪不能用了。大部分时候都是员工自己不会造成的。
具体要干啥要根据实际的公司业务走；我是公司业务运维，不是实施、外包或者对外提供服务啥的，所以平时的运维工作都是企业内部业务上面的支持；以我的工作经验分为两种情况说明：
这是主要部分，一般来说没有啥问题，平时就是看看zabbix监控有啥报错，然后根据报错去排查问题；还有就是开发需要有什么软件环境啥的（比如：Nginx代理、搭建个临时网站啥的），给部署一下；
数据库维护也是很简单，主要工作是数据库数据的备份和恢复(mysqldump命令)；其次是日常一些数据的插入、修改和删除的操作，一般都是开发给我命令，我登录到数据库去执行，因为要直接修改业务上面的东西，我们运维不参与，这一点可能和其他公司不太一样；
一般都是分布式存储glusterfs的维护，包括glusterfs服务的维护、数据的备份和恢复（rsync命令，然后写周期性计划任务备份）；
比如每个月，进行一次大的检查，包括机房硬件设施、云服务器、核心服务、数据备份情况、网络情况啥的，都检查一遍。一般来说服务、数据啥的都能做成巡检的脚本来实现。
这个就要依据具体的业务来定了，比如：网站访问有问题；网络很卡、服务宕了等等。
这是很苦逼的一个事情，如果是刚入门运维会被分配桌面运维事情：什么修打印机、修电脑、修手机、修键盘、公司上网的网络、什么电视机、投影仪啥的，都是运维的事情（若遇到这样的工作，干够一段时间就撤，否则会被烦死）
现在很多公司都没有自己的机房，所有的业务都是直接上云，要增加一台机器或者新增一个服务啥的，都是直接在云上面开一台新机器就开搞，省去了机房维护的成本。那我就说下云服务维护的情况。
就是所有的业务服务，比如：Nginx、httpd、Tomcat、kafka、mysql、zabbix等，都是搭建在云服务器上面；平时维护的方式和机房的没有区别，都是用ssh连接上面去维护的。也主要是依据需求部署服务、看看监控有没有报错；服务是不是正常啥的。
如果上云的话，数据库也是会迁移到云上面的，我们一般都是用云服务商提供的数据库，以亚马逊为例：RDS=mysql、Elasticache=redis；所以根本不要求我们搭建，用的时候开起来，不用了就删掉。
现在k8s很火，我们平时学习的时候都是自己搭建，但实际生产中一般都是云服务商提供的现成的k8s平台，我们也是开起来用就可以了，阿里、腾讯和亚马逊都有自己的平台，用的时候调研一下就可以了。
这个也是要单独说明一下，在网络公司一般都是有自己的cicd流程的；cicd流程实际上的意思就是上线的流程。这里以修改前端网页说一下cicd流程：
前端研发人员修改了html网页代码，现在需要把修改的网页推送到网站上面，如果有几百台那就要一台一台的推到/usr/share/nginx/html/ （这里以Nginx为例）下面覆盖原来的文件来完成修改；那这就很不方便了，而且容易出错。所以就引出了cicd流程；
cicd就把这一套步骤做成一个固定的流程；cicd的软件一般是：Jenkins + gitlab仓库；
cicd流程：开发修改代码，然后git push 代码到 gitlab仓库中去 ---》Jenkins检测到代码发生了变化，会自动触发cicd流程 ---》在这个流程中，会自动的执行代码构建 (就是执行推送新html到网页目录的过程)、测试修改是不是正确、最后才部署到生产环境的Nginx服务器里面；这样就完成了上线任务；
a. 部署Jenkins+gitlab的cicd流程，一般都是区公司的时候已经有了，不会让你再去部署一遍，但是作为运维一定要知道如何部署；
b. 知道部署是不够的，还要知道Jenkinsfile里面每一个阶段都在干啥；
c. 如果cicd流程出问题了，而且不是研发人员代码的问题，那就需要运维人员出马，看看是流程除了什么样的问题，该如何来解决，这是运维的工作，这里就会用到上面两点了。
最后，希望上面的东西对你有帮助，说了很多，是因为原来这么多东西也曾困扰过我；感触最深的就是出了问题就去谷歌，能解决90%的问题；其次就是要对公司的业务比较熟悉，尤其是和运维衔接的一些节点。
其中大部分都是mysql-0-bin文件，之前的文章介绍过binlog备份的过程，这里做下改进，比如有1000个binlog文件，仅对编号大于500的binlog文件做备份，为什么这么改进呢，因为假设0-500的文件已经备份过了，再次备份已经没有必要了
另外为了节约磁盘空间，可以对0-500这些binlog文件做压缩，然后从服务器上下载到比如固态硬盘里面，然后把这些文件从备份目录里面删除，达到节省磁盘空间的目标。
上面是对binlog备份目录文件进行的操作，也可以对mysql数据目录中的binlog文件做删除操作，
我们公司是做云平台的，当然，只是企业内部用。作为平台运维，目标用户也只是，公司的别的业务部门。不过，一般用户会先找一线，一线处理不了才会找到我们二线，我们再处理不了就得拉开发了。
我们运维的日常得分两部分来答，值班周和非值班周。值班周要处理一线的问题，以及接告警电话。
早上9点半到公司，先看看内网论坛，脉脉，看有没有瓜吃。然后就看早上有没有咨询了，有咨询的话，就得帮一线排查问题，一般问题都最简单，五六分钟就搞定了，复杂的问题可能就需要，调试，排查，抓包分析啥的。
吃完饭回来大概12点，玩玩游戏，刷刷知乎到1点，赶紧拿出自己的行军床准备睡觉。
2点睡醒继续变身打工人，基本上也是处理一线的咨询，或者一些用户咨询，毕竟一线拉几次人，用户就知道接入层我负责，就会直接找我。接入层基本没啥告警，有时候在大多数情况下要更新下过期证书啥的。下午6点半下班，有咨询的话就处理下，没有就直接下班，结束打工人的一天。
晚上可能会收到告警，接入层告警不多，有就是大问题，得进程起床处理，一个月都不一定有一个。
依然9点半到公司，因为不值班，可以放松点，摸鱼到10点，看看之前负责的一些项目计划，去催催进度。
最近对调试器比较感兴趣，这周没值班，一周都在研究调试器，看看腾讯大佬的书，跟着步骤去实现了一下调试器的简单功能，试着去用代码解析debug-info，调试代码花了两天，达到了自己想要效果。
前段时间，想写一个分布式的抓包服务。写一个agent在目标服务器运行，再写一个服务端控制所有agent，可以多个服务器同时抓包，同时过滤分析啥的。后面agent实现完了，服务端又懒得写了，就先放着了。
除了弄一个自己感兴趣的事情，还得去做一些其他有工作成果的事情，毕竟每周是要写周报的。这周部署了多少个集群呀，做了多少次扩容呀。哪个项目跟进到什么程度呀。
首先说一下“运维工程师”的概念：说到运维工程师，一般人都会认为是修电脑的，其实不然，并非只是会修电脑这样简单的技能就可行的。说白了运维就是“运行维护”，那么也就能够理解运维工程师的职能就是保障业务的正常运行并在出现一些明显的异常问题时及时维护。
运维工程师的日常分为两种情况：第一种，运维工程师需要他们完成一个项目产品的时候，有些时候需要加班好几个星期。
他们在产品项目完成的不同阶段会发挥不同的作用。所以其实他们的工作内容很多：产品发布前：负责参与并审核架构设计的合理性和可运维性，以确保在产品发布之后能高效稳定的运行。产品发布阶段：负责用自动化的技术或者平台确定保证产品可以高效的发布上线，之后能够迅速稳定迭代。产品运行维护阶段：负责保障产品7*24H稳定运行，在此期间对出现的很多问题可以快速定位并解决；在日常工作中一直在优化系统架构和部署的合理性，以提升系统服务的稳定性。
运维工程师是一个需要二十四小时在线的职业，因为你不了解什么时候系统就需要你去维护。所以就算你休假在家，需要运维工程师的时候也需要出手。运维工程师会有着很多业务需求，如果运维工程师能够很好的满足业务需求，或者主动挖掘业务的痛点和改进方法，就能为业务实现更多的价值。业务由于故障引起的中断一定会造成损失，所以能在发病之前就将它修理好，这才是运维工程师的核心价值。在满足业务需求时，优先面对业务加快速度进行发展很重要的需求，例如稳定性，部署和变更效率，容量管理。
当然不是了，如果你这么做的话，会被炒鱿鱼的。那运维工程师日常工作是干嘛呢？1，每日定时对机房内的网络服务器、数据库服务器、Internet服务器进行日常巡视，检查是不是正常工作，公司的网站是否能正常访问；
2，每日巡查计算机系统各个终端电脑、打印机、复印机等设备是否工作正常，是否有不正确的操作使用，是否有带故障工作的设备；
3，每天夜间在大家都下班之后对财务软件进行自动实时备份,每周做一次物理数据备份，并在备份服务器中进行逻辑备份的验证工作；
4，每周至少对文件服务器做一次物理数据备份；还有就是处理各种有关网络的突发问题。
当然每个公司的运维工程师从事的工作是大同小异的，有的公司可能还会给运维工程师安排其他的工作。所以，正在学习从事和想要成为运维工程师的你们，对自身想要从事的岗位工作内容有没有多一点了解？希望以后别人问起来运维工程师是干嘛的，千万别再让别人觉得你就是个修电脑的了。