工作总结
发布时间：2026-04-10〔优质〕2026年安全年终工作总结。
今年这年过得，说实话，像坐了趟过山车。年初的时候我还觉得手头那套监控挺靠谱，半夜被叫醒的次数比去年少了。结果三月份一个扩容，直接把我从梦里拽回现实，后半年基本都在补窟窿。挑几件印象深的说说，算是给自己一个交代。
一、那次扩容，差点把整个交易系统搞崩
三月中旬，业务那边说交易量涨了30%，要求加节点。我们按标准流程，提前准备好镜像、配置模板，测试环境也跑通了。操作窗口批的是凌晨两点，我带着一个新同事上线。
新节点加进集群后，我习惯性看了一眼监控——CPU使用率瞬间从20%飙到95%以上。当时心里“咯噔”一下，赶紧去查连接数，果然，部分老节点的连接开始往下掉。业务群里还没人喊，但我已经知道要出事。
第一步是先切流量。我手动把新节点从负载均衡里摘掉，业务慢慢恢复。整个过程大概用了七分钟，但那七分钟我感觉像过了半小时。事后查原因，发现是新节点的JDBC连接池里有个参数——maxActive——设成了200，而老节点是50。半年前为了应付一次大促，我在某台机器上手改了这个值，后来标准化文档没更新，这次扩容的人照着旧文档配的。
更气人的是，我们全站有四套环境，每套的配置都不一样。那两天我啥也没干，就一台一台连上去，把每个节点的配置导出来，用diff一条条比对。结果发现有三台机器都存在类似的历史遗留问题。最后我写了个Python脚本，每周自动比对一次配置基线，发现差异直接钉钉告警。同时把配置中心搭起来，所有参数必须从中心拉取，谁再手改我直接打回。
这个事让我明白一个道理：文档不同步等于没文档，自动化不是用来炫技的，是用来堵人祸的。 不过说实话，配置中心推行的时候也遇到了麻烦——有个老系统的启动参数写死在代码里，根本改不了，到现在还只能手工维护。这个坑，明年还得接着填。
二、半夜三点，磁盘写满，然后Agent疯了
七月份一个周六，我正在家看孩子睡觉，电话响了。监控显示日志采集Agent挂了，我远程连上去，敲了个df -h，/var/log分区用到了100%。常规操作：删掉三天前的日志，大概清了20G出来。重启Agent，心想完事了。
结果Agent起来后，CPU直接飙到300%。我第一反应是“完了，是不是删错了系统文件？”赶紧用strace跟了一下进程，发现它在疯狂重试写操作——每秒钟几百次write调用，全返回失败。当时手心全是汗，孩子还在旁边哭。
后来追了三天日志，把Agent的debug模式打开，才发现问题根因：磁盘写满的时候，Agent的写缓存区进入了一个异常状态，清理磁盘后它没自动恢复，反而进入死循环重试。这个bug在测试环境从来没触发过，因为测试环境的日志轮转策略是每天切一次，而生产是每小时切一次——就差这一个参数。
紧急措施：先把所有Agent降级到上一个稳定版本，业务恢复用了大概20分钟。然后拉上开发一起过代码，在写操作前加了磁盘状态自检，如果检测到写满就停止写入并直接告警，而不是死扛。
从那以后，我要求测试环境和生产的每条轮转策略、每个超时参数必须严格对齐。说白了，差一个配置项，线上就是另一个世界。
三、验收时没留神，上线第二天就出事
九月份一个网络改造项目，施工方把测试报告发过来，ping时延、丢包率都合格，我们签了字。结果上线第二天，有个跨机房调用的业务开始频繁超时，用户投诉进来了。
我抓包一看，发现改造后新交换机的ECMP哈希算法和老设备不一致，导致部分长连接被分配到不同路径，触发了TCP重传。而施工方的验收只做了ICMP测试，根本没测这个。我当时就想抽自己——验收报告上明明有“业务流量模拟”这一项，但我觉得麻烦，没执行，就签了字。
后来我们重新制定了验收规范，强制要求用生产流量镜像回放至少24小时，并且必须包含TCP重传率、乱序包比例这些深层指标。同时，所有设备维护后的质量验收，必须由我们自己跑一遍压测脚本，不能全信施工方。那次之后，我每次验收都多留一个心眼：报告上的数据再漂亮，不如自己跑一遍真实流量。
四、今年的一些实在变化
全年主导变更37次，其中失败回滚3次，成功34次。失败的那三次，除了上面说的扩容事故，还有两次是脚本里的路径写错了。每次回滚我都记下来，后来写了个变更前的自动检查清单，跑脚本前必须逐项确认。
监控告警也改了。以前每天收几百条，我基本不看。今年重新分了级：P0级（业务中断）直接电话+短信+钉钉，P1级（性能劣化）只发钉钉，P2级（潜在风险）进日报。效果很明显，再也没人半夜被无关告警吵醒——包括我自己。
还有个小事：我们每个季度搞一次故障演练，不是背文档，是给你一个故障场景，让你在规定时间内找到对应的处置步骤。上次我出的题是“Redis挂了，但业务没做降级，怎么办？”结果有两个人直接去重启Redis，把问题搞大了。考不过的不能独立值班，这个规矩执行下来，团队的整体反应速度确实快了。
五、明年不吹牛，就两件事
一是混沌工程要真刀真枪地干。今年好几次故障都是因为某个组件挂了，依赖它的服务没做降级。明年我计划每个月搞一次随机破坏实验——比如随机kill一个Redis节点、把某台机器的网络延迟拉到200ms，强制业务方把容错能力补齐。我已经跟开发那边说好了，不配合我就每天在他们群里发告警截图。
二是知识库要活起来。现在我们有个Wiki，但大家遇到问题还是去群里问。我打算搞个机器人，把历史故障的处理过程、命令、验证方法都结构化存起来，你在群里提问时机器人自动匹配相似案例。这个技术方案我已经调研过了，用Elasticsearch加个简单的语义匹配就行，明年一季度争取上线。
今年背了两个P2故障的考核，扣了季度奖。但说实话，每次事故都让我学到点东西。明年没啥大目标，就是把混沌工程那个实验跑通，别再因为Redis挂了把整个业务拖死就行。还有，少背点锅。
-
推荐阅读:
(优质)2026年学校财务年终工作总结
2026年建筑年终工作总结
2026年超市员工年终工作总结
2026年卫生院年终工作总结
2026年抖音主播年终工作总结
【经典】2026年炊事班年终工作总结
-
我们精彩推荐工作总结专题，静候访问专题：工作总结
