2024年双11
一、【S2】10月31日限购系统因一个禁售规则（含2.6万个地址）造成数据热点，可用率下降至75%，C端会提示“限购服务异常”，引发1500+客户咨询
故障影响：
用户在线咨询量1500+
故障原因：
限购系统里部分SKU下禁售区域地址过多，存在大量大KEY访问，JIMDB分片被阻塞，从而导致可用率下降，且前台文案展示“限购服务异常”，引发用户集中咨询。
主要改进：
1）系统优化：短期将本地缓存过期时间从2秒调整为60秒，应对大Key问题；长期优化大Key分桶存储，并梳理缓存异步化处理。
2）产品优化：优化限购系统透传到前台的展示文案。
3）监控优化：限购系统增加jimdb大Key实时监控。
二、【S3】10月31日激励系统服务不可用，导致退款延迟，引发200+客户咨询
故障影响：
用户在线咨询量120+，IT工单100+，问题时段退款积压单量约2W+，后续系统恢复后逐步重试处理完成，部分订单由IT协助处理完成。
故障原因：
激励研发调整应用日志级别(INFO变为DEBUG)排查问题，原计划只针对一台机器生效，但因localcache刷新机制设计不合理，导致激励服务所有机器日志级别均变为DEBUG，进而导致CPU飙升及业务不可用，持续37分钟。
主要改进：
1）系统优化：短期新建专门用于存放本地缓存清理配置项的DUCC目录，并与日志级别配置隔离，避免全量发布风险；优化localcache刷新机制，去除对DUCC-API的不合理使用；长期解除退款系统与激励系统的强依赖，以保证接口超时或者偶发异常的情况下不影响全量退款订单。
2）测试优化：深入了解业务代码缓存刷新实现方式，补充操作DUCC配置后刷新缓存场景，并对交易缓存测试场景进行排查及加固测试。
三、【S3】11月2日客服G系统到天擎系统分流失败，导致约1209通话务未被接起
故障影响：
1）时段进线总量13238，溢出6789，溢出失败4252，失败话务继续回到全职排队，增加全职排队量 2）增加的排队量，导致全职应接起减少1209通，计算方式：13238＊（问题恢复后时段接起89%—问题时段接起79.87%)
故障原因：
客服三期职场防火墙替换过程中出现网络中断，触发客服天擎IVR应用（用于承接溢出话务）的3台JDOS容器探活异常而自动重启，因启动脚本存在BUG，导致其中1台容器虽启动成功（端口可提供服务）但未加载正常配置，当客服话务发生溢出时，流转至该容器的话务失败又回流至话务平台排队等待接起。
主要改进：
1）系统优化：修复启动脚本BUG，并增加服务配置自动检查，确保应用启动后正常提供服务。
2）监控优化：增加客服系统分流失败的业务监控告警，提高问题发现能力。
四、【S3】11月5日商品同时开启采销预定和VMI预定，库存系统误处理为无限预定，引发超卖1900+单
故障影响：
用户在线咨询量100+，超卖订单1915笔，预估因无法发货产生外呼赔付金额9.5万元
故障原因：
采销预订是通过在SKU的库房维度设置【预订标识】+【可预订数量】实现有限预订，若只设置【预订标识】则为无限预订。采销已设置有限预订时，当供应商开启VMI预订，系统应自动清除采销预订（与VMI预订互斥），但实际系统实现时只清除了采销预订数量，未清除采销预订标识，导致采销有限预订变成无限预订，引发超卖。
主要改进：
1）测试优化：完善采销预定、VMI预定互斥的用例步骤；梳理库存用例的断言完整性，重点关注涉及渠道、预售的逻辑。
2）系统优化：优化无限预定系统逻辑，异常兜底调整为不可售卖，避免出现超卖。
3）监控优化：监控同时开启VMI 以及采销预定等互斥业务场景。
4）产品优化：调研业务无限预订的使用场景制定产品方案，对于开启无限预定场景增加审批管控流程。
五、【S3】11月6日用户参加酒类会员积分兑换活动，兑换失败但积分未立即退还，引发110+客户咨询
故障影响：
用户在线咨询量110+，触发热点舆情橙色大风预警；兑换失败订单11091笔（涉及2365个用户）。
故障原因：
商品同时参加积分兑换活动和预约抢购活动，两个活动互斥导致积分兑换失败；积分返还任务是每4分钟调度一次，每次调度大概可消费1500单左右，故障期间兑换失败单量上涨，产生消费积压，因任务处理是按ID倒排，导致起初积压的订单在最近的几次调度中都没有被处理，延迟最长达到18分钟，且前端未给予用户积分退还说明，用户感知到积分没有立刻退还，引发客诉。
主要改进：
1）系统优化：兑换失败时立即触发一次回滚，同时优化回滚任务的消费效率，保障用户积分返还时效。
2）产品优化：管理端创建活动时添加互斥规则校验，用户端对涉及资产的处理增加明确说明。
3）监控优化：增加错误码监控，完善报警策略。
2024年618
一、【S3】6月4日天擎电话系统异常，持续26分钟，导致1800+客服话务未被正常接起
故障影响：
故障持续26分钟，期间零售部分坐席无法登录、外呼及呼入接线异常，时段接起率降低29%，受影响坐席800+，1800+电话未被正常接起。
故障原因：
智能算法组研发同学于13:55:50通过行云部署平台发布算法服务预发环境，在进行镜像包拉取并扩容30个实例时，选择发布机房错误（部署时宿迁机房存在多个资源可选，误选了客服机房资源）， 发布过程中导致宿迁天擎话务系统ip段达到300M带宽上限，数据出现拥塞，引起电话系统相关服务无法正常与缓存中间件通信，进而导致坐席无法正常接线。
主要改进：
1）系统优化：建设系统双机房灾备能力，异常情况可快速切换实现快恢；同时加强客服机房资源权限管控，仅供电话团队使用，对其他团队不可见，避免误操作；行云平台镜像构建时增加大小提醒，并通过平台实现镜像大小卡点管控。
2）监控优化：防火墙策略增加触发限流告警功能，及时发现触发限流阈值，并介入处理；客服职场流量增加1min流量数据环比，实现流量激增告警，同时优化流量采集系统数据统计周期（由10min优化至3min），快速识别出突发流量来源。
3）流程优化：规范上线流程，明确发布流程及目标集群，增加预发上线审批机制，严格管控。
二、【S2】6月4日公有云ClickHouse研发误删实例集群
故障影响：
物流侧：21个实例，运输调度控制中心看板、仓运营看板无法查看；供应链管理平台运输等报表无法生成，履约数据无法推送和查看等。
零售侧：14个实例，涉及安全风控部奖惩系统，搜客激活实时数据无法查看、青云离线报表无法查询等。
故障原因：
ClickHouse研发人员同时登录测试和生产两个终端窗口，期间在处理线上用户运维工作后误以为已切到测试环境中，实际仍在生产终端窗口，执行了kubectl delete命令误删CRD文件，导致一个K8S集群所有容器被全部销毁。
主要改进：
1）流程优化：K8S集群CRD及高风险操作权限统一收敛管控。
2）系统优化：完善整体集群资源被删的恢复预案及演练，优化Operator删除处理流程。
三、【S3】6月11日生态监管平台误操作下发错误配置，导致主搜、秒送、前置仓部分搜索结果只展示图书
故障影响：
1）订单影响：1W单
2）用户体验影响：主站、LBS门店&前置仓门店搜索、首页秒送搜索只展示图书类目商品，无结果请求会展示兜底结果
故障原因：
生态服务部的监管同学，为了屏蔽“电池修复器”类型商品，在规则管控平台创建对应管控规则，但是相关配置项过于灵活复杂导致内容错误，并且规则管控平台无相关的审批流、通知流，导致错误的管控规则在无其他人知晓的情况下直接下发至搜索中台生产环境生效，最终使主搜、秒送、前置仓部分搜索结果只返回图书类目的商品。
主要改进：
流程优化：线上变更操作需进行DoubleCheck确认；对监管平台下发的规则，完善对应的灰度机制，充分校验后再全量生效。
系统优化：生态管控平台规则配置优化，上线前的审批流从线下邮件改成线上xbp；前置仓搜索、秒送搜索兜底逻辑优化，保证任何时候都有结果返回。
四、【S3】6月12日博库网预订商品不显示履约时效，造成100+客户进线催单
故障影响：
涉及订单3000+，共产生100+在线咨询
故障原因：
6月1日商家通过京麦系统进行商品预定标识设置，系统提示设置成功，实际京麦系统调用商品中台接口时命中规则校验（预订开始时间和结束时间相差超过10天），京麦系统在一次请求中调用多个接口时未做一致性判定及保障，实际预定信息设置失败，导致该商品前台商详页库存状态展示为采购中，但没有预计发货时间，由于订单迟迟不发货，在6月12日引发用户集中咨询。
主要改进：
1）流程优化：收口封装预定的业务服务提供统一的能力，所有的校验逻辑前置到调用库存和商品中台接口，由提供预定服务的一方收口，jos、京麦端统一调用封装好的统一服务。
2）监控优化：针对一次请求中涉及多个接口调用的情况，增加部接口调用分失败异常监控报警；完善预定接口调用失败的业务监控告警。
五、【S2】6月18日公有云网络被DDoS攻击
故障影响：
1、云侧评估：DDoS网络攻击期间（6月18日01:3501:40、02:5202:57、04:064:11、05:2005:25、06:3306:39、07:487:53、09:0209:07、10:1510:20）公有云华北区域机房出口满载。 2、客户侧评估：攻击期间，公有云华北区域均受到影响，京东物流、京东科技（云、AIDC、通信云）大客户贝壳、陌陌等8个外部客户业务可用性下降。
故障原因：
华北机房入口带宽有限，并发被攻击的智能客服业务IP数达300+，超出现有购买的运营商黑洞压制并发数。夜间和凌晨业务流量小，前几次攻击造成的网络抖动时长较短，已联系被攻击IP的业务方更换IP进行处置。此次同时攻击300个IP需要使用运营商黑洞并紧急扩容，由于涉及费用投入，所以观察攻击流量是否持续。六点半左右攻击持续，开始紧急扩容处置，扩容需运营商配合，导致整体处置时间较长。
主要改进：
1）系统优化：公有云业务网络隔离，IAAS和网络侧新建独立网络出口，将易被攻击的业务迁移至此出口，减轻对华北大客户和集团业务的影响。
2）流程优化：公有云安全防护能力提升，常态封禁通道数购买增加到50个并发攻击ip数量，攻击超过现有黑洞压制通道，立即升级决策扩容；单IP超过2G一律封禁，系统自动触发封禁通知客户，单IP未超过2G，但单次攻击打满出口持续5分钟以上，或单天0~24累计影响5分钟攻击打满出口，立即执行封禁。
2023年双11
一、【S3】10月31日UMP秒级监控延时问题
故障影响：
10月31日晚八UMP秒级监控出现50秒左右的数据延时
故障原因：
秒级埋点数据峰值流量超预期（去年双十一3.52亿/分，今年618为4.51亿/分，双十一开门红为6.11亿/分（同比增长74%，比历史峰值高35%），因Flink部分分片处理延迟，导致整个计算任务出现了积压，最终影响UMP监控数据的实时性。
主要改进：
1）系统优化：Flink参数调优及扩容，双流单写优化成双流双写，并进行压测，并进行合理有效key的长期治理。
2）流程优化：深入学习熟悉Flink平台能力，提升问题处理时效。
二、【S1】11月7日到家订单误锁单问题
故障影响：
约2.4W笔订单延迟履约，超履约时效的订单给予赔付以安抚用户。
故障原因：
11月7日风控侧为了验证到家风控处置结果，将生产流量转发至风险决策系统的预发布环境，因该预发布环境开启了线上处置功能，原计划仅进行风险打标处理，实际误将订单同步进行了锁单处置，导致约2.4W单到家订单被误锁单。
主要改进：
1）系统优化：处置系统提供一键回滚功能，进一步降低解锁处理时长；针对到家下游部分独立系统未对接解锁消息的场景，需进行到家风控锁单/解锁整体链路优化；全面梳理天网预发环境调用线上情况，天网系统预发环境彻底隔离。
2）流程优化：封版期间涉及线上系统配置变更，需强化加严审批确认流程。
三、【S3】11月9日部分有价优惠券订单被系统自动取消引发400+客户咨询
故障影响：
1）用户体验影响：触发橙色烈风预警，用户在线咨询量400+，京东负面舆论量40例;
2）业务影响：受影响的取消订单共1593单（大时尚事业部业务侧已联动客服通过赔付优惠券的方式进行客户安抚，当前赔付优惠券用户累计核销719个，涉及券成本约14.6W）。
故障原因：
商家设置有价优惠券商品的定时上架时间为11月9日10:00，因定时上架Worker是单点架构设计（仅一台机器），服务器宕机未及时发现，导致商品未能准时上架；后续商家通过Shop端手动操作上架并修改商品属性保存，此时虽库存数量显示不可修改，但实际会将页面库存数量下传至库存中台覆盖真实库存数量，造成商品与优惠券库存不一致，用户下单成功后，因优惠券库存不足触发订单自动取消，引发客诉。
主要改进：
1）系统优化：有价优惠券商品进行商品属性修改时限制不允许修改库存。
2）产品优化：商品信息编辑功能与库存修改功能解耦，并优化虚拟订单交易流程，针对有价优惠券库存不足等情况避免自动取消订单。
2023年618
一、【S2】5月31日20点20分起，部分商家/采销陆续反馈，设置促销活动不能及时生效，直至21点38分完全恢复
故障影响：
影响约4100+个商家的约30%促销活动延迟10分钟以上生效，产生1000+咨询
故障原因：
a、数据库运维侧:一个跨店促销热点活动(单活动 3000+万 SKU)于 20:11 点击发布(因平台交互复杂造成运营误会 29 日活动已发布，晚 8 后发现未生效，则立马点击发布)，经促销活动创建系统，20:20 至数据库流量突增，触发单台老旧物理机假死(性能严重下降)，数据库运维同学未及时采取有效预案执行主从切换，且主从切换效率较低，导致故障恢复时间较长。 b、促销活动研发侧:数据库性能异常期间，未能快速判断正确根因，联动数据库运维及时采取有效预案，且促销活动创建系统限流值与数据库当前容量不匹配，使得数据库流量超出其承载能力， 触发其性能显著下降。
主要改进：
1）系统优化：优化促销活动系统架构，实现流式入库生效，降低业务影响风险，并尽快推动完成JED数据库切换。
2）监控优化：监控告警及时跟进处理，并实现热点监控，合理设置限流值。
3）流程优化：熟练应用pfinder等监控平台，加速故障分析定位；提升切库效率，控制切库失败等待超时时间在1分钟内，整体切换完成时间在10分钟内。
二、【S3】5月31日部分用户尾款订单在订单中心支付时，提示“网络异常，请稍后再试”，引发5300+客户咨询
故障影响：
1）用户体验影响：天象在线咨询量5300+，触发热点舆情橙色烈风预警
2）订单影响：受影响且未支付完成的1700+订单，后续通过PUSH消息等举措提醒用户继续完成尾款支付
故障原因：
V12.0.2版本在做接口异常监控优化需求时，引入了BUG，用户点击“直接支付”时，会出现接口数据无法解析，前端展示网络异常。
主要改进：
1）测试优化：完善预售核心场景的测试用例及版本发版前的全面回归机制；大促封版前对大促期间才生效或被使用的核心场景进行全面的回归验证。
2）系统优化：完善相关降级预案的系统能力，紧急风险问题可快速降级或者引导支付。
三、【S3】5月31日部分供应商反馈新增或编辑商品时提示“产品线不匹配”，导致无法正常发布商品
故障影响：
收到40+供应商反馈，问题期间对于需要紧急发品的供应商已引导可通过现有系统能力自行调整产品线到新部门下，受部门撤销影响的产品线于18:32全部恢复完成
故障原因：
供应商发品可选的类目和品牌强依赖产品线，发品时会获取当前登录账号所属采销对应事业群下所有一级部门已授权产品线信息做校验，由于CHO侧业务调整撤销了老部门未提前周知且各事业群未将供应商产品线提前调整至新部门，最终导致查询不到产品线影响发品。
主要改进：
1）流程优化：完善部门架构调整的信息同步、风险评估、跟进确认的流程机制，出现问题需第一时间考虑回滚/数据恢复；
2）监控优化：增加业务异常监控，按部门查不到产品线量显著增加时进行业务报警；
四、【S3】6月9日凌晨至上午10点，大促通栏内外联动失效触发兜底
故障影响：
1）影响时段：6.9日1:25-17:48（1:25-9:55为首页SOA兜底展示，9:55-17:48为推荐兜底展示，17:48后业务策略数据完全生效）。
2）用户体验影响：前端为兜底展示，类目多样性缺失（多个用户可能出现相似品类），当日UV点击率0.72%，环比估算下降约30%。
故障原因：
业务运营6月9日00:36修改规则生成新的did分期后，推荐侧接收数据后发生程序处理异常（由于架构没能充分保障数据时序，数据截止标记被先处理，造成正常数据没能入库），导致无数据返回触发兜底；内外联动恢复后，又由于干预制备的冷启数据没有考虑类目多样性，造成线上出现品类聚集（偏时尚skuid）问题。
主要改进：
1）系统优化：优化处理引擎拓扑逻辑，消除更新did热点；离线存储进行缩分片（将默认2000分片缩小到100分片），缓解数据io放大问题；同时首页兜底增加商品多样性，提升用户体验及转化。
2）监控优化：增加入口出口对账报警，便于及时发现数据异常情况，快速定位问题。
3）流程优化：大促期间重要业务策略调整，提前周知各方做好风险评估及效果验证。
五、【S3】6月18日首页秒杀频道内外到手价不一致问题
故障影响：
首页秒杀频道内外显示的到手价不一致，引发用户咨询
故障原因：
在首页核心楼层新老交接过程中，联合产品对秒杀频道的历史逻辑进行了梳理，梳理出部分可降级或下线的字段。针对可降级字段设计了降级开关，其中为降级秒杀频道“历史最低价天数文案”字段的代码逻辑处理有误（“历史最低价天数文案“需先获取到手价，降级开关的逻辑同时控制了到手价和“历史最低价天数文案”，应设计为两个降级开关，分别控制），导致开关开启后降级了历史最低价天数文案，同时降级了首页秒杀频道的到手价，出现内外价格不一致问题。
主要改进：
1）监控优化：增加首页核心楼层价格与频道内页价格对比监控，完善首页核心楼层的核心链路监控告警。
2）系统优化：梳理首页核心楼层涉及的降级开关，并进行验证，明确降级影响。
六、【S3】6月18日主站APP-iOS端首页mini商详推荐位数据断流持续约50分钟
故障影响：
影响时长50分钟，期间推荐广告收入损失预估5.07万，误拦截请求量约25W次
故障原因：
iOS验签组件客户端与服务端对特殊字符解析规则不同，导致验签失败。客户端请求时将 “+” urlEncoding 为 “%2B” ，客户端用NSURLComponents API提取参数时还原为 “+” ，而服务端处理后参数与客户端不一致，致使加签及验签结果错误，最终拦截请求引发业务异常。
主要改进：
1）系统优化：验签组件对请求中携带“+”号的请求进行修复，确保验签结果的正确性；针对空白异常兜底页面优化保障用户体验。
2）监控优化：细化监控告警规则，确保策略异常时能及时发现。