稳定性建设-交易中台-故障sop
准备工作
|
check |
检查项 |
备注 |
|---|---|---|
|
检查是否在上下游的问题反馈群中，如若不在请联系 @韩建起 、oulong、lichuangjian、zhengyin02及时加入 |
|
|
|
检查公司VPN是否能正常使用（在家值班额外关注） |
参考： |
|
|
检查使用的基础组件和工具平台(服务治理、监控运维、消息队列等)是否有权限 |
以上没有权限可找各组负责人进行添加 |
|
|
提前检查是否能收到报警（大象、短信、电话、邮件），电话畅通随时保持联系 |
无法收到报警联系对应系统负责人 值班期间手机不要停机，不要开飞行模式 |
|
|
检查是否已经可以登录组内所有机器，使用系统日志查看、数据库查询等 |
跳板机参考：新美大跳板机使用指南-北京 |
怎么看
|
分类 |
细分项 |
关键指标 |
备注 |
|---|---|---|---|
|
大盘类 |
|
重点关注 |
|
|
关键业务指标及接口TP90&TP99 |
重点关注 |
||
|
|
|
||
|
|
|
||
|
|
||
|
监控平台 |
P0、P1，P2报警 Problem（Error、Long-Service） Transaction（QPS、TP999） 接口调用量（异常QPS） 直连商家收单监控 (是否还有效) |
重点关注P0，P1报警 |
|
|
视情况而定一般用于Cat无法满足的场景 主机（CPU、IO、MEN、NET） 宿主机 JVM（Thread、GC） |
重点关注P0，P1报警 |
||
|
error日志分析 流量来源分析 节点管理，流量配比，一键扩容等 |
|
||
|
消息生产&消费堆积情况，现有交易中台topic汇总 |
调整积压报警阈值和报警接收人 |
||
|
主从延迟，慢查询 |
调整超时和连接池大小 |
||
|
下单、申请支付、出票等场景的失败比例和抽样订单 |
看能不能收到 fdp 的告警 |
||
|
其他 |
大象 |
|
公司平台各个群 |
|
短信 |
P0，P1报警 |
|
怎么做
workflow
操作工具和平台
|
工具平台 |
应对那些问题 |
如何操作 |
备注 |
|---|---|---|---|
|
禁用节点流量 |
|
|
|
|
|
调整节点流量 |
|
|
|
|
thrift接口限流 |
|
必须指定被限流业务方的appkey |
|
|
调整机房流量分配 |
|
|
|
|
一键扩容机器 |
|
|
|
|
hulk自动扩容机器 |
|
|
|
分等级业务降级 |
|
||
|
|
分等级接口降级 |
||
|
|
核心http接口限流 |
||
|
优惠精细化降级 |
|||
|
使用详情参考：solution-修复工具使用说明 |
按时间段修复出票延迟订单，对应修复场景：
|
1、登录solution网址：http://solution.trip.sankuai.com/solution/query/ordercenter 2、选择15修复项，输入订单号，多个订单号中间以逗号隔开； 3、单击提交后，进入solution中的订单详细查询中，查看该订单的状态为成单，则修复成功； |
修复工具直接调用的是order项目的miniflow机器即：dx-trip-trade-order03@10.32.78.162 |
|
|
按订单号修复出票延迟订单，修复场景同上； |
1、登录solution网址：http://solution.trip.sankuai.com/solution/query/ordercenter 2、选择17修复项，输入响应的时间；(时间段跨度不超过一天) 3、单击提交后，登录miniflow机器，搜索日志“按时间维度修复”，查看需要修复的订单，然后在solution中确定该订单的状态为成单，则修复成功； |
修复工具直接调用的是order项目的miniflow机器即：dx-trip-trade-order03@10.32.78.162 |
|
|
修复核销，中台核销成功，业务线核销失败 |
|
|
|
|
修复核销流水 |
|
|
|
|
退款相关问题 |
|
|
|
【推荐】 solution |
修复订单未推送美团/点评订单中心问题
|
|
|
|
|
|
|
应急手段
优先级高低代表紧急程度和影响范围，颜色代表出现概率
|
优先级 |
应急手段 |
应对场景 |
如何操作 |
操作后影响 |
|---|---|---|---|---|
|
P0 |
调整节点流量 |
单节点压力过大，比如 1）流量不均衡，单节点流量过大 2）GC严重 3）CPU等资源压力大 |
|
|
|
P0 |
禁用节点流量 |
单节点故障，比如 1）节点挂了 2）未知原因接口出错率持续很高 2）GC异常严重 3）线程block严重等 |
|
|
|
P0 |
重启Java进程 |
单节点异常，比如 1）GC异常，需要重启 2）线程block较多，需要重启等 |
|
|
|
P0 |
关闭Java进程 |
节点故障，比如单个机器未知原因失败率升高 |
命令行关闭：切换到sankuai账号下，sudo svc -d ${serviceName} |
|
|
P1 |
一键扩容机器 |
接口流量过大，超出处理能力，集群负载过高； 如果集群已经处于不可用状态，先限流再扩容 |
|
|
|
P1 |
按时间段修复出票中订单 |
收银台和直连都回调了回来，但是出票失败 |
http://solution.trip.sankuai.com/solution/query/ordercenter 使用详情参考：solution-修复工具使用说明 |
|
|
P1 |
按订单号修复出票中订单-1 |
发起了直连支付，但是直连没有回调回来或者回调失败，导致的未出票 没有发起直连支付，导致的未出票 |
http://solution.trip.sankuai.com/solution/query/ordercenter
使用详情参考：solution-修复工具使用说明 |
用户无法下单 |
|
P2 |
thrift接口限流 |
接口流量过大，超出处理能力，集群负载过高 |
|
|
|
P2 |
一键降级门票订单详情 |
|
两种可行操作：建议第二种 |
用户无法看订单详情 |
|
P2 |
一键降级填单页优惠入口 |
|
红包与潘多拉同时降级： https://mbop.sankuai.com/#/service/detail/flow?appkey=com.sankuai.trip.trade.order&env=prod
|
用户无法使用优惠 是否需要降级文案？ |
|
P2 |
一键降级潘多拉优惠入口 |
|
https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.order&env=prod |
|
|
P2 |
一键降级酒旅红包优惠入口 |
|
https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.order&env=prod |
|
|
P2 |
一键降级限购功能 |
检索服务完全不可用 |
|
商家限购功能失效 |
|
P2 |
一键降级门票锁库存 |
锁库存接口完全不可用 |
(其他业务线在 lv3-高 分组中) |
门票不校验库存 |
|
P2 |
抢购保护
|
|
https://mbop.sankuai.com/#/service/detail/flow?appkey=com.sankuai.trip.trade.order&env=prod |
随机拒流 抢购商品的deal能否收集到 |
|
P2 |
Level-1 业务降级 |
集群负载过高，或者DB负载过高，超过5分钟未定位具体原因 |
https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.order&env=prod https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.center&env=prod |
|
|
P2 |
Level-1 接口限流 |
集群负载过高，或者DB负载过高，超过5分钟未定位具体原因 |
https://mbop.sankuai.com/#/service/detail/flow?appkey=com.sankuai.trip.trade.order&env=prod |
|
|
P2 |
Level-2 业务降级 |
集群负载过高，降级Level-1之后未缓解 |
https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.order&env=prod https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.center&env=prod |
|
|
P2 |
Level-2 接口限流 |
集群负载过高，降级Level-1之后未缓解 |
https://mbop.sankuai.com/#/service/detail/flow?appkey=com.sankuai.trip.trade.order&env=prod |
|
|
P2 |
Level-3 业务降级 |
集群负载过高，无法对外提供服务 |
https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.order&env=prod https://mbop.sankuai.com/#/service/detail/breaker?appkey=com.sankuai.trip.trade.center&env=prod |
|
|
P2 |
Level-3 接口限流 |
集群负载过高，无法对外提供服务 |
https://mbop.sankuai.com/#/service/detail/flow?appkey=com.sankuai.trip.trade.order&env=prod |
|
|
P3 |
美团/点评订单中心补单 美团/点评UGC补单 |
MQ发送异常或者降级 MQ消息堵塞 |
http://solution.trip.sankuai.com/solution/query/ordercenter |
|
|
P3 |
订单号生成服务启动 |
ordercenter项目mac_info表过大（超过256条数据），导致新扩容的服务器启动失败 |
1.删除mac_info表中无用数据 delete from mac_info where id in (X,Y) (X和Y为需要删除的id） 2.调整mac_info表AUTO_INCREMENT属性 alter table mac_info AUTO_INCREMENT=X (X为mac_info表主键id下一个值） 3.最后再发布服务 |
|
|
P3 |
删单恢复 |
用户误删单要求恢复 |
http://solution.trip.sankuai.com/solution/query/ordercenter 该修复任务执行后会自动补单 |
|
|
P3 |
对Cellar降级 |
cellar出现故障，长时间不不能恢复 |
事件记录丢失且无法失败重试 |
|
|
P4 |
保存机器现场 |
GC异常，线程block，线程deadlock等 |
curl -fsSL http://dx-trip-trade-solution01.dx.sankuai.com:8090/tools/dump.sh > dump.sh 在sankuai账号下执行 sh dump.sh |
|
|
P4 |
日志清理 |
机器磁盘容量不足 |
cat /dev/null > logfile 优先清理时间早、级别低的日志 |
|
|
P4 |
对trip-schedule降级 |
order项目向trip-schedule提交任务执行延迟时间 |
order mcc：tripScheduleJobRetryInterval=2000,120000 order流控：qps_ts_job=20 向ts提交任务执行时间延后2s，如果提交任务qps高于20，延后时间增长到2min |
|
|
|
|
|
||
|
|
|
|
故障处理SOP
机器和网络故障
节点挂了/网卡异常/其他原因不可用
-
现象
falcon报出节点存活异常报警节，或tcp loss等 -
影响
分发到该节点的流量无法处理等 -
如何处理
1）反馈到交易群
2）通过OCTO禁用节点，【服务详情】→ 【服务提供者】→ 【节点状态】
注意：thrift和http都要禁用 该节点上所有端口都要禁用3.1）【推荐】通过plus关闭服务功能，停止提供服务
3.2）如果plus无法正常关闭服务，还可以登录到机器停掉进程，停掉进程的命令：sudo svc -d ${serviceName}
${serviceName}可以到/service目录下找，如下所示代码块bash[hanjianqi@set-gh-trip-trade-order-test28 ~]$ sudo -iu sankuai[sankuai@set-gh-trip-trade-order-test28 ~]$ cd /service/[sankuai@set-gh-trip-trade-order-test28 service]$ lscplugin falcon-agent kms_agent log_agent log_agent_file log_io plus_agent trip.trade.order[sankuai@set-gh-trip-trade-order-test28 service]$ jps2473 Bootstrap2989 Jps[sankuai@set-gh-trip-trade-order-test28 service]$ sudo svc -d trip.trade.order[sankuai@set-gh-trip-trade-order-test28 service]$ jps3124 Jps注：停止进程 sudo svc -d ${serviceName}
启动进程 sudo svc -u ${serviceName}
重启进程 sudo svc -t ${serviceName}
某个IDC网络拥塞
-
现象
RPC访问特定IDC下节点大量超时或异常 -
影响
分发到异常IDC节点的流量处理异常 -
如何处理
1）反馈到交易群、故障通知群和SRE群
2）通过OCTO一键扩容其他IDC节点，保障集群容量正常
如果DX机房故障，扩容GH机房（YF机房属于BJ1中心，DX和GH属于BJ2中心）
如果GH机房故障，扩容DX机房
如果YF机房故障，扩容DX和GH
3）通过OCTO禁用该IDC下所有节点，注意：thrift和http都要禁用 该节点上所有端口都要禁用
磁盘容量不足
-
现象
falcon磁盘容量不足报警 -
影响
日志写入失败 -
如何处理
1）反馈到交易组大象群
2）确定是日志导致磁盘空间不足，执行 cat /dev/null > logfile
3）非程序日志文件导致磁盘空间不足，参考节点异常的处理方案，最后反馈给SRE处理
单台机器CPU压力过大
-
现象
loadaverage报警 -
影响
接口响应超时慢，超时 -
如何处理
1）反馈到交易组
2）排查是否GC异常，如果是参考【单台机器GC异常】处理手段。排查手段：cat和falcon的gc报警，falcon的gc指标监控，cat的gc指标监控
3）如果GC正常，排查是否流量异常。如果流量明显高于其他机器，则通过OCTO调小节点流量权重
注意：thrift和http都要调整， 该节点上所有端口都要调整
4）如果流量也正常，直接下掉这个机器。先在OCTO上禁用节点，然后通过plus关闭服务
注意：thrift和http都要禁用， 该节点上所有端口都要禁用
大量机器CPU压力过大
-
现象
大量机器 load.average报警 -
影响
业务流程处理缓慢，很影响业务 -
如何处理
1）反馈到交易组和故障通知群
2）如果已经影响到业务，一键降级非核心level-1接口和非核心level-1功能，视情况决定是否降级level-2接口和level-2功能
3）通过octo一键扩容机器
3）如果是有特定某个接口流量异常增长，通过CAT先定位异常增长接口，然后通过CAT 【RPC】→ 【提供RPC服务】找到调用方appkey，通过appkey在OCTO上找到服务负责人，电话对方负责人处理跟进
基础类故障
单台机器GC异常
-
现象
falcon和cat出现gc time异常持续报警，或fullgc持续报警 -
影响
业务请求处理缓慢，访问tair，squirrel，db等外部依赖超时，DB连接池被耗尽等 -
如何处理
1）反馈到交易群
2）则通过OCTO把流量权重调整到0。注意：thrift和http都要调整， 该节点上所有端口都要调整
3）登录到机器，执行以下命令保存机器现场（如果solution机器down掉，按照非业务性异常时系统场景保存自动化脚本执行）代码块bash[hanjianqi@set-gh-trip-trade-order-test28 ~]$ sudo -iu sankuai[sankuai@set-gh-trip-trade-order-test28 ~]$ curl -fsSL http://dx-trip-trade-solution01.dx.sankuai.com:8090/tools/dump.sh > dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sh dump.sh4.1）【推荐】安全重启服务
4.2）如果plus无法安全重启服务，可以登录机器重启java进程，在sankuai账号下执行 sudo svc -t ${serviceName}命令
注意：记得通过jps看下Bootstrap进程号是否更新，确认重启成功代码块bash[sankuai@set-gh-trip-trade-order-test28 ~]$ cd /service/[sankuai@set-gh-trip-trade-order-test28 service]$ lscplugin falcon-agent kms_agent log_agent log_agent_file log_io plus_agent trip.trade.order[sankuai@set-gh-trip-trade-order-test28 service]$ jps2473 Bootstrap2989 Jps[sankuai@set-gh-trip-trade-order-test28 service]$ sudo svc -t trip.trade.order[sankuai@set-gh-trip-trade-order-test28 service]$ jps5138 Bootstrap3124 Jps
大面积机器GC异常
-
现象
大量机器出现 gc time异常持续报警，或fullgc持续报警 -
影响
业务请求处理缓慢，访问tair，squirrel，db等外部依赖超时，DB连接池被耗尽等 -
如何处理
1）反馈到交易组和故障通知群
2）如果已经影响到业务，一键降级非核心level-1接口和非核心level-1功能，视情况决定是否降级level-2接口和level-2功能
3）通过octo一键扩容机器
4）登录到一台GC异常机器，执行以下命令保存机器现场。（如果solution机器down掉，按照非业务性异常时系统场景保存自动化脚本执行）代码块bash[hanjianqi@set-gh-trip-trade-order-test28 ~]$ sudo -iu sankuai[sankuai@set-gh-trip-trade-order-test28 ~]$ curl -fsSL http://dx-trip-trade-solution01.dx.sankuai.com:8090/tools/dump.sh > dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sh dump.sh5）如果未恢复，且仍在影响业务正常运行，一键降级level-3接口，逐个机器重启java进程，再逐步按比例放开流量
单台机器线程block
-
现象
falcon或cat报警 jvm.thread.block -
影响
-
如何处理
1）反馈到交易群
2）则通过OCTO把流量权重调整到0。注意：thrift和http都要调整， 该节点上所有端口都要调整
3）登录到机器，执行以下命令保存机器现场（如果solution机器down掉，按照非业务性异常时系统场景保存自动化脚本执行）代码块bash[hanjianqi@set-gh-trip-trade-order-test28 ~]$ sudo -iu sankuai[sankuai@set-gh-trip-trade-order-test28 ~]$ curl -fsSL http://dx-trip-trade-solution01.dx.sankuai.com:8090/tools/dump.sh > dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sh dump.sh4.1）【推荐】安全重启服务
4.2）如果plus无法安全重启服务，还可以登录机器重启java进程，在sankuai账号下执行 sudo svc -t ${serviceName}命令
注意：记得通过jps看下Bootstrap进程号是否更新，确认重启成功代码块bash[sankuai@set-gh-trip-trade-order-test28 ~]$ cd /service/[sankuai@set-gh-trip-trade-order-test28 service]$ lscplugin falcon-agent kms_agent log_agent log_agent_file log_io plus_agent trip.trade.order[sankuai@set-gh-trip-trade-order-test28 service]$ jps2473 Bootstrap2989 Jps[sankuai@set-gh-trip-trade-order-test28 service]$ sudo svc -t trip.trade.order[sankuai@set-gh-trip-trade-order-test28 service]$ jps5138 Bootstrap3124 Jps
大面积机器线程block
-
现象
-
影响
-
如何处理
1）反馈到交易组和故障通知群2）如果已经影响到业务，一键降级非核心level-1接口和非核心level-1功能，视情况决定是否降级level-2接口和level-2功能
3）通过octo一键扩容机器
4）登录到一台异常机器，执行以下命令保存机器现场。（如果solution机器down掉，按照非业务性异常时系统场景保存自动化脚本执行）代码块bash[hanjianqi@set-gh-trip-trade-order-test28 ~]$ sudo -iu sankuai[sankuai@set-gh-trip-trade-order-test28 ~]$ curl -fsSL http://dx-trip-trade-solution01.dx.sankuai.com:8090/tools/dump.sh > dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sh dump.sh5）线程block异常如果未恢复，且仍在影响业务正常运行，一键降级level-3接口，逐个机器重启java进程，再逐步按比例放开流量
单台机器thrift线程池满或者workQueue满
-
现象
falcon报警，thrift线程池或workQueue即将耗尽 -
影响
拒绝请求，或者请求被排队不能及时处理 -
如何处理
1）反馈到交易群
2）则通过OCTO把线程池满的thrift端口权重调小
3）通过cat或octo排查是否有流量异常徒增、流量分配不均匀、gc异常、cpu压力大等
大面积机器thrift线程池耗尽或者workQueue满
-
现象
falcon报警，thrift线程池或workQueue即将耗尽
接口耗时陡增 -
影响
拒绝请求，或者请求被排队不能及时处理 -
如何处理
1）反馈到交易群和故障通知群
2）在弹性工程，一键降级非核心http接口
3）通过octo一键扩容机器
4）按比例逐步放开level-1 http接口流量
5）排查具体原因，是否流量陡增，流量分配不均，或者其他原因
单台机器Jetty线程池耗尽
-
现象
报警jetty线程池资源不足
http接口耗时陡增 -
影响
http接口耗时上涨，拒绝http部分请求 -
如何处理
1）反馈到交易组
2）通过octo将http端口流量权重调小，注意：是提供http服务的端口
3）通过cat或octo排查是否有流量异常徒增、流量分配不均匀、gc异常、cpu压力大等
大面积机器Jetty线程池耗尽
-
现象
大量机器报警jetty线程池资源不足
http接口耗时陡增 -
影响
http接口耗时上涨，拒绝http部分请求 -
如何处理
1）反馈到交易群和故障通知群
2）在弹性工程，一键降级非核心http接口
3）通过octo一键扩容机器
4）按比例逐步放开level-1 http接口流量
5）排查具体原因，是否流量陡增，流量分配不均，或者其他原因
存储组件故障
单台机器DB连接池耗尽
-
现象
cat报警org.apache.tomcat.jdbc.pool.PoolExhaustedException -
影响
-
如何处理
1）反馈到交易组
2）则通过OCTO把流量权重调整到0。注意：thrift和http都要调整， 该节点上所有端口都要调整
3）确认是否GC或thread异常，如果是，保存现场，然后重启java进程代码块bash[hanjianqi@set-gh-trip-trade-order-test28 ~]$ sudo -iu sankuai[sankuai@set-gh-trip-trade-order-test28 ~]$ curl -fsSL http://dx-trip-trade-solution01.dx.sankuai.com:8090/tools/dump.sh > dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sh dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sudo svc -t /service/trip.trade.order
大面积机器DB连接池耗尽
-
现象
大面积机器cat报警org.apache.tomcat.jdbc.pool.PoolExhaustedException -
影响
-
如何处理
1）反馈到交易组和故障通知群
2）如果已经影响到业务，一键降级非核心level-1接口和非核心level-1功能，视情况决定是否降级level-2接口和level-2功能
3）通过octo一键扩容机器
4）按比例逐步放开level-1 http接口流量，关闭非核心功能业务降级开关
5）排查具体原因，是否流量陡增，依赖超时，或者其他原因
DB主从延迟过大
-
现象
falcon报警主从延迟（需要找DBA添加报警权限） -
影响
-
如何处理
1）反馈到交易组和DBA群
2）排查主从延迟原因是写入量过大，还是读过大，或者是其他原因。
3）如果写入量大导致，直接对下单接口限流，限流操作入口；
如果读过大导致，通过CAT排查读流量最大接口，在OCTO上直接对thrift接口限流
4）如果是大量慢查询，或者其他原因导致，联合DBA排查处理
单台机器DB读写超时
-
现象
CAT报警 mysql因超时导致的失败率上升 -
影响
-
如何处理
1）反馈到交易组
2）一般是由机器自身原因导致，排查GC，CPU，内存指标等。
3）如果流量分配不均，单机流量比较高或者单机GC异常、CPU压力大灯，则先通过octo一键扩容扩一台机器，然后禁用异常机器流量，保存现场，并重启代码块bash[hanjianqi@set-gh-trip-trade-order-test28 ~]$ sudo -iu sankuai[sankuai@set-gh-trip-trade-order-test28 ~]$ curl -fsSL http://dx-trip-trade-solution01.dx.sankuai.com:8090/tools/dump.sh > dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sh dump.sh[sankuai@set-gh-trip-trade-order-test28 ~]$ sudo svc -t /service/trip.trade.order
大面积机器DB读写超时
-
现象
大面积CAT报警 mysql因超时导致的失败率上升 -
影响
-
如何处理
1）反馈到交易组和故障通知群
2）如果影响到下单、支付、核销、退款业务，一键降级非核心level-1接口和非核心level-1功能，降级后仍不能恢复继续降级level-2接口和leve-2功能，如果仍不能恢复直接对下单、核销、退款接口逐步开启限流
3）一般是流量增加、某个接口流量增加，长事务中某个外部依赖耗时增加原因导致。排查流量情况，长事务中外部依赖耗时情况
大面积机器Cellar读写超时
-
现象
大面积CAT报警 cellar因超时导致的失败率上升 -
影响
-
如何处理
1）反馈到交易组和cellar-旅游酒店群2）各模块手动降级策略服务模块
手动降级开关
降级后影响
备注
trade.order
MCC上置event_retry_enable_v1开关为false
ED不再执行重试任务
请注意判断cellar的area，area=7
eventDriven
ED发送时不再执行Cellar操作
snapshot
cellar功能关闭
直接查询产品中心，有可能和下单时候的数据不一致。
请注意判断cellar的area,area=22
大面积机器Squirrel读写超时
-
现象
大面积CAT报警 squirrel因超时导致的失败率上升 -
影响
1）支付后无法风控
2）下单不对userId_dealId加锁，存在小概率重复下单、刷单风险。 -
如何处理
1）反馈到交易组和交易Squirrel群
2）如果未自动熔断，进入弹性工作目前使用squirrel的项目 squirrel链接 (截止到06-06下图列表为业务重点使用的)
服务模块
手动降级开关
降级后影响
备注
order
关闭squirrel功能
下单不对userId_dealId加锁，存在小概率重复下单、刷单风险
无法关单，走定时任务补偿
因为否是非核心流程，所以squirrel使用统一个集群
order-center
降级 squirrel 功能 (勿降级squirrel_hdel)
所有数据查询不走缓存直接查库，谨慎使用
trade-center
关闭squirrel功能
不进行风控校验
meilv
关闭squirrel功能
所有加锁功能失效，并发操作时可能发生资源争抢问题
refund
关闭squirrel功能
所有加锁功能失效，并发操作时可能发生资源争抢问题
大面积MQ消息读写超时
-
现象
1）Cat监控报警：发送消息队列积压报警（发送端线程池队列积压超过500）
2）大面积CAT报警，mq因超时导致失败率上升，耗时上升
3）MQ平台报警消息堵塞，用户投诉下单后在订单列表状态与订单详情页状态不一致；保险支付后在保险详情看不到出保状态
-
影响
1）同步订单状态到订单中心延迟，故障期间用户在订单列表的状态错误
2）保险无法出保
3）支付后返券无法通知到潘多拉
4）景+X状态支付状态无法同步到景+X业务
5）手工出票订单出票后无法自动核销 -
如何处理
1）反馈到交易组、故障通知群和Mafka酒旅运维群2）打开开关切换至RPC通道（有自动降级/熔断策略），注：该开关是配置在各个业务方熔断降级开关中的。
3）RPC备用通道Cat监控（EventDriven RPC备用通道Cat监控）
大面积ES故障
-
现象
1）CAT报警，es接口耗时/失败率飙升
2）CAT报警，下单限购错误量异常 -
影响
下单耗时增加、下单失败 -
如何处理
1）反馈到交易组、故障通知群
2）开启限购降级开关
核心依赖故障
收银台故障-申请支付token不可用
-
现象
CAT报警，prePayOrder接口失败率飙升，用户反馈在客户端无法调起支付页
CAT大盘监控“下单/支付比例”下降，CAT报警“用户支付比例下降” -
影响
下单失败 -
如何处理
1）反馈到交易组、故障通知群和支付平台业务方技术对接群
2）一键降级业务下单接口？（应该没有必要，降级和不降级对外的表现都是下单失败，这种情况下只能坐等收银台恢复故障；但是也有可能收银台要求业务方降低申请支付token的流量；如果这个接口被刷了怎么办）
收银台故障-客户端支付不可用
-
现象
CAT大盘监控“下单/支付比例”下降，CAT报警“用户支付比例下降” -
影响
下单失败 -
如何处理
1）反馈到交易组、故障通知群和支付平台业务方技术对接群
2）一键降级业务下单接口？（应该没有必要，降级和不降级对外的表现都是下单失败，这种情况下只能坐等收银台恢复故障；但是也有可能收银台要求业务方降低申请支付token的流量；如果这个接口被刷了怎么办）
收银台故障-支付回调不可用
-
现象
ordercenter/v1/pay/notice调用量下降
用户投诉支付后仍然展示未付款 -
影响
用户支付后，订单详情显示待支付 -
如何处理
1）反馈到交易组、故障通知群和支付平台业务方技术对接群
2）一键降级业务下单接口？（需要讨论是否可行，此时如果降级下单入口，直接无法下单；如果不降级下单入口，用户可以下单，但是会投诉）
降级操作入口：https://mbop.sankuai.com/#/service/detail/flow?appkey=com.sankuai.trip.trade.order&env=prod
收银台故障-退款回调不可用
收银台故障-退款不可用
收银台故障-查询退款不可用
用户中心故障
-
现象
-
影响
1）下单不可用，C端提示“请您登陆后再进行操作”（getUserByToken接口故障）
2）订单详情页不可用，C端提示“请您登陆后再进行操作”（getUserByToken接口故障）
3）门票退款、发票功能不可用，C端显示“请您登陆后再进行操作”（getUserByToken接口故障）
4）getUserById故障，填单页不展示默认游玩人，没有游玩人的下单会失败
5）getVirtualBindByDpUserId故障，点评订单列表、点评订单count，删除点评订单服务不可用 -
如何处理
1）反馈到交易组和MT用户中心-客户群
2）如果getUserByToken接口不可用，一键降级下单接口和订单详情页
平台订单中心故障
-
现象
-
影响
用户下单后在美团app订单列表看不到最新订单 -
如何处理
1）反馈到交易组、故障通知群和美团订单中心问题咨询
2）等订单中心回复后，在发起按时间段的补单操作
直连故障-下单接口不可用
-
现象
CAT报警 -
影响
-
如何处理
1）反馈到交易组、故障通知群和直连问题反馈/解决群
2）故障恢复后统计故障影响和损失
直连故障-支付接口不可用
-
现象
-
影响
用户支付后，订单卡在出票中状态 -
如何处理
1）反馈到交易组、故障通知群和直连问题反馈/解决群
2）如果大面积卡在出票中，超过X分钟不恢复，一键降级业务下单接口？（需要讨论是否可行，此时如果降级下单入口，直接无法下单；如果不降级下单入口，用户可以下单，但是会大量投诉）
3）故障恢复后，通过solution修复直连下单工具修复出票中订单
直连故障-下单回调不可用
-
现象
-
影响
-
如何处理
1）反馈到交易组、故障通知群和直连问题反馈/解决群
2）如果大面积下单失败，超过X分钟不恢复，一键降级业务下单接口？（需要讨论是否可行，此时如果降级下单入口，直接无法下单；如果不降级下单入口，用户可以下单，但是不会跳转到支付页面）
直连故障-支付回调不可用
-
现象
-
影响
用户支付后，订单卡在出票中状态 -
如何处理
1）反馈到交易组、故障通知群和直连问题反馈/解决群
2）如果大面积卡在出票中，超过X分钟不恢复，一键降级业务下单接口？（需要讨论是否可行，此时如果降级下单入口，直接无法下单；如果不降级下单入口，用户可以下单，但是会有大量投诉）
直连故障-refundOrder不可用
-
现象
-
影响
-
直连订单申请退款通知直连失败
-
-
如何处理
-
反馈到交易组、故障通知群和直连问题反馈/解决群
-
已接入trip-schedule重试，无需处理
-
直连故障-orderRefundNoticePartner不可用
同上
直连故障-退款回调不可用
-
现象
-
影响
-
直连商家同意退款，但执行退款失败
-
-
如何处理
-
反馈到交易组、故障通知群和直连问题反馈/解决群
-
有补偿任务，无需处理
-
直连故障-核销通知不可用
哥伦布故障-价格库存查询不可用/deal查询不可用
-
现象
-
影响
填单页不可用
用户下单失败 -
如何处理
1）反馈到交易组、故障通知群和哥伦布客户端使用群
2）如果下单大面积失败，超过X分钟不恢复，一键降级业务填单页接口和下单接口？（需要讨论是否可行）
哥伦布故障-库存更新不可用
-
现象
-
影响
用户下单失败 -
如何处理
1）反馈到交易组、故障通知群和哥伦布客户端使用群
2）如果下单大面积失败，超过X分钟不恢复，一键降级门票锁库存降级开关（不再锁定门票库存，但是在支付后还继续异步调用扣减库存）
3）记录下所有不走锁库存操作的订单，以备后续善后处理
产品快照故障
-
退款查询快照
-
进入meilv降级工作台，找到
开启降级开关
-
-
订单详情页查询快照
-
进入mbop-order-熔断降级，找到
开启降级开关
-
酒旅风控故障
-
填单页风控
风控接口抛出异常，开关会自动降级/熔断
如果风控策略出现问题或接口耗时影响服务可用性，可手动降级
-
下单风控
风控接口抛出异常，开关会自动降级/熔断
如果风控策略出现问题或接口耗时影响服务可用性，可手动降级
-
支付风控
风控接口抛出异常，开关会自动降级/熔断
如果风控策略出现问题或接口耗时影响服务可用性，可手动降级
squirrel故障
见上面：大面积机器Squirrel读写超时
rd 后续处理需要注意的两点：
-
（售后使用db锁进行兜底操作）如果db锁也出现异常，关闭db锁，此时transact无
ordercenter弹性工作台，开启db熔断。（如果手动开启，squirrel恢复后，关闭db锁）锁
-
如果 squirrel.hdel 发生降级。
会收到cat P2报警 “squirrel.hgetAll发生降级，需确认DB压力与squirrel恢复情况”。需要做以下2步确认。
-
查看db是否存在报警。dba查询qps是否在安全范围（单机QPS低于12000）。数据库查询qps 查看max
-
查看squirrel 是否恢复正常。访问dbus 故障收集系统 将故障批量执行，且成功。
如果db无法承受 或者 确认squirrel 恢复成功。则访问orderCenter 统一配置中心，将 cache_query_fallback_switch 置为false.
-
Cellar故障
见上面：大面积机器Cellar读写超时
潘多拉故障
-
现象
-
影响
填单页不展示潘多拉活动
下单时如果有潘多拉活动，则下单失败
支付后、消费后、评价后通知潘多拉失败 -
如何处理
1）反馈到交易组、故障通知群和酒旅营销平台技术沟通群
2）如果下单大面积失败，超过X分钟不恢复,且暂时无法定位问题，直接一键降级填单页优惠入口3）如果要在填单页过滤特定活动，使其不展示：
-
核心业务异常
用户侧-大面积下单失败
-
如何发现
1）CAT P0报警门票生单失败量2）FDP 下单失败报警
-
如何处理
1）反馈到交易组、故障通知群2）查看FDP-下单监控，查看是否集中在单一用户或单一deal，通过样例查找失败原因
3）查看下单失败cat监控，查看是否是正常的业务异常，如果不是，查看下单失败原因，执行对应SOP
用户侧-大面积出现付款后展示未支付
-
如何发现
1）CAT 支付率报警2）FDP 支付申请失败报警
-
如何处理
1）反馈到交易组、故障通知群2）查看FDP-支付申请监控，查看是否集中在单一用户，通过样例查找失败原因
3）查看申请支付失败cat监控，查看是否是正常的业务异常，如果不是，查看申请支付失败原因，执行对应SOP
-
-
用户侧-大面积出现付款后未出票
-
如何发现
1）CAT 出票率报警2）BCP 未出票报警
2）FDP 未出票报警
-
如何处理
1）反馈到交易组、故障通知群2）查看FDP-出票监控，查看是否集中在单一deal，与直连同学进行沟通确认
3）查看出票延迟cat监控
用户侧-大面积出现无法核销
用户侧-个别用户出现无法核销
故障预防措施
业务容量风险预防
-
接入hulk，根据资源使用率动态扩缩
-
ordercenter动态扩缩有风险，数据库表中最多支持127个机器
DB主库读风险预防
-
思想
-
加缓存，缓解主库读压力30%~40%左右
-
非数据强一致性要求业务流程，读从库
-
标热用途的cellar强依赖，支持根据appkey降级（降级后，核心业务appkey读主，非核心业务appkey读从；根据业务下单量区分业务是否核心？）
-
-
现象
-
接到大象报警通知
-
主库(dx-travel-mysql-triporder04)的读达到15K以上
-
-
影响
-
数据库变慢拖垮系统，系统整体响应变慢？
-
-
如何处理
-
octo上order-center项目调整热标记时间，key为hotkey_expiretime_millisecond给为100
-
集群流量均衡控制
依赖超时重试排查
服务接口流量控制
meilv
-
核销流量突发
-
如果DB有问题，打开"总是拒绝"策略
-
如果想限制流量，打开"集群频次限制"策略，默认1s 90次，超过则拒绝，如不满足可配置
refund
-
退款查询流量激增，DB压力大
-
进入退款mbop截流
-
-
浙公网安备 33010602011771号