维护模式 playbook：solo 开发者停机时的三层通知

背景与问题

solo 产品的服务器维护/故障是单人应对：没有客服团队，通知晚了差评就来。调研移动 app 维护模式的标准做法：计划内停机与计划外故障各怎么通知，三层（应用内/状态页/商店）各承担什么。

发现

（来源访问日期均为 2026-09-17）

• 事实（Chameleon 停机横幅模板）：应用内横幅要动态切文案——「预定维护（开始时间）」与「正在维护中」是两种状态，不要一条文案顶到底。
• 事实（UX StackExchange 讨论）：计划内/计划外的区别在给预期：哪些功能不可用、其余是否正常、何时恢复——三要素写全，差评和客服问询显著减少。
• 事实（Atlassian Statuspage 指南）：状态页是计划维护的公告与滚动更新主场；个人开发者可用 Statuspage 免费档或自建静态页（opc-edge-api-workers 可挂）。
• 事实（坑，Reddit NextCloud 实例）：维护结束后客户端可能缓存旧维护标志，用户看到「维护中」假死——恢复后要处理客户端缓存的标志位。
• 推测：solo 场景下商店层（store listing「正在进行维护」文案 / 版本更新说明）是第三层但最弱——用户已在 app 里时看不到；它的真实作用是给「放弃打开的人」一个解释，防一星。

结论

1. 三层通知模板（按优先级）：①应用内横幅：远端开关控制+动态文案（预定/进行中/恢复三种）②状态页：免费 Statuspage 或 Workers 挂静态页，滚动更新③商店：计划内维护才动 listing「说明」，计划外不动（更新审核来不及）。
2. 远端开关是前提：横幅文案和「维护中」判定必须服务端可控——发版不可依赖。做进下一次发版。
3. 恢复路径写死：维护标志位在客户端设置 TTL（如 5 分钟自愈重试），防假死缓存坑。
4. 流程排练：半年一次 10 分钟 drill（opc-backup-restore-drill 同场）——把横幅开关、状态页更新、恢复确认各走一遍。

待办 / 下次继续

• 应用内维护横幅的远端开关实现排进下个版本。
  
• 状态页挂到现有 Workers 域名（静态模板 1 页）。
  

关联

opc-edge-api-workers opc-external-uptime-monitoring opc-backup-restore-drill opc-support-first-response-templates