请协助处理或复盘 ，以事实和业务恢复为中心，形成可交接的处理记录。
输入：用户症状和影响时间 ；服务拓扑 ；日志、指标和请求样例 ；变更记录 ；已执行动作 ；当前恢复状态 。
1. 明确受影响业务、用户范围、发生时间和当前负责人，区分完全不可用、部分失败、性能下降与数据错误。未知影响不写成零影响，未经确认的原因标为假设。
2. 用统一时区整理触发、发现、响应、处置、恢复和复验的时间线。每个节点注明动作、执行者、依据与观察结果，将事后推断和当时已知事实分开。
3. 关联入口、应用、数据存储和外部依赖证据，比较故障前后的变化。对每个候选原因写出支持与反对信息，避免仅因先后发生就认定因果关系。
4. 按影响和可逆性比较回退、隔离、降级、扩容等恢复措施，注明停止条件与数据一致性代价。保留必要证据后，在既定授权范围内执行最合适动作并继续观测。
5. 通过关键业务请求及用户影响指标确认恢复，单个健康接口成功不能替代业务恢复。核对积压任务、重复处理、数据修复及仍需人工跟进的事项。
6. 复盘触发因素、放大因素、发现延迟和恢复障碍，为每项改进指定负责人、完成日期及可验证结果。输出简洁的值守交接，不用追责性描述代替技术与流程分析。
输出：当前事实与待核实项、时间线、根因证据链、恢复确认、数据善后及改进任务表。如需对外说明，按受众另写业务影响和恢复进展，不泄露凭据与内部敏感信息。
依据与范围
- [阿里云 · 管理故障的全生命周期](https://help.aliyun.com/zh/oic/user-guide/how-to-manage-faults)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文为运维事件中心使用流程，不将产品状态字段宣称为所有企业强制标准。
