支援信息清单是什么
无论找同事、找云厂商还是找运营商，一份标准信息包都能显著加速处理：它迫使你把现象、范围、时间与已做测试整理成可行动的问题描述。对方最需要的是可执行的复现线索，而不是背景故事。信息包不是越全越好，与问题无关的输出会稀释重点，反而延长沟通。
基本信息
| 必备要素 | 现象、影响范围与优先级、起始时间、涉及对象、已做测试、最近变更、诉求 |
|---|---|
| 涉及对象 | 域名、IP、端口、线路编号、实例 ID、工单号 |
| 输出要求 | 命令原始输出带时间戳，便于对齐现场 |
| 避免 | 无时间戳的截图、与问题无关的大段日志 |
典型使用场景
- 首次向云厂商提工单：一次性给出实例 ID、时间窗与自测结论
- 向运营商报障：附 mtr 长样本与光猫状态截图
- 跨团队协作：让对方无需追问即可接手，减少来回
- 变更相关故障：附上最近一次变更的时间与内容
- 疑难问题升级：把之前所有测试的结论与证据打包提交
一键归档现场输出
一键归档现场输出
# 把后续所有输出同时写入带时间戳的日志文件
LOG=/tmp/ticket-$(date +%F_%H%M).log
exec > >(tee $LOG) 2>&1
# 记录基础环境信息
date -R; ip -br a; ip route; cat /etc/resolv.conf
# 记录解析与路径信息
dig +short example.com
traceroute -n 8.8.8.8 | head -20
# 需要挂起时保留现场
free -m; ss -s | head -5信息要素对照
| 要素 | 为什么要 | 示例写法 |
|---|---|---|
| 一句话现象 | 让对方立刻理解问题 | 10:05 起约 30% 请求超时 |
| 影响范围 | 决定优先级与资源投入 | 仅北京办公区，上海正常 |
| 时间窗 | 便于对方查同期数据 | 10:05-10:20 稳定复现 |
| 已排除项 | 省掉对方重复劳动 | DNS、端口、本机负载均正常 |
输出文件务必带时间戳：几天后回看时，只有文件名能告诉你这是哪次故障的现场，缺少时间戳的归档在复盘时几乎无法使用。
提交前检查是否含有敏感信息（内部主机名、账号、密钥片段）：工单与外部平台往往有留存与共享机制，原始输出需要先做必要脱敏。