导航栏

×
申请书 > 工作总结 > 导航

(最新)工程部个人年终工作总结

又熬夜了。我把最后一台设备的日志归档完,靠在椅背上扫了一眼工单系统——今年经手的故障单,从#0124到#3071,一共四十七张。这个数字比去年少了十一张,但有几单的折腾程度,够我记一辈子。

最让我后背发凉的是开春那回。核心交换机,Cisco的那台老家伙,突然开始丢包。告警是下午两点零三分跳出来的,我当时正蹲在机房另一头给新服务器贴资产标签。手机震了三下,我拔腿跑过去。登录设备,show interface,端口错包计数在缓慢爬升。第一反应是带宽跑满了——去年年底我们就报过扩容,预算批下来才俩礼拜,还没来得及割接。可一看流量图,才38%。不是带宽的事。

那就查物理层。光功率,正常。温度,正常。我有点懵。把相邻端口的参数调出来对比,发现一个细节:故障口的光模块接收功率在-9.2dBm,隔壁正常的是-7.5dBm。差了两不到,按理说在阈值内。但那天下午机房空调刚好做轮巡停机,温度从22℃慢慢升到29℃。我盯着show interface transceiver的实时刷新,模块温度每涨一度,接收功率就往下掉0.5个dB。到了49℃的时候,功率直接跌到-15.8dBm,丢包率开始肉眼可见地飙升。换掉那个模块,一切恢复。

事后我写了段监控脚本,把每个光模块的温度、接收功率、电压做成联动阈值——单看哪个都在合格线,但三者同时漂移就必须预警。这脚本跑了半年,提前挖出四块濒临失效的模块。你说技术多高深吗?没有。就是那天蹲在机柜前,盯着刷新页面看了四十分钟,逼出来的。

还有一回,真是让人火大。二季度做数据库迁移,方案评审了三轮,测试环境跑了五遍,一切绿灯。上线后第三个小时,业务那边反馈某个边缘报表跑不出来。报错信息是“对象名无效”。我一看就知道完了——肯定是哪个存储过程里写了硬编码的链接服务器名。果然,开发同事三年前写了个定时任务,里头直接引用了旧服务器的四段式名称。我们的割接文档只要求改应用程序的连接字符串,压根没人想到去扫数据库对象内部的依赖。

那个晚上,我带着两个兄弟,从错误日志倒着往上查。先找到报错的存储过程,再用sys.sql_expression_dependencies视图把所有依赖对象拉出来,一个个看定义。后来发现这个视图抓不到动态SQL里的链接服务器,又不得不用全文检索在sys.sql_modules里搜'SELECT.*FROM\s+\[旧服务器\]'这类模式。折腾到凌晨四点,改了七个存储过程和一个视图。我那天在复盘记录里写了句很重的话:“方案评审如果漏了依赖扫描,就等于没评。”

现在每次变更前,我会强制跑一遍全库依赖检查,把结果打印出来人工过。打印,不是看屏幕——因为打印出来拿笔画圈,比在屏幕上扫两遍管用。这办法土,但管用。

说个真事。有天凌晨两点,我被值班电话叫醒,说某套系统的定时任务又崩溃了,连续第三天。远程看Windows事件日志,只有一行“服务意外终止”,没有任何异常堆栈。我抓了进程dump,用WinDbg慢慢啃,发现崩溃点在GDI+的字体渲染模块。再往前追,是某个报表生成任务调用了一个冷门的中文字体,这个字体在生成PDF时会不断分配内存画字形,画到第793页时内存碎片堆到临界值,底层库直接崩。为了验证,我在测试环境用循环脚本跑了二十遍,到第793页必崩,一页不差。解决方案很简单:换一个字体,或者每生成500页重启一次进程。我选了后者,因为字体是客户指定的,改不了。

这件事让我养了个习惯:每次疑难故障解决后,不光写解决方案,还要单独写一条“我当时错误的判断”。比如“不要想当然认为新设备就没有硬件暗病”“不要把系统日志里的警告当成废话”“不要在凌晨三点相信自己还记得某个参数”。这些写下来,比什么培训都管用。

今年系统可用性从去年的99.92%提到了99.95%。这0.03个百分点怎么来的?主要是两件事:光模块主动巡检从季度改成月度,以及把核心设备的配置备份从手动改成Git管理——后者帮我挡住了一次有人误删VLAN配置的低级错误。明年一季度,我打算再把备份加上配置语法检查,用pre-commit hook跑一遍show running-config的解析校验。这事不酷,但能防住那种“改个端口配错一个字母”的破事。

干这行久了就明白,没什么一劳永逸。每次平稳运行的背后,都是被故障扇过耳光之后长出来的记性。我现在最大的愿望,就是明年告警再响的时候,我能比今年少花半小时找到那个根因。半小时,够我回家给儿子讲个睡前故事了。

    更多精彩工作总结内容,请访问我们为您准备的专题:工作总结

文章来源://m.swy7.com/a/5325234.html

更多
L

猜你喜欢

更多
N

最新更新

更多
H

推荐访问