四层监控各看什么
怎么分层：硬件层看显卡利用率、显存、温度与校验错误；推理层看排队长度、首字延迟分位与失败率；业务层看任务成功率与接管率；成本层看单位任务花费。四层缺一层，问题就会在别处冒出来。
告警要分级
把告警分成影响业务、影响容量、仅需记录三级，分别对应电话、值班群与日报。为什么必须这样分：所有告警都打电话，两周后值班人员就会静音，真正的事故反而没人接。阈值按基线设，不照抄默认值。
版本与配置可回滚
模型、提示词、依赖镜像、网关配置都要有版本号与回滚包。怎么做：每次变更前留存当前镜像与配置快照，变更后跑固定评测集；没有回滚包的变更不应进入生产，这条规则比任何工具都重要。
容量与巡检按节奏做
按月做容量预测，按季做故障演练与权限复核，按年做架构评估。为什么强调巡检：不是走形式：要把上次遗留项逐条关闭，否则问题一直挂在清单上，直到某次故障把它们一起引爆，再补救代价更高。
适用与不适用
适合谁
- 已上线私有化环境、需要长期运维的团队
- 需要向审计提供运行记录的机构与部门
- 准备承接二期扩容的运维项目组与责任人
不适合谁
- 尚未交付、没有运行环境的在建项目
- 把所有运维工作全外包且不设接口人的单位
典型场景
一家医院的信息科在私有化问答上线后，把值班表与告警分级贴到工位：显存告急发值班群，服务不可用打电话，成本异常进日报。每月复盘一次遗留项，季度做一次断网演练，运维手册随变更同步更新。
可执行步骤
- 列出四层监控指标与采集方式，明确采样频率与保留周期，形成文档
- 按影响程度给告警分级，绑定通知渠道并指定值守责任人，写进值班表
- 为每次变更准备镜像与配置快照，留存可直接回滚的完整包，留档备查
- 按月复盘遗留项，按季做故障演练与权限复核，记录结论并形成纪要
- 把运维手册与变更记录纳入审计留痕，每季核验一次并指定保管人
常见坑
- 只监控服务存活状态，不看排队与延迟，用户先感知到变慢，排查时完全没有数据可依。
- 所有告警都推给同一个人，两周后他开始静音，真正的事故被漏掉且无人复核，损失扩大。
- 变更不留镜像与配置快照，出问题只能整体重装，恢复时间不可控，业务方也难以安排停服窗口。
自检与验收清单
- 四层指标都有采集与看板，口径统一可查
- 告警分级已绑定通知渠道与值守责任人
- 每次变更都留存可回滚的镜像包与配置
- 遗留项按月关闭，并逐条记录关闭原因
- 运维手册随变更同步更新，并每季复核
常见问题
监控工具必须买商业版吗
不一定。开源方案足以覆盖指标采集、看板与告警，成本主要在部署与维护人力。选型时优先看是否支持长期存储与审计导出，以及团队是否熟悉，工具再强、没人会配也等于没有。
值班一定要全天候吗
取决于业务时段与承诺。只在工作时间使用的内部系统，可以设工作时段值班加次日处理；对外服务或生产关键系统则需覆盖全时段，否则夜间故障会累积到早上，处置成本更高。
模型更新后效果变差怎么发现
靠固定评测集与业务指标双轨监控。每次更新后跑同一组评测，比较成功率与典型错误类型；同时看接管率与投诉量是否异常。只看主观感受容易误判，也说不清是模型问题还是提示词问题。