以下为本页可直接引用的结论要点，均来自正文对应章节的详细论证。
结论：故障处理的第一步是分级，级别决定通知范围、响应时限与是否启动应急预案。分级按「影响用户范围 × 功能重要程度 × 是否有降级手段」三要素判定，而不是按技术现象判定。同样是检索报错，影响全员与影响单个部门的处理方式完全不同。
| 级别 | 判定标准 | 首次响应 | 处置原则 | 是否启动应急预案 |
|---|---|---|---|---|
| P3 一般 | 个别用户、非核心功能异常，有替代方式 | 1 个工作日 | 记录并排期修复 | 否 |
| P2 较重 | 部分用户或部门核心功能受影响，体验明显下降 | 2 小时 | 先降级止损，再定位根因 | 否，但需同步业务方 |
| P1 严重 | 大面积用户核心功能不可用 | 30 分钟 | 止损优先，同步升级 | 是 |
| P0 紧急 | 系统整体不可用，或涉及数据丢失、安全事件 | 15 分钟 | 立即止损并上报 | 是，并通知管理层 |
一条重要原则：处置顺序永远是「先止损、后定位、再根治」。止损手段包括切备用节点、关闭非核心功能、限流、临时提高超时、以及回退上一版本。允许在 P1 及以上故障中先执行止损动作再补流程，但必须在 24 小时内补齐变更与复盘记录。
结论：无论什么故障，都按「确认范围 → 看变更 → 看依赖 → 看日志 → 做对比」五步推进。跳过前两步直接翻日志是最常见的低效做法，因为大约六成的生产故障与近期变更或依赖服务相关。
五步的具体动作如下，每步都要留下结论（是/否/不确定），避免在多个假设之间反复横跳。
| 步骤 | 要回答的问题 | 常用手段 | 耗时参考 |
|---|---|---|---|
| 1. 确认范围 | 影响哪些用户、哪些功能、多大比例、从什么时候开始 | 监控看板、错误率曲线、用户反馈、抽样验证 | 5 分钟 |
| 2. 看变更 | 故障起点前 24 小时内有没有发布、配置变更、证书或凭证轮换 | 变更记录、发布历史、配置版本对比 | 5 分钟 |
| 3. 看依赖 | 数据库、检索、对象存储、身份源、网络是否正常 | 健康检查、连通性测试、依赖方状态确认 | 10 分钟 |
| 4. 看日志 | 错误集中在哪个服务、哪个接口、什么错误码、是否有堆栈 | 按 TraceID 串联、错误码聚合、时间窗口对比 | 15 分钟 |
| 5. 做对比 | 正常环境与异常环境的差异是什么（配置、数据、版本、流量） | 配置对比、数据抽样、版本核对 | 15 分钟 |
立即执行降级止损，不要继续深挖。同时组织第二人并行排查，避免单人思路固化。规定「30 分钟阈值」能显著降低故障时长，因为大多数长时间故障都卡在「再查一下就好」的循环中。
必须记录，且实时记录而不是事后补。记录内容包括：时间点、做了什么动作、观察到什么结果。这既是复盘的输入，也能在交接或换人时避免重复劳动。
登录类故障的特点是「用户第一感知」，影响面大但通常定位较快。按现象分五类处置，先判断是个别用户还是全员，这两类的根因完全不同。
| 现象 | 可能原因 | 定位方法 | 处置动作 | 预防措施 |
|---|---|---|---|---|
| 全员无法登录（SSO 环境） | 身份源不可用、证书过期、回调地址变更、密钥轮换未同步 | 检查身份源状态页、证书有效期、回调配置 | 切换到本地应急管理员排查；身份源恢复后验证同步 | 证书有效期纳入监控；保留应急管理员 |
| 个别用户无法登录 | 账号被停用、目录同步失败、多因素校验失败、口令过期 | 查该账号登录日志的失败原因码 | 按原因码处理：同步失败则触发同步，锁定则解锁 | 账号生命周期与主数据联动 |
| 登录后立即掉线 | 会话配置异常、负载均衡未开启会话保持、时间不同步 | 检查会话超时配置、负载策略、服务器时间 | 修正会话保持策略或同步服务器时间 | 多节点部署时统一配置并做时间同步 |
| 提示无权限访问 | 授权未生效、授权已过期、被更高层级策略拒绝 | 查该用户有效权限清单与实际授权记录 | 补授权或修正冲突策略；检查是否多条授权互相覆盖 | 授权带有效期并到期提醒 |
| 集成接口调用 401 | 凭证过期、凭证被轮换、IP 白名单变更 | 检查凭证有效期与调用来源 IP | 重新签发凭证并更新调用方配置 | 凭证到期前 30 天告警，灰度轮换 |
检索类问题要先区分「系统故障」与「效果不佳」。前者表现为报错、超时、返回空；后者表现为能返回结果但不准确。前者按故障处理，后者按调优处理，两者的责任人与处理节奏都不同。混淆会导致用调优的方式处理故障，或用重启的方式处理效果问题。
| 现象 | 可能原因 | 定位方法 | 处置动作 |
|---|---|---|---|
| 检索直接报错 | 检索服务异常、索引损坏、分片不可用 | 查检索服务健康检查与分片状态 | 重启检索服务；分片不可用则恢复副本，必要时重建索引 |
| 检索全部返回空 | 索引未同步、权限过滤过严、元数据条件不匹配 | 用管理员账号检索同一问题，对比结果 | 管理员能查到则是权限问题；都查不到则触发索引重建 |
| 部分新内容搜不到 | 入库任务积压或失败、向量化未完成 | 查任务队列与该文档的入库状态 | 重试失败任务；持续积压则临时扩容 worker |
| 检索很慢 | 索引膨胀、分片不均、复杂过滤、缓存命中下降 | 拆分召回、重排、生成三段耗时 | 按瓶颈段处理：慢在召回优化索引，慢在生成则限流或降级 |
| 答案与来源不符 | 召回内容错误、重排失效、生成参数异常 | 看召回内容是否正确；召回正确则是生成问题 | 召回错则修索引与切分；生成错则调提示词与阈值 |
| 频繁答「未找到」 | 拒答阈值过严、内容确实缺失、元数据过滤过严 | 统计未找到问题的类型分布 | 内容缺失则补内容；阈值过严则下调并观察准确率 |
重建索引是重操作，执行前确认三件事：原始数据完整、有足够的临时空间（通常需要双倍）、以及业务低峰窗口。重建期间检索可能降级，需提前通知用户。优先选择「新建索引后切换」而不是「原地重建」，以便随时回退。
任务类故障的核心判断是「积压来自消费慢还是失败重试」。前者表现为队列增长但成功率正常，后者表现为失败率上升且重试次数激增。两者的处置方向相反：前者加资源，后者先修根因——在根因未修复时增加 worker，只会让失败更快堆积。
| 现象 | 可能原因 | 定位方法 | 处置动作 |
|---|---|---|---|
| 队列持续积压 | worker 不足、大文件集中入库、下游限流 | 看任务平均耗时与并发数是否达到上限 | 扩容 worker 或错峰调度；下游限流则协商配额 |
| 失败率突然升高 | 文件损坏或格式不受支持、依赖服务异常、磁盘满 | 按错误类型聚合，看是否集中在某类文件 | 先暂停该类任务；修复后批量重试 |
| 重试风暴 | 失败任务无限重试、重试间隔过短 | 看重试次数分布与队列增长速度 | 临时关闭自动重试，改为人工触发；修正重试策略（指数退避 + 上限） |
| 同步任务长时间未完成 | 源系统数据量大、增量标记丢失导致全量重跑 | 看同步日志的扫描与写入条数 | 确认增量位点；必要时分批同步 |
| 定时任务未执行 | 调度服务异常、时间配置错误、服务重启丢失调度 | 查调度日志与任务下次执行时间 | 重启调度服务并补跑；核对时区配置 |
采用指数退避（如 1 分钟、5 分钟、30 分钟、2 小时）并设置重试上限（3 至 5 次），超过上限转入死信队列等待人工处理。禁止无限重试，它是把小故障放大成系统性故障的主要机制。
区分任务类型：入库与向量化任务可延后重跑，不丢数据；通知类任务可丢弃；涉及状态变更的任务不可丢，必须补偿。建议在任务设计阶段就标注是否可重放、是否可丢弃。
性能问题按「CPU、内存、磁盘、网络、数据库」五类资源逐项排除，每类都有明确的观测指标与快速判断方法。不要一开始就调参数，先确认瓶颈在哪一类资源上。
| 瓶颈 | 观测指标 | 快速判断 | 常见处置 |
|---|---|---|---|
| CPU | 使用率、负载、进程占用 | 负载持续高于核数说明 CPU 饱和 | 定位高占用进程；错峰任务；扩容或升配 |
| 内存 | 使用率、Swap、GC 频率 | Swap 使用增加或 GC 频繁说明内存不足 | 检查缓存配置与泄漏；升配或拆分服务 |
| 磁盘 | 使用率、IO 等待、IOPS | IO 等待高说明磁盘是瓶颈 | 清理空间；分离数据与日志盘；错峰批量任务 |
| 网络 | 带宽、连接数、重传率、DNS 解析 | 跨网段访问慢且重传率高 | 检查网络策略与链路；就近部署；压缩传输 |
| 数据库 | 慢查询、连接数、锁等待、主从延迟 | 慢查询数量突增且集中在某条 SQL | 优化索引与 SQL；限流；必要时读写分离 |
排障效率很大程度取决于「知不知道去哪看」。DravenAI 的日志按服务分目录存放，建议统一接入日志平台后用服务名与 TraceID 检索；未接入日志平台时，可按以下路径直接查看。
| 日志 | 内容 | 排障用途 | 检索关键字建议 |
|---|---|---|---|
| 网关访问日志 | 请求路径、状态码、耗时、来源 IP | 确认是入口问题还是内部问题 | 按状态码 5xx 过滤，按路径聚合 |
| 应用服务日志 | 业务处理、异常堆栈、慢操作 | 定位具体服务与代码位置 | 按 TraceID 串联；按错误码聚合 |
| 检索服务日志 | 查询耗时、召回条数、分片状态 | 定位检索慢与返回空 | 按查询关键字与耗时排序 |
| 任务服务日志 | 任务创建、执行步骤、失败原因 | 定位入库与同步问题 | 按任务 ID 与文档 ID 检索 |
| 审计日志 | 登录、权限变更、访问、导出 | 安全事件与越权排查 | 按账号与时间范围检索 |
一个实用技巧：先在网关日志中找到失败请求的 TraceID，再用 TraceID 串联其余日志，可以在几分钟内还原完整调用链。没有 TraceID 时，用「时间窗口 ±2 秒 + 用户标识」做近似关联，效率会低但通常够用。
应急预案要提前写好并对齐演练，不能临时想。以下五套预案覆盖大多数场景，每套需明确「触发条件、执行动作、负责人、影响与告知话术、恢复条件」五要素。
触发：健康检查连续失败 3 次。动作：重启服务 → 未恢复则切备用节点 → 仍不行则回退上一版本。告知：发布故障公告，说明影响范围与预计恢复时间。恢复条件：核心接口成功率恢复正常并持续 30 分钟。
触发：连接池耗尽或主库不可用。动作：切主备 → 限流保护 → 必要时只读降级。告知：说明当前为只读或部分功能受限。恢复条件：主备切换完成且数据一致性校验通过。
触发：检索服务不可用或重建索引期间。动作：切换到关键词检索或关闭语义检索，保留基础查找能力。告知：说明检索结果可能不完整。恢复条件：检索服务恢复且索引校验通过。
触发：积压超过 1000 或等待超 30 分钟。动作：暂停低优先级队列 → 扩容 worker → 修复失败根因后批量重跑。告知：说明新内容入库延迟。恢复条件：积压清零且失败率回到正常区间。
触发：异常批量导出、异常地点登录、越权访问告警。动作：先冻结账号与导出权限 → 保留现场日志 → 评估影响面 → 按流程上报。注意：不要急于重启或清理日志，会破坏取证链条。
每套预案每季度至少演练一次，演练要真实执行动作而不是走流程讲解。演练后记录实际耗时，与预案中的目标对比，差距过大的要修订预案或补充工具脚本。
结论：P1 及以上故障必须复盘，P2 故障可选择性地做简化复盘。复盘的目的不是追责，而是产出可执行的改进项并闭环。复盘会应在故障恢复后 3 个工作日内召开，此时记忆最新、材料最全。
复盘采用四问法：① 时间线上到底发生了什么（按分钟还原）；② 为什么没更早发现（监控与告警缺口）；③ 为什么恢复花了这么久（止损手段与工具的缺口）；④ 如何防止再发生（改进项、责任人、时间）。前三问负责还原事实，第四问负责产出行动。
| 复盘输出 | 内容要求 | 闭环标准 |
|---|---|---|
| 故障时间线 | 按分钟记录：发生、发现、响应、止损、恢复各时点 | 各时点有日志或记录佐证 |
| 根因分析 | 区分直接原因、根本原因与 contributing factor | 根本原因可追溯到具体机制而非「人为疏忽」 |
| 改进项清单 | 每项含动作、责任人、完成时间、验收方式 | 全部进入排期并在下次复盘时回顾完成率 |
| 监控/预案补充 | 新增告警规则、新增或修订预案 | 告警已上线并验证可触发 |
改进项完成率是复盘机制有效性的唯一硬指标。若连续两次复盘出现同类改进项未完成，说明复盘机制本身出了问题，应升级处理：要么调整责任人，要么重新评估该改进项的必要性并正式关闭。
先看监控。监控能在 2 分钟内回答「影响多大、从什么时候开始、哪个组件异常」，这决定了后续排查方向。直接翻日志容易陷入细节，且往往选错时间窗口。
能暂时解决，但不能根治。重启适用于资源泄漏、连接未释放、状态错乱这类可恢复问题；对配置错误、数据损坏、容量不足则无效且会复发。重启后必须继续定位，并把根因写入故障记录。
满足以下任一条件时考虑重建：分片损坏且副本不可用、切分策略调整、大量内容删除后索引膨胀明显、版本升级要求重建。日常效果不佳不要重建，应走调优流程。
常见原因有三个：用户端缓存、网络链路差异（不同办公地点或外网）、以及监控采样间隔掩盖了瞬时抖动。排查时先确认用户具体环境（浏览器、网络、时间），再对比监控口径。
需要。在止损前尽量保存：服务堆栈快照、关键日志片段、监控截图、以及触发条件。特别是安全类事件，保留现场比快速恢复更重要；其余场景可在恢复后 24 小时内补齐材料。
按上线前确定的《运维职责矩阵》界定：应用服务与任务服务由平台方主导，主机、数据库、网络与备份由客户方主导，集成通道按接口归属划分。界定不清时先联合止损，责任归属事后依据日志判定。
止损性质的变更（回滚、切备、限流）可以做，其他变更一律禁止。多条变更并行会让根因判断彻底失效，也会增加恢复难度。所有故障期间的变更必须逐条记录。
按故障类型定：确定性故障（有明确触发条件）验证修复后即可关闭；偶发性故障建议观察一个完整业务周期（通常 1 至 4 周）；与容量相关的故障需观察下一个高峰窗口。
把每条故障沉淀为「现象 → 定位路径 → 处置动作 → 改进项」的短卡，接入知识库供检索，并挂到对应告警规则上。半年后这份记录会显著缩短平均定位时间，也是新人上手最快的材料。
可以，但要把工作标准化：清单化巡检、预设告警阈值、五套预案写成脚本化动作、以及考虑托管运维服务。小团队最忌讳的是依赖个人经验，一旦人员变动就失控。