去年十月那个凌晨，我被值班电话拽起来时，监控大屏上新闻发布系统的接口错误率已经从0.3%蹿到12%。第一反应不是看流量，而是让同事把最近半小时的nginx日志和数据库慢查询日志拖过来。那晚折腾到四点，最后定位到一个第三方供稿接口的证书过期，重试机制压根没覆盖证书异常这种场景。处理完后我靠在椅子上想，这种问题其实能提前三天发现——如果当时做了证书到期巡检的话。
干一线运维快五年了，新闻中心这套系统从上线到迭代，大大小小故障捅了二十几个篓子。下面挑三个典型的，把怎么踩坑、怎么填坑、填完又学到什么，全摊开说。
一、发布系统“雪崩”后的根因排查
那次故障发生在一个周一早高峰。编辑在群里喊“保存文章转圈转了一分钟”，接着502开始冒出来。登录服务器，top看到load average冲到30，php-fpm进程全部占满。我试着重启了一组进程，好了不到十分钟又瘫了。
按理说该扩容，但我多了个心眼。用strace -p 随便附到一个卡住的php进程上，发现全卡在curl_exec()。再查网络连接，到某个外部推荐引擎的端口上堆了几百个SYN_SENT。电话打过去，对方承认当天上线了新算法，接口响应从平时的200ms飙到8秒。我们这边连接池没设超时，请求全堵死了。
修复动作很快：第一，临时在代码里给那个接口加了三秒超时和熔断开关，超时直接走本地缓存；第二，把所有外部依赖拉清单，给每个调用都配上超时、重试（只对查询类接口）和降级逻辑；第三，监控上增加了外部接口P99响应时间的告警，阈值设500ms。
事后我写了份《外部接口容灾清单》，每个依赖明确写死超时值、重试次数、降级方案。那文档现在贴在Wiki首页，新人入职第一周就要背。另外每季度做一次混沌实验，随机断掉一个外部接口，看系统能不能自己扛住。这半年再没因为外部依赖挂掉导致发布卡顿。
二、一次“无声”的磁盘故障与数据完整性
某天编辑要调去年两会专题的配图，发现好几张打不开。我上存储系统一看，阵列显示健康，文件也能列出来，但读特定区域就报I/O错误。
这台存储用了四年，一直挺稳。我带了坏块扫描工具跑了两小时，发现有17个扇区重映射计数异常。阵列固件没报错，只是默默重试，导致读取变慢或者直接失败。说实话，查出原因那一刻我后背全是汗——因为前一个月我忘了测试备份脚本的恢复流程。
动作分三步：第一，从备份恢复受损文件，只丢了当天新增的三个小文件，还好不是重要稿件；第二，换掉故障盘重建阵列，同时把监控项里S.M.A.R.T.属性的Pending Sector和Reallocated Sector阈值从“默认忽略”改成“超过1就预警”；第三，把《存储设备日常巡检作业指导书》里每月一次的表面扫描改成每周一次，并且每次扫描后随机抽十个文件做读校验。
那个雨后的早晨，编辑组长打来电话说图片都确认没问题了。我没说“不客气”，而是告诉他：“这次运气好，备份脚本还能跑通。但恢复花了两个半小时，新闻要求是半小时内。下个月我要做一次离线冷备份演练，到时候可能要停读写十几分钟，提前跟你打招呼。”
三、直播推流花屏——交换机缓冲区配置的教训
今年两会报道，新闻中心做了一场高清直播推流。开播十分钟，画面开始出现马赛克和卡顿。编码器端显示正常，接收端也正常，中间经过三层交换机。
我当时的判断是网络丢包。登录核心交换机，用show interface counters 看错误计数，没发现CRC错误。又查了缓冲区命中率，发现某个端口的输出队列丢包计数在缓慢增长。原因是直播流是突发性的大包，交换机默认的缓冲区分配太小，瞬时队列塞满就丢。
解决方案不复杂：调整端口的tx-queue buffer size，把共享缓冲区的权重调高，同时给这个端口做了流量整形，限制突发速率。改完后用iPerf打了一小时流，丢包率从0.5%降到0。
教训是什么？别以为交换机买回来配置好VLAN和路由就完事了。新闻场景下流媒体、大文件传输这些突发流量，必须针对具体业务调缓冲区、调队列调度算法。我把这个案例写进了《网络设备配置基线》，以后所有交换机上架前都要跑一轮突发流量测试。
几点实打实的习惯
故障处理我坚持“先止血再查因”。业务高峰期别做什么深度分析，先切流量、降级、重启，保住发稿通道。事后必须出复盘报告，格式固定：时间线、根因、影响范围、改进措施、责任人、完成时限。十二个月攒了23份报告，每份都像资产一样归档。其中有一半的改进措施是真的执行到位的——我会每个月随机抽两份报告去现场验证，看该加的监控加没加，该改的代码改没改。
巡检这事容易走形式。监控图上一片绿就觉得没事，结果上月一次磁盘慢I/O导致数据库响应变慢，静态阈值没触发。我是手动对比“每秒读写次数”的周趋势才发现异常。后来把所有静态阈值改成了动态基线告警，系统自己学过去七天的数据，偏差超过三倍标准差就报警。
文档必须硬。每套系统的拓扑、配置参数、常见故障处理步骤，全用Markdown写进内部Wiki。比如那个证书过期的问题，我在Wiki上把“证书巡检”那一步从“每月检查”改成了“每周自动脚本跑一遍，过期前15天发邮件到钉钉群”，还在后面加了一行红色警告字：“别手填，用脚本”。
最后说句实在话
干这行别指望不出事，要练的是出事时能稳住，而且下次不再犯。今年虽然没出过大面积长时间中断，但小毛病从来没断过。每个故障都是一次压力测试，测试的不是系统，是我的应急能力和对细节的敏感度。新闻中心的工作不等人，稿子发不出去就是事故。这种压力下我养成一个习惯：任何变更前先在测试环境跑一遍，任何新设备上架前先做破坏性试验。多一次测试，少一次半夜被叫醒——这话不油，因为我这半年确实只被叫醒过两次，去年这个时候是七次。（通知范文吧 tv2288.coM）
-
需要更多的工作总结网内容，请访问至：工作总结
