清单为什么有用
Redis 变更上线前按固定顺序核对：变更内容与回滚方案、影响实例与角色、执行窗口、备份与持久化状态、观察指标定义、执行与验证。清单的价值在于把记得做变成按表做，尤其是回滚方案这类平时想不到、出事时救命的部分。它是流程约束，不是文档装饰。
基本信息
| 前置项 | 备份与持久化状态确认 |
|---|---|
| 执行约束 | 低峰窗口，且可回滚 |
| 后置项 | 指标观察窗口与变更记录 |
| 适用变更 | 配置调整、版本升级、拓扑变更、批量数据操作 |
| 产出 | 变更单与观察指标表 |
典型使用场景
- 配置项调整，例如 maxmemory、timeout、save 策略
- 版本升级或重启前的状态确认
- 拓扑变更：加从库、迁移槽位、切换主库
- 新参数的灰度试点与验证
- 大规模数据导入或清理前的准备
变更前后核对命令
变更前后核对命令
redis-cli INFO persistence # 确认 RDB/AOF 状态与最近一次落盘是否成功
redis-cli INFO replication # 确认角色与从库链路，评估变更影响面
redis-cli INFO memory # 记录水位基线，便于事后对比
redis-cli CONFIG GET maxmemory # 记录待改配置的当前值，作为回滚依据
redis-cli SAVE # 手工落一份 RDB，形成可回退的数据点
# 变更后按观察表逐项验证：延迟、错误率、连接数、主从延迟、内存水位阶段与检查项
| 阶段 | 检查项 | 目的 |
|---|---|---|
| 前置 | 备份与持久化状态 | 确保存在可回退的数据点 |
| 前置 | 影响实例与角色 | 明确爆炸半径，决定通知范围 |
| 执行 | 低峰窗口 | 缩小受影响的人群 |
| 执行 | 回滚方案与触发条件 | 出问题时能快速回退 |
| 后置 | 观察指标定义 | 用数据确认变更生效且无副作用 |
| 后置 | 变更记录归档 | 复盘与审计的依据 |
涉及不可逆操作的变更（清库、大键删除、拓扑切换）必须单独标注，并安排双人复核后再执行。
变更后的观察窗口太短，会把慢性问题留到次日暴露。窗口长度按变更类型定，配置类变更至少覆盖一个业务高峰。
把观察指标提前写进变更单，执行完直接按表核对，比凭印象判断有没有异常可靠得多。