DataWorks DataService服务故障分析报告：安监管理平台API调用异常导致服务宕机

DataWorks DataService服务故障分析报告：安监管理平台API调用异常导致服务宕机

一、基本情况

数据服务（DataService），属于阿里云产品DataWorks服务之一，主要提供API托管、鉴权、授权和管理等功能，提供快速将数据生成API接口的服务，供外部调用，直接对接API网关服务。

二、异常现象与影响范围

2023年1月11日08:09分总部大数据中心发现DataService服务容器不到终态，08:30分左右陆续有湖南省公司、冀北省公司、浙江省公司反馈api接口调用不通，9点15分完成服务JVM堆内存扩容和拉黑安监管理平台api后故障恢复，总影响时长66分钟。

受影响省公司详述：

• 总部：网上电网系统反馈服务调用api接口报错。
• 湖北省公司：云平台反馈有API接口调用504报错，业务系统未反馈业务有影响。
• 冀北省公司：云平台反馈有API接口调用504报错，业务系统未反馈业务有影响。
• 浙江省公司：云平台反馈有API接口调用504报错，业务系统未反馈业务有影响。
• 其他省公司无反馈。

三、检修经过及故障处置过程

2023年1月11日

• 08：09 【故障发生】大数据中心上报DataService服务两个容器tianji显示均为达终态，预计影响全国的api接口调用。
• 08：10 【故障发现】大数据中心专责上报故障至云运营中心运维处监控值守小组值班室。
• 08：11 监控值守小组受理故障，并开始电话通知到运维处组件运维小组、阿里运维负责人、故障接口人。
• 08：16 运维处相关故障处理人员上线，监控值守小组连接内网投屏开始排查。
• 08：19 发现DataService服务容器经常被tianji自恢复重新拉起，确认由于健康检查不通过导致。
• 08：23 开始确认是否由于业务高峰导致CPU、内存被打满导致容器异常触发tianji服务重启。排查发现容器CPU、内存使用率均为达到100%。
• 08：29 阿里研发人员上线，转变排查思路，进一步确认是有由于服务异常，重启未生效，导致tianji一直触发重拉。
• 08：36 由于早会原因，投屏人员从亦庄值班室切换至钢院运维专区。
• 08：41 完成投屏切换，完成申请执行重启操作，重启DataService服务
• 08：50 实时打印服务启动日志，未发现报错，确认服务启动正常。分析组件逻辑，怀疑是由于业务请求过多时会占用程序JVM堆内存，导致JVM堆内存不足，最终造成DataService服务异常。
• 09：00 【初因定位】查看服务jvm堆内存使用情况，发现有频繁的full GC。确认故障直接原因，开始制定应急方案。
• 09：03 确定应急处置方案，一是将jvm堆内存从4G扩容到8G，二是建议客户将调动量大的api临时限流，降低压力。
• 09：09 【恢复执行】完成其中一台的jvm内存扩容。
• 09：12 大数据中心反馈限流一个api调用量大的ip。
• 09：14 完成剩余一台的jvm内存扩容，服务状态逐步正常。
• 09：15 【故障恢复】上游ApiGateway监控504占比开始逐步减低，200占比开始恢复。后台查看日志显示调用恢复正常。
• 09：23 湖北省公司反馈api调用504也开始恢复。
• 09：40 放开限流的api网络，问题未复现，业务确认恢复。

四、原因分析

业务侧api请求调用失败保护机制有缺陷。安监管理平台api请求调用异常后的重试机制没加重试频率和次数限制，导致失败的请求一直请求向DataService服务，产生高频调用，最终将DataService服务的JVM堆内存占满，导致服务频繁产生Gull GC，上游ApiGateway产生大量504报错。

由于DataService服务属于中心化部署，省公司请求都需要经过总部DataService服务，所以对全网产生了影响。

原因补充：

• 安监管理平台api开始工作后监控截图如下：

• 其他服务接口调用延迟增高，调用量下降监控截图如下：

安监管理平台api开始工作后api总体调用延迟上升，调用请求下降，与故障现象一致。安监管理平台api频繁调用占用了大量服务资源。

五、整改及优化

1. 业务优化

优化应用api调用失败后的重试机制，限制重试次数，避免出现高频的请求压力。大数据中心已通知到项目组进行整改。

2. 产品优化

• 优化数据服务的请求保护机制，限制单个应用调用次数及频率，增加服务的健壮性，防止单个应用高频调用将整个DataService服务打挂。
• 优化数据服务的java线程保护机制，限制java线程数量，增加服务的健壮性，减少过高线程数带来的JVM堆内存耗尽后所产生的Full GC概率，从而防止整个DataService服务被打挂。
• 目前已安排监控值守小组对DataService服务凌晨JVM对内存进行评估，按照目前使用量建议继续沿用目前的8G规格，后续研发会在v3.14-sp012完成规格固化，防止重启后内存回滚至4G。

3. 监控优化

• 近期开发的“一分钟”故障发现监控，涵盖DataService服务状态外发告警，形成24小时外发的预警方式，提升运维故障发现效率，支撑安全生产故障快速发现的应急处置要求。
• 将DataService服务纳入重点服务中，添加服务JVM内存监控告警添加到“可观测”监控体系开发中，从而提升Base组件故障原因快速效率。

4. 流程优化

将特殊时间点的应急处理人员调配进行细化梳理，如早会等非工作时间，做到处理人员交接无缝隙对接，消除本次早上5分钟的处理人员切换时间损耗，提升故障应急效率，更新至《应急标准及规范》中。

总结

本次故障是由于安监管理平台api请求调用异常后的重试机制没加重试频率和次数限制，导致失败的请求一直请求向DataService服务，产生高频调用，最终将DataService服务的JVM堆内存占满，导致服务频繁产生Full GC，上游ApiGateway产生大量504报错。故障持续时间为66分钟，影响了湖南省公司、冀北省公司、浙江省公司等部分省公司的API接口调用。

为避免类似故障再次发生，建议进行以下优化：

1. 业务优化：优化应用api调用失败后的重试机制，限制重试次数，避免出现高频的请求压力。

2. 产品优化：优化数据服务的请求保护机制，限制单个应用调用次数及频率，增加服务的健壮性；优化数据服务的java线程保护机制，限制java线程数量，增加服务的健壮性，减少过高线程数带来的JVM堆内存耗尽后所产生的Full GC概率，从而防止整个DataService服务被打挂。

3. 监控优化：将DataService服务纳入重点服务中，添加服务JVM内存监控告警，形成24小时外发的预警方式，提升运维故障发现效率。

4. 流程优化：将特殊时间点的应急处理人员调配进行细化梳理，提升故障应急效率。