四层监控指标
基础设施看 GPU 温度、显存、磁盘与电力；服务层看成功率、分位延迟与队列长度；边界层看出站请求与白名单偏差；业务层看任务完成率与人工接管率。为什么分层：只看资源会漏掉业务退化，只看业务又定位不到根因，四层要能按同一个 trace 串起来。
出站异常告警
为出站流量设基线，出现新目的地址、非常规端口或流量突增时立即告警。怎么做：把白名单做成配置而非硬编码，变更走审批；边界是告警不能只发邮件，要有值班接收与升级路径，否则夜里发生的异常要到第二天才被看到。
日志脱敏与访问控制
日志用于排障，但不能成为新的泄露渠道。怎么做：按字段分级，敏感内容落库前脱敏或加密，访问日志本身也要留痕；边界是排障需要与最小化原则冲突时走临时授权并设定到期时间，不能长期开着全量，也不要多人共用同一个账号。
版本灰度与容量自查
模型、推理引擎与脱敏规则的变更都要灰度，先小流量验证再全量，并保留可回滚的上一版本。为什么重要：本地环境缺少外部兜底，一次错误的权重替换可能让回答质量整体下滑。按周看资源水位，按季做边界自查并留档。
适用与不适用
适合谁
- 已在本地运行模型服务、需要长期维持边界的运维团队
- 要建立值班与告警机制的信息中心与安全部门
- 承担托管运维、需要向客户证明边界有效的服务商
不适合谁
- 仍在选型阶段、尚未上线任何本地服务的项目
- 没有人力接收告警、也不准备建值班机制的小团队
典型场景
某能源企业的本地推理环境上线半年后，运维在月度巡检中发现一个新增的出站目的地址，追查是监控代理升级后默认上报。团队把上报字段改为脱敏摘要并加入白名单审批，同时把出站基线告警接入值班手机。季度自查时又发现两条过期权限，一并回收并注明了处理人。
可执行步骤
- 按四层列出监控指标、告警阈值与责任人，并写入运维手册与值班表
- 建立出站流量基线，把白名单做成可审批的配置并接入值班告警手机
- 对日志字段做分级与脱敏改造，同时限制可访问的人员范围与账号权限
- 为模型、引擎与脱敏规则变更配置灰度比例，并准备一键回滚脚本演练
- 每季度做一次边界自查，形成留档报告并跟踪整改到闭环与具体责任人
常见坑
- 只监控服务器资源，不监控出站流量，数据从旁路流出很久都无人发现，边界实际上已经破了。
- 告警只发邮件而无人接收，夜间异常拖到次日，处置窗口被浪费，小问题被拖成需要上报的事件。
- 排障时临时开放全量日志，事后没有关闭，日志变成长期泄露源，还可能被内部人员滥用。
- 模型升级不做灰度，一次替换导致回答质量整体下滑，只能整批回退，业务中断时间被拉长。
自检与验收清单
- 四层监控指标是否都有阈值、责任人与升级路径
- 出站流量基线是否覆盖全部服务与全部时段并留档
- 日志敏感字段是否脱敏，访问是否留痕可审计
- 模型变更是否配置了灰度比例与一键回滚脚本
- 季度自查报告是否留档并跟踪整改到闭环状态
常见问题
本地部署还需要七乘二十四小时值班吗？
取决于业务时段与服务承诺。至少要有告警接收人与升级路径，夜间可以按等级决定是否响应。完全无人值守时，出站异常与资源耗尽往往要等到次日才发现，代价可能高于值班投入。
日志里能存用户原文吗？
要看用途与保存期限。排障需要与最小化原则要平衡，建议分级存储、限期清理，并对敏感字段脱敏或加密。访问日志本身要留痕，避免日志成为绕过权限的另一条数据通道。
季度自查具体查什么？
流量与白名单核对、权限与账号复核、删除记录抽查、模型与规则变更记录、备份恢复演练结果。每项都要有结论与责任人，发现问题要登记整改并跟踪到关闭，不能只写一句已检查。