“一级告警！XX医院HIS系统，门诊挂号功能不可用！”
上午九点十七分，运维中心的红色灯牌亮了。
值班工程师小王，看了一眼告警，心跳加速。
这不是普通故障，是业务中断。
他做的第一件事，不是去查原因，而是拿起电话，打给项目经理小张、技术负责人老周、客服主管。
“一级告警，门诊挂号不可用。我已经确认，不是网络问题，不是负载均衡问题，是挂号接口超时。”
挂掉电话，他又在应急响应群里发了标准化消息：
“`
【一级响应】XX医院门诊挂号不可用。
当前时间：09:18
影响范围：全部门诊窗口（20个）
受影响业务：挂号、预约、取消
初步判断：挂号微服务异常
我已 actions：
– 排查挂号服务日志
– 通知信息科李主任
– 准备回滚到旧版本
请求支援。
“`
这是软佳”应急响应SOP”的第一步：告警→确认→通报→初步行动。
1. 九点二十分：第一次事故会
九点二十分，应急响应群已经@了12人。
小张（项目经理）Establish 语音会议。
参会者：
– 老周（技术负责人）
– 小王（值班工程师）
– 小李（DBA）
– 小吴（网络工程师）
– 小赵（开发工程师）
– 信息科李主任
– 信息科网络管理员老陈
小张主持会议，一句话概括当前情况：
“挂号微服务持续报错：’数据库连接超时’。已经重启服务一次，没用。数据库连接池使用率持续100%。”
“小李，数据库什么情况？”
“挂号数据库CPU 95%，有大量慢查询。执行计划显示，某个查询走了全表扫描。”
“是什么查询？”
“查询患者的’已挂号记录’，用于在挂号界面显示历史。平时这个查询很快，但今天慢。”
“为什么今天慢？数据量暴增了吗？”
“数据量没变，但查询条件变了。今天挂号界面新增了一个’按科室筛选’功能，查询语句加了WHERE department_id = ?条件。这个字段没有索引。”
小赵（开发）突然说：”这个功能是上周五晚上紧急加上的，为了配合省卫健委的数据上报要求。我们没想到会影响这个查询。”
老周打断：”现在不是说谁责任的时候。小王，能否临时关闭’科室筛选’功能，恢复旧逻辑？”
“可以，但需要改代码上线。”
“多快？”
“热更新，5分钟。”
“做。”
2. 上午十点：第二次事故会
五分钟后，’科室筛选’功能关闭，查询恢复旧逻辑。
数据库CPU降到60%，挂号接口响应时间从15秒降到2秒。
但问题没完全解决——2秒还是太慢，正常应该<500毫秒。
“这个查询还有其他地方慢。”小赵说，”还有几个查询也慢，都是因为没有索引。”
“需要加索引。”小赵说。
“加索引需要锁表，能在线加吗？”老周问。
“可以online DDL，但会有短暂性能影响。”
“那就加。但增量加，先加最关键的三个索引，观察影响，再加其他的。”
他们制定了”索引热加”计划：
1. 先给patientvisits表的departmentid字段加索引（最关键）
2. 等待5分钟，观察性能
3. 如果正常，再加第二个、第三个
第一个索引加到一半，出事了。
数据库日志报错：”磁盘空间不足，无法创建索引”。
小李查磁盘空间：数据盘剩余5%，索引创建需要20%的额外空间。
“清理空间！”老周吼道。
清理什么？
– 清理归档日志（但归档日志是必须的，不能删）
– 清理临时表空间（有临时表可以删）
– 增加磁盘？不可能，物理机硬盘满了
他们决定：临时删除三个最占空间的非核心索引，腾出空间给新索引用。
这些索引是历史遗留，很少用，但删了再建也得时间。
更麻烦的是，删索引也会锁表（虽然时间短，几秒钟），但期间系统性能会雪崩。
“能不能不删，把旧索引挪到其他磁盘？”
不行，没有其他磁盘。
老周咬牙：”删，然后立刻建新的。窗口期只有10分钟。”
3. 中午十二点：第三次事故会
第一个新索引建好。
效果立竿见影：那个慢查询从2秒降到100毫秒。
但系统还是不流畅。
小王说：”有一个’统计查询’接口，平时10秒一次，现在15秒，超时了。”
这个接口，是领导看实时门诊量的，不直接影响患者，但影响领导决策（院长要看数据）。
查日志：这个查询很复杂，联查了六张表（患者、挂号、科室、医生、付费状态、退号标志），而且没索引。
“这个查询不能加索引吗？”老周问。
“可以，但涉及的字段多，需要组合索引，而且查询条件不固定（可以按时间、科室、医生任意组合），很难优化。”
“能不能把这个查询移出去，不要实时查？”
“但领导要实时看。”
小张说：”我们先加个临时缓存，把这查询结果缓存10分钟。同时，跟信息科沟通，让他们理解，这个数据有10分钟延迟。”
李主任同意了。
但缓存加好后，发现数据不对——统计口径问题（重复计数了）。
“这个查询的SQL有bug，统计了重复数据。”小吴说。
“那怎么办？重写？”
“重写需要测试，不敢直接上。”
“那就先关掉这个统计接口，等会后修复。”
4. 下午两点： blamed 会议
门诊终于恢复了正常。
患者能挂上号，医生能看诊，药房能发药。
但信息科杨院长，召开了”事故分析会”。
参会的不只是信息科，还有软佳的全体相关人员。
杨院长问：”为什么好端端的，一个’科室筛选’功能，能把系统搞崩？”
小赵解释：”我们没考虑到那个查询的索引…”
“你们测试的时候，没有性能测试吗？”
“有，但测试环境数据量只有生产的10%，没发现慢。”
杨院长转向老周：”你们软佳，交付前不是有’压测’吗？”
老周低头：”压测是做的，但场景不够全。’科室筛查’这个新功能，我们没压测。因为它是上线后一周才加的（为了满足新规），跳过了性能测试。”
“为什么没压测？”
“因为它是变更频繁的功能，我们以为只是个小改动…”
杨院长叹了口气：”小改动？现在门诊受影响，病人等了两小时。这是小改动吗？”
会议室很安静。
老周知道，这是他们的错。
5. 三个小时，写出事故报告
会后，小张带着团队，写事故报告。
根因：
1. 新功能’科室筛选’引入，未做性能评估（假设数据量不变）
2. 相关查询缺少索引
3. 磁盘空间不足（5%），限制应急响应速度
4. 慢查询监控有，但告警阈值设得太高（5秒以上才告警），等发现已经晚了
整改措施（48小时内生效）：
1. 所有SQL变更，必须走性能评估（执行计划分析+小数据量验证）
2. 建立”索引变更SOP”：加索引→监控→评估→推广
3. 建立”磁盘空间预警”：低于20%告警，低于10%自动清理临时文件
4. 所有功能变更，必须包含”性能测试用例”，压测通过才能上线
5. 慢查询监控阈值从5秒降到1秒
报告发给杨院长。
杨院长看完，回了一句：”希望这是最后一次。”
6. 事后，我们改了”变更流程”
老周在部门内复盘，说：
“这次事故，表面是技术问题，根子是变更管理流程缺失。”
我们有个流程：需求→开发→测试→上线。
但测试环节，只测功能，很少测性能。
性能测试， normally 是上线前专门做一次。但这次’科室筛选’是上线后一周才加的（为了满足新规），跳过了性能测试。
所以，我们要加一个环节：任何影响数据库查询的变更，必须附上’执行计划分析’和’索引影响评估’。
不能开发说”我觉得没问题”，要有客观数据。
而且，我们要建立’慢查询门禁’：新功能上线后，第一个月的慢查询数，不能超过 baseline 的150%。超过，自动回滚。
7. 72小时应急响应的”黄金法则”
这次事件后，软佳完善了”应急响应SOP”：
一级告警（业务中断）流程：
1. 5分钟内确认（值班人员）
2. 15分钟内建立应急群，相关人员到位
3. 30分钟内临时恢复（降级、回滚、扩容）
4. 2小时内根因定位
5. 24小时内根治方案上线
二级告警（性能严重下降）流程：
1. 15分钟内确认
2. 1小时内临时缓解
3. 4小时内根因定位
4. 24小时内优化上线
三级告警（功能异常）：
1. 1小时内确认
2. 24小时内解决
值班制度：
– 7×24小时值班（每班1人）
– 值班人员必须持有”应急启动U盾”，有权启动回滚
– 升级机制：15分钟内解决不了，自动升级到项目经理
8. 组织韧性：从”救火队”到”防火队”
这次事故后，软佳成立了”应急响应小组”，常设。
成员：
– 运维负责人（组长）
– DBA
– 网络工程师
– 核心开发
– 客户成功经理
每月一次演练，模拟各种场景：
– 数据库死锁
– Redis宕机
– 网络中断
– 磁盘满
– 应用OOM
演练后写报告，改进流程。
老周说：”应急能力，不是天生的，是练出来的。“
9. 事故的”正面价值”：警醒与改进
杨院长后来在一次医院信息会议上说：
“那次挂号故障，虽然只影响了两个小时，但让我们 seeing 了软佳团队的责任心——凌晨两点还在查问题，第二天就给了整改报告。”
“也让我们 seeing 了自己的IT管理问题——磁盘空间监控一直没重视。”
“坏事变好事。”
10. 给所有技术管理者的建议：应急不是运气，是准备
老周最后的总结：
“没有不出问题的系统，只有出问题后能不能快速恢复的系统。“
应急响应的核心，不是”技术多牛”，是：
1. 流程清晰——每个人知道自己该干什么
2. 工具趁手——有监控、有告警、有回滚按钮
3. 授权充分——值班人员有权启动预案，不需要层层请示
4. 演练真实——不是走过场，是真模拟
“这次72小时，我们救了系统，也救了客户信任。”
互动话题
你经历过最严重的业务中断事故是什么？怎么处理的？有什么经验？
> 基于真实医院场景改编，人物均为化名
立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html
手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）
支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语
说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。
你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。
