医疗交付局点的线上故障，卡点从来不是"发现慢"，而是**重启之后证据全没了、方向猜错、日志不敢传**。我们把后方架构师的排障经验固化为一个 CloudQ Skill（cloudq-med-incident-rca）：驻场一句话报障，Skill 在只读边界内冻结现场、多假设交叉证伪定位根因，把同一条证据链输出为驻场能照做的止血单和研发能直接改代码的根治包，处置动作经分级授权后由人执行。本文聚焦三件事：问题怎么处理、达到什么成效、沉淀了哪些可复用的经验。案例基于多个医疗局点的同类故障整理，名称与部分数字已处理，调用输出为示意输出。

## 一、问题：故障现场的三个动作，只活在两三个人脑子里

周一 08:32，某三甲医院诊间支付大面积报「系统繁忙」。驻场同事做了三件事：重启门诊计费服务的两个实例、打包网关日志、在群里问研发「是不是医保局慢了」。09:15 业务自己恢复了——早高峰过去，锁等待自然消散。

真正的根因后来才查清：一行汇总记录的锁等待从 08:18:12 就开始了，比第一条网关告警早 12 分 53 秒。**08:41 那次重启把连接池清空了两分钟，也把最有价值的证据——线程栈、连接池水位、锁等待链——全部抹掉了。** 接下来三天，研发怀疑现场配置，现场怀疑医保专线，来回要日志、要截图。下一个周一，同样的事再来一次。

复盘下来，驻场同事缺的不是日志（日志多到看不过来），缺的是三个必须在重启**之前**完成的动作，每一个都依赖经验：

| 动作 | 难点 | 为什么靠人撑不住 |
| --- | --- | --- |
| **抓现场** | 在哪一分钟、对哪几个服务、抓哪几样易失证据 | 只有排过几十次故障的人才会判断；重启一次全部归零 |
| **看懂因果** | 业务链路长（自助机→网关→计费→集成平台→医保前置机），告警时间≠故障起点 | 首条告警常滞后真实拐点十几分钟，顺着告警查方向就错了 |
| **安全传证据** | 日志里有患者姓名、身份证号、医保卡号 | 数据出域合规约束下，多数局点干脆不传，研发只能盲猜 |

三个角色各自的卡点：驻场不知道先干什么，默认动作是重启；研发拿到的是 200MB 日志包和截图，没有锁等待链、没有拐点时间；院方信息科无法核查传出去的日志有没有患者信息。

方案目标只有三条：**现场不丢、方向不错、数据不出域**。非目标同样明确：不自动执行任何生产变更，不替代研发改代码。

## 二、处理：一个 Skill，五步只读取证

问题想清楚之后，方案就是把这「三个动作」固化成 CloudQ 可调用的 Skill。流程来自一个追问：后方架构师远程接手时实际按什么顺序做事？答案稳定地只有五步。

![1a16249188a3b.png](https://developer.qcloudimg.com/http-save/yehe-7660620/6cada813eba57c46253105746886f8d7.png)

**五步：** ① 收敛告警并冻结现场（聚类去重，各项之和必须等于原始条数；并发抓指标、连接池水位、DB 锁快照）→ ② 沿医疗业务图谱回溯，划清「院内核心域 / 院外交互域」→ ③ 定位真实拐点，只对拐点前后 [-15m, +5m] 窗口取证，取回内容强制先过脱敏脚本 → ④ 三个假设（院内代码缺陷 / 数据库锁争用 / 医保前置机超时）交叉证伪，区分根因与传导影响 → ⑤ 同一条证据链输出两份：驻场止血单 + 研发根治包。

三个关键设计决策，每个都对应一类真实事故：

**只读是硬边界，不是可配置项。** Skill 不挂载任何写工具，连重启都不做。止血动作以命令文本输出，授权后由人执行。局点没有预发环境，早高峰一个错误写操作会把局部故障放大成全院故障。

**因果以拐点为准，不以告警时间为准。** 这条直接学自征文示范 cloudq-alert-triaging。早高峰排队累积让症状延后，Skill 用指标拐点和首个锁等待时间戳定因果，告警时间只用来圈时间窗。

**两件事交给确定性脚本，不交给模型。** 数字守恒（收敛各项之和=原始条数）和隐私脱敏。模型会算错总数、漏掉一个身份证号，这两种错误在医疗局点都不可接受——用正则和算术兜底，模型只消费脚本处理后的结果。

Skill 按 CloudQ 目录约定组织，行业差异集中在三个文件里（见文末迁移表），核心是 SKILL.md：

```text
cloudq-med-incident-rca/
├── SKILL.md                     # 元数据 + 工具边界 / 五步 / 安全边界 / 铁律
├── references/
│   ├── med_service_topology.md      # 标准调用链
│   └── known_error_patterns.md      # 常见根因库：热点行、事务内RPC、前置机超时…
├── scripts/
│   ├── phi_desensitizer.py      # PHI 确定性脱敏（按字段名+格式）
│   ├── conservation_check.py    # 守恒校验 + 拐点检测
│   ├── scoped_log_fetch.py      # 按故障域+时间窗取证，出口强制脱敏
│   └── db_lock_snapshot.sql     # pg_locks 阻塞链快照（只读）
└── assets/                      # 止血单 / 根治包模板
```

```markdown
---
name: cloudq-med-incident-rca
description: 面向智慧医疗交付局点的线上故障只读取证、多假设根因定位与双层方案生成。收敛告警并冻结易失现场，沿 HIS/医保业务图谱回溯依赖，以指标拐点与脱敏后的日志、数据库锁快照交叉验证因果，输出驻场应急止血单与研发代码级根治包。当交付或运维人员提到「医院现场故障」「医保结算卡顿」「收集现场日志」「分析报错给研发修复方案」时使用。仅做只读取证与诊断，任何处置动作交回用户侧授权确认。
---

# 智慧医疗局点故障取证、根因定位与双层方案

## 工具与证据边界
cloudq.alert.query / cloudq.graph.trace / cloudq.metric.query
scripts/scoped_log_fetch.py / scripts/db_lock_snapshot.sql（局点只读账号）
证据仅来自五类：告警、业务拓扑、指标时序、故障域内脱敏后的错误日志与调用链、数据库瞬时锁快照。
不在范围内：heap dump、core dump、完整业务报文、医保中心端日志、任何未脱敏的患者数据。
需要范围外证据才能定论的，只输出高优假设并标注待验证项。

## 执行步骤
1. 现场冻结与告警收敛：聚类去重，过滤例行字典同步与变更窗口；conservation_check.py 校验各项之和=原始条数。并发抓黄金指标、连接池/线程池水位，执行 db_lock_snapshot.sql 固定锁等待链。
2. 图谱回溯与内外定界：结合 med_service_topology.md 判定「院内核心域」/「院外交互域」，明确调用方向。
3. 拐点定位与按窗口取证：只对故障域内实例拉 P99、连接池活跃数、DB 活跃会话，定位劣化拐点；仅对拐点前后 [-15m,+5m] 窗口取证，输出强制经 phi_desensitizer.py 脱敏。
4. 多假设交叉证伪：H1 院内代码/配置缺陷、H2 数据库锁争用/慢SQL、H3 外部医保前置机/专线超时，同时取证；按「拐点先后+调用方向+堆栈/锁证据」判定，区分根因与传导影响，给出置信度及其依据。
5. 双层方案：依据 known_error_patterns.md 与模板，输出【驻场应急止血单】（每条附前置检查与回滚命令）与【研发根治方案包】（脱敏调用链+代码定位+修复步骤）。

## 安全边界
- 全流程只读。不执行重启、Kill 会话、改配置、切流等任何变更，动作仅以命令文本输出，用户授权后执行。
- 进入对话或方案包的日志、SQL 参数、堆栈，必须先经 phi_desensitizer.py；患者姓名、身份证号、医保卡号、手机号一律替换为 [REDACTED_*]。
- 探针缺失（无锁快照、拓扑未知、日志不可达）时标注「未知」，降级推理不中断，不编造缺失证据。

## 铁律
- 因果先后以指标拐点与首个锁等待时间戳为准，不以告警触发时间、也不以驻场报障时间为准。
- 与下游拐点同刻或滞后发生的上游超时、网关 5xx、线程池耗尽，一律归为传导影响，不得作为独立根因。
- 置信度必须说明「为什么不是更高」，列出待补齐证据；不确定就上报，不编造堆栈、行号或 SQL。
- 止血单优先级：先阻止证据灭失（不重启），再降低持锁时间，最后才是扩容。
```

脱敏脚本的关键取舍：正则抓不住自由文本里的人名，所以 Skill **根本不取业务报文 body**，只取结构化字段、堆栈和 SQL 绑定参数；姓名与医保卡号按字段名脱敏（各省格式不一），身份证、手机号按格式脱敏。宁可少取，不冒险。每次调用的脱敏拦截计数写入审计日志，院方信息科可抽样回查——这一条往往是方案能否上线的决定因素。

```python
# scripts/phi_desensitizer.py  患者隐私确定性脱敏（节选）
NAME_KEYS = r"(?:patientName|patient_name|pat_name|姓名|患者姓名)"
INSUR_KEYS = r"(?:insurNo|medicareNo|医保号|医保卡号|社保卡号)"
PATTERNS = [
    ("ID_CARD", re.compile(r"(?<!\d)\d{6}(?:19|20)\d{2}(?:0[1-9]|1[0-2])(?:0[1-9]|[12]\d|3[01])\d{3}[\dXx](?!\d)")),
    ("PHONE",   re.compile(r"(?<!\d)1[3-9]\d{9}(?!\d)")),
    ("NAME",    re.compile(rf'("?{NAME_KEYS}"?\s*[:=]\s*"?)([^",\s}}\]]+)')),   # 按字段名替换
    ("INSUR_NO",re.compile(rf'("?{INSUR_KEYS}"?\s*[:=]\s*"?)([^",\s}}\]]+)')),
]
def sanitize(raw):
    text, counts = raw, {}
    for label, pat in PATTERNS:
        text, n = pat.subn(f"[REDACTED_{label}]", text)
        counts[label] = n
    return {"text": text, "redacted": counts, "total": sum(counts.values())}  # 计数入审计日志
```

处置动作按**爆炸半径和可逆性**分级授权，Skill 只把动作、风险等级、回滚方式写清楚：

| 等级 | 动作性质 | 谁授权 | 谁执行 |
| --- | --- | --- | --- |
| T0 只读 | 查询、快照、脱敏取证 | 无需授权 | Skill 自动执行 |
| T1 低风险可逆 | CONCURRENTLY 建索引、清理 idle in transaction | 驻场交付 | 驻场按止血单执行 |
| T2 高风险 | 重启、改配置、调连接池上限 | 院方信息科 | 驻场在院方确认后执行 |
| T3 根治 | 代码与结构变更 | 研发负责人+院方变更窗口 | 研发走发布流程 |

## 三、成效：同一次故障，Skill 在 08:38 给出的东西

把开头那次故障回放给 Skill，驻场只需要在 WorkBuddy 里说：

> 今早 08:30 开始，门诊诊间支付大面积报「系统繁忙」，告警刷了八百多条。我不知道该抓哪个服务的日志，帮我收集分析一下，给研发一份能直接改的方案。

Skill 返回（示意输出，局点名与部分数字已处理）：

```text
【告警收敛与现场冻结】846 条 → 有效 19 条（收敛率 97.8%）
  重复合并 712｜已知网络抖动 81｜晨间字典同步窗口 34｜保留有效 19
  守恒校验：712 + 81 + 34 + 19 = 846  通过
  已冻结：4 个故障域服务 [-15m,+5m] 窗口日志、2 次 DB 锁快照（08:25 / 08:33）
  合规审计：脱敏拦截并替换 1,420 处（ID_CARD 388｜PHONE 212｜NAME 541｜INSUR_NO 279）

【关键时序与真实拐点】
  08:18:12  his-billing-db 首次出现对 med_insur_daily_summary 单行的锁等待   ← 实际起点
  08:24:40  his-outpatient-billing HikariCP 活跃连接 12 → 100（占满）
  08:31:05  med-api-gateway 首条 504 告警                                     ← 滞后拐点 12m53s
  08:32:00  诊间支付、收费窗口大面积报错
  08:36:10  驻场报障（本次调用）

【根因】置信度 0.91（H1 院内代码缺陷 + H2 锁争用，同一处代码的两个后果）
  医保预结算接口在同一事务里：UPDATE 全院共用的当日汇总行 → 同步调医保前置机（1.2s）
  → UPDATE 结算流水表。早高峰每笔结算都拿同一行的锁，87 个会话排队，连接池打满。
  辅因：insur_seq_no 无索引，事务内 UPDATE 走 Seq Scan（均值 3,812ms），持锁时间 1.3s → 5.1s。
  证据：08:25 锁快照根会话 idle in transaction + 87 会话 wait_event=Lock；脱敏 Trace 时序
  （事务开启→RPC→UPDATE→commit）与图谱传导方向吻合。
【传导影响（已排除独立根因）】网关 504、挂号查询超时均在拐点后出现，共享同一连接池；
  H3 医保专线 P99 与近四周基线一致，排除。
【置信度未达更高的原因】未开 auto_explain，无法确认执行计划跳变；前置机侧日志不在证据范围内。

【驻场应急止血单】以下动作需你授权后执行
  0. 先不要重启。重启只清空连接池，2 分钟内会再次打满，而且会丢掉现场。
  1. CREATE INDEX CONCURRENTLY idx_settle_insur_seq ON med_insur_settlement_log (insur_seq_no);
     不锁表，预期单笔持锁 5.1s → 约 1.3s，排队会话随之回落
  2. 清理 idle in transaction 超 30s 的会话（先预检列出目标，确认后终止）
  3. 不建议上调连接池上限：瓶颈是热点行串行化，加连接只会让更多会话排队
  预期：1、2 执行后 3 分钟内结算成功率回升。

【研发根治方案包】已归档 #INC-20261012-HIS01
  问题代码：OutpatientSettleServiceImpl#executeMedicarePreSettle（Line 235~269）
  缺陷模式：事务内嵌套远程调用（持锁被外部耗时放大）+ 热点行实时汇总
  Step 1 拆事务：RPC 移出事务，短事务写流水，持锁目标 < 20ms
  Step 2 汇总异步化：按分钟聚合替代每笔结算写同一行
  Step 3 Flyway 固化 insur_seq_no 索引
  验收：早高峰并发压测，行锁等待 < 10ms，结算接口 P99 < 800ms
  附件：脱敏 Trace（28KB）｜锁快照 ×2
```

**与人工过程的前后对比，就是这套方案的成效所在：**

| 维度 | 人工（文章开头） | Skill | 变化 |
| --- | --- | --- | --- |
| 故障起点 | 认在首条告警 08:31 | 推到锁等待 08:18:12 | **前推 12m53s，研发查错方向直接纠正** |
| 第一个动作 | 重启（抹掉全部易失证据） | 「先别重启」+ 冻结现场 | 证据链完整保留 |
| 研发拿到的东西 | 200MB 日志包 + 截图 + 「重启之后好了」 | 脱敏 Trace + 2 份锁快照 + 类名行号 + 已证伪方向（医保专线） | 从盲猜到直接改代码 |
| 定位周期 | 三天拉扯 + 下周一复发 | 一次调用，分钟级 | 闭环提前两个量级 |
| 驻场需要的技能 | 知道抓哪个服务、哪一分钟、抓什么 | 一句自然语言 | 经验门槛归零 |
| 合规 | 原始日志拷出域（或干脆不传） | 1,420 处脱敏，计数可审计 | 证据敢传了 |

上线采用**三阶段放量**，信任是跑出来的不是宣布出来的：先只读伴飞 2–4 周（止血单关闭，考核根治包采纳率与「研发二次索要日志」次数下降），再打开 T1 受控止血（以历史 P1/P2 故障脱敏回放集考核首轮根因命中率、传导误判为根因的次数），最后换三个文件复制到其他局点。**回放集是第二阶段的命门**——没有它，「达到内部阈值」就是一句空话。

## 四、对标信通院《云上 Agent 基准度量模型》六维

经验要对标，前提是先拆开——拆成能落进格子的设计，每一格给一个可被第三方检查的点，而不是形容词。

| 层级 | 维度 | 对应设计 | 可审计的检查点 |
| --- | --- | --- | --- |
| 红线 | 功能性 | 收敛→回溯→拐点→脱敏取证→多假设证伪→双层方案，五步闭环 | 每次输出必含【根因】【传导影响】【置信度未达更高的原因】三段，缺一即未完成 |
| 红线 | 安全性 | 只读不挂写工具；止血动作文本输出回授权；全量文本先过脱敏脚本 | 工具清单无写接口；输出附脱敏拦截计数，可抽样回查 |
| 核心 | 可靠性 | 守恒由脚本校验；因果以拐点+首个锁等待时间戳为准；缺探针标注「未知」降级 | 守恒结果写入输出；缺失探针的局点应出现「未知」而非补全证据 |
| 核心 | 成本效益 | 先定故障域再取证，只取拐点前后 [-15m,+5m] 窗口 | 本次取证 4 个服务、20 分钟窗口而非全院当日日志，范围在输出中可见 |
| 评价 | 用户体验 | 一句自然语言报障；输出分驻场/研发两份，各自能直接执行 | 止血单每条附前置检查与回滚；根治包含类名、行号、验收标准 |
| 评价 | 性能效率 | 冻结、定因、出方案一次调用完成 | 报障到输出耗时记录在调用日志，可按局点统计分布 |

我们刻意没写「效率提升 N 倍」：上线时间尚短，局点与故障数不足以支撑统计结论。能给的是一次完整实录、每一格的检查方法和回放集考核机制——等回放集跑过足够多的历史故障，再补数字。

## 五、经验总结：五条带得走的

**1. 固化的不是「分析日志」，是三个动作本身。** 「AIOps 辅助排障」容易写成泛化能力，落地要的是把「抓现场、看因果、安全传证据」拆成固定顺序、只读执行、带脱敏的具体步骤。能力越泛，越不可审计。

**2. 只读边界决定信任曲线。** 写权限留给人，方案的价值就只取决于判断准不准，而不取决于会不会闯祸。这是医疗这类敏感行业敢于引入 Agent 的前提。分级的依据是爆炸半径和可逆性，不是技术难度。

**3. 模型和脚本各干各的。** 模型做它擅长的（多假设推理、区分根因与传导、生成双层方案），确定性的事（数字守恒、隐私脱敏、按窗口取证）交给脚本兜底。两种错误——算错总数、漏一个身份证号——在医疗局点都不可接受。

**4. 降级优于中断，边界写在明处。** 图谱缺失就把置信度压到 0.7 并说明原因；没有锁快照就明确写「疑似，无法区分锁等待与慢查询」；日志不可达就把「日志不可达」列为第一条待验证项。**一个 Skill 可信的前提，是它知道自己不知道什么。**

**5. Skill 骨架与行业无关，行业属性收敛在三个文件里。** 换掉它们就能迁移，调用方式、输出结构、六维检查点都不用动：

| 要换的文件 | 医疗局点 | 金融渠道侧 | 政务一网通办 |
| --- | --- | --- | --- |
| references/*_topology.md | 自助机→网关→计费→集成平台→医保前置机 | 手机银行→渠道网关→核心前置→核心系统→人行/银联 | 政务App→统一门户→事项中台→部门系统→共享平台 |
| references/known_error_patterns.md | 热点汇总行、事务内调医保、字典同步窗口 | 批量代扣热点账户、日终跑批抢锁、回调超时 | 共享平台限流、证照调用超时、月初集中申报 |
| scripts/phi_desensitizer.py 规则 | 身份证、医保号、患者姓名、诊断 | 卡号、账号、手机号、交易对手 | 身份证、户籍地址、社保编号 |

一次沉淀的价值不在一个局点，而在它能被多少个局点直接拿走。

## 写在最后

文章开头那位驻场同事，后来成了这个 Skill 最早的使用者。他说：「以前出事我最怕的不是修不好，是不知道该先干什么。」这套方案做的，就是把「该先干什么」从两三个人的脑子里拿出来，写成一份流程、一个 Skill、四个脚本和一张授权表。它不替人做决定，不碰生产环境的任何写操作——只是在早高峰最混乱的那几分钟里，把现场冻住，把方向指对，把证据脱敏后交到该看的人手上。

医疗交付局点的线上故障，卡点从来不是"发现慢"，而是重启之后证据全没了、方向猜错、日志不敢传。我们把后方架构师的排障经验固化为一个 CloudQ Skill（cloudq-med-incident-rca）：驻场一句话报障，Skill 在只读边界内冻结现场、多假设交叉证伪定位根因，把同一条证据链输出为驻场能照做的止血单和研发能直接改代码的根治包，处置动作经分级授权后由人执行。本文聚焦三件事：问题怎么处理、达到什么成效、沉淀了哪些可复用的经验。案例基于多个医疗局点的同类故障整理，名称与部分数字已处理，调用输出为示意输出。

抓不到现场、看不懂日志、不敢传数据：基于 CloudQ 的智慧医疗局点线上故障协同处置方案

医疗交付局点的线上故障，卡点从来不是“发现慢”，而是重启之后证据全没了、方向猜错、日志不敢传。本文把后方架构师的排障经验固化为一个 CloudQ Skill（cloudq-med-incident-rca）：驻场一句话报障，Skill 在只读边界内冻结现场、多假设交叉证伪定位根因，把同一条证据链输出为驻场能照做的止血单与研发能直接改代码的根治包，处置动作分级授权、由人执行。

资深架构师

数据库

医疗局点故障根因定位慢、重启致证据丢失问题，可通过只读取证Skill解决。方案冻结现场、多假设证伪、脱敏传证，输出止血单与根治包，定位周期从3天缩至分钟级，研发可直接改代码。

代码解释

WorkBuddy 

CloudQ

AIOps

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

抓不到现场、看不懂日志、不敢传数据：基于 CloudQ 的智慧医疗局点线上故障协同处置方案-腾讯云开发者社区-腾讯云

抓不到现场、看不懂日志、不敢传数据：基于 CloudQ 的智慧医疗局点线上故障协同处置方案

抓不到现场、看不懂日志、不敢传数据：基于 CloudQ 的智慧医疗局点线上故障协同处置方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐