故障恢复及定位-京东云开发者社区

首先，故障发生时最重要的是“恢复故障”，而不是“定位问题”，这点对于工程师来讲强调多少次都不为过，在很多情况下，工程师往往出于对解决问题的好奇心和好胜心导致在线上Debug定位问题。

那么故障恢复有没有章法可循呢？有的，下面我们就从常见的几种故障和应对方案聊一下。

### 1 故障恢复

#### 1.1 软件/硬件升级故障

首先，最常见的故障是“软件/硬件升级”导致的故障，比如我们开发需求上线后出现了一些大规模的线上故障，这种故障基本上占到60%左右，通常对于这种情况最简单且快速的处理办法是“回滚”，当然这个前提要建立在系统/接口设计要有足够的兼容性来保障（可参考Google API规范）。

所以一旦系统出现了因系统升级导致的故障，在兼容性设计前提下可以尽可放心的做回滚操作，这样能保证在最短时间内恢复系统，这也是为什么在接口设计过程中强调“兼容性”的重要原因。

#### 1.2 请求流量过大

第二种常见的故障场景是因为“请求流量过大”导致的系统负载过高，进而导致大量请求失败。针对这种情况我们常用的手段是“扩容”和“限流”，其中“限流”是保护手段，用来保障系统仍处于服务状态，并且不会将洪流蔓延到下游系统中，变成雪崩式的灾难；而“扩容”则是解决手段，毕竟流量大于系统的负载能力，只有通过扩容才能最终解决。

对于无状态的服务来讲扩容比较容易些，例如接口服务、MQ消费者等，我们很容易通过水平扩容达到扩大集群规模的目的，尤其现在有了Docker，很容易通过镜像拉起新的服务。但是对于有状态的服务则扩容则可能会更复杂一些，典型的例如MySQL、ClickHouse等数据库，往往这种服务垂直扩容（升级配置）更容易一些，而水平扩容则需要架构上的变化，需要引入分库分表中间件。对于使用云储存的MySQL类RDS来讲，垂直扩容不需要迁移数据，原理上来讲可以做到秒级，但是对于使用本地存储的RDS，则需要迁移数据，即便是垂直扩容也需要迁移数据，需要更长时间。

服务“降级”也可以做为一种保护手段变向达到目的，这通常需要业务上的提前约定，提前将一些掉用量较高的接口做好降预案，在达到触发条件时进行人工或自动降级。

当然，服务“限流”作为一种业务有损的保护方案，也是一种较为常见的措施，通常我们会根据调用方的等级等维度进行有损限流，或者为了保护系统自身，针对流量异常的调用，按照某种规则进行限流。目前市面上有很多较为成熟的限流组件，甚至可以做到按规则自动化限流，例如：Hystrix、Sentinel；另外，像在安全方面经常见到的“高防IP”其实也是限流的一种应用场景。

#### 1.3 软硬件环境故障

第三种常见故障场景是“软硬件环境故障”，其实在大规模集群组成的应用中，某一个节点的硬件故障也是比较常见的，这时我们的做法通常时“流量切换”，这种场景通常需要探活或者健康检查方面的支持。流量切换通常需要中间件方面的支持，例如后端系统系统发布的JSF服务，通常由注册中心提供了服务的注册和发现功能，能够很好的做到在某个节点出现故障宕机的情况下自动摘除不可用实例。Nginx做为常用的负载均衡方案，也提供了健康检查和摘除实例的方案。

另外，当遇到软件故障时“重启”也是常见的快速恢复手段。关于重启大法在很多情况下都是一种不争的玄学。当然，重启其实也是有科学依据的，毕竟软件的Bug无处不在，有很多情况下隐藏的及其深，导致并不容易复现，这种情况下我们只要给他一个指令，使其重新初始化运行也算是一种缓兵之计。像平时遇到的系统内存异常、线程异常等，都可以通过重启大法很好的快速恢复，甚至像致命的数据库慢SQL，也可以通过重启应用服务器的方式来释放连接恢复数据库的运行能力。

以上，是关于故障恢复的基本思考和总结，下面给出了我整理的思维导图供大家查看。

![](//img1.jcloudcs.com/developer.jdcloud.com/ed8d02b4-6472-44e5-8b93-44a090202a7e20220315141810.png)

### 2 定位原因

上面聊了很多故障快速恢复的思考，终于到了作为技术人最喜欢探究的原因环节了。

#### 2.1 软件Bug

首当其冲的是我们自己写的Bug，通常是一些逻辑错误或者是需求考虑不全导致的场景缺失，这种情倒是定位起来不算复杂，但是想在后续避免就要采用一些专业的技术手段，例如针对代码Bug，我们可以通过增加单元测试覆盖率的方法可以在编码过程中发现大部分Bug。又例如用户故事方法中的验收条件、可视化需求分析方法等一些专业手段，可以有效的降低场景遗漏和产研信息传递过程中的信息损失。关于需求分析方面的技巧以后有机会可以单独分享一篇文章，再此不展开讨论。

#### 2.2 与业务相关

这种情况最常见的是由于“流量大于预期，造成系统无法支撑业务”，例如对于微博来讲，某些热点突发事件导致的流量突增，或者我们大促过程中促销流量评估不准确、系统资源预备不足等导致的情况都可以归到这一类当中。这种情况如果有基础架构方面的支撑，如果可以做到弹性扩容可以最大程度的避免损失，像K8S在这方面已经有很好的支撑方案。如果无法做到自动弹性扩容，那只能通过最原始的手工方式进行扩容了，即便是在手工扩容方面，基于Docker的镜像部署也要远远优于手工部署软件包。

另一种情况是“异常流量”，通常是由于黑客DDos攻击所造成。这种情况下可以采取高防IP策略，尽可能的过滤掉异常流量，保证系统的稳定。当然，异常流量远不止黑客攻击，我曾经遇到过一次因为前端系统Bug，导致点击按钮事件在每次打开页面时重新注册，但老的注册并没有销毁，最终导致累加的情况，造成了人为的异常攻击，好在当时通过网关的请求日志、用户日志，很快的定位到了具体的用户，并最终确认了Bug。

#### 2.3 与依赖相关

首先是“外部依赖”故障，包含依赖的中间件、外部服务、基础云平台等等。通常来讲，这些基础服务是要保证自身的高可用的，否则一旦发生故障将会是致命伤害，通常来讲我们确实也没有什么更好的办法。以前我也见过一些项目做了中间件backup（例如mq发送失败时落库，改由worker发送），在遇到问题时做了切换或降级的准备。这种情况在系统高可用要求极高，同时使用了不太稳定或没有把握的中间件时可能需要这么做，但这种方式成本太高，我是极不推荐的。我更倾向于在中间件不够稳定或没有足够信心时先让部分稳定性要求不那么高、出现问题影响没那么大的系统优先当小白鼠试验。

另一个就是与外部相对应的“内部依赖”了，主要体现在系统自身依赖的三方库Bug、配置类错、数据库异常等。三方依赖库Bug在常规系统开发中并不多见，大部分开源软件稳定版本还是比较可靠的，但是如果运气不好，一旦碰上，排查起来就像对复杂了，这可能需要你对该软件非常熟悉，同时需要一定的阅读源码的能力。当然，大部分情况下可以先尝试Google一下问题，基本上你能遇到的问题其他人早已遇到过了，如果还没有其他人遇到，也是一个很好的提交PR的机会。

配置类错误通常都是由于团队疏忽导致，排查难度为中等，通常需要结合日志来进行排查。

对于数据库异常，因为通常原因都是因为系统请求导致的，所以将其归类到内部依赖中，最常见的是慢SQL，这也是事故最高发的场景之一，甚至在大促备战时我们会讲“只要搞定数据库慢SQL，大促就不会有问题”，同时每年也会有慢SQL专项优化，可想而之这种情况的严重性。另外QPS、TPS较高、连接数暴涨等原因也较为常见，这些都需要好的数据库监控平台监控和管理。

#### 2.4 与环境相关

与环境相关的故障场景也较为常见，例如网络波动、软硬件兼容性问题、操作系统时钟错误等等。对于其中一部分场景，可以通过监控系统来报警和判断，另外一些可以通过标准化和统一化来尽可能避免，例如统一系统镜像版本，度减少个性化配置，降低出现偶发问题的概率。

下图是我关于定位问题相关思维导图，供大家参考。

![](//img1.jcloudcs.com/developer.jdcloud.com/872d7403-9bf8-4637-8d35-f7fedfa0f2d120220315141927.png)

### 3 展望未来

经过上面的讨论，大家一定对故障恢复和定位原因有了一个整体的认识。其实想做到故障快速恢复一定离不开智能监控系统的支持。目前的监控更多停留在主动监控层面，指标预警也是固定方式，并不具备提前发现和预警的机制。相信未来，会有更多的基于机器学习和人工智能的智能监控系统来辅助我们提早发现问题和风险，这方面业内也已经有了很多尝试甚至实际应用场景。

最后，关于以上内容如果你只能记住一件事，那请记住：遇到故障优先尝试回滚、重启、扩容。

------------

###### 自猿其说Tech-京东物流技术与数据智能部
###### 作者：郭峰