程序员都惧怕的故障域

程序员最怕的是异常告警，特别是产品反馈有大范围的用户投诉，身上焦虑激素分泌必然瞬间暴涨。稍不留神就会眉毛胡子一把抓，无法从全局角度分析告警的来龙去脉。而本次分享正是针对故障域这个话题展示一系列的分析，带你掌握问题排查的思路。

我们经常遇到的问题主要包括调用时延增高、异常返回码增多、数据库内存告警、基础依赖的连接数过高，更严重的是页面无法打开。这些问题又通常是因为网络波动、代码变更、数据库慢查询、请求超时后重试等等原因导致的。当毫无联系的功能集中触发告警的话，根据经验估算，很有可能是基础依赖的性能有所下降，比如某个数据库操作影响了数据库的性能，我们可以去数据库监控控制台验证我们的猜测，查看表锁、行锁、更新等调用量的突增情况，或者从活动会话中寻找可能触发严重慢查询的语句。可以看到，事故排查的方法论就是提出一个假设，然后想办法进行辅证或者排除，直到找到原因。这是一个将问题分层再拆解的过程。不过当系统复杂度较大时，我们还需要更多的信息减少干扰，才能快速定位和恢复。根据香农理论，引入更多的信息，才能减少不确定性降低信息熵，从而减少计算量。接下来我会进一步展开说明。

当我接收到产品转发给我的客诉聊天记录时，第一反应是能否复现，首先按照正常操作流程走一遍看看是个例还是全局性的问题，如果不能复现，说明可能是个例问题，或者是操作链路和用户的不一致，所以还需要问清楚用户在碰到问题前做了什么。这个是本文要讲的第一点也就是借助用户的信息。如果是全局性的问题，可能还得结合听云类的软件进行拨测，爬虫似地探测各地区到接入点的链路质量问题，判断哪些省份的哪些运营商受到了影响，进一步排除是否光纤专线故障，或者CDN个别节点上是否保存着过期的静态资源。这是在借助共性信息进行分析。

刚刚介绍的思路是站在模拟用户操作角度考虑的，我们还可以多问问自己，比如异常是否有规律性、最后一次对平台变更操作的时间和内容是什么、监控日记中是否有明显的错误信息，充分借助服务系统信息进行分析。我之前处理一个线上大量报警的问题，第一反应是数据库性能问题，但是查看监控后发现并不是这样的，数据库基础监控如CPU使用率和内存使用率都是正常的，此时又有不依赖数据库操作的监控触发了告警，然后我又去检查了下服务实例的基础监控，发现也是正常的，百思不得其解，最后在日记中发现了一些端倪，数据库操作无法获取到连接，反馈给运维后，发现是死锁导致的，最后强制终止死锁会活连接后才恢复。

其实还有一个很有用的信息来源。《奇葩说》节目的导师罗振宇分享过这么一个故事，大概意思如下，他的员工无法按时完成任务，员工委屈地说"找了很多人帮忙也无济于事"，罗老师反驳说"你没有找我啊，我就在你身后啊"。这个故事说的是学会求助，不要对上级知道问题有所排斥。

最后还要多提一点。异常虽然是恢复了，但是后续再出现时怎么能快速定位和解决，也是一个值得深思的问题。比如说某个服务在夜间某个时间段内频繁触发可用率告警，但是在白天基本不会出现，看似自愈了，但是要不要及时处理？这算不算是一个隐患呢？另外，我觉得很多人都干过这件事，包括我在内，就是服务实例内存频繁告警时快速重启恢复，但是没有保存现场，或者内存告警频率下降后干脆就不管了。正确的做法是保留个别实例不重启但是摘掉流量，留做标本，进一步判断是否文件流没有及时关闭、传输大对象等等原因导致了内存泄露，该优化还是要尽早优化。

到这里本文就要结束了，如果你阅读完只能记住一句话，我希望是：问题排查时，引入更多的信息，才能减少干扰，直击要害。好，我是梁松华，希望本文对你有所帮助。