自查评工作总结
发表时间：2026-03-27[最新]2026年自查评工作汇报。
一季度自查评，我翻出来三个事，都不大，但都够恶心人。我是干运维的，这些年养成的习惯——出了故障，第一反应不是急着甩锅，是把现场焊死，把日志捞干净，然后对着证据说话。
第一个事，机房那两台华为S12700。每隔两周，下午四点来钟，业务就喊卡，丢包，延迟跳到两百多毫秒，三五分钟后自己好了。监控只报个“网络抖动”，根本看不出根因。那段时间我蹲在机房里，笔记本连着串口线，盯着终端窗口，一到四点心脏就提到嗓子眼。它偏不犯，我刚回工位，电话就来了。这感觉，像被设备戏弄。
我实在忍不了，干脆在核心设备上把日志级别调到debug，同时把上下联所有端口做了镜像，拿台服务器跑着Wireshark，24小时抓包。第四天下午四点零八分，抓到了。我盯着屏幕，CPU利用率从15%直线拉到98%，然后回落，整个过程不到十秒。顺着CPU中断的线索，查到是一个叫“STP”的进程在处理TC报文时卡住了。再往下挖，我把核心收到的TC报文按源MAC地址统计了一下，妈的，99%都来自同一个MAC地址。顺着MAC地址表，找到一台藏在机柜角落的接入交换机。当时看到结果，心里骂了一句，这破设备藏得够深的。
现场排查发现，那台交换机的下联端口，光纤跳线老化，端口物理状态频繁up/down。按理说，边缘端口变动不应该影响核心，但它有个历史遗留配置，把端口设成了“stp edged-port disable”，导致每次抖动都往核心发TC报文，核心CPU被撑爆，转发层面跟着抖。
处理本身不复杂：换掉那根老化的跳线，把端口强制配成边缘端口。但从那以后，我养了个习惯——周期性抓一下核心交换机的STP状态，看看TC报文有没有异常。说实话，这件事让我后背发凉。我们日常巡检只看端口流量、看设备灯，但STP这种基础协议的报文覆盖，监控系统里是零。也就是说，这个问题可能已经存在很久了，只是我们一直没看见。
第二个事，是生产线扫码入库的老系统。SQL Server 2014，跑了快六年。每到下午四五点换班的时候，操作员扫码枪扫完要等三四秒才有反应，平时都是秒回。查服务器资源，CPU、内存、磁盘IO都在正常范围，你说气人不气人。
我判断是执行层面卡住了。用扩展事件，专门抓超过500毫秒的查询。跑了半天，抓到一堆阻塞会话。顺着阻塞链追到源头，发现是一个“插入”操作。它带了个触发器，触发器里调了个存储过程，去更新一张汇总表。那张汇总表没建索引，每次更新全表扫描，而且存储过程里还用了“NOLOCK”提示——这简直令人难以置信。开发可能想用NOLOCK提高查询性能，结果在高并发下，锁的粒度问题把自己给阻塞了，把后面的写入全堵上了。
我当时做的第一件事，是在业务低谷期给那张汇总表加了个复合索引，字段顺序是（批次号，生产日期，扫码时间），把查询条件里用到的字段全包进去了。加完那一刻，我盯着监控，眼睁睁看着锁等待曲线像跳水一样砸下来，响应时间从三四秒降到两百毫秒以内。那感觉，比喝了口冰可乐还爽。
但我知道这只是治标。第二天拉着开发团队复盘，把那个触发器和存储过程的逻辑从头捋了一遍。坦白说，这里面有历史包袱，早期业务量小，这么写没问题，现在日活上来了，这种写法就是定时炸弹。最后我们达成共识，把触发器的逻辑改成了应用层异步处理——用消息队列把数据写出去，后台服务慢慢消费，彻底消除数据库内的隐式事务依赖。
这次之后，我把关键业务SQL的执行计划审计，加进了巡检清单。有些设备是需要维护的，那些跑了五六年的存储过程，它们也是“设备”。
第三个事，跟预案文档有关。有天晚上值班，一台存储控制器坏了，按预案应该执行主备切换。值班兄弟照着文档敲命令，执行到一半卡住了。文档里写的是“switchover active”，但新版本系统里这个命令已经废了，得用“redundancy force-switchover”。就这一个词的差异，电话里我教了他二十分钟，最后还是我远程连上去敲的。挂了电话，我他妈当时真想隔着电话线踹他一脚，但回头一想，踹他不合适，该踹的是那份没人维护的文档。
我们一直有应急预案，但从来没验证过。文档和实际操作之间的鸿沟，靠纸面是填不平的。后来我跟团队商量，建了个故障演练沙箱环境。把核心的切换、恢复操作，定期在沙箱里跑一遍，确保预案里的每一行命令都是可执行的。这不是为了写更多文档，是为了让文档变“热”。
这次自查评，我翻出来的这三个事，都不是什么大架构问题，都是细节。光纤老化、STP配置、触发器逻辑、文档过时——每一样都够恶心人，每一样也都堵得上。系统的稳定性，就是这么一点一点抠出来的。
接下来我心里有数了。监控盲区要补，STP的TC报文覆盖、SQL执行计划的定期审计，这两件事已经排进迭代。演练沙箱月底前搭出来，第一轮跑核心存储切换。别的不说，先把欠的账还上。
- 更多精彩的自查评工作总结，欢迎继续浏览：自查评工作总结
