多产品最危险的不是功能落后，是某个你忘了的东西在凌晨过期。
一、凌晨三点的证书
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
一位开发者同时维护三个产品，共用一个域名下的子域。某个周末，主域名证书自动续期失败，三个产品同时报证书错误。他直到周一早上收到用户邮件才知道。
事后他发现，续期失败的原因很简单：一个用于验证域名所有权的 DNS 记录在几个月前被清理了。这条记录在任何一个产品的文档里都没有写。
维护负债的特征就是这样：平时完全不可见，出事时同时爆发。
二、要盯的七类会过期的东西
| 类别 | 例子 | 过期后果 | 提前期 |
|---|---|---|---|
| 依赖版本 | 框架、库、SDK | 安全漏洞、兼容性断裂 | 持续 |
| 运行时生命周期 | 语言版本、数据库大版本、操作系统 | 停止安全更新 | 6–12 个月 |
| 证书 | TLS、代码签名、推送证书 | 服务不可用、应用无法安装 | 30–90 天 |
| 域名 | 主域、子域、备用域 | 整站不可访问、被抢注 | 60 天 |
| 外部 API 版本 | 支付、邮件、地图、AI 接口 | 调用失败、计费异常 | 按公告 |
| 平台政策 | 商店审核规则、隐私要求、分成比例 | 下架、拒审、收入变化 | 按公告 |
| 账号与凭证 | 云账号、支付账号、开发者账号 | 无法登录、资金冻结 | 持续 |
2.1 为什么「运行时生命周期」最容易被忽略
依赖可以靠工具提醒，证书可以靠监控，但运行时的大版本停止支持往往只有一条公告。等你发现时，通常已经无法直接升级，需要先跨几个大版本。
对多产品来说，这个问题会被放大：三个产品可能跑在三个不同的运行时版本上，升级是三套工作。
减少运行时版本的数量，本身就是一种维护优化。
三、建立账本
账本不需要工具，一张表就够。每个产品一行，每个类别一列。
| 产品 | 运行时 | 依赖告警 | 证书 | 域名 | 外部 API | 平台政策 | 账号 |
|---|---|---|---|---|---|---|---|
| A | Node 24 | 自动 | 自动续期 | 2027-03 | 支付 v2 | 商店规则 | 双因素 |
| B | Node 22 | 自动 | 自动续期 | 2027-05 | 支付 v2 | 无 | 双因素 |
| C | Python 3.13 | 手动 | 手动 | 2026-12 | 邮件 API | 目录收录 | 双因素 |
3.1 账本必须记录的三件事
- 当前版本或到期日。 没有日期，就没有提前量。
- 谁负责。 一个人也要写「我」，写下来才会进巡检。
- 上次检查时间。 防止「以为查过了」。
四、季度巡检表
每季度花半天，按下面顺序过一遍。顺序很重要：先查会立刻导致不可用的，再查会逐渐劣化的。
| 顺序 | 检查项 | 动作 | 预计耗时 |
|---|---|---|---|
| 1 | 证书与域名 | 确认到期日、自动续期是否生效 | 15 分钟 |
| 2 | 备份与恢复 | 随机抽一个产品做恢复演练 | 60 分钟 |
| 3 | 运行时与依赖 | 检查 EOL 公告与高危漏洞 | 30 分钟 |
| 4 | 外部 API | 检查弃用公告与额度 | 20 分钟 |
| 5 | 平台政策 | 检查商店、支付、目录的规则变更 | 20 分钟 |
| 6 | 账号与凭证 | 确认双因素、备用邮箱、恢复码 | 15 分钟 |
| 7 | 监控与告警 | 确认告警能到达你 | 10 分钟 |
| 8 | 账本更新 | 更新版本号与到期日 | 10 分钟 |
4.1 恢复演练怎么做
不要只看「备份任务成功」。真正的验证是：
- 随机选一个产品的一份备份。
- 在隔离环境恢复。
- 检查关键数据是否完整。
- 记录恢复耗时。
没做过恢复演练的备份，只能算「有文件」，不能算「有备份」。
五、风险分级
不是所有问题都要立刻处理。综合影响、可利用性、暴露面、现有控制与截止时间分级。分数不能让正在被利用的漏洞或凭据泄露降级；以下是维护排程示例：
| 级别 | 定义 | 响应 |
|---|---|---|
| 红 | 会导致全部产品不可用，且确定会发生 | 本周处理 |
| 橙 | 会导致单个产品不可用，或有安全风险 | 本月处理 |
| 黄 | 会逐渐劣化体验或增加成本 | 本季度处理 |
| 绿 | 仅影响可维护性 | 排入路线图 |
5.1 一个分级示例
| 问题 | 影响面 | 确定性 | 级别 |
|---|---|---|---|
| 主域证书 7 天后到期且自动续期失败 | 全部 | 确定 | 红 |
| 支付 API 旧版本 6 个月后停用 | 全部 | 确定 | 橙 |
| 某依赖有中危漏洞，尚未确认利用情况 | 单个 | 需核实暴露与补丁 | 先做风险评估，不能仅因无公开利用判黄 |
| 框架大版本已发布，当前版本仍支持 | 单个 | 远期 | 绿 |
六、哪些能自动化，哪些不能
| 检查项 | 能否自动化 | 说明 |
|---|---|---|
| 证书到期 | 能 | 监控 + 到期告警 |
| 域名到期 | 部分 | 注册商提醒 + 自动续费 |
| 依赖漏洞 | 能 | 依赖扫描工具 |
| 运行时 EOL | 部分 | 需订阅公告或定期人工查 |
| 外部 API 弃用 | 部分 | 可订阅公告与做契约测试；影响评估需人工 |
| 平台政策变更 | 部分 | 可跟踪公告；适用性、迁移和合规判断需人工 |
| 隔离恢复与一致性校验 | 可以部分自动化 | 自动恢复、校验数据与应用；人工另演练接管和异常判断 |
| 账号凭证 | 部分 | 双因素可自动提醒，恢复码需人工保存 |
自动化的价值是把「会忘的事」变成「会响的事」；不能自动化的部分，必须靠日历。
七、常见错误
| 错误 | 后果 | 更好的做法 |
|---|---|---|
| 只盯代码，不盯域名与证书 | 凌晨全线不可用 | 巡检表把基础设施放第一位 |
| 以为自动续期一定生效 | 验证记录被删后续期失败 | 每季度确认一次续期状态 |
| 从不做恢复演练 | 出事时发现备份不可用 | 每季度抽一个产品演练 |
| 多个运行时版本并存 | 升级工作量翻倍 | 尽量收敛到同一版本 |
| 告警发到不看的邮箱 | 出事时无人知道 | 确认 P0 能到手机 |
| 账本只在脑子里 | 交接或遗忘时全丢 | 写进一个文件 |
八、行动清单
- 建一张七列的产品维护账本。
- 填上每个产品的运行时版本与到期日。
- 确认证书、域名都开启了自动续期，并验证续期链路。
- 确认 P0 告警能到达你的手机。
- 本季度做一次恢复演练，记录耗时。
- 把季度巡检放进日历，固定半天。
- 收敛运行时版本，减少升级面。
使用边界与实操验收
“没听说公开利用”不是没有风险。证书和域名剩余天数只是一个信号，权限泄露和数据风险要按事件响应规则立即评估。
巡检验收：选测试备份自动恢复，检查订单金额、外键与对象引用，运行应用健康检查；再发送一条明确标记“演练”的测试告警，确认通知进入实际 on-call 通道并被确认。记录自动结果与人工接管耗时，不能只截图任务成功。
关键参考与核验范围
以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。
- EDPB 数据泄露指南 ：按处理角色与风险判断通报，不以恢复完成作为起点。
- 语义化版本规范 ：约定公共 API 兼容性，不能单独保证数据库或部署安全。
系列导航
- 上一篇：什么时候砍掉一个产品：继续、冻结与日落
- 下一篇：组合的收束：卖掉一条线、合并或回到单品
- 回到目录：一个人的产品线：第二个产品与组合运营
- 相关阅读：SaaS 技术债政策 、独立开发者的资产韧性
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。