一个人运维，不是不出事，是出事后知道先做什么。
这个系列解决什么问题
产品上线之后，工作重心会悄悄换一次：从「把它做出来」变成「让它一直能用」。这件事没有排期、没有验收、也很少有人提醒，直到某天你被一封「你们的服务是不是挂了」的邮件叫醒。
这个系列把这部分补上：先把可用性换成每月停机分钟，定下对外承诺与内部目标；再用五条探针把发现时间从四十七分钟压到三分钟；把四十条告警降成三条；用请求 ID 把日志串成证据；用状态页与三条模板解决「故障时说什么」；用四项水位判断先撞哪堵墙；为九个依赖各写一条降级动作；在发布后的四个窗口里按阈值决定回滚；用五分钟止损、一天说明、七天复盘处理事故；最后用十项控制与四张表做一次季度验收。
它服务的是一个人。 你没有值班表、没有 SRE、没有 on-call 轮换；你能投入的是每月四小时，和一份出事时还能看懂的清单。
核心主张：五条口径
- 可用性是预算，不是形容词。 每月 43200 分钟，允许用掉多少要先说清；说不清就永远在争论「够不够稳」。
- 先发现，再修复。 探针把发现时间压到三分钟，比任何优化都便宜；用户先发现，你就已经输了半小时。
- 告警只留能行动的。 不能行动的告警是噪音；四十条里只有三条需要动，其余应该进看板。
- 先止损，后根因。 回滚十二分钟，热修四十分钟；顺序错一次，就多花二十八分钟。
- 验收看控制，不看运气。 探针、告警、日志、状态页、演练这些控制做到位，好结果才可重复。
10 篇速览
| # | 文章 | 核心内容 | 阶段 |
|---|---|---|---|
| 01 | 可用性是一份预算：四个 9、停机分钟与一个人的取舍 | 停机分钟换算、三档成本、对外与对内两档承诺 | 目标 |
| 02 | 最小监控：四个信号、五条探针与三分钟发现 | 延迟/流量/错误/饱和度、五条关键路径探针、发现时间 | 发现 |
| 03 | 告警降噪：从 40 条到 3 条 | 四类告警、三级分级、持续时间、抑制与静默 | 通知 |
| 04 | 日志与错误聚合：在五分钟内找到那一次失败 | 四个必记字段、请求 ID、指纹聚合、采样与保留 | 取证 |
| 05 | 状态页与故障沟通：故障时说什么、多久说一次 | 五种状态、三条模板、15 分钟首发与 30 分钟更新 | 沟通 |
| 06 | 容量与成本：先找瓶颈，再谈扩容 | 四项水位、三倍增长、零成本优先的扩容顺序 | 容量 |
| 07 | 第三方依赖运维：供应商挂了，你怎么办 | 九个依赖、SLA 读数、三层降级与一次演练 | 依赖 |
| 08 | 发布后的 24 小时：观察窗口、回滚判据与冻结期 | 四个窗口、五条阈值、回滚与热修的算术 | 发布 |
| 09 | 事故响应与复盘：五分钟止损、一天说明、七天复盘 | 三选一止损、五段式复盘、MTTR 与长尾事故 | 事故 |
| 10 | 运维验收：十项控制、四张表与月度巡检 | 十项控制、四维加权、3.9 分与季度只改一件事 | 验收 |
三条阅读路径
路径 A：刚上线，还没有任何监控。 从 02 建五条探针，再用 03 把通知压到能看，接着用 05 把状态页与模板准备好。这条路径的重点是「先能发现，再谈优化」。
路径 B：有监控，但天天被误报吵。 先做 03 的四类分诊与持续时间条件，再用 04 把日志串起来、08 定下回滚判据。这条路径的重点是「把噪音换成信号」。
路径 C：刚出过一次大事故。 从 09 的五分钟三选一与五段式复盘开始，回到 01 重算可用性，再用 10 做一次季度打分。这条路径的重点是「把这次的教训变成下一次的顺序」。
与其它专题的边界
站内已有运维与安全内容，但多在团队与基础设施语境。下表说明本组不重复什么。
| 既有内容 | 它讲什么 | 本组边界 |
|---|---|---|
| 独立开发者的资产韧性：一个人的账号、数据与恢复能力（10 篇） | 账号、域名、代码、备份、收款与账号被盗的 72 小时 | 它保证「资产不丢」；本组保证「服务可用」，两者的触发条件与处置顺序不同 |
| 一个人把软件交付到用户手里：签名、安装、更新与审核（10 篇） | 构建、签名、安装包、商店审核与崩溃遥测 | 它管「怎么发到用户手里」；本组管「发出去之后怎么盯住」 |
| 一个人给产品加 AI：判据、成本、护栏与验收（10 篇） | 推理成本、滥用防线与供应商降级 | 它针对单一 AI 链路；本组处理全站依赖、容量与发布 |
| 一个人的自助支持：帮助中心、排查树与工单减少（10 篇） | 帮助中心、排查树、更新日志与升级路径 | 它让用户自助解决；本组让你先知道出了问题 |
| 一个人的消息系统：事务邮件、通知分层与送达率（10 篇） | 事务邮件、通知分级与送达率 | 它管「发给用户的消息」；本组管「发给自己的告警」 |
| 一个人的财务：现金流、runway 与月度结账（10 篇） | 现金、成本、runway 与月度结账 | 它算钱；本组算停机分钟与时间预算，两者共用同一个四小时/月 |
| 一个人的公司：独立开发者的主体、税务与合规底座（10 篇） | 主体、合同、知识产权与法定申报 | 它是法律义务；本组是工程控制，合规口径以其为准 |
| 信息安全与云安全专题 | 威胁建模、认证授权、供应链与安全运营 | 它讲安全工程；本组只讲可用性，不涉及攻击面与数据保护 |
| 独立开发者生存指南专题导航：11 篇从认知到 12 个月路线图的完整手册 | 12 个月路线、变现与项目节奏 | 它是长期策略；本组是上线后的日常动作 |
| 一个人的产品度量：事件字典、指标口径与决策看板（10 篇） | 事件字典、指标口径、漏斗、看板与数据质量 | 它量用户行为；本组量系统状态，两者的告警不该混在一条通道 |
| 一个人的架构：技术选型、模块边界与演进（10 篇） | 技术选型排除法、九个模块与依赖方向、数据迁移三步、四个升级窗口、技术债预算、三次规则、重构判据、可替换性、幂等与补偿、四维验收 | 那组讲代码层的幂等与补偿；本组讲可用性、告警、事故与值班 |
| 一个人的计费系统：订阅状态机、按比例计费与失败重试（10 篇） | 订阅状态机、五个时点、按比例计费、按量计量、催收、退款拒付、发票税务、对账漏损、自建决策、十二项验收 | 那组讲交易与对账；本组讲可用性、告警、事故与值班 |
| 一个人的隐私工程：数据地图、最小化与删除权（10 篇） | 数据地图、最小化、合法性依据与同意、政策一致性、数据主体请求、删除、保留期、跨境与供应商、泄露响应、十二项验收 | 那组讲事故与日志里的个人数据；本组讲可用性、告警、事故与值班 |
| 一个人的数据搬家：导入、去重、迁移与退出（10 篇） | 迁移漏斗、导入契约、字段映射、去重合并、幂等重跑、人工代导入、窗口与回滚、附件限额、导出退出、十项验收 | 那组讲导入窗口与回滚演练；本组讲可用性、告警、事故与值班 |
| 一个人的质量守门：验证预算、回归清单与发布门禁（10 篇） | 47 缺陷与三条红线、12 条关键路径、三层配比、38→26 回归、六项门禁、四级缺陷、测试数据、不可逆保护、测试债、十项验收 | 那组管上线前敢不敢发；本组管上线后的可用性、告警、事故与值班 |
| 一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应 | 14 个攻击面、认证与枚举、会话撤销、17 个密钥三档、四条边界、41 个依赖与 186 条告警、四类限流、9 类审计日志、72 小时三段响应、20 项验收 | 那组管「别被破」；本组管「别挂」——可用性、告警与事故 |
| 一个人的性能与账单：4.2 秒的首屏、一千二百次查询与每月 210 美元 | 4 项预算与 20 格、RUM 与慢查询、412→168 KB、1,200→3 次查询、0→86% 缓存、34 秒导出、7→4 个第三方、210→118 美元、3 次回归告警、10 项验收 | 那组管「同样容量下快不快、贵不贵」；本组管「别挂」——可用性、告警与事故 |
| 一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单 | 9 家询价与 130 h、96 天采购、148 题问卷、7 个子处理者、SLA 43.2/216 分钟、26 h SSO、4 周试点、38 天到账、8 h 实施、10 项验收 | 那组讲 SLA 敢承诺几个 9；本组讲可用性预算、告警与事故复盘 |
| 一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护 | 4,200 star 与 1,949 美元、612 h 维护、214 依赖、48,600 行 78/22、1,180 个 issue、214 条告警、23 个赞助者、9 家双许可、17 位贡献者、10 项验收 | 那组讲开源项目的维护与告警分流；本组讲可用性预算、告警与事故复盘 |
这十篇不承诺「按这套做就不会出故障」，也不提供任何厂商报价。可复算的部分全部用四则运算给出算式；不可复算的部分（实例价格、SLA 条款、供应商赔付）明确指向账单与合同。所有数字都是教学假设，代入前请换成自己的水位与记录。
本组统一口径
全组共用一组教学假设，各篇引用时不换分母：
产品：一人 SaaS，120 个付费账户、344 个登录账号
月历：30 天 = 43200 分钟
对外承诺 99.5% → 每月允许停机 216 分钟
内部目标 99.9% → 每月允许停机 43.2 分钟
近 90 天（129600 分钟）：4 次故障、累计 138 分钟 → 99.89%
其中依赖方 42 分钟、自因 96 分钟（含数据库恢复 82 分钟）
探针：5 条 × 每分钟 1 次 = 7200 次/天 = 216000 次/月
告警：40 条/月 → 抖动 22、重复 9、非紧急 6、真实 3 → 误报率 77.5%
日志：写入 1.2 GB/月，采样 10% → 索引 0.12 GB/月，保留 30 天
请求：18 万次/月 → 6000 次/天，峰值约 0.42 次/秒
容量：连接 9/20、队列 320/1000、存储 1.8/10 GB、CPU 62%
发布：4 次/月 × 45 分钟观察 = 3 小时；双周发布 = 90 分钟
运维预算：4 小时/月 = 48 小时/年，不新增现金支出
四周月口径。 凡涉及月度的地方按 30 天计算；季度按 90 天、129600 分钟计算，不用自然月的长度替换。
可用性按分钟算。 99.89% 与 99.9% 看着接近，差的是 8.4 分钟；不换成分钟，讨论会停在形容词上。
成本是教学假设。 55、190、640 与 40 美元只用来展示数量级；真实价格随区域、规格与合同变化。
时间是本组真正的分母。 4 小时/月是所有方案的约束：任何建议如果超过这个预算，就不适合一人产品。
使用说明
先读 01，不要先去买监控。 不知道自己要承诺几个 9，买什么工具都只是多一个看板。
每篇都可以单独使用。 文章之间共享基线，但不依赖前后文；你可以只拿 03 的降噪规则或 08 的回滚阈值回去改。
先做零成本的动作。 五条探针、持续时间条件、请求 ID、状态页静态化、连接池调整，这些都不花钱。
工具越少越好。 一个探针服务、一个错误聚合、一个状态页，比五个平台更容易坚持。
本组的证据与使用方法
证据类型。 本组用的是「探针记录 + 错误日志 + 事故时间线 + 账单水位」：可用性分钟数、告警条数、错误分组、连接与存储水位。没有行业均值，也没有「通常来说」的推断。
如何使用。 先把 01 的 138 分钟填成自己的记录，再用 02 的五条探针补上发现能力，用 03 的三级分级压掉误报，最后用 10 的四维评分做季度体检。
如何复核。 取最近 90 天的探针结果与事故记录，按 01 的口径重算可用性、按 03 的口径重算误报率、按 06 的口径重算四项水位；缺关键分母时先补采集，结论以实际数据为准。