工作总结
发表时间：2026-04-182026年主持工作总结。
干了快一年的主持，说白了就是背锅位。别人搞不定的故障你得顶上，出了事故你第一个被叫醒。今天不说漂亮话，聊三个我亲手搞砸又亲手填回去的坑。哪个都疼，但疼完记住的才叫经验。
先交代个背景。我手头这套系统，核心设备跑了六年，日志每天滚好几个G，交换机固件三年没升过级，配置文件散落在五六个目录里。接手的头一个月我就知道，这活儿迟早得出事。只是没想到出得这么密。
第一刀：半夜三点半，磁盘报警
Zabbix弹出/var/log分区98%。常规操作是登录删旧日志。但我多看了眼进程列表——有个叫“log_sync”的僵尸进程，PID 2841，已经卡了四小时。父进程是公司的统一日志采集器。
我没急着kill。先lsof -p 2841看了一眼，它死死拽着一个20GB的日志文件，文件名带当天日期，但文件已经被logrotate重命名了。这就是空间没释放的原因——进程还占着，删不干净。
手边咖啡洒了一半。我先kill -9 2841，再手动删那个残留文件，空间掉到12%。系统恢复。但我知道这事没完。为什么采集器会卡死？翻代码发现它用了一个阻塞队列，上游日志生产太快，下游消费不动，队列无限膨胀，最后内存溢出导致线程僵死。
第二天我补了两个东西。一是给采集器加了背压——队列超过5000条就自动丢INFO日志，只留WARN和ERROR。5000这个数是压测出来的：我们峰值每秒写入3000条，队列5000能扛两秒抖动，再高就该降级了。二是在logrotate配置里加了postrotate脚本，强制让采集器reopen文件。顺便补了监控——grafana上专门做了个丢弃计数器，丢了日志我能立刻看见。
说实话，最怕的不是故障本身，是你以为修好了，结果三个月后又来一遍。这次我把处理过程、压测数据、监控截图全钉在confluence上，标题叫“别再他妈忘背压”。
第二刀：交换机升级，全网半瘫
三月份，机房核心交换机固件要升级。窗口凌晨两点到四点。我提前做了健康检查、备份配置、回滚脚本。十五分钟升完，心里还挺美。
业务恢复验证时，三台数据库服务器同时报连接超时。Ping交换机管理地址通，但跨VLAN的TCP连接全部重置。我立刻回滚配置，重启交换机——没用。再看日志，交换机CPU飙到100%。
抓包。发现新固件默认开启了一个叫“全局MAC地址学习限制”的功能，阈值100。我们的数据库集群有200多个虚拟IP，全在广播域里漂移，直接触发惩罚机制——交换机把所有相关端口err-disable了。
那会儿凌晨三点四十。数据库组的人电话打过来，语气已经不太好了。我说在查，五分钟后给方案。临时解法：登录交换机，手动关掉那个限制。业务四分钟后恢复。
第二天复盘，网络组说他们也不清楚这个默认行为变了。我翻厂商的升级文档，Release Notes里就提了一句“增加了MAC地址学习限制功能”，没写默认开启，也没写阈值。后来打电话给技术支持，对方承认这是新版本的“隐形变更”。
现在每台交换机的基础配置模板里，我加了显式设置“mac-address-learning max 1024”。更重要的是，每次固件升级前，我会用diff工具对比新旧版本的默认配置文件，把差异项一条条列出来，签字确认后才动。
那次之后，变更窗口的验证步骤也改了——必须包含跨VLAN连通性测试，写进checklist，少一项不许收工。
第三刀：自己删了生产配置
这个最丢人。某天下午，紧急处理一个安全漏洞——某个服务的配置文件里写死了root密码。我需要用sed批量替换成新加密串。结果正则写错了，直接把整个配置段删了。
等service restart失败我才反应过来。线上服务已经停了四分钟。我脑子嗡了一下。手头有昨天的全量备份，但恢复要十分钟。怎么办？
翻history，找到刚刚执行的sed命令，反向构造恢复逻辑——幸好配置文件的原始版本还在/usr/share/defaults/目录下。我cp回来，改正确字段，重启，三分钟恢复。
这四分钟刚好赶上业务小高峰，十几笔支付超时，客服接到三个投诉。主管没骂我，但我自己写了份检讨，贴在工位上，到现在没撕。
事后补了三道闸：第一，所有生产环境的配置文件全部进git，每次变更走PR，有人review才能合。第二，写了个shell脚本叫“safe-edit”，自动备份原文件加时间戳，再调vim。第三，把sed从所有运维账户的PATH里踢出去，要用必须输全路径。
现在想想，这三个坑本质是一个毛病：太相信自己手快，没给意外留余地。日志采集器没想它会满，交换机升级没想默认参数会变，改配置没想正则写错。每次都是“这次肯定没问题”，然后就出问题。
我现在的习惯变了。每次变更前，我会打开桌面那个叫“别他妈再犯.txt”的文本文件，里面记着这三次事故的教训。看一遍，再问自己：最坏会怎样？能不能三十秒内止损？有没有不动生产的方案？答不上来就不签字。
今年还清了三十多个技术债，包括日志采集器的队列监控、交换机配置模板的标准化、配置文件的git化。MTTR从去年平均四十分钟压到了十五分钟。但这些数字写在报告里没人看，真正管用的是每次敲回车前那三秒钟的犹豫。
犹豫不是怂，是记住了疼。
- 欲了解工作总结网的更多内容，可以访问：工作总结
