可靠性 —— 系统如何保持健壮¶
xiangqin 每天在背后跑6 个自动化演练 + 1 套指标观测，保证服务不会悄悄失效。这一页说清楚我们做了什么、为什么，以及你可以怎么验证。
两类风险，两套策略¶
| 风险 | 场景 | 策略 |
|---|---|---|
| 防腐烂 | 备份恢复、机器迁移这类"半年才用一次"的流程，真要用时才发现已经坏了 | 定期自动演练 → 早发现 |
| 防降级 | 响应变慢、错误率悄悄抬升，用户反馈才知道已经晚了 | 每日聚合指标 + 徽章可视化 |
行业叫法：Chaos Engineering（Netflix 首创）+ Observability（Google SRE）。大厂标配。
6 个自动化演练 + 1 套指标¶
每个都在 GitHub Actions 上定时自动跑。你可以打开 repo 的 Actions 页面看历史成功率。
防腐烂（4 个备份恢复演练）¶
| 代号 | 一句话 | 频率 |
|---|---|---|
| M1 备份新鲜度 | 每小时问一次云存储："最新备份是多久以前的？" 超过 26 小时就报警 | 每小时 |
| M2 备份完整性 | 每天把最新备份下载到本地，用 sqlite 工具打开，确认文件没损坏、核心表都在 | 每天 |
| M3 异地恢复演练 | 每周在一台全新干净的机器上从云备份恢复数据库，模拟"服务器整机丢失还能救吗" | 每周日 |
| M4 装机流程演练 | 每月真开一台新机器，跑装环境脚本、部署服务、smoke 测试，再销毁；证明"换机流程没生锈" | 每月 1 号 |
| M6 完整迁移演练 | 每月跑一次真数据迁移：开新机 → 拉最新备份 → 恢复到新机 → 用真数据验证服务能响应；证明"到期换机"整套流程能跑通 | 每月 15 号 |
防降级（1 套指标）¶
| 代号 | 一句话 | 频率 |
|---|---|---|
| M5 性能指标聚合 | 每天算过去 24 小时 API 响应时间（p50/p95/p99）+ 错误率，展示为徽章（绿/黄/红） | 每天 |
怎么验证我们真做了¶
打开主仓 README 顶部的徽章墙 —— 每个演练对应一个徽章：
- 绿色
passing= 最近一次跑成功，系统健康 - 红色
failing= 失败了，代码仓里有人正在修（或等修） - 点击徽章直接跳到 GitHub Actions 历史
任何人都能看到： - 哪个演练多久跑一次 - 最近 N 次跑的历史 - 失败的具体错误原因（log 公开）
透明 = 可信。我们没有隐藏任何故障。
当你最担心什么¶
"你们的备份真的有用吗 / 数据丢了能救回来吗？"¶
M1/M2/M3 覆盖。每小时确认备份在、每天确认备份能读、每周真从备份恢复一遍。如果这三个徽章全绿 —— 意味着昨晚的数据现在立刻能恢复到任意全新机器。
"服务器挂了怎么办 / 换机要多久？"¶
M4/M6 覆盖。每月演练"从零开机到服务起来"的完整流程。目前实测大约 10 分钟完成（装机 + 部署 + 验证），一次演练成本几分钱。
真换机（业务切换）采用维护窗口模式：用户看到 1-5 分钟的"系统升级中" → 然后完全恢复。对 SQLite 架构这是合理上限（真 zero-downtime 需要 Postgres 主从，待 v0.5+ 业务规模需要时实现）。
"性能会不会悄悄变慢？"¶
M5 覆盖。每天徽章显示 p95 响应时间：
- 绿：< 100ms（体感即时）
- 黄：100-1000ms（有点慢但可用）
- 红：> 1000ms（明显感知）
连续多天黄或红 → 我们已经在看问题。
我们从失败里学到什么¶
演练的价值不只是"预防"，还是"暴露"隐藏问题。举个实例：
2026-04-23 第一次跑 M4 迁移演练，在新机器上部署时挂了 —— 原因是 SSH 空闲超时（小机器装依赖较慢）。如果不是 chaos drill 先暴露，这个 bug 会在真换机时才被发现（那时候是灾难场景）。
每次失败都是一次免费的真实事故演练。这才是 chaos engineering 的核心价值。
未来改进方向¶
- 性能退化告警：当 M5 指标连续多天恶化 → 主动 notify
- 告警链路本身演练（演练演练本身）
- 依赖包安全扫描定期：防供应链攻击
如果你对实现细节感兴趣，所有演练都是 GitHub Actions workflow，yaml 配置公开在 .github/workflows/chaos-*。