故障处理的惯用思路

• 【报障来源及描述】
• 【明确之故障现象】
• 【定位分析并验证】
• 【处理方法与结果】
• 【经验教训和精华】

以上5段虽是我们故障报告的格式，但其实是总结了故障处理的惯用思路：

【报障来源及描述】

了解这些，是为了做形势分析。———这也是《5个优势思维》里边的第一条，对重要性和紧急性有个初步判断。

比如，老板报障的？付费客户报障的？客服收到大量投诉报障的？监控告警主动发现的？ 或是个别用户个别同事反映的？

【明确之故障现象】

对故障现象的本身明确清楚，是为了聚焦排障范围，也避免兜转一圈回来才发现方向查错（比如人家其实不是乐视主站挂了，而是百度QQ全都打不开）。 明确故障现象的方法就是问4个W：

• What ——— 具体现象是什么？有报错提示内容？同类对比正常吗？能提供操作方法或URL或截图或抓包？
• Who ——— 是谁发现类似现象？ 还有其他人吗？ 哪位方便我们联系抓包或测试？
• Where ——— 位置是在公司还是哪里？ 哪个型号终端？ 哪个版本？ 没绑定hosts吧？
• When ——— 什么时候发现的？ 一直这样吗还是突然变这样的？

【定位分析并验证】

首先需要定位：这只是个案？还是局部故障？还是全局故障？

• 分析方法1：手里有条件就立马快速上线，查看各个日志等
• 分析方法2：查看带宽、QPS、负载 的曲线图，通过环比+同比、观察变化的趋势和影响的幅度。如果带宽/请求数/连接数/负载出现陡升或陡降那很可能就是发生了故障，否则可能是个案或局部。
• 分析方法3：对比事发时间点的前后日志，按error_log 和access_log 中各字段归类排序取top10，找出规律共性（比如增长的请求或错误的请求被发现集中在某接口、某IP、某UA？）
• 分析方法4：缩小范围到某设备或某进程后，使用抓包工具分析，比如lsof、strace、tcpdump、ping、traceroute/tcptraceroute/mtr

有了分析推测后，再做相应调整。验证效果，观察各曲线变化及各日志的反馈。

【处理方法与结果】

故障的处理方法分短期和长期。

短期的调整需要使得当前故障快速缓解并恢复，不能等待影响扩散蔓延，必要情况就电话上级争取资源协调支持。

长期的优化方案可能涉及架构调整、扩容建设、功能开发改造等，需要投入较大的设备资源和人力资源。

【经验教训和精华】

唯有思维质量才是我们的核心竞争力，不是所谓的“经验”。

而善于总结经验教训，才能提升我们的思维质量。 否则，同类的坑你今天掉完，往后还会再掉进去的。