工作总结
发表时间：2026-04-06业务人员年度工作盘点。
干我们这行的，一年到头最怕的不是活儿多，是同一个坑踩两回。今年我算是把这句话刻进骨头里了。
先说那桩让我连着三周没睡好觉的事。
二季度，一个核心数据采集系统，每周五下午准时犯病——延迟从平时不到100毫秒直接飙到八九秒，CPU占用率冲到98%以上。前两周，我们的操作基本就是重启服务、清缓存、观察半小时，看恢复了就收工。第三周又来了，我当时就火了：这他妈摆明了不是偶然故障。
周五晚上我没走，泡了杯浓茶，把过去一个月的监控日志从硬盘里拉出来一条条捋。从应用日志看到系统日志，再从系统日志看到交换机端口统计。查到凌晨两点多，终于找到根儿了——不是什么代码性能问题，也不是硬件老化。原因说出来有点丢人：合作方每周五下午会集中推送一批批量数据，而我们的采集脚本没有做任何流量控制。就好比一个单车道收费站，周末下午所有车同时挤过来，不堵才怪。
找到症结后我干了三件事。第一，在数据入口用令牌桶算法加了个限流器，桶容量1000，每秒填充200个令牌，超出的请求直接排队。第二，给数据打了优先级标签——核心交易数据走快车道，统计分析类的放慢车道。第三，也是最难办的，找合作方的技术负责人商量，把批量推送时间从周五下午三点分散到周一到周五每天三个时段。对方一开始不乐意，说他们的业务流程不好改。我拿着监控数据跟他算账：每次拥堵导致的数据重传和人工介入，双方加起来损失至少四小时工时，还不算业务影响。磨了两轮，总算谈妥了。
这三板斧下去，同样的业务量，系统跑了五个月没再犯过。峰值CPU从98%降到62%，P99延迟稳定在120毫秒以内。但这事给我的教训不止是技术层面的——我意识到，一个真正的稳定系统，不是靠反应快救出来的，是靠你主动去挖出那些“你以为不是问题”的问题。
再说说“手感”这东西怎么变成大家的本事。
以前处理故障，我习惯一个人闷头干。比如听到硬盘有轻微的“咔咔”声，就知道这块盘快不行了，赶紧查smartctl的Media_Wearout_Indicator。再比如看日志里Connection reset by peer出现的频率，就能判断是防火墙会话超时还是对端主动断开。这些判断，说好听点叫经验，说难听点就是个人手感，别人学不会。
今年我逼自己干了一件特别别扭的事——把每次故障的处理过程，写成一份笨到极致、照着做就能复现的操作清单。就拿一次网络丢包故障来说，最后总结成《网络抖动场景排查七步法》：
第一步，ping -f -s 1472 目标IP，测试路径MTU是否超过1500。第二步，在两台交换机之间跑mtr -r -c 100，看每一跳的丢包率和抖动。第三步，登录上游交换机执行show interface counters errors | include CRC|Frame，检查物理层错包。第四步，ethtool -S eth0 | grep drop，看驱动层丢包。第五步，如果前面都没问题，用tcpdump -i eth0 host 目标IP -c 1000 -w capture.pcap抓包，再用Wireshark分析TCP重传和零窗口。第六步，检查交换机端口的缓冲区占用，show buffers pool，看有没有tail-drop。第七步，根据结果调整ECN阈值或增加缓冲区。
每一步都写了预期输出是什么，异常情况下应该看哪个计数器，甚至附上了截图示例。有人嫌啰嗦，说“直接问你不就行了”。说实话，听到这种话挺无奈的——我要是不在了呢？或者我也在忙呢？
转折发生在八月的一个凌晨。值班的新人小周遇到了一次类似的网络抖动，当时我不在线。他翻出那份清单，一步一步走，走到第五步发现TCP重传率异常高，再结合第六步确认是交换机端口缓冲区tail-drop，照着预案里的命令调整了ECN阈值，问题在十五分钟内解决。他在群里说：“按清单走到第五步就定位了，后面的步骤验证完直接执行。”那一刻我才觉得，之前熬的那些夜真没白费。后来我统计过，这份清单用在上半年，平均故障定位时间从45分钟压到了22分钟。
验收这件事，我以前也有走过场的时候。
说起来丢人。今年五月，一个边缘节点的新设备上架，施工方提交的验收报告上写着“机柜接地电阻0.8欧姆，合格”。按照《GB 50343-2012》第6.2.3条，接地电阻应小于1欧姆，报告合格，我本来打算签字走人。那天不知哪根筋搭错了，我多带了一个钳形接地电阻测试仪，顺手卡在接地线上测了一下——4.5欧姆。
当时后背真的有点发凉。拆开接地排的保护盖一看，螺栓压根没拧紧，而且有一段接地线被油漆盖住了，接触面基本绝缘。我让施工方当场返工，打磨接触面、重新压接线鼻子、用力矩扳手拧到12牛·米。再测，0.5欧姆。
从那以后我给自己定了个死规矩：凡是涉及安全和稳定性的关键指标，报告写得再好也得自己动手复测。 工具自己带，流程自己走，数据自己记。信任，必须建立在交叉验证的基础上。
这个习惯后来确实救了场。有一次设备维护记录上写着“风扇模组已更换，型号AF1212A”，我到现场用手持热成像仪扫了一下，发现出风口温度异常，再用串口连上BMC一看，新风扇的固件版本是1.0.3，而管理系统只兼容1.0.2以上但实际需要1.1.0以上——版本号没对上，导致PWM调速信号失效，风扇只能全速或者停转。如果直接上线，夏天机房温度一高，大概率过热宕机。
- 作文5000网zW5000.COm精品合辑:
- 业务人员转正工作总结 | 统计人员年度工作计划 | 年度工作体会 | 年度工作述职 | 业务人员年度工作总结 | 业务人员年度述职报告
当然，今年也不是没干过蠢事。
六月份一次变更，我自信满满地给一个消息中间件升级版本。测试环境跑了三天没问题，生产环境半夜两点上线。结果升级完刚切流量，消费端就开始疯狂报错——我漏了一条依赖：新版本要求ZooKeeper也同步升级，而测试环境的ZK是事先升过的，生产环境忘了。回滚花了四十分钟，那四十分钟里业务消息积压了三十多万条。
第二天早会，领导没怎么骂我，但那种失望的眼神比骂人还难受。我自己写了份事故报告，列了三条原因：变更前没有做依赖关系全量扫描、没有准备完整的回滚预案、灰度切流只切了10%就以为万事大吉。后来我补了一个“变更三板斧”的检查清单：第一斧，备份配置和二进制文件；第二斧，灰度从单机到单机房逐步放量；第三斧，回滚步骤必须在变更前实测一遍。这东西现在贴在每个人的工位隔板上。
说到底，这一年最大的变化是心态。
以前我总想着“别出事、别犯错”，像个守门员。现在我更愿意主动去“折腾”系统——在业务低峰期故意拔根网线、kill一个进程、让磁盘写满，看系统能不能自己扛过去。一开始同事都说我有毛病，好好的系统折腾它干嘛。但搞了几次之后，大家发现每次演习都能暴露出监控盲区、超时配置不合理、重试机制没生效这些问题。提前补上，比半夜被叫起来舒服多了。
明年的事，我不想说太多虚的。就一条：把今年攒下的那些检查清单、操作手册、故障预案，全部搬到内部wiki上，每个季度组织一次红蓝对抗。目标是让任何一个新人，照着文档能在半小时内独立定位一次中等复杂度的故障。
活儿干得漂不漂亮，不看你说得多好听，看你下次出事的时候，是不是还慌。
- 更多精彩的工作总结，欢迎继续浏览：工作总结
