变更窗口为什么要有回归清单
发布与网络变更之后最容易发生的不是「彻底不通」，而是指标悄悄劣化：解析变慢了几十毫秒、重传率从万分之几涨到千分之几、连接数上限被逼近。这些变化不会立刻报警，却会在流量上涨时集中爆发。回归清单的作用是把关键指标在窗口内逐项核对一遍，用变更前后的增量而不是绝对值来判断，让问题在窗口内被拦下来。
基本信息
| 检查项 | 解析、连通、端口监听、证书有效期、超时配置、连接数、错误日志与关键计数 |
|---|---|
| 方法 | 变更前采集基线，变更后对比增量，重点看重传、溢出与错误率 |
| 记录 | 两次采样与时间戳存档，作为回滚与复盘的判据 |
| 自动化 | 写成脚本配定时任务，降低人工遗漏 |
| 适用时机 | 发布、割接、扩容、策略调整等任何网络相关变更 |
典型使用场景
- 发布后验收：确认接口响应与关键指标未劣化再宣布完成
- 割接切换后核对：确认解析与连通的路径都符合预期
- 扩容后验证：新节点是否真正承接流量且健康检查正常
- 策略调整后确认：确认端口与来源放行未误伤其他业务
- 回滚决策：用清单里的量化指标替代主观感觉
最小回归清单
最小回归清单
dig +short api.example.com
ss -tlnp | grep -E ':80|:443'
ss -Htan state established | wc -l
nstat -az | grep -iE 'ListenOverflows|RetransSegs' | head
curl -sS -o /dev/null -w 'code=%{http_code} dns=%{time_namelookup} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://api.example.com/healthz
dmesg -T | tail -20 # 内核侧是否有新的告警检查项与判据
| 检查项 | 采集方式 | 劣化信号 |
|---|---|---|
| 解析 | 查询关键域名并看 TTL 与耗时 | 解析变慢或指向异常节点 |
| 连通与端口 | 查看监听与连接状态 | 监听丢失或队列溢出 |
| 握手与首字节 | 分段计时模板 | 相对基线明显上升 |
| 重传与溢出 | 内核统计计数 | 增量高于变更前基线 |
| 连接规模 | 已建立连接数与状态分布 | 连接数异常上涨或堆积 |
| 内核日志 | 带时间的内核日志尾部 | 出现新的告警条目 |
回滚判据要事先写清楚，例如错误率超过百分之一或首字节耗时超过两秒立即回滚，避免在故障中争论；但网络类问题不一定靠回滚解决，先定位再决策。