云原生服务的运营止损设计

云原生服务的运营止损设计云原生推理服务的止损方案应该在故障前约定触发条件、限制动作、用户提示和恢复验证。等队列已经失控再临时调参数通常只能看到多个问题叠在一起请求仍在进入旧任务没有取消上游开始重试扩容实例又因模型加载而迟迟不能接流量。大模型服务与普通短请求接口的差异主要在资源模型。输入长度、输出上限、并发请求和 KV Cache 会共同影响显存与完成时间流式响应还会让连接保持更久。因此单看 Pod 存活或 HTTP 状态码不足以判断服务是否还能接收新任务。先定义要保护什么止损不是简单地“发现异常就重启”。需要先区分用户任务、推理实例和整个服务三个层次。单个任务超过自己的时间或 Token 预算时可以取消后续生成并返回明确状态某个实例持续拒绝请求或资源无法回落时可以停止给它分配新任务让已开始的请求在有限窗口内结束整个集群接近容量边界时则要在入口限流避免所有实例同时进入排队状态。这些动作不能由一个模糊的“负载高”告警触发。应组合观察入口速率、排队任务、首 Token 与完成延迟、取消数量、错误类别、GPU 利用和 KV Cache 占用。具体指标名称会随推理引擎与版本变化部署前要从实际暴露的指标中核对不能直接复制另一套环境的 PromQL。阈值同样没有通用答案。先用代表性请求做容量测试记录在不同输入长度和并发下队列何时开始持续增长。止损线应早于资源耗尽点并留出停止接流、迁移流量和实例恢复的时间。健康检查分为存活、就绪与容量Liveness 只回答进程是否需要重启不应因为短时排队就频繁杀 Pod。Readiness 用来决定实例能否继续接收新请求可以结合模型是否加载完成、关键依赖是否可用和当前实例是否处于 drain 状态。容量指标则交给入口限流或调度器避免把每次压力波动都转换成实例重启。自定义检查还要限制开销。健康接口不能执行一次真实的长文本推理也不能在每个探针周期访问多个外部系统。它应读取服务内部已经维护的状态并为数据过期或采集失败提供独立结果。监控缺失不能当作零负载。下面的 Python 示例把“取不到指标”保留为None决策函数在证据不足时返回UNKNOWN只告警并阻止自动扩张动作。它不直接修改 Kubernetes 资源实际处置应交给有审计和权限边界的控制器。from dataclasses import dataclass from enum import Enum from typing import Optional class Decision(str, Enum): ACCEPT accept LIMIT limit DRAIN drain UNKNOWN unknown dataclass(frozenTrue) class Signals: waiting: Optional[float] cache_ratio: Optional[float] error_ratio: Optional[float] dataclass(frozenTrue) class Limits: waiting: float cache_ratio: float error_ratio: float def evaluate(signals: Signals, limits: Limits) - Decision: values (signals.waiting, signals.cache_ratio, signals.error_ratio) if any(value is None for value in values): return Decision.UNKNOWN assert signals.waiting is not None assert signals.cache_ratio is not None assert signals.error_ratio is not None if signals.error_ratio limits.error_ratio: return Decision.DRAIN if ( signals.waiting limits.waiting and signals.cache_ratio limits.cache_ratio ): return Decision.LIMIT return Decision.ACCEPT这里的DRAIN也只是建议状态。执行前还要确认是否有其他健康实例、最大可隔离比例、当前是否处于发布以及该实例上的任务如何结束。自动脚本一次把所有匹配 Pod 改标签可能让服务瞬间失去后端修改标签是否影响路由也取决于 Service 与流量规则的实际选择条件。在入口控制排队和重试推理服务最怕的是隐藏队列。网关允许大量请求等待推理引擎内部又有一层队列客户端超时后继续重试三个位置看到的负载会完全不同。应明确谁负责排队并给等待设置容量和时限。达到边界后尽快拒绝比让请求等到客户端自行超时更容易恢复。重试要按错误分类。参数无效、内容被拒绝、预算耗尽和输出校验失败原样重试不会变好。连接在请求送达前中断或服务明确返回短暂不可用时才可能在剩余预算内有限重试。对于流式任务客户端断开后要把取消信号传到推理引擎不能只关闭浏览器连接。Service Mesh 的连接池与异常实例剔除可以作为外围防线但它不了解 Token 长度和模型队列。配置值应通过当前负载验证并与应用层容量控制配合。普通 HTTP 重试策略不要直接套在昂贵的生成接口上是否重试、是否切换备用模型都需要业务层知道。切换小模型并非无感降级。模型能力、上下文上限和输出风格可能变化用户应知道当前结果来自降级路径。对格式要求严格或涉及外部动作的任务宁可暂停并等待人工也不要为了保持“可用”而返回未经验证的结果。恢复条件比触发条件更容易漏限流后看到队列下降不代表可以立即恢复。先确认入口速率已经稳定、旧任务完成或取消、实例资源回落并用一组短请求检查首 Token 和完成状态。放量要分阶段进行若队列再次增长回到上一档限制。被 drain 的实例恢复前应核对模型、配置和依赖版本确认不是某个特定版本导致错误。重启只能清除当前状态无法证明根因消失。若指标采集本身有缺口先修复观察能力再恢复自动处置。复盘关注完成任务而不是漂亮的可用率运营报告可以同时看请求接受率、在目标时间内完成的任务比例、排队与生成耗时、取消是否生效、单位完成任务的资源消耗。长短请求最好分组统计否则大量短请求会掩盖复杂任务持续失败。每次止损记录触发信号、采取动作、受影响任务、未知状态和恢复依据。不要补写没有来源的“优化百分比”也不要用一次平稳运行证明方案永久有效。容量、模型版本和流量结构变化后阈值都需要重新验证。有效的止损设计是让服务在过载时少接任务、尽快说明状态并保住可以正确完成的部分。入口限流、实例 drain 和用户降级各自有边界把它们串成可观察、可回退的流程才不会在一次资源波动中同时触发重试、扩容和重启。