公众号|松华说|程序员都惧怕的故障域
  • 分享在京东工作的技术感悟,还有JAVA技术和业内最佳实践,大部分都是务实的、能看懂的、可复现的

扫一扫
关注公众号

程序员都惧怕的故障域

博客首页文章列表 松花皮蛋me 2020-06-03 08:53

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

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

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

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

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

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

到这里本文就要结束了,如果你阅读完只能记住一句话,我希望是:问题排查时,引入更多的信息,才能减少干扰,直击要害。好,我是梁松华,希望本文对你有所帮助。最后,欢迎关注我的公众号:松花皮蛋的黑板报。