售票系统在节假日卡住，多数不是被买票页面压垮的，而是被通道上的核验请求和后台刷新一起压垮的。这时候临时决定关什么已经来不及：通道前排着几十人，值守的人只能选保谁。降级的核心是事先写死保留顺序和分档动作，现场只做开关，不做判断。

一、保留顺序：核验放行、订单查询、出票支付。核验停一分钟，通道就堵几十人，事故会往人身安全方向走；订单查询失败，游客只是多问两句；出票支付停摆，可以转到窗口终端和自助售取票机，或者把线上购票顺延到之后时段。这个顺序按后果严重程度排，不按业务重要性排。

二、可以先放下的功能。数据大屏与报表刷新、活动叠加计算、改签、发票开具、评价与售后流转。它们共同特点是有人在等但不至于出安全事故。关闭时页面要留一条可见提示，说明当前处于高峰模式、该功能稍后恢复，否则游客会反复提交，把请求量再抬一次。

三、分三档，每档一张动作清单。一档只关报表与大屏轮询，这是最常见的隐性压力源，后台每几秒全量刷新一次就能占掉大部分连接；二档再关活动叠加、改签与发票，出票入口做限流与排队；三档只保留核验放行与人工放行，线上出票暂停，售票全部转到窗口和手持检票机。三档的动作要印在值守手册上，逐项打勾执行。

四、触发人是值班站长，不是研发。判据用三个可测的量：核验请求平均响应时长持续超过约定秒数、核验失败率超过约定比例、入口排队长度超过约定米数或人数。任一项连续两个观测周期成立就升一档。让研发临场决定关什么，会出现关掉核验而保留报表的荒谬结果。

五、降级期间的兜底要提前就位。闸机与手持检票机的本地缓存要有可用的名单版本和有效票段规则；版本落后超过约定时长就不能再自动放行，转人工确认。订单查询走简化视图，只返回订单号、场次和核销进度，不做明细聚合。

六、恢复的三条判据。响应时长、失败率、排队长度同时回落到阈值之下并连续保持若干分钟，再逐档放开，先放报表最后放出票。三档一起恢复是常见错误，因为报表一开、轮询一挤，核验通道又开始排队，等于把事故重演一次。

七、离线数据怎么补回来。降级期间设备本地攒的核验流水，恢复后要按固定顺序处理：先上传流水，再拉新作废与停场名单，最后对离线期间的通行做二次比对，把用了退款票、作废票和非本景区凭证的通行挑成异常。顺序反了会出现流水还没上传就被新名单覆盖。

被关掉的改签与活动要在恢复后补做，不是直接抹平。降级期间的核销记录要带降级标记，报表里单独一档，避免当天的出票量、时长和转化率被误读成业务波动。改签未受理的游客信息要留档，事后按票号补处理并留痕。

这套东西只靠出事那天想不起来，所以每季度做一次演练：主动升到二档，走一遍核验、人工放行和流水补传，看值守手册能不能执行到位。复盘只看三个数——响应时长、失败率、补传异常条数，其余都不作为评价依据。