工作总结
发表时间：2026-03-13证券年终工作总结。
翻翻这一年的运维记录，有几个故障让我睡不踏实，也有几个决定做得还算利索。挑两个说说，都是真金白银换来的经验。
先说存储切换那次。四月份，用了五年的存储设备到了退役年龄，必须在新股发行季前把数据迁到新设备上。计划定的是周六凌晨两点开始，四点前结束，不耽误周一开市。预演做了一遍，所有步骤都走通了，数据同步、应用切换，顺风顺水。可到了真动手那天晚上，出了岔子。 WwW.Jt56w.cOM
数据同步到97%的时候，监控突然报延迟飙升。我登上去一看，复制链路上有个参数跟演练环境不一样——演练时用的是千兆测试网，实际生产是万兆多路径，多路径软件的负载均衡策略没调成轮询，导致一条链路拥塞后数据全挤在单线上。当时两点四十，离预定结束时间只剩一个多小时。说实话，后背有点冒汗，脑子里飞快过了一遍回滚步骤，手已经放在中止命令上了。但看着那跳动的同步进度，还是决定再盯三十秒。我让同事盯着同步状态，自己把多路径配置翻出来，现场改了负载算法，重新加载，链路立马均衡了，同步速度从十几MB/s蹿到五十多MB/s，最后三点二十完成切割，留出足够时间给业务做连通性测试。那天晚上回家路上我一直在想，要是预演环境能完全照着生产搭，多路径参数早点核一遍，根本不用受这惊吓。后来复盘报告里我加了一条：所有涉及链路的配置项，必须用生产环境的真实流量模型做压测验证，演练得跟实战一模一样，差一个参数都不行。
比起这个，另一个事儿更让我长记性。七月份，下午开盘后半小时，报盘机连着丢了三次心跳，每次自动重连成功，但柜台那边报了好几条“行情延迟超5秒”的告警。我上去看日志，发现行情网关服务器的CPU0使用率飙到95%，其他核心却只有20%。一开始怀疑是网络抖动，让网络组查了所有端口，没发现丢包。后来抓包分析，才发现行情组播流进来的时候，网卡中断全打在CPU0上，而CPU0还要处理时钟同步和部分管理任务，流量高峰时中断响应不过来，导致内核缓冲区溢出，丢包触发重传。我当时就在想，这问题其实挺老的，网卡多队列和中断亲和性，十年前就该注意，可这些年硬件性能上来了，反倒把这些细节给忽略了。我赶紧把网卡的多队列打开，让中断分散到四个核心，同时把行情进程绑到单独的核心上，避开管理中断。改的时候手有点抖，毕竟是盘中，万一改出问题影响交易，那麻烦就大了。我先观察了几分钟，确认CPU0使用率掉到30%，毛刺消失，才松了口气。后来再没出现闪断。这个事给我的教训是，别总盯着应用层，底层的分配策略得定期扫一遍，尤其是行情这类高吞吐低延迟的业务，一根线松了都可能卡住脖子。
还有一回是版本发布。升级交易接口的SDK，开发说兼容老版本，我们就没做全量回归，只测了新增接口。结果上线后，一家做市商的程序因为用了过期的加密套件，连上来就报错。查下来是新SDK默认关闭了TLS1.0，而对方没升级。你懂的，生产环境永远有你没照顾到的老古董。后来改了发布流程：凡是涉及通信协议的变更，哪怕号称兼容，也必须找一两家真实柜台做联测，不能光靠实验室环境。
这一年，系统没少折腾，故障也碰了几回，但真正让我睡踏实的，不是没出事，而是出事后能快速摁住，并且把漏洞补上。明年？先把这几次数得着的技术债还了：行情网关的CPU绑定得写到自动化脚本里，存储切换的应急文档还得再精炼精炼，还有那些个老古董客户的协议版本，得挨个摸一遍。活儿是干不完的，但别在同一条沟里翻船就行。
-
需要更多的工作总结网内容，请访问至：工作总结
