障害対応の最小 Runbook：検知から告知文面まで
B 方向·OPC 最佳实践。发布日应急三预案（opc-launch-contingency）管 D-Day，本篇管平常時の障害：LINE bot 挂了/推送没发/判定服务超时，solo 的响应流程与告知文面。
背景与问题
- 见守产品的信任靠「每天一条消息」积累——一次无通知的长时间故障对老人端=「息子が止めた？」的不安，对子女端=「这个服务靠谱吗」。故障不可免，告知的质量可控。
发现
流程设计【推断：基于 Runbook 族方法论，业界通行框架】：
- 影响判定三档：P1（告警/推送未达→用户直接感知）・P2（功能部分劣化：判定慢/内容缺）・P3（后台作业延迟，用户无感）——只有 P1/P2 需要用户告知。
- 告知双通道：① 子女端=LINE 一封（平易日语，不制造恐慌）；② 老人端=原则上不发（避免不安；若服务中断影响老人的日常话头，用「今日はお休み」的轻口径）——银发 UX 的故障告知和一般 SaaS 相反，少即是多【推测：以种子用户反应校正】。
- 文面三要素：发生了什么（一句）/影响（能做什么不能做什么）/恢复预期（「今日中に復旧予定」）——不写技术细节、不过度道歉（信頼毁损来自含糊，不来自故障本身）。
- 事后 1 ページ post-mortem：发生了什么/为什么/三行修复措施→ opc-llm-eval-pipeline 的 golden set 回流（若涉及判定错误）。
结论
可行动启发：
- 告知模板两版先写好（P1 用户告知/P2 劣化告知，日语母语校对）——故障时不再写文案，填空即发；模板放 opc-launch-runbook 同一目录。
- P1 定义写死进 monitoring：opc-monitoring-basics-solo 的三層栈里，「webhook 端点 15 分连续 down」或「cron heartbeat 缺失 2 回」自动=P1 触发告知流程——判定自动化，故障时不做判断题。
- 恢复后的「复旧のお知らせ」必发：一封闭环消息比故障期间沉默更能积累信任（「昨夜の障害は復旧しました」+一句感谢）——这封是唯一同时发老人端+子女端的障害消息。
- 季度障害演练 10 分钟：手动停 webhook→走一遍检测/告知/修复/复旧通知全链路——pre-mortem（opc-premortem-ritual）的日常版，演练发现的断点修在平时。
待办 / 下次继续
关联
- 应急族：opc-launch-contingency（D-Day）× 本篇（平常时）× opc-sunset-runbook（关停）；检测 opc-monitoring-basics-solo；文面纪律 japan-yasashii-nihongo-ui。