主题
Checklist 大全（上线 / 巡检 / 应急 / 安全 / 容量 / 割接 / 灾备）
本页是可逐条勾选的运维检查清单，每条都附"判定标准"，用来当上线前和日常的红线检查。 用法：复制对应清单到你的工单/发布单里，逐条打勾；任何一项不通过就停下来，不要"差不多就行"。 配套模板见 运维文档模板；指标口径见 SLO 与错误预算。
一、上线前检查（发布前必过）
| 检查项 | 判定标准（不满足就不准发） |
|---|---|
| 回滚预案 | 已写回滚步骤，且在测试环境验证过回滚能在 X 分钟内恢复 |
| 监控就绪 | 新版本的核心指标（错误率、延迟、QPS）有看板和告警 |
| 配置核对 | 新配置已在预发/测试环境验证，无硬编码、无遗留调试开关 |
| 数据库变更 | 表结构变更有备份、兼容旧版本、有回滚 SQL |
| 依赖确认 | 上下游（缓存、MQ、第三方接口）已同步兼容 |
| 流量灰度 | 支持灰度/分批发布，能先放 1%~10% 流量观察 |
| 资源评估 | 新版本资源占用不超预订，不会打满现有实例 |
| 时间窗口 | 业务低峰、非节假日/大促前发布 |
| 通知到位 | 业务/客服/值班已知情，应急联络人在线 |
红线
没有回滚预案 = 不准上线。 这一条没有例外。发布最常见的事故不是新版本有 bug，而是出问题后回不去。
二、日常巡检（每日/每周）
| 频率 | 检查项 | 判定标准 |
|---|---|---|
| 每日 | 系统可用性 | 核心链路可用性 ≥ 约定 SLO（如 99.95%） |
| 每日 | 告警情况 | 无 P0/P1 未恢复告警；昨日告警已分类 |
| 每日 | 资源水位 | CPU/内存/磁盘/带宽无 >80% 的持续告警项 |
| 每日 | 磁盘与 inode | 磁盘使用率 <70%（>80% 需清理），inod 不超 80% |
| 每日 | 日志与报错 | error/fatal 日志无突增 |
| 每周 | 备份有效性 | 抽验一次备份能不能恢复（不是只看备份成功） |
| 每周 | 证书/密钥 | 证书剩余有效期 >30 天（<30 天立即续期） |
| 每周 | 安全补丁 | 高危 CVE 已在排期内 |
| 每周 | 容量趋势 | 按增长趋势评估，是否在 1 个月内会触顶 |
巡检能自动化的都自动化（见 Python 运维自动化）。巡检的价值不在"看过"，在"异常被发现"。
三、应急响应（故障发生时）
| 阶段 | 检查项 | 判定标准 |
|---|---|---|
| 止血 | 先恢复还是先找根因 | 优先止血（回滚/降级/扩容），根因之后查 |
| 定界 | 影响范围 | 已明确影响的系统、用户、量级，并通知相关方 |
| 指挥 | 明确一个指挥人 | 应急有唯一指挥，避免多人同时操作 |
| 沟通 | 状态同步 | 每 X 分钟对外同步一次进展，别让所有人干等 |
| 操作 | 高风险操作双人确认 | 回滚/重启/删数据等操作需第二人复核 |
| 恢复 | 验证恢复 | 核心指标回到正常区间，持续观察 X 分钟 |
| 收尾 | 复盘安排 | 48 小时内安排复盘，输出行动项（见 复盘模板） |
应急铁律
先止血、后找因。 很多故障拖长，是因为大家急着在生产环境里边猜边改，越改越乱。能回滚就先回滚。
四、安全基线检查
| 检查项 | 判定标准 |
|---|---|
| 账号 | 无共享账号、离职账号已禁用、无默认弱口令 |
| 登录 | SSH 禁止 root 直接登录、禁密码登录改用密钥、有失败锁定 |
| 权限 | 遵循最小权限，生产账号非必要不给 sudo |
| 端口 | 无暴露公网的数据库/缓存/管理端口，有防火墙白名单 |
| 密钥 | 代码仓库无明文密钥，密钥有定期轮换机制（见 密钥管理） |
| 补丁 | 高危漏洞已修复/排期 |
| 审计 | 关键操作有审计日志（见 跳板机） |
| 数据 | 敏感数据加密存储、备份介质同样受保护 |
五、容量评估（扩容/压测前）
| 检查项 | 判定标准 |
|---|---|
| 现有水位 | 峰值 CPU/内存/带宽/连接数 <70%，有余量 |
| 增长预测 | 按业务增速评估，当前容量能支撑的天数（>1 个月才安全） |
| 压测验证 | 目标容量经过压测验证，不是拍脑袋 |
| 瓶颈定位 | 明确系统瓶颈是 CPU / 内存 / 网络 / 磁盘 / 连接数中的哪一类 |
| 扩展方式 | 知道是垂直扩容还是水平扩展，有无状态、能否平滑扩 |
| 成本 | 扩容后成本在预算内（见 FinOps） |
| 应急预案 | 扩容失败/压测不达标时有备选方案 |
容量方法论与灾备见 容量规划、高可用与灾备。
六、迁移 / 割接检查
| 检查项 | 判定标准 |
|---|---|
| 方案 | 有完整割接方案（见 变更/割接模板） |
| 数据校验 | 迁移前后数据一致性已校验（行数、抽样校验、checksum） |
| 预演 | 至少在测试/预发环境完整演练过一次 |
| 回退窗口 | 明确回退时间点和回退步骤，超过窗口立刻回退 |
| 流量切换 | 支持灰度切流，可随时切回旧链路 |
| 双跑观察 | 新旧链路并行观察 X 小时，确认无差异 |
| 通知 | 业务方、上下游、客服已知情，有应急联络 |
| 资源 | 新环境资源已就绪并验证，不是割接当天才申请 |
七、灾备演练（定期做，否则等于没有灾备）
| 检查项 | 判定标准 |
|---|---|
| 备份可恢复 | 真实做过一次恢复演练，恢复时长在目标 RTO 内 |
| RTO/RPO | 明确业务能接受的恢复时间（RTO）和数据丢失量（RPO） |
| 切换演练 | 真实切到灾备环境跑通一次，不是只看备份文件 |
| 数据一致性 | 灾备数据与主库一致，无静默延迟/损坏 |
| 回切 | 灾备切回主环境的流程同样演练过 |
| 责任人 | 演练有明确负责人和时间计划，每年至少一次 |
| 演练报告 | 演练结果、发现的问题、整改项已记录 |
灾备最大的误区
"备份成功"不等于"能恢复"。 大量企业的备份从没恢复过，真到灾难时才发现备份是坏的。定期恢复演练是灾备唯一的验证方式。
使用建议
- 把这份清单变成发布单/巡检工单的必填项，而不是存在文档里吃灰。
- 每条 checklist 都要能"自动判定"的尽量自动化（脚本/平台），人工只留需要判断的部分。
- 定期回头看：哪些项总是"不通过"，那就是系统性问题，值得做成项目去根治，而不是每次靠人盯。
相关速查
- 配套的文档模板：运维文档模板
- 指标与可用性口径：SLO 与错误预算
- 容量与灾备方法论：容量规划、高可用与灾备
- 混沌工程（主动制造故障来验证韧性）：混沌工程
- 把巡检/应急操作自动化：Python 运维自动化
- 安全加固基线：Linux 安全
官方文档
- Google SRE Book（灾备与可靠性）：https://sre.google/sre-book/table-of-contents/（需科学上网）；国内平替：https://blog.csdn.net/sanhewuyang/article/details/162757718
- DORA 研究（变更与稳定性基准）：https://dora.dev/research/