一、为什么先做两个面板

1. 一个面板答一个问题

访问量面板回答“现在压力有多大”：请求在涨还是在跌、涨得有多快、集中在哪个接口。失败率面板回答“处理成功了多少”：失败占多少、失败集中在哪里、是什么类型的失败。

两个问题合起来，能判断出四种状态：量涨且失败涨、量涨但失败稳、量稳但失败涨、量跌而失败涨。四种状态对应的处置完全不同，这也是必须联动看的原因。

2. 其余指标是下钻，不是并列

首字延迟、单条生成速度、显存水位、队列长度这些指标都要采，但它们的位置在“下钻层”：先由两个面板发现异常，再往下钻到具体指标，定位到是哪一环。把它们全摆到首页，只会分散注意力。

判断一个面板做得好不好，有个简单标准：值班的人看一眼，十秒内能说出“现在正常还是不正常”。做不到这一条，图再多也是装饰。

3. 两块面板要能下钻

总览上看到失败率从零点几个点跳到三个点，点进去要能按维度拆：按接口、按调用方、按模型版本、按实例、按错误类型。拆不开的面板，只能告诉你“有问题”，不能告诉你“问题在哪”。

下钻路径要提前设计好，不要等出事时临时拼图。

二、访问量面板看四个维度

1. 总量与增速

总量按分钟或按小时聚合，重点看曲线形态而不是绝对值。三种形态各有含义：突增多半是上游批量调用或重试放大；缓慢下滑可能是某个调用方切走了流量；周期性波动要看是否与业务时段吻合。

看增速比看总量有用。量翻一倍用了五分钟还是用了五小时，处置方式完全不同。

2. 分接口

同一套服务往往挂着几个入口：对话类、摘要类、结构化抽取类。三类请求的处理成本差别很大，混在总量里看，会误判压力来源。

分接口看还有一个用处：某个接口的量突然归零，往往是调用方配置改了或链路断了，属于“静默故障”，不看分项发现不了。

3. 分调用方

按调用方拆开，能回答“这是正常业务增长，还是某个客户端在刷”。这一维度对重试放大尤其关键——一处重试策略写错，就能把总量抬高数倍。

分调用方也是配额与成本的依据。没有这一维，用量归属不清，后面算账会扯皮。

4. 输入输出长度分布

大模型服务与传统接口差别颇大的地方在这里：同样一次请求，输入几百字与输入几万字，成本差出两个量级。所以要单独看长度分布，而不只看请求条数。

三、失败率面板必须分层

1. 一个笼统的失败率没用

把所有失败加在一起算一个比例，只能得出“今天不太好”，得不出该怎么改。失败要按发生的位置分层，每层对应不同的责任方与处置动作。

2. 六层分法

第一层入口层：请求没进到服务就被拒，常见原因是限流、鉴权失败、参数格式不符。第二层排队层：请求进了队列但等太久，超时退出。第三层服务层：服务本身报错或崩溃。第四层模型层：模型拒绝生成、内容被拦截、输出格式不符合要求。第五层依赖层：检索、数据库、外部接口变慢或失败。第六层体验层：请求成功了，但调用方判定结果不可用，比如输出被截断、结构解析失败。

六层各自计数、各自看趋势。哪一层涨，责任方就清楚了。

3. 超时要单独统计

超时是容易被混进“失败”里的一项，但它与真正的错误完全不同：错误意味着某处坏了，超时往往意味着容量不够或某处变慢。两者混在一起，会让人误以为系统出了故障，实际上该做的是扩容或优化。

超时还要分两段看：等首字的时间，与生成过程的时间。首字慢说明排队或调度有问题；生成慢说明单条处理成本变高，常见于输出变长。

4. 失败率要能按版本拆

每次换模型版本、改推理参数、调整提示，都要在监控数据上打标签。否则失败率一涨，没人能判断是不是这次变更引起的。

这条在实践中容易被漏。版本标签不在监控里，就只能靠回忆“昨天是不是改过什么”。

四、两个面板要联动看

1. 量涨、失败涨

常见的解释是容量不足：请求进得比处理得快，队列堆积，超时增加。判断依据是队列长度是否同步上涨、首字延迟是否同步变长。若两者都涨，问题在容量。

处置动作是扩容或限流。要防的是盲目扩：如果失败集中在一层，比如鉴权失败，那扩多少实例都没用，因为请求根本没进到需要处理的那一步。

2. 量涨、失败稳

这是比较健康的状态，说明容量还有余量。仍要做两件事：看延迟分位值有没有悄悄上移；看显存水位是否接近上限。这两项是提前预警，等到失败率起来时已经晚了。

3. 量稳、失败涨

这一类尤其需要警觉，因为大概率是变更引起的：新版本上线、依赖方抖动、证书或密钥过期、上游接口改了返回结构。排查顺序是先看近期的变更记录，再看各层的失败分布。

判断办法很直接：把失败率曲线与变更记录叠在一起看，两条线是否在同一时刻拐弯。

4. 量跌、失败涨

两种可能：一是上游链路断了，请求进不来，同时进来的那些也失败；二是调用方在重试，但每次重试都失败。这种组合往往意味着服务对外的入口出了问题，要看入口层的失败构成。

五、告警怎么分级

1. 分三级，各走不同渠道

一级是用户可感知的中断：失败率超过阈值并持续数分钟、核心接口成功率为零。这类直接打到值班渠道，要求有人立刻响应。二级是趋势异常：延迟分位值上移、队列持续增长、容量接近上限。这类进工作群，当天处理。三级是记录类：偶发单次失败、个别调用方异常。这类只进日报，不打扰人。

分级的意义是保住注意力。所有告警同级，等于没有告警。

2. 双窗口

同一类异常用长短两个窗口各配一条规则：短窗口抓突发，长窗口抓缓慢劣化。只用短窗口，慢慢变坏的情况会一直不触发；只用长窗口，突发要等很久才报。

两个窗口的阈值不同，短窗口的容忍度更低但持续时间更短，长窗口相反。

3. 静默与抑制

计划内的变更要做静默，防止自己制造告警。

4. 每条告警必须对应一个动作

配告警时问一句：这条响了之后，值班的人具体做什么？答不上来的，就不该配成告警，应该做成报表或趋势图。

这条规则能砍掉大半无效告警。

六、值班的三分钟路径

1. 第一分钟：判断范围

先确认三件事：影响的是全部接口还是某个接口；是所有调用方还是某个调用方；是一类错误还是多类混杂。三个问题各看一眼，范围就大致定了。

2. 第二分钟：判断方向

按范围对号入座：全部接口全挂，先查入口与依赖；单接口挂，查这个接口对应的服务与模型；单调用方挂，查它的鉴权与请求形态；多类错误混杂，查近期变更。

3. 第三分钟：决定动作

三种动作选一个：扩容、限流降级、回退版本。选哪个取决于前面两步的判断。若三分钟内判断不出来，就先做保护性动作——限流保住核心链路，再继续排查。

4. 把路径写成一页

把上面三步写成一页纸，贴在值班能看到的位置。真出事时，人是慌的，一页纸比一篇文档有用。

七、每周沉淀什么

1. 一份基线表

按模型版本、实例规格、输入长度区间，记录一组基准值：单实例稳定承担的路数、首字延迟分位值、单条生成速度、显存水位、失败率。有这份表，后面任何一次异常都能快速判断“是业务变了，还是系统退化了”。

没有基线，只能凭感觉说“好像比以前慢”。

2. 一次告警复盘

每周挑一条告警复盘三件事：是不是误报、有没有被及时看到、处置动作对不对。误报多的规则要改阈值或降级，长期不触发的规则要复查是否还有意义。

结语

运维能做住，靠的不是指标多，而是注意力集中。访问量告诉你压力有多大，失败率告诉你处理成功了多少，两者联动能定出四种状态，四种状态各有各的处置方向。失败率必须分层，否则只会得出“今天不太好”这种结论；告警必须分级，否则真问题会被噪音淹没。

落地建议：先把两个面板做出来，各带下钻；再按六层把失败率拆开，配上版本标签；然后按三级配告警，每条都对应一个具体动作；最后写一页值班路径、建一张基线表。判断这套运维是否成立，标准很实在：某个工作日下午流量突然翻倍，值班的人不看文档、不问人，六分钟内能说出问题在哪一层，并且已经做了止血动作。