三个月试用期结束，我把这九十来天的工单记录和笔记翻了一遍，一共处理了23个线上问题，其中自己独立解决的有14个，剩下的需要老同事复核。有个数字我记得很清楚：平均响应时间从第一周的43分钟降到了最近两周的7分钟。这不是什么光荣榜，就是干这行的及格线。
先说那个让我挨骂最多的故障。入职第二周，监控系统的雷达图上一根线突然翘起来——核心交换机到等保区的延迟从2ms飙到了380ms。带我的老张扫了一眼屏幕：“你去查。”我当时腿有点软，但脑子清楚：不能乱动生产配置。我先登录核心交换机，用show log刷了几百条，发现MAC地址在G1/0/8和G1/0/12两个端口之间反复漂移，每几秒就跳一次。这个现象不对——正常交换机的MAC地址表应该是稳定的。我又查了MAC地址表，目标MAC对应的服务器是一台上周刚上架的存储设备。厂家工程师已经撤了，留下十二页的部署文档，我翻了十分钟，在第8页的附注里看到一行小字：“双活模式下，两个控制器的心跳接口禁止接入业务VLAN。”我立刻对照现场：那条心跳线果然插在了业务交换机上，并且两台控制器在同一个广播域里争抢同一个虚拟MAC。我把那条心跳线所在的端口shutdown，延迟在两秒内掉回3ms。老张后来把我叫过去，没表扬，直接骂：“文档第8页你看过没有？下次提前看，别等出了事再翻。”我记下了，也确实活该。
这件事捅出来的窟窿不止一个。事后复盘发现，这台存储的上架流程里根本没有“双活模式心跳隔离”这个检查项。我跟负责验收的同事商量，加了一条“存储控制器心跳接口VLAN隔离验证”，并且要求双人确认。这算是我入职后参与修改的第一个操作规程。
五月中旬那次半夜值班，我差点犯大错。凌晨一点四十，短信报警说某个业务系统的连接池满了。我远程登上去看，连接数从平时的80个涨到了200个上限，应用日志全在报Connection not available。按常规思路，应该先重启应用释放连接。但我多看了一眼操作系统层面的netstat -an | grep ESTABLISHED | wc -l，发现实际TCP连接只有130个左右，跟连接池统计的200个对不上。这让我警觉了。我翻了连接池监控，发现preparedStatement缓存数量异常高，每个连接里缓存了三四十个语句对象，加起来占了一百多兆内存。我掏出自己的检查清单——两周前我刚好在笔记里记过一笔：“Druid连接池，当maxPoolPreparedStatementPerConnectionSize设得太大（比如超过20），在高并发下会导致内存碎片，连接无法及时回收。”我查了当前配置，是30。改回20，再重启连接池，三分钟后连接数回落到85。那晚我盯着屏幕坐了一个小时，确认曲线平稳才去睡。如果当时直接重启应用，问题会暂时消失，但一周后肯定再犯。多查一层OS状态救了我。
差点翻车的是另一回。六月有一次例行切换演练，主备防火墙倒换。备墙正常接管流量，但我用ping -f测试丢包率时发现，前九十秒内丢了将近两千个包，业务接口人直接打电话过来说“页面转圈”。我赶紧把切回来的脚本准备好，但忍住没动——先看原因。抓包发现，备墙在切换后的前九十秒内，每一个新会话都要去磁盘读安全策略库，而不是从内存读取。九十秒之后，策略库被全部缓存进内存，丢包才停止。这个设计缺陷在平时低负载下根本测不出来，因为策略库小的时候能直接被内存装下。我们现在这台墙的策略库已经膨胀到三万多条规则，读一次磁盘要二十多秒。我写了一份详细报告，建议厂家把策略库预加载改成异步预读到内存，目前在等对方给补丁版本。这件事让我明白：高可用不等于高可用性，得看切换过程中的“服务质量瘸腿时间”。
七月初那个雨天的傍晚，内网监控平台突然报出一台数据库服务器的CPU sys占比超过40%。值班同事怀疑是慢SQL，我登上去先看了mpstat -P ALL，发现sys高但user正常，这不是数据库的事。再看iostat -x 1，发现await值在200ms以上跳动，磁盘阵列明显在拖慢。我连到存储管理界面，看到写缓存状态是disabled。查操作日志，当天下午有人做了磁盘巡检，脚本误触发了“清除写缓存”的命令。这事让人挺无奈——巡检脚本是三个月前另一位同事写的，用的命令参数不够严谨，在特定条件下会匹配到写缓存模块。我重新改了脚本，加了--exclude=write_cache的参数，并且要求以后执行巡检前必须人工确认一次缓存状态。那天本来约了朋友吃饭，硬是泡到晚上九点才走。
三个月下来，我的手写笔记已经攒了37页A5纸。每页上方是故障现象，中间是排查步骤的“三草稿”——有时候画拓扑，有时候抄命令输出，有时候只是几个关键词：“别上来就重启”、“先看日志再动端口”。反面记的是那些让我踩过坑的设备型号和固件版本，比如“H3C S6800，版本R2612，特定条件下MAC地址表抖动，需升级至R2615”。
-
好拿网-HN373.COm精选攻略:
- 三个月试用期转正总结 | 超市三个月试用期转正总结 | 地铁三个月试用期工作总结 | 超市三个月试用期工作总结 | 新员工三个月试用期转正工作总结 | 新员工三个月试用期转正工作总结
下一步我不打算列什么宏伟计划。先把那两台数据库老存储的固件升了，它们的BBU都已经报过两次警告。然后把防火墙切换的脚本里加上策略预热的步骤，确保九十秒的丢包窗口能压到十秒以内。最后把我那三十七页笔记里的高频坑整理成一份新人避坑指南，下次有新同事来，能让他少熬几个夜。
要说这三个月最大的收获，不是什么技术突飞猛进，而是学会了一条：出了故障，第一时间不是证明自己没错，而是找到它本该被拦住却没拦住的那个环节。那个环节往往不是系统，是人——要么是我没看文档，要么是流程没写清楚，要么是巡检脚本少了一个参数。承认这个，改掉它，比学会一万条命令都管用。
-
更多精彩的工作总结，欢迎继续浏览：工作总结