日志、监控、备份与恢复
产品上线后仍会失败。可观测性让你知道失败发生在哪里，备份与恢复让错误不至于变成灾难。
- 产品出问题时，不需要靠用户截图才知道发生了什么。
- 结构化日志、错误追踪和关键指标
- 人为制造一次可控失败，确认日志、告警、回滚和恢复路径。
- 完成 7.4「域名、HTTPS、SEO 与可访问性」
FOUNDATION
必须理解
产品上线后仍会失败。可观测性让你知道失败发生在哪里，备份与恢复让错误不至于变成灾难。
上线后你无法站在每位用户身边。日志、指标和告警让系统留下证据，备份与恢复则确保最坏情况发生时仍能找回关键数据。
运营一家店需要收银记录、监控仪表、异常报警和备用账本。只有顾客投诉后才知道停电，或者有备份却从没试过恢复，都不算可靠。
任务应用记录带请求 ID 的结构化错误，监控响应时间与失败率，对异常登录和数据库错误告警，并定期备份 PostgreSQL、演练恢复。
结构化日志、错误追踪和关键指标
日志记下某次具体事件和上下文，指标把大量事件汇总成趋势，追踪再把一次请求经过的多个服务串起来。它们都不能顺手记录密码和完整敏感数据。
基础概念
日志记录离散事件，指标把大量事件聚合为数值趋势，错误追踪收集异常与上下文。结构化表示字段稳定，便于搜索、关联和告警。
进一步理解
一条请求日志可有时间、级别、requestId、路由、结果和耗时；指标可统计成功率、延迟分位数与队列长度。
日志不能记录密码、完整令牌和无必要个人数据。requestId 可串联浏览器错误、服务端处理与下游请求，而不暴露秘密。
创建任务失败时，前端显示 requestId；维护者用它找到接口异常、数据库超时和同一时间段失败率上升。
日志多不等于可观测。没有稳定字段、上下文和查询方式的大量文本只会增加成本与隐私风险。
这一小节记住：记录能回答谁、何时、在哪里、发生什么和影响多大的必要证据。
健康检查、告警与服务依赖
好告警应该告诉你用户受到了什么影响，以及接下来能做什么。相比 CPU 偶尔升高，登录失败率、接口延迟和核心流程成功率往往更接近真实体验。
基础概念
健康检查回答服务当前能否履行基本职责，告警在关键指标越过阈值时通知负责者，服务依赖是应用运行所需的数据库、队列或外部 API。
进一步理解
存活检查确认进程存在，就绪检查确认能否接收流量。深度健康检查要谨慎，避免一次依赖波动让所有实例同时被判死。
好告警围绕用户影响、持续时间和可行动性设计。偶发 CPU 高不一定需要叫醒人，核心流程持续失败则应立即处理。
任务 API 的就绪检查确认必要配置和数据库连接；告警关注五分钟创建成功率低于阈值，并附仪表盘与处理手册。
健康接口返回 200 只证明检查内容通过，不证明每条业务流程都健康；告警也不是所有异常都发一条消息。
这一小节记住：监控最接近用户价值的信号，并让告警指向可以采取的行动。
数据库备份、恢复演练和回滚
备份文件存在不代表一定能恢复。你还要知道多久备一次、保存多久、放在哪里，以及实际恢复会丢多少数据、花多少时间。
基础概念
备份是数据的独立可恢复副本，恢复演练证明副本真的可用，回滚是把应用或配置切回稳定版本。RPO 描述最多可接受丢失多久数据，RTO 描述最多可接受恢复多久。
进一步理解
备份要规定频率、保留周期、存储位置、加密与访问权限。与生产放在同一故障域的副本可能一起丢失。
恢复必须在隔离环境定期演练并记录时间与校验结果。代码回滚不能撤销已发生的数据写入，数据库恢复也会影响恢复点之后的新数据。
任务数据每小时增量、每日完整备份；季度在隔离库恢复，验证记录数量、关键关系和应用读取，并记录实际 RPO/RTO。
看到备份任务“成功”不代表内容完整可恢复；回滚部署也不等于把数据库自动回到昨天。
这一小节记住：只有经过恢复验证的备份，才是可信的灾难恢复能力。
AI COLLABORATION
AI 如何参与
让 AI 根据请求 ID、时间和错误上下文分析日志，但先移除密码、令牌和个人数据。
推荐协作顺序
- 1
先把用户最重要的三条流程告诉 AI，让监控围绕它们设计。
- 2
让它把每项日志、指标和告警对应到一个具体问题。
- 3
拿一次模拟故障检验告警是否能指导动作，并演练从备份恢复。
请为小型任务应用设计最小可观察性方案。流量每天少于 1000 请求。列出必须日志字段、3 个核心指标、2 条可行动告警、备份频率和季度恢复演练。禁止记录密码、Cookie、令牌和完整任务正文。
方案规模与小产品匹配，关注登录和任务读写成功率，不引入过重平台；每条告警有负责人动作。
人工检查清单
- 确认日志脱敏、错误可关联、备份与生产分离，并明确实际恢复验证。
- 让 AI 的诊断引用具体日志字段、指标时间窗和依赖状态，并标明缺失证据。
- 实际制造可控失败与隔离恢复演练，确认告警到达、手册可执行、备份能读取。
COMMON TRAPS
常见误区
错误不是需要隐藏的失败，而是帮助你看清系统边界的证据。下面三类问题在 AI 辅助学习中最常出现。
日志很多，却回答不了问题
- 你会看到
- 每个请求打印十几行，但缺少时间、用户边界和 requestId。
- 为什么发生
- 没有上下文的文本日志无法关联请求，多到一定规模只能搜索模糊关键词，定位仍靠猜。
- 怎样纠正
- 保留能串起一次请求的结构化字段，删除无助排查的噪声。
告警响了也不知道做什么
- 你会看到
- CPU 偶尔升高就通知，却没有用户影响和处理步骤。
- 为什么发生
- 对基础资源的短暂波动过度告警会制造疲劳，真正用户故障出现时反而被忽略。
- 怎样纠正
- 告警要对应核心流程、阈值、负责人和第一行动。
有备份，从没恢复过
- 你会看到
- 真正出事才发现文件损坏、缺权限或恢复耗时过长。
- 为什么发生
- 备份流程只验证文件生成，不验证内容、密钥和恢复步骤，灾难时才发现副本不可用。
- 怎样纠正
- 定期在隔离环境恢复，记录实际可恢复时间和数据缺口。
HANDS-ON
动手任务
人为制造一次可控失败，确认日志、告警、回滚和恢复路径。
- 完成 7.4「域名、HTTPS、SEO 与可访问性」
跟着做
- 01
为每次请求生成或传播 requestId。
- 02
定义结构化日志字段和禁止记录清单。
- 03
记录请求量、错误率和延迟三项基础指标。
- 04
为登录失败激增和任务 API 高错误率建立告警说明。
- 05
执行一次数据库备份并在隔离环境恢复验证。
产品出问题时，不需要靠用户截图才知道发生了什么。
写一份 20 分钟故障处理卡：确认影响、止损、沟通、恢复、复盘分别做什么。
离开本课前，自问四件事
- 日志、指标与错误追踪分别适合回答什么问题？
- 存活检查、就绪检查和业务健康有什么区别？
- 一个可行动告警至少应包含哪些信息？
- RPO、RTO、备份、恢复演练与代码回滚如何关联？
确认完成后，会同步更新学习中心的课程学习进度。