分级上报是什么
排障不是独角戏，升级也不是甩锅。分级上报是事先约定好『各自边界内先自证到什么程度、什么条件下带着哪些证据升级给谁』的规则：应用组先证明自己的服务与网络依赖状况，网络组再证明链路与设备状况。缺少这条规则时，最常见的结果是把未定位的问题直接丢给下一环，对方一测全通又弹回来，时间全部消耗在往返上。
基本信息
| 升级前必备 | 现象、影响面、时间线、已做的测试与结论、当前假设 |
|---|---|
| 升级对象 | 按边界划分：主机、网络、应用、数据库、云厂商、运营商 |
| 原则 | 带证据升级，不带情绪升级；先自证再外推 |
| 输出物 | 一份可直接转发的信息包，对方无需再问你要背景 |
典型使用场景
- 怀疑网络问题但需要先排除应用自身：先在应用侧拿到证据再升级，避免被退回
- 跨团队协作故障：明确谁在下一次跟进、什么时间点前给出反馈
- 云厂商工单：把实例侧与平台侧的观察分开列，便于对方定位到具体产品
- 重大故障指挥：升级同时通知相关方，避免多个团队重复排查同一对象
升级信息包模板
升级信息包模板
【问题一句话】X 服务 10:05 起约 30% 请求超时
【影响面】仅北京办公区用户；上海正常
【已排除】DNS 解析正常、端口可达、本机负载正常、日志无异常
【关键证据】curl -w 阶段耗时、mtr 结果、抓包摘要（附文件与时间戳）
【当前假设】出口线路或中间设备丢包
【具体请求】请协助检查 10:05-10:20 出口链路的丢包与限速情况按边界划分责任
| 边界 | 自证内容 | 常见反证现象 |
|---|---|---|
| 应用 | 错误率、耗时分布、发布与配置变更记录 | 只有一个接口慢，其他都正常 |
| 主机 | CPU/内存/磁盘/连接数、内核计数（含重传） | 多目标同时异常，指向本机栈或出口 |
| 网络 | 路径时延与丢包、设备计数、策略命中 | 不同目标表现一致，指向本机出口 |
| 云平台 | 安全组、网络 ACL、路由、网关指标 | 同一 VPC 内其他实例正常 |
把『已排除项』写清楚能省掉对方大量重复劳动：它是升级包里信息密度最高的部分，也是自己排查质量的直接体现。
升级不等于停止跟进：约定反馈时间点，超时未回复要主动推进并升级到上一层，避免问题在某个队列里静默躺平。