当几百人同时调用 AI 时怎样保持可用？设计并发、批处理、优先级、限流与降级策略

先看结果：不是把并发上限调大，而是让五类流量在坏掉时仍有确定终态

峰岸出行服务集团有9,500名员工、2,400个客服坐席。平时，AI帮助坐席查询行程、起草回复、抽取邮件和生成班后摘要。一次区域天气事件发生后，在线坐席突然增至1,900人。旧系统把所有请求都送进同一条队列；供应商一超时，客户端便立即重试。结果，普通摘要挤占了中断旅客支持的资源，监控却因为网关仍返回成功状态而显示“可用”。

团队没有再把“并发量”当成一个孤立数字，而是先按业务后果把流量分成五类：P0中断处置辅助、P1普通坐席辅助、P2邮件抽取、P3班后批处理、P4评估与回填。用生产候选配置和真实输入长度重放后，五类流量的峰值总需求是每秒488.1个内部工作单元，整条服务链能持续承受的安全容量是每秒560个单位。

随后，一次持续22分钟的供应商降级把可用容量压到每秒420个单位。系统暂停P4，把P3从每秒99个单位降到60个，优先保住P0、P1和P2。最终，受影响的86,400个业务对象都有唯一状态；团队没有为了可用性临时放开未经批准的模型、区域或数据边界。

P0通道每月有240万个合格结果，99.9%的服务目标最多容许2,400个失败终态。这次事件产生2,200个失败，单次便用掉91.7%的月度错误预算。因此，团队冻结了非必要的路由和配置发布，只保留事故修复与紧急安全变更。

“供应商恢复正常”也不等于系统已经恢复。18,000个批任务要以每秒40个作业的净处理速度排空，需7.5分钟；6,400封邮件以每秒30个作业的净处理速度排空，约需3.6分钟。每个对象重新执行前，还要再次核验截止时间、身份权限和幂等状态。

公司、流量、工作单位、模型、容量、费率、服务目标和事故均为虚构教学案例，不代表任何供应商或真实服务承诺。真实服务协议、用户权益、合同、业务连续性、劳动、数据与安全要求须由组织的业务、平台、风险、法务与专业负责人决定。

本文只处理服务容量与可靠性：模型质量、推理位置、总体拥有成本和业务连续性仍有各自门槛

前提是任务已选、模型配置已过质量/资料门、在线/本地/混合位置已决定、成本范围可解释。容量工程回答：在给定负载和故障下，系统能接收多少、让谁等待、怎样拒绝、如何恢复。它不能用更多副本修复错误答案，也不能用限流许可未授权资料。

“几百人同时用”不是可计算需求。一个用户会停下来阅读，也可能一次触发检索、模型、验证器和工具；一个批处理作业可能没有用户却占用大量资源。项目以业务对象、到达率、服务时间、输入/输出形状、尝试和截止日期为基础，用户/席位只做采用与授权维度。

容量责任贯穿整条服务链：业务团队定义优先级、截止时间和人工路径；应用团队定义状态与重试；平台团队管理准入、队列和模型池；数据来源与工具各自保护容量和权限；供应商提供配额与变更证据；可靠性团队负责演练；财务团队支持储备取舍。没有一个团队能单凭图形处理器或接口配额承诺端到端服务目标。

服务目标要从用户任务定义：接口成功、模型有字和网关可用都不等于业务成功

成功必须同时通过身份与策略、来源访问、模型生成、格式与证据验证以及应用状态检查。供应商返回成功状态，但格式错误、引用越权或超过截止时间，都不能进入成功分子。正确拒绝未授权请求不算可用性失败，但要单独报告分母和拒绝原因，防止团队通过扩大排除范围美化服务目标。

这里需要分清内部服务目标与对外服务协议。前者是系统运行和变更控制的依据；后者还包含未达标后的商业责任，由业务、法务和采购共同决定。案例门槛来自虚构任务，Google SRE资料只用于说明服务指标、服务目标和错误预算的方法，不表示Google为本案例背书，也不表示这些数字是行业标准。

50分位、95分位和99分位分别展示常态、尾部和极端情况，平均延迟不能用于承诺。可用性也按合格结果的比例计算，而不是只数“故障了多少分钟”。批任务关心截止日期和积压时长，交互任务关心首次反馈和完整结果，人工路径关心排队时长。把这些通道求成一个漂亮平均数，会掩盖真正失败的任务。

每项服务指标都要有一张填写完整的定义卡，包括事件来源、分子、分母、成功、失败、拒绝、取消状态、测量点、统计窗口、延迟起止、迟到与重复的处理方法、数据缺失政策、负责人和查询版本。P0从“工单进入AI可处理状态”开始，到“验证器通过且坐席可见草稿”结束。用户在提交前自行取消要另列；模型超时后转人工，AI路径仍然失败；正确的策略拒绝不进入合格分母，但拒绝率必须保留。

分母审计每周随机抽取200个原始事件，核对应用状态与指标查询是否一致。若某个版本把“超时”改名为“取消”并自动排除，服务结果就会虚假变好。指标负责人应立即回滚查询、重算受影响窗口并记录数据事故。必需遥测缺失时不能默认成功；高风险通道是按保守失败处理，还是把窗口标记为无效并停止变更，应由预先制定的政策决定。

服务目标还要写清业务理由和成本边界。P0选择99.9%，不是因为“三个九好看”，而是旅客截止时间、人工连续性和储备成本共同形成的取舍。若要提高到99.99%，就要证明额外的容量、供应商和人员投入与业务后果匹配。门槛变更由业务与可靠性负责人共同批准，不能按照当前最好表现倒写目标。

用负载合同把五类流量变成可调度对象，优先级不能由部门和职级决定

优先级绑定业务后果和截止日期，不绑定职级或喊得最响的部门。P0只为已确认中断的受权案例，普通改签咨询不能自报P0；应用注册表/任务状态签标签，网关验证。滥用P0会挤占真正中断流量，按负责人/案例审计和纠正。

P3批处理可以延后但不能丢，P4可以取消后重跑，P2有2分钟业务截止时间，P1需要保证交互体验。它们虽然都不是P0，处理方式却不相同。每一类都要保存最大上下文、输出上限、候选模型、来源与工具、成本、队列存活时间、重试规则、人工路径和终态；调度器不能根据请求地址猜测优先级。

反例是客户权益写操作。即使P0，AI也只产生草稿/只读查询；真正改签由独立预订服务验证用户、库存、价格、授权、幂等键和人工确认。容量压力不能取消先决条件或让模型文本变成动作权限。

负载画像取连续8周的数据，按15分钟切分，并标记天气、节假日、营销活动、系统故障和异常重试。输入长度的50分位与95分位来自分词器实测，输出上限来自任务合同，不能直接照搬模型的最大上下文。新任务只有一周数据时，应分别保存低位、基准和高位估计及其置信度，先在小范围运行，不能把2,400个席位简单乘以“每人每分钟一次”就当成峰值。

档案还要保留同一旅客在多个渠道同时到达的相关性。航班中断会让电话、邮件和应用流量一起上升，按各通道的独立分布估算，反而可能低估共同峰值。负载测试包因此按历史事件保留相关性。相反，同一业务对象因前端自动刷新产生的请求不能统计成新需求，应先按对象编号去重，再单列技术尝试次数。

先标定内部工作单元，再用同一把尺计算混合负载和安全容量

团队定义1 工作单元为P1参考配置在固定输入/输出与最终适配器下消耗的实测服务量；每类通过重放得到系数。它只用于这个池的混合负载/容量模拟，模型、上下文、批量、量化或硬件改变就重标定，不能拿去比较另一供应商。

每秒560个单位的安全服务容量，来自同一套混合重放中同时满足任务质量、尾部延迟、错误率和内存门槛的最大可持续点，再扣除配置变化和测量误差所需的余量。它既不是设备标称峰值，也不是把各单通道吞吐相加。当前需求与安全容量之比为488.1÷560=87.2%，只剩每秒71.9个单位，也就是相对当前需求14.7%的余量。这个水平应进入预警，而不能被理解成“还有12.8%可以随便用”。

供应商降级25%把安全容量降到420。先暂停P4 49，再把P3从99降到60，即需求488.1−49−39=400.1，保留19.9 单元/秒。若仍超门，再按截止日期把P2入队并限制P1新长上下文；P0 底线不借给评估。降级顺序在事故前审批，不由值班临场按成本排序。

工作单元只描述模型服务近似负载，身份、检索、验证器、队列/日志和人工另测。某模型更快却让验证器失败/人工修改增加，不能以单元/秒胜出；容量验收同时看合格结果。

系数校准用每通道 1,000个冻结样本重复3轮。参考P1在安全区间处理1,000份需要总服务资源1,000单位，故系数1.00；同环境P0因长上下文/证据产生1,802单位，取1.80；P2为697取0.70，P3为451取0.45，P4为1,396取1.40。展示值四舍五入，计算层保留原值和范围；三轮差异>5%就查缓存、批量、长度或噪声，不发布一个假稳定系数。

寻找560这个数时，团队保留了完整的阶梯记录：从每秒350个单位开始，每轮增加35个单位，并持续运行30分钟混合负载。到每秒595个单位时，P1的99分位延迟、验证器队列和内存错误都越过门槛；每秒560个单位连续三轮通过。因此，560是当前配置下最后一个满足全部任务门槛的实测点，不是从595随意扣一个安全比例。配置变化后，还要用同一组阶梯样本重新测量。

系数会随组合非线性。单独跑P3的批量效率可能高于0.45，但与P0混跑会争内存/缓存；因此既保存单通道诊断，也用真实组合决定承诺。容量账记录配置哈希、输入切片、批量、缓存、区域、配额和日期，缺任一项不能跨环境引用。

到达率乘以服务时间只能估算平均在途量，不能代替负载测试

利特尔定律可以画出第一张容量草图：稳定系统中的平均在途量，约等于到达率乘以平均服务时间。P0峰值为每秒52个请求，平均服务时间3.6秒，约有187个请求在途；P1为180×4.8≈864个；交互流量合计约1,051个。这个估算解释了为什么1,900名在线坐席不等于1,900个并发模型请求，也提示连接、队列和内存至少要承受千级在途量。

1,500这个上限不是把1,051乘一个安全系数拍脑袋得到的。重放数据包含95分位长输入、流式连接、超时和一次有界重试；团队观察内存、队列时长和尾部延迟后才确定上限。利特尔定律要求系统处于稳定状态，不能把95分位延迟直接代入并当成95分位并发，也不能用来解释已经发散的队列。事故期间，应以实际在途状态和队列遥测为准。

并发控制还有多个层级：用户与会话层防止循环，应用与部门层保证公平，任务层保护服务目标，模型与供应商层遵守配额，来源与工具层保护依赖，最后由全局上限保护平台。用户配额还有余额，不代表供应商并发一定有余；错误响应要说明卡在哪一层、何时可重试以及有哪些替代路径。

连接并发、计算并发与业务并发要分别计算。一个流式连接可能正在等待用户阅读，并不占用模型计算；一个批次可能一次占多个工作槽；一个坐席可以同时打开两张工单，却只能对其中一张执行权益动作。连接池按套接字和内存保护，模型池按工作单元和在途量保护，应用按活跃案例与最终状态保护。只用一个“并发数”，往往会在某一层过宽、另一层过窄。

1,500个在途请求的门槛采用高低水位控制：达到1,350时进入一级节约状态，并拒绝可选的长上下文；达到1,500时停止接收新的P1任务，同时告知预计等待时间。只有在途量降到1,200以下，且95分位延迟连续稳定5分钟，才恢复正常准入，避免开关反复抖动。P0虽然有独立预留队列，仍受每秒200个工作单元的最大值和人工放行限制，不是无限通道。

长上下文通道要单独限制并发。输入长度95分位达到9,800个令牌，不能与短请求共用同一个请求上限。准入时先估算输入、输出、内存、工作单元和截止时间；超过约定形状的请求进入长任务队列，或要求缩减可选资料，不能先接收，等内存溢出后再重试。

瓶颈图要覆盖整条服务链，扩模型池可能只是把拥堵推向下一环

每个依赖都有负责人、服务目标、超时、重试、资源池和故障域。模型超时设30秒，来源读取也设30秒，会让用户的总截止时间早已失守。时间预算要从用户截止时间向前倒推，并在实际追踪中验证串行和并行路径。某个来源变慢时，不能占满所有执行器；隔离舱要让其他旅程继续。

容量测试要逐层找到拐点：吞吐增长到某一点后，99分位延迟和错误率会突然上升。安全上限应放在这个陡升点之前，并留出变更余量。只压入口网关得到每秒2,000个请求，不代表端到端服务也能承受；只测模型而不包含检索增强和验证器，同样会高估容量。

人工同样是服务链上的依赖。草稿在6秒内生成，却在复核队列里等待18分钟，对旅客而言就是18分钟；服务目标应在应用端测量完整结果。不能靠扩模型掩盖排班不足，也不能通过取消复核制造表面可用性。

用户截止时间要拆成可执行预算。P0总计12秒：入口、身份与策略的99分位预算为0.6秒，来源与检索为2.4秒，模型为6.0秒，验证器为1.2秒，应用、网络和界面为1.0秒，另留0.8秒不确定余量。各组件预算不能简单相加成服务目标，最终仍以端到端测量为准；它的价值是让团队看到，来源读取已经花掉5秒时，即使模型自身达标，也救不回整个任务。

瓶颈记录还写降级后果。身份/策略缓存可降低延迟，但撤权事件必须使缓存失效；来源副本可减负，但权限/版本要一致；遥测缓冲可延后上传，但关键动作事件不得丢。每个容量优化同时审正确性和资料边界，防止为了吞吐复制未授权数据。

准入、队列与重试共同决定系统接什么、等多久以及怎样安全失败

底线不是永久预占空资源；空闲可借，但P0到达时借用者必须可被抢占或停止接新，不能杀已进入不可逆动作。P3/P4支持检查点，最适合归还；P1 流给用户明确降级，不中途拼另一模型内容。

准入在昂贵工作前校验身份、应用/任务、输入形状、截止日期、配额、路由集与幂等性。未知任务、无截止日期/负责人或超最大上下文的生产请求被拒/进入入职，不默认归低风险聊天。拒绝自身有低成本路径，避免过载时生成复杂错误页再次调用模型。

配额至少分资金、速率、并发、工作单元、上下文、队列和操作。软预算只告警/分摊显示，硬性技术上限保护循环与合同；业务负责人可申请限时突发，记录截止日期、量、人工和过期。连续突发触发预测/容量复核，而不是把紧急永久化。

每次准入决策都要记录请求、任务、应用、输入形状、估算工作单元、截止时间、各层配额、获批路由集合、预计排队时间、最终处理方式和理由。P1长请求即使遇到全局容量有余，只要长上下文配额已满，也应缩短可选历史或进入短队列，不能借用P0。P0若资料访问门槛失败，即使保留容量空闲也要拒绝。用户得到稳定的错误说明，支持人员则能按决策编号复现当时判断。

容量借用采用限时租约：P3最多借用P0每秒60个空闲工作单元，有效期5分钟，而且必须支持检查点。P0需求激增时，系统要在30秒内停止接收新的P3任务并释放容量；已经完成的对象保持终态。租约到期时间、实际归还时间和未能释放的原因都进入容量告警，避免“动态共享”最后变成永久占用。

突发容量申请要写明事件、任务、数据与动作边界、到达曲线、起止时间、最大工作单元和队列、人工人数、供应商确认、成本、降级方案与负责人。到期后自动恢复原上限；期间若服务目标或边界越线，可以提前撤销。经理口头说一句“今天重要”，不能改变生产优先级。

队列按截止日期和公平性调度，排队不能把失败藏到未来

队列项保存业务对象、任务与版本、优先级、截止时间、尝试次数、来源编号、策略与配置版本、幂等键和检查点，不保存不必要的全文。入队前要告知预计等待时间和替代路径，排队期间定期检查剩余有效期；出队前重新核验身份、来源访问权限、策略、模型和业务状态，不能把入队时的许可当成永久许可。

耗尽时间=积压/(服务−新到达)，不能用积压/服务忽略恢复期间新流量。若服务≤到达，队列不会排空；必须增加容量、继续分流或延长/取消截止日期。恢复初期还需金丝雀与缓存预热，260/125是验证后的服务率，不能一变绿就全速重放。

同一优先级内按租户和应用分配公平份额，再结合截止时间调度，防止某个重试循环占满队列。等待时间加权只用于同一风险范围内防止长期饥饿，不能因为P4等得久，就让它越过P0。过期项进入取消或人工流程并通知负责人，仍计入服务目标失败；从队列删除过期项，不能同时删除失败事实。

队列状态为等待中→已租用→运行中→已验证→已释放/人工/已取消，租约超时回等待中但尝试递增；最终状态不能回到运行中，补发必须创建新版本并关联旧对象。调度器在领取时用原子租约，应用在放行时核幂等/业务先决条件，从两头防两个执行器同时生成两份外部结果。

一个P2邮件对象EM-309在事件第12分钟入队，截止时间为120秒。系统在第22分钟恢复时，它早已过期，不能因为队列中还有这个对象就直接重放。系统将其标记为迟到并转人工，通知队列负责人，同时保存原始到达、等待以及从未调用供应商的事实。另一封截止时间为30分钟的邮件，则在重新核验来源访问权限后继续运行。这样的样本记录能防止团队用“最后都处理完了”抹掉服务失败和权限变化。

队列磁盘/消息系统也有容量：按项元数据、必要加密负载、峰值小时与保留生存时间估算，设高水位/拒绝和灾备。为了避免爆盘不能无限丢最老消息；按业务状态取消并留下墓碑/审计，确保恢复对账知道发生过什么。

重试、超时、断路器和幂等必须共同设计

若提供商故障为25%，每次最多3次额外重试且假设独立，调用乘数为1+0.25+0.25²+0.25³≈1.328；488.1 单元/秒可被放大到约648.2，超过560，故障由下游扩成自身过载。实际错误相关性可能更糟，公式只是风险提示。

客户端要遵守服务返回的速率信号。RFC 6585把HTTP 429定义为“请求过多”，响应可以通过“Retry-After”字段提示何时重试，但没有规定服务如何识别用户或计算请求次数。本文只把这两个信号作为协议线索，不假设每家供应商都会完整提供，也不把它们当成完整的容量策略。

退避带抖动和截止日期，重试预算跨实例集中计量，避免每个客户端都以为只重试一次。熔断器在连续超时/429/错误率越门时停止新调用，走队列/替代/人工；半开用少量金丝雀恢复。只有已批准替代且任务/数据/动作门相同才能路径。

幂等不只是加一个键：应用写入前核当前案件状态和先决条件，动作账本保证一次权益变化，重复回复可返回既有结果。模型草稿本身可重做，但用户看到/发送/工具动作必须有版本与单一最终状态。

25%的失败并不相互独立：区域过载时，连续重试更可能再次失败，因此1.328只是一个偏乐观的估计。负载测试还要让一组客户端故意忽略重试时间提示，验证网关能否按应用隔离并打开熔断器，不能让遵守规则的客户端一起受罚。重试预算按“额外尝试次数÷原始合格对象数”计算，达到5%后停止自动重试，转入队列或人工路径。

超时预算要随剩余时间缩短。P0来源读取已经用掉4秒，就不能仍给模型10秒并允许3次重试。编排器先计算剩余时间，只有在还能完成验证和界面交付时才发起下一次尝试。超过截止时间到达的模型结果不能再向业务释放，但要保留调用和延迟记录，防止迟到回答覆盖人工决定。

写动作失败需要查询/对账而非盲重试：预订服务若返回超时，应用以动作键查状态，确认未执行才由人工重新提交；无法确定则进入对账，宁可显示“处理中”也不重复权益变化。模型不得决定重试写动作。

交互、批量和评估要分池调度，人工连续性也必须按真实容量计算

P3按业务截止日期形成小批，检查点后可暂停；P4只在维护窗口，用独立配额，生产事件立即取消。批量通过更高吞吐降低成本，但不能因合批跨租户、混资料、扩大上下文或让单个失败重做整批。

离峰时段要按实际时区和事件判断，不能把午夜默认当成低峰。天气中断可能让夜间仍处于峰值；调度器根据预测和当前服务指标决策，业务截止时间优先于“便宜时段”。评估数据可以与生产共享基础设施，但不能因此共享敏感缓存或日志权限。

批处理失败按对象隔离。一个坏输入不让32个全部重试，毒丸项进入人工/错误队列并保留原因；检查点的状态写入本身幂等。恢复时先处理最早截止日期，不因批量大而优先。

形成批次前要按租户、数据边界和配置分组，不能为了凑满32个对象，就把不同保留策略或区域要求混在一起。拆分输出时逐一核对对象编号、顺序和格式，少一项就只重做该对象。若供应商只返回整批错误，适配器应把32项标为“状态未知”，而不是假设全部成功或全部失败。批次、对象和计费三个层级的记录共同支持成本核算与恢复。

P3每小时记录完成数、迟到数、异常输入、重试次数、检查点年龄和预计排空时间；P4还要保留取消与重建清单。维护窗口结束仍未完成的评估任务可以取消并记录，不占用第二天的生产容量；生产批任务则不能因为窗口结束而删除，而应按截止时间进入下一状态。

人工连续性也要做容量测试，人工不是无限的安全网

集团预先训练了320名客服与主管处理P0人工任务。在压力情境下，每人每小时约能处理18个案例，理论总能力为每小时5,760个，22分钟约能处理2,112个。事件中有960个紧急对象转入这条通道，占这段理论容量的约45.5%；测试时还要叠加原本已经存在的人工工作。其余6,400个P2对象并不是要求人工在22分钟内全部完成，而是进入最长2小时的降级或人工队列。

人工操作手册要写明：怎样从AI界面切换到受控查询和模板，如何保留案例，谁批准外部动作，以及系统恢复后怎样交回。不能让员工临时用个人聊天工具补位。紧急授权仍要遵守最小权限，设置到期时间并保留记录，事故后统一复核。

人力容量有明显的疲劳曲线。每小时18个案例只适用于这次22分钟演练，持续两小时不能简单线性外推。长时间事故中的轮班、休息、主管比例、场地、网络和支持条件都要进入业务连续性计划。如果AI错误预算已经耗尽，需要增加复核，而人工通道同时满载，正确做法是缩小范围或暂停部分流量，而不是同时要求一线人员“更快、更严”。

320人的排班不能只是一份姓名表。演练前要抽查单点登录、人工工作区、旅客资料范围、模板版本、操作权限和培训有效期；无法登录、请假或权限过期的人必须从容量分母中扣除。第8分钟实际到位296人，每人22分钟平均处理3.24个紧急案例，共约959个，与960个对象基本对上，剩余1个由事件负责人接手。若实际只到位200人，P0准入就要更早停止并通知用户，不能继续按理论上的每小时5,760个案例承诺服务。

主管在外部动作发生前抽查关键字段，事故后对权益变化和跨旅客错误做100%复核。人工吞吐量达标，但严重错误上升，不能算连续性成功。一线人员还要反馈哪些证据难找、哪些模板过期，用来改进界面和操作手册，而不是只被要求提高速度。

负载测试要覆盖正常、峰值、长时运行、故障、重试和恢复

测试数据包要保持真实的输入和输出长度、语言、工具调用、缓存命中、到达相关性和租户混合；敏感内容使用经过批准的回放数据或保持形状一致的合成数据。负载生成器本身不能成为瓶颈，客户端、服务器与端到端时序要对时。每轮都记录配置、环境、配额、预热状态、原始追踪和失败样本，不能只截一张平均每秒请求数的图。

容量结果必须带置信度。每个场景重复3轮并报告范围；供应商临时放宽限制、使用空闲区域或提前预热缓存，都要在报告中注明，不能拿演示条件承诺生产。提示词、模型、检索增强、验证器或运行时只要发生变化，就要重新测试受影响的质量和性能，因为工作单元系数可能随之改变。

每次压测都要生成运行清单：案例与负载版本、到达序列种子、配置指纹、环境与区域、配额、预热状态、起止时间、故障注入、客户端时钟、成功定义、原始追踪位置和审批人。验收报告展示三轮的50分位、95分位、99分位、吞吐量、队列、错误、质量和资源，不能只挑最好的一轮。异常样本列表则逐条解释超时、错误或测量缺失。

72小时长时运行要检查内存与连接泄漏、队列缓慢增长、令牌和缓存变化、日志积压、成本以及人工支持负担；短时峰值测试看不到这些问题。测试结束后按授权删除数据，并逐项撤销压测创建的凭证、功能开关和临时配额，防止测试能力遗留在生产环境。

测试环境若比生产少一个来源或没有真实验证器，报告标部分，不能给端到端承诺。生产金丝雀继续验证，但不把用户当无边界压测流量；群组、停止、人工和沟通事先批准。

P1从每秒180个请求突增至320个，使混合需求增加140个单位，达到每秒628.1个单位。暂停P4的49个单位和P3的99个单位后，需求降到每秒480.1个，低于560。测试还要同时验证P3检查点完整、取消P4没有业务影响、P0的95分位延迟没有退化，并在突发结束后按净服务率恢复，而不是只证明系统“没有崩”。

降级阶梯逐级减少可选能力，不减少资料、动作、关键质量或审计门

可选上下文由任务合同预定义，如历史对话从20轮降到8轮但保留当前行程与规则；必需来源、关键验证器和人工发布不可为延迟删除。用户看到降级模型/资料范围、预计等待和人工入口，不能悄悄降低。

降级触发既看领先指标，也看用户侧服务指标，包括资源池利用率、队列时长、限流响应、超时和错误预算燃尽率。不能等到月度服务目标已经失败才开始降级。恢复时设置迟滞：指标连续稳定并通过小流量验证后才逐级回升，避免一级和二级状态反复切换，造成更多缓存与路由变化。

降级改变质量/成本，决策日志保存级别、触发、路由/配置、受影响对象与解除。事故后抽样验证替代输出和人工编辑；可用性成功不自动等于质量成功。

界面是降级控制的一部分。二级保护状态明确显示“使用备用模型，答案需额外核对”；三级连续性状态显示只读事实和排队时间；四级故障安全状态不能返回空白成功。坐席不能把旧草稿误认为当前行程。状态文案由业务和客服团队测试，不能把平台错误码直接展示给旅客。

降级检查表逐级列所需证据、可取消能力、禁止动作、人工入口、预计容量与恢复门。一次事故临时发现“没有短上下文提示”说明L1不可用，应直接到已验证L2，不在生产现场编辑提示词并称降级。

用22分钟事故走完容量下降、分流、人工接管和恢复对账

第0分钟提供商延迟/错误与合成任务同时告警；第2分钟判定安全容量从560降至约420，第3分钟熔断器限制坏路径并暂停P4，第4分钟P3只保留60 单元/秒，预测需求400.1；第6分钟启用已通过P1门的替代并显示降级，第8分钟320人人工排班进入P0连续性。

事件 INC-47：容量从每秒560个单位降至420个
准入需求：488.1 - 暂停P4的49 - 推迟P3的39 = 400.1
86,400个对象分别进入继续、重路由、排队、人工、逾期失败状态
全局额外尝试预算不超过5%，故障路径熔断，未形成重试风暴
第22分钟供应商恢复：1%小流量验证 -> 10% -> 受控恢复
P3排空：18,000/(260-220)=450秒
P2排空：6,400/(125-95)=213.3秒
每个对象重放前重新核验策略、截止时间和幂等状态

31,200+28,600+18,000+6,400+2,200=86,400。最后2,200个对象不是正确的策略拒绝，而是符合条件的P0任务没有在截止时间前获得可用草稿，因此计为可用性故障并通知人工。即使后来由人工完成，业务终态可以更新，原服务目标失败仍要保留。重复预订动作为0，是一条独立的硬门槛。

对象IT-8821在第5分钟进入P0时，主路由熔断器已经打开。获批替代路由可以访问同一旅客工作区，预计耗时9秒；准入仍保留12秒截止时间。生成在8.1秒完成，验证器通过，坐席在第10.4秒看到草稿并人工确认，因此计为P0成功，同时标记为降级路由。另一个对象IT-8840遇到来源访问控制服务超时；由于该用户刚被撤权，缓存不能使用，系统没有调用模型，而是在11秒时转人工并显示原因。它虽在截止时间内获得人工接管，AI路径按定义仍然失败，但业务状态保持安全。

IT-8912在主路由和备用路由都没有合格区域容量，第12秒进入故障安全关闭，归入2,200个失败对象。之后人工在第6分钟完成处理，也不能抹除原服务目标失败。三个对象分别证明，重路由、人工接管和无法准入不是同一个笼统的“异常”状态；事件账本必须保留每条路径、截止时间、人工过程和最终操作。

86,400 对账先按业务对象找缺失/重复，再对尝试/提供商呼叫、队列、人工和动作账本；发票多一次重试不会变两个对象，两个草稿也不能变两次权益动作。所有不一致有负责人，未解释前不关闭事故。

恢复时先让1%的固定案例和新流量做小流量验证，再扩大到10%。队列重放和新到达任务共同分配容量，既不能让旧队列饿死新的P0，也不能让新流量永远挤压积压任务。供应商恢复正常，但验证器或审计仍然落后时，系统要停在三级连续性状态。事件后分别修复客户端重试、容量系数、人工排班和供应商证据，不能只写一句“第三方问题”就结案。

错误预算把可靠性和变更速度连接，但不能让关键错误被普通成功抵消

预算以合格结果计算，不把严重错、数据越界或重复权益动作作为可花的普通失败；这些是零容忍停止门限。P0剩200个失败空间不足以支撑常规发布风险，团队冻结非必要模型/路由/功能，优先修事件和增加可靠性。窗口重置也不自动忘记根因。

Google SRE资料把错误预算定义为1减去服务目标，并用它平衡可靠性与变更速度。本文采用这一控制思想，但具体冻结政策由案例团队自行定义。燃尽警报同时观察短窗口和长窗口，既要发现快速事故，也要避免被偶发单点噪声误导。阈值以及告警、工单和日志动作，都写入本组织的运行手册。

若实际表现长期远超服务目标，也要重新检查额外储备成本是否值得，不能追求“100%可用”的口号。人工和故障切换演练能暴露假设，但不能机械照搬其他公司的做法。

错误预算策略写四类动作：剩余>50%允许常规金丝雀；20%—50%缩小变更并增加观察；<20%暂停非必要放行/扩量；耗尽只允许修复可靠性、关键安全与经负责人批准的紧急业务变更。例外记录原因、风险、范围、回滚和过期，不能口头绕过。

预算按通道独立计算，P1的大量成功不能补偿P0的关键失败。共享依赖事故可能同时消耗多个通道的预算，要分别记账。P3虽然延迟，只要在2小时内排空就不消耗失败预算，但仍要记录队列和延迟风险；在截止时间前完成可以计为服务目标成功，事故影响仍要进入可靠性复核和成本核算。

窗口边缘不游戏化：团队同时看28天滚动和短/长燃尽，不在月底清零后立刻大改。数据延迟时冻结高风险变更，不用“还没看到失败”当有预算。政策模板和每次决策记录供审计复算。

可观测性把追踪、指标、日志和业务终态连接：监控自身也有容量与降级策略

追踪要串联入口网关、身份、来源、模型、验证器、应用和工具，但不默认携带敏感全文。指标用于聚合，日志保存决策，内容快照按案例单独授权。OpenTelemetry官方区分追踪、指标、日志和上下文传递等信号；本文借用这一概念，不规定固定字段或保存期限。

遥测管道过载时，优先保留关键拒绝、外部动作、严重错误和事件记录，普通成功事件可以采样。必需审计缺失时，P0外部动作不能继续。监控延迟、事件丢失、时钟漂移和格式变化本身也要有服务指标；不能在事故中已经失明后，仍声称服务目标达标。

告警也要分级：立即威胁P0或边界的事件才通知值班人员；可以在数日内处理的容量趋势进入工单；其余信号保留记录供复核。每条告警必须有负责人、操作手册、可执行阈值和抑制规则，避免值班人员被重复的限流告警淹没。

高基数标签必须受控。工单编号用于追踪和受限日志，不能直接成为指标标签；指标按任务、应用、区域和状态聚合，防止监控成本和后端基数失控。跨组件上下文只传递必要的不可逆标识与声明，不能把旅客姓名、完整行程或提示词复制给每一个依赖。数据字典写清用途、访问、留存和删除规则。

仪表盘第一行按用户任务展示合格结果、95分位与99分位延迟、队列时长、关键错误、重复动作和人工负载；第二行才展示组件利用率、限流和内存。这样即使网关健康，只要验证器堵塞，页面也不会一片绿色。每张图表都链接原始查询版本与运行手册，避免事故中临时争论统计口径。

90天从测量、隔离、混合峰值到业务演练，不直接把全部坐席接入同一池

每批扩大坐席、区域、任务和峰值其一，其他保持固定；关键/数据/操作未过门不进容量测试。120坐席技术成功不能外推1,900，必须用真实到达相关性、长上下文和人工队列；合成负载用于规模，授权影子用于业务分布。

验收不能只看服务目标。关键错误为0、重复动作为0、策略边界、人工容量、支持工单、每个合格结果的成本和恢复时间都要一起看。某个通道容量不足，可以继续保持小范围或改成异步处理，不能靠降低质量或审计要求达到数字。

发布资产包括容量配置、仪表盘、告警、运行手册、负载包和恢复账簿；试点停止时撤临时配额/凭证/队列/数据，不能留下P4作业继续偷生产资源。

上线后每周看预算与队列，每月重做需求，每次配置变更重标工作单元

预测按15分钟到达量的分位、事件日、季节、增长和计划活动计算，不能使用月平均值。长上下文、尝试次数、供应商调用和人工分钟分别作为驱动因素。容量计划要给出正常、峰值、降级、单一依赖失败四种情境及负责人，而不是只写一个“最大并发”。

工作单元版本化。提示词增加证据、模型更新、提供商批次、检索改变或验证器变慢都会重测；旧/新桥接防止系数变化被误读为需求增长。安全容量有有效期与置信度，季度至少浸泡测试/恢复，重大变更立即。

采购的服务协议和配额要与内部服务目标建立映射。供应商只承诺接口可用，不等于企业获得了合格业务结果；配额充足，也不等于尾部延迟达标。合同中的速率、突发能力、支持、变更通知、区域、数据导出和事件证据写入依赖记录；人工路径和替代路由仍由企业自己验证。

交付容量与可靠性包：从一个业务对象到560单位/秒都可复算

Google SRE的服务目标章节强调从用户关心的服务指标定义目标、使用百分位，并为不同工作负载设置不同目标；其错误预算资料把1减去服务目标用于可靠性与变更决策。RFC 6585定义了HTTP 429“请求过多”，并允许通过“Retry-After”提示重试时间。MLCommons推理资料区分服务器、离线和交互式等场景，支持按负载形态测性能，而不是只看一个每秒请求数。OpenTelemetry区分追踪、指标、日志和上下文传递等信号。本文借鉴这些方法，但案例数值、工作单元、服务目标和策略均不是来源规定。所有来源核验于2026-07-21。

• Google SRE Book：Service Level Objectives
• Google SRE Book：Production Services Best Practices / Error Budgets
• Google SRE Workbook：Example Error Budget Policy
• RFC Editor：RFC 6585 / 429 Too Many Requests
• MLCommons：MLPerf Inference Submission Scenarios
• OpenTelemetry：Signals

实际落地时，先选一条最重要的真实任务，不要从“最大并发”开始。写出合格结果、截止时间、严重错误、人工路径和服务目标；采集15分钟到达量、输入与输出长度和服务时间，用生产候选配置测量拐点和安全容量；再分别为交互、批量和评估流量设置容量底线、队列、重试预算与降级阶梯。只有混合峰值、供应商容量下降25%、重试风暴和恢复回放都能保持资料与动作边界、单一终态和真实人工容量，才能扩大坐席范围。