工作总结
发布时间：2026-05-19第二周工作记录。
这周的工单系统记录我翻了三遍，不是找问题，是找规律。值班日志、变更记录、巡检脚本的输出，全摊在桌面上。第二周比第一周真实得多——设备跑满7x24小时后，那些实验室里永远测不出来的边界条件，一个一个往外蹦。
先说说周一凌晨那个告警。四点二十分，监控大屏跳红：核心交换机G1/0/12端口错包率超过阈值，紧接着数据库连接池耗尽告警跟上。值班同事先接手，我到现场是六点四十。按照常规打法，这种错包率异常第一反应是查光纤——看看弯曲半径是不是小于40毫米，或者接头上有灰。我蹲在机柜前用手电照了照，链路指示灯全绿，光模块收发光功率正常。那就换个思路。
我注意到一个细节：高错包的端口只连着一台新上线的日志采集服务器。这台服务器的验收是我上周五签的字，当时打了标准流，双向1G跑满，丢包率0.008%，端口协商强制写为千兆全双工。没毛病。但问了一圈，没人动过配置。我让值班同事查一下网卡驱动版本——出厂是2022年的，但装机时系统自动更新过内核到6.1。查出来果然有问题：旧版驱动对多队列的调度策略在内核升级后没适配，高并发小包场景下缓冲区溢出。
当时业务已经有投诉了，领导在群里催。我临时在交换机上对那个端口做了流量整形，把突发削平，五分钟内错包率从0.7%掉到0.02%。然后申请了半小时紧急变更窗口，直接编译新版驱动升上去。彻底恢复后错包率归零。事后我翻验收文档，发现我们只测了双向大流量和小包定速，没测随机突发。这个盲区我当天补了一条到验收模板里：“日志类、监控类设备，增加64字节小包+随机突发混合测试，持续10分钟。”并且把那条测试命令(pktgen -i eth0 -m 64 -b 100m -t 600)写进了附录。
周三下午有个事让我真想骂人。按照施工规范GB/T 50312，机柜内电源线和信号线间距不小于20厘米，绑扎带松紧要能塞进一根手指。我去机房巡检，看到新来的外包施工队把两台交换机的管理网线和PDU电源线扎在一起，死扣勒得紧紧的，线缆弯曲半径目测不到3厘米。我当场叫停。施工队长跟我扯，“之前别的机房都这么干，没出过事”。我直接拿出手机拍照片，打开规范文档截图，当着他面发到项目群里，@了项目经理和监理。然后让他全部拆掉重做，并且打印了三张规范配图贴在机柜侧面和施工区的墙上。这种事让人无奈——很多故障的根源根本不是技术难题，就是最基础的工艺没人盯。如果我不在现场抓到，过两个月开始出现偶发丢包，到时候查起来得浪费多少个通宵。
周四晚上十点，业务方反馈某个分区的查询越来越慢。我连上去一看，数据库从库延迟已经飙到800秒。主库压力正常，网络带宽也只用了30%，但从库的IO线程一直报“Waiting for log space”。用iostat -x 1一看，磁盘利用率100%，但是容量还剩60%。谁占的IOPS？iotop扫一眼，发现是台刚部署的Nginx，日志级别从error被人改成了debug，而且没做轮转。单日写入了187GB的小文件，把磁盘IO彻底打爆。这台Nginx是业务部门自己装的，没经过CMDB登记，没走资源申请流程。我们运维这边完全不知道。
处理倒是简单：systemctl stop nginx，find /var/log/nginx -name "*.log" -delete（这个命令执行的时候我手抖了一下，差点敲成rm -rf /var），然后改配置，重启数据库同步。延迟从800秒往回追的时候，我每隔五分钟跑一次show slave status\G，看着Seconds_Behind_Master一点一点往下掉，从800到600到300到50。整个过程两小时十七分钟。但真正的麻烦在后面——怎么防止业务部门再这么干？我第二天一早就拉着业务负责人开了个十分钟的短会，态度没软：以后所有新增服务必须先填CMDB申请单，否则网络和存储资源我们不给预留。他一开始说“就装个测试工具至于吗”，我把昨晚的故障截图和数据发给他，加了一句：“这个故障的工时成本折合大概四千块，你报销？”他没再吭声。会后我更新了运维规范，在第四条加了加粗的一行：“未经CMDB登记的服务，运维有权直接断网。” qX54.cOm
周五最后一项是老存储设备的质量验收。这台设备用了六年，这周做完数据迁移和业务切换。验收清单上我列了十一项，逐项打勾。其中有一项“热备盘激活测试”——模拟一块数据盘故障，看热备盘能不能自动顶替并重建。我用megacli -pdmarkmissing -physdrv[252:4] -a0强制拉掉一块盘。热备盘确实激活了，但重建速度只有45MB/s，而预期应该是100MB/s以上。查原因，用fdisk -l看分区对齐，发现4K扇区没对齐——老设备固件版本太旧，对高级格式化磁盘的兼容性有问题。升固件，再重建，速度跑到112MB/s。验收单上我在备注栏手写了一句：“所有存储类设备验收，必须增加parted /dev/sda unit s print检查扇区对齐，未对齐的不予通过。”
机房独白那段其实没什么浪漫的。周三晚上从库恢复那会儿，我一个人蹲在机柜后面，笔记本放在静电地板上，Console线连着服务器。等到Seconds_Behind_Master变成0的那一秒，监控弹出了恢复告警。我站起来，膝盖咔咔响，去饮水机接了一杯水。没心情看窗外，因为还要写故障报告、通知业务方、再去检查另外两个从库有没有类似隐患。等所有事做完，凌晨一点二十，我给值班同事发了条消息：“睡了，有事打电话。”然后关机回家。说实话那一刻没什么成就感，只是觉得又活过了一天。
回头总结这一周。六个故障工单，三个监控自动发现，两个业务方报的，一个是巡检撞上的。每个故障都能对到流程或规范的漏洞上。我把六个案例全部整理到一个复盘表里，新增了一列叫“能否在验收环节拦截”——四个能，两个不能。不能的那两个（Nginx日志问题和网卡驱动问题），我准备下周推动修改资源申请单模板，增加“驱动版本确认”和“日志策略配置”两个必填项。
第二周让我更清楚一件事：稳定性不是靠响应快堆出来的，是靠把每个验收步骤、每个布线要求、每个变更审核死磕到流程里，再配合对内核参数、驱动版本、扇区对齐这种细节的强迫症式跟踪。下周我打算把故障复盘表打印出来贴在工位隔板上，每天扫一眼。另外那个施工队返工后，我给他们每人发了一根冰棍，算是缓一缓关系。该硬的时候硬，该软的时候软，这活儿才能干下去。
-
推荐阅读:
第二周工作计划(通用十七篇)
实习第二周总结(汇编17篇)
会计顶岗实习第二周周记（汇编十四篇）
实习周记记录工作(汇总十七篇)
党员谈心谈话记录2024年最新第二季度工作(合集7篇)
第二学期安全工作总结(合集9篇)
-
欲了解工作总结网的更多内容，可以访问：工作总结
