工作总结

时间:2026-04-15 赵老师教案网

2026年公司职员个人工作总结。

今年是我干运维的第五年，负责的线上业务系统从去年底的12个增加到现在的19个，服务器节点160多台，团队算我总共3个人。说这些不是为了凑字数，是想让看这份总结的人有个底：我们是在这种资源下干活的。

故障处理：两次P0，我都记得

全年经手47起故障。P0级两次，说出来不光彩，但得认。

第一次是1月份，一个数据迁移脚本写错了时间范围，把上个月的历史订单状态批量更新成了“已取消”。凌晨四点接到电话，我先停了脚本，然后手工跑修复SQL，从备份表里捞数据一条条对比。忙到早上七点半，恢复了98%的订单，剩下2%因为备份延迟实在找不回来，只能让业务方人工补录。那天早会上被问了三遍“为什么没做灰度？”我答不上来。后来我加了两层保护：所有批量更新脚本必须先跑--dry-run模式输出影响行数，超过1000条的要二次确认；同时把备份策略从每天一次改成每六小时一次，保留三天。

第二次P0是6月份，负载均衡器的配置被人误删了一条转发规则，导致某个地区的用户访问不了图片服务。发现问题用了12分钟——因为监控只报了“5xx增多”，没有直接定位到具体规则。事后我改了告警策略：凡是核心业务接口的5xx超过阈值，自动拉取最近5分钟的配置变更对比，把差异项发到群里。这个功能是用Python写的一个小脚本，跑在Jenkins上，后来帮我们提前发现过三次类似的误操作。

其他那些P1、P2的故障，我最烦的是重复发生的。比如磁盘告警，每个月总有那么一两回，要么是日志没轮转，要么是临时文件忘了删。今年我干脆写了个定时任务，每天凌晨两点扫一遍所有服务器的磁盘使用率，超过75%的自动清理/tmp和/var/log下7天前的文件，同时发个消息到钉钉机器人。跑了半年，磁盘告警从月均5次降到了0。但我也得承认，有一次清理脚本出bug，把/var/log/nginx下当天正在写的access.log给删了，导致那台机器的访问日志断了两个小时。后来我在脚本里加了个白名单，access.log和error.log永远不删，只删带日期的轮转文件。

一个让我后怕的案例：缓存穿透

9月份，运营搞了个秒杀活动，预计流量是平时的五倍。我跟开发说，你们那个商品详情页的缓存策略有问题——用的是简单的get/set，没有布隆过滤器，一旦有大量请求查不存在的商品ID，会直接穿透到数据库。开发负责人觉得“概率很小”。我说不行，这个必须改，要不然秒杀开始后数据库必挂。

最后各退一步：我帮他们写了个简单的本地缓存，把不存在的key也缓存一分钟（值是null），至少挡住重复查询。同时我把数据库的连接池上限临时调高了一倍，但做好了熔断准备。

秒杀当天，前十分钟一切正常。到了第12分钟，监控突然跳出一波慢查询，全是SELECT * FROM product WHERE id = ?，而且ID都是随机的大整数——明显有人在恶意扫描。那个本地缓存起了作用，大部分请求直接返回空，数据库连接数只涨了20%，没被打死。事后我跟开发说，你这个布隆过滤器下周必须加上，这次是侥幸。他们总算没再拖。

质量验收：我跟开发拍过三次桌子

公司有上线流程，但之前都是走形式。今年我牵头搞了个《上线前检查清单》，分四张表：代码变更（有没有CR、单元测试覆盖率）、配置变更（回滚方案、灰度开关）、依赖检查（DB变更、MQ新增topic）、安全项（密钥有没有硬编码）。

推行起来阻力很大。第一次给开发团队培训，有人说“你这清单比我们代码还长”。我说你可以不填，但出了事故你要背。后来真的有一次，一个开发没填“DB变更”那一项，上线后才发现他加了个字段没建索引，导致一个核心查询从50ms变成8秒。那次复盘会上，我当着leader的面把清单甩出来，他没话说。

现在这清单已经跑了八个月，经手86次上线，因为遗漏检查项导致的事故从上半年的7次降到下半年的1次。那1次还是我自己疏忽——没注意到一个定时任务的cron表达式写错了，本该凌晨两点跑，结果下午两点跑了，影响了一小部分报表数据。我在复盘里写了，检查清单再加一条：所有定时任务必须先在测试环境观察一个完整周期。

日常巡检：那个被我们忽略的硬盘

★赵老师教案网ZjAn56.cOM权威推荐:

新入职员转正个人工作总结 | 公司人事个人工作总结 | 2026年终工作总结 | 2026年度个人总结 | 公司职员个人工作总结 | 公司职员个人工作总结

巡检脚本我维护了两年，一直以为挺全的：CPU、内存、磁盘使用率、网卡丢包、NTP时间偏移。今年9月，一个同事无意中看了下smartctl -a的输出，发现一台数据库服务器的“待重映射扇区数”从0涨到了48。我们查了历史记录，这个数字三个月前就开始缓慢增长，但一直没触发任何告警。也就是说，那块盘已经坏了很久，只是还没彻底死掉。

那天下午我们申请了热备切换，把业务迁到从库，然后换掉了那块盘。拆下来的时候，用肉眼都能看到盘面上有一圈浅浅的划痕。如果等到它完全坏掉，至少会导致半小时的写入阻塞。

这件事之后，我改了巡检策略：不再只看“使用率”，而是每周跑一次SMART自检，把关键指标（重分配扇区数、待重映射扇区数、通电时间）入库，画成趋势图。现在如果连续三天有增长，会自动发预警。

一点不套话的体会

有次处理完一个凌晨的故障，早上七点回到家，孩子还没醒。我老婆问：“又出事了？”我说：“嗯，搞定了。”她说：“你们这行真没意思，做好了没人知道，做坏了全公司骂。”我想了想说：“不是没意思，是这个岗位的本质就是这样——让坏事不发生，或者发生了能快速抹平。抹平了，大家就觉得本来就没出事。”

这活儿不伟大，但需要有人干。明年我打算把监控的盲区再补一补，主要是那些老旧的外挂脚本和定时任务，现在覆盖率只有85%左右。另外，故障复盘报告目前全靠手写，我想试着用ELK的API自动拉取时间线，把告警、变更、日志堆栈拼在一起，省点力气。

就这么多了。活儿还没干完，接着干。

推荐阅读: