“周总，出事了。”
凌晨三点，周总被电话叫醒。
电话是XX医院护理部陈护士长发来的，声音很急，带着哭腔：”我们护士站，突然批量出现’医嘱无法执行’，几十个护士等着用药，病人家属都围过来了。有病人等着急救，系统不响应，我们在用手写…”
周总立刻清醒了。
这是XX医院HIS系统上线后第四个月，第一次出现大规模的在线故障。
他一边穿衣服，一边打电话给小张（项目经理）、小刘（运维负责人）、小李（DBA）。
“一级响应，所有人半小时到医院。带上笔记本电脑、备份U盘、应急工具。”
半小时后，三人都到了医院信息科。
李主任已经在了，脸色很难看，在走廊里来回踱步。
“什么情况？”周总问。
“大约半小时前，开始有护士报错：’医嘱执行失败，系统错误’。起初是个别现象，我们以为是网络问题。但不到十分钟，半个医院的护士站都报错。现在门诊、住院的药房系统也受影响，没法发药。”
周总和团队冲进机房。
1. 紧急排查：从”症状”到”根因”
小刘开始查日志。
日志显示：”医嘱执行”这个接口的错误率，从0%飙升到了87%。错误信息是”数据库连接超时”。
但数据库连接池正常（使用率60%），CPU使用率正常（45%），网络也正常（延迟1ms）。
“不是连接不上数据库，”小刘说，”是某个查询特别慢，把连接占住了。”
“哪个查询？”
“”获取待执行医嘱列表”这个接口。平时这个接口300毫秒，现在有的请求要15秒。”
小刘调出那条SQL：
“`sql
SELECT o.order_id, p.patient_name, d.drug_name, o.status
FROM orders o
JOIN patients p ON o.patient_id = p.patient_id
JOIN drugs d ON o.drug_id = d.drug_id
WHERE o.status = ‘待执行’
AND o.created_time >= DATE_SUB(NOW(), INTERVAL 1 DAY)
ORDER BY o.priority DESC, o.created_time ASC;
“`
“为什么突然变慢？”周总问。
小吴查了一下：”这个SQL，最近一次代码变更是一周前，加了ORDER BY o.priority。但上周压测通过了啊。”
“数据量现在多大？”
“orders表，加上四月份的数据，现在有230万行。’待执行’状态的，大概15万行。”
老周看执行计划：
– o.status 有索引（status_idx）
– o.createdtime 有索引（createdtime_idx）
– 但ORDER BY o.priority没有索引
– MySQL选择用status_idx，扫描15万行，然后排序15万行
这就是问题所在——“文件排序”（filesort）导致性能雪崩。
小吴说：”上周压测时，数据量只有50万，’待执行’只有3万，排序很快。现在量大了三倍，排序变慢10倍。”
周总：”加个组合索引：(status, priority, created_time)，能不能解决？”
小吴：”可以，但需要锁表。online DDL也要10分钟，现在能用吗？”
现在门诊还在运行，锁表会雪上加霜。
2. 紧急处理：降级、扩容、加索引，三管齐下
老周决定三管齐下：
第一步：功能降级
– 临时关闭”优先级排序”，按created_time排序就够了
– 改SQL，去掉ORDER BY priority
– 热更新配置，不需要重启
– 5分钟完成
效果：查询时间从15秒降到2秒，但还不够（正常应该<500毫秒）
第二步：扩大连接池（临时）
– 连接池从50扩大到100
– 防止其他功能因为等待连接而卡住
– 效果：其他接口恢复正常
第三步：热加索引
– 给orders表加组合索引：idxstatusprioritytime (status, priority, createdtime)
– 使用MySQL的ALGORITHM=INPLACE, LOCK=NONE在线加索引
– 预计时间：15分钟
– 期间性能会有轻微下降
小吴开始执行。
但加索引到一半，出事了。
3. 危机升级：磁盘空间不足
数据库日志报错：”磁盘空间不足，无法创建索引”。
小李查磁盘空间：
– C盘（系统盘）：剩余5%
– D盘（数据盘）：剩余3%
– 日志文件占用空间，从三个月前的50GB，增长到了160GB
“日志为什么占这么大？”老周问。
信息科老陈说：”系统日志级别设为了DEBUG，每条SQL都记录。平时没事，但上线后bug多，日志量大增。我们还没来得及调整。”
而且，自动日志清理任务，上周执行失败了——因为没人检查执行结果。
老周明白了：这不是单一原因，是系统性的运维意识薄弱。
几个环节：
– 日志级别不合理（DEBUG级别太细，应该WARN或ERROR）
– 没有监控磁盘增长（告警阈值设为5%，等发现时已经太晚）
– 自动清理任务失败了没人管（有执行，没验证）
三个小问题，叠加在一起，造成了大故障。
老周当机立断：
1. 临时删除最占空间的三个非核心索引（历史遗留，很少用）
2. 清理一周前的日志文件（压缩备份后删除）
3. 调整日志级别为WARN
4. 加索引继续
折腾了40分钟，腾出30GB空间。
索引终于加完。
效果立竿见影：
– 那个查询从2秒降到80毫秒
– 系统错误率从87%降到0%
早上四点三十分，系统恢复。
护士们终于能正常开医嘱、发药了。
4. 根因分析：一个”小疏忽”引发的大事故
事后，周总主持了深度复盘。
参与的包括软佳团队、信息科、护理部代表。
周总先问了一个问题：”这次故障，直接原因是SQL慢。但SQL为什么慢？”
小吴：”因为数据量大了，排序开销大。”
“数据量大是突然发生的吗？”
“不是，是按月增长的，四月份增加了30%。”
“那为什么我们没有提前预警？”
没人说话。
周总自己回答：
1. 没有容量规划——不知道数据增长趋势，不知道索引会失效
2. 没有性能回归测试——上周改代码时没测这个查询在新数据量下的表现
3. 没有监控磁盘空间——告警阈值5%太低，应该20%就预警
4. 没有自动任务验证——日志清理任务失败没人发现
5. 没有紧急响应预案——遇到磁盘满不知道优先做什么
“这不是技术问题，是运维管理问题。”
5. “救火”后，我们做了三件事：从”被动响应”到”主动预防”
周总回到公司，没睡觉，而是组织了一次”售后复盘会”。
他做了三件事：
① 建立”预防性运维”清单
软佳为客户提供的”月度健康检查”清单，增加了五项：
– 检查磁盘空间增长趋势（提前发现数据膨胀）
– 检查自动任务执行日志（确保任务没silently失败）
– 检查日志文件大小和级别（适时调整，避免占满磁盘）
– 检查慢查询日志（及时优化，防止雪崩）
– 检查缓存命中率（防止缓存失效导致穿透）
② 推出”健康巡检”服务
每月一次上门，免费为医院做系统健康检查。
检查清单包括上面那五条，再加上：
– 备份有效性验证（备份能否恢复）
– 安全补丁状态（操作系统、数据库、中间件）
– 性能基准测试（对比上月，看是否退化）
巡检后给一份报告，列出风险和建议。
“这个服务，目前免费。”周总对李主任说，”但半年后，如果你们觉得有价值，我们可以签年度服务协议，一年18万。”
李主任点头：”你们想得挺周到。”
③ 为所有客户做一次”紧急响应演练”
模拟各种故障场景：
– 磁盘满
– 数据库死锁
– 网络中断
– 应用OOM
– Redis宕机
演练工程师的响应流程：
1. 告警确认（5分钟内）
2. 快速定位（15分钟内）
3. 临时解决（30分钟内）
4. 根因分析（4小时内）
5. 整改（24小时内）
评估：响应时间、解决效率、沟通质量。
周总说：”这次凌晨故障，暴露了我们应急流程的问题。人员到场时间是30分钟，太长。下一次，我们要做到15分钟内响应核心故障。”
6. “售后服务”才是真正的营销：最好的销售是解决危机
三个月后，周总正在给另一家医院（ZZ医院）做巡检。
这家医院的情况，比XX医院还糟糕：
– 日志文件300GB，占满了C盘
– 数据库有137个未使用的索引，拖慢写入
– 有一个批量任务（每晚跑），每天凌晨跑5小时，但业务不知道它在跑什么
– 磁盘监控是摆设，告警一直没处理
周总边检查，边对信息科主任说：”你们这系统，就像一个从不保养的汽车，勉强能开，但随时可能抛锚。”
主任苦笑：”我们这不是不知道要保养吗？”
周总帮他制定了年度运维计划：
– 每月健康巡检
– 每季度性能调优
– 每年架构评审
– 每半年灾难演练
“签个服务协议吧。”周总说，”我们帮你们把系统养好，你们能安心用。”
主任问：”多少钱？”
“一年18万。”
主任心里一算：请一个专职DBA，一年工资都不止这个数。还有监控工具、巡检成本…
“签。”
7. 售后服务的”心法”：从”成本中心”到”利润中心”
周总后来在一次行业会议上，分享了他的”售后服务经”：
“很多人觉得，售出产品，销售就结束了。但我觉得，售出产品，销售才刚开始。”
“产品就像种子，售后就是浇水、施肥、除虫。没有好的售后，再好的种子也长不好。”
“而售后，是最好的营销。”
为什么？
因为客户在遇到问题时，最能感受到你的价值。
产品一帆风顺时，客户觉得”这系统还行”；但出问题时，你响应快、解决得好，客户会觉得”这公司靠谱”。
(“一次成功的应急响应，胜过十次销售拜访”)。
XX医院那次凌晨故障，我们到场半小时，解决问题两小时。事后，他们信息科主动给我们介绍了一家新客户。为什么？因为他们 seeing 了我们的责任心和专业能力。
所以，售后服务不是成本，是投资。
而且，这个投资的回报率，非常高——一个满意的老客户，会带来新客户；一个不满意的客户，会带走一片客户。
软佳后来成立了”客户成功部”，不再是简单的”售后技术支持”，而是”客户成功经理”制。
每个客户，配一名成功经理，职责：
– 定期巡检
– 主动优化
– 健康度评估
– 需求收集
– 续约推进
成功经理的KPI，不是”处理了多少工单”，而是：
– 客户健康度评分
– 系统可用率
– 故障次数趋势（下降）
– 客户NPS
– 续约率
这个部门，成了公司增长最快的部门——不是因为签了多少新单，而是老客户续约率从75%提升到了92%。
“很多公司，把售后当成本中心。”周总说，”我们把它当利润中心。”
解释：一次成功的售后，带来口碑，带来新客户，新客户的第一年收入，就是售后部门的”贡献”。老客户续约，也很大程度取决于售后体验。
所以售后部门创造的”间接价值”，远超其人力成本。
8. 凌晨电话，是信任的信号
陈护士长后来给周总发了条短信：
“周总，那天凌晨不好意思，打扰你们了。但说真的，你们来得很快，解决得很快。护士们都说，软佳的人，靠谱。”
周总把这条短信，贴到了客户成功部的墙上。
他说：”这条短信，比任何销售合同都有价值。因为它是客户在情绪最焦虑的时候，发给我们的——这种时候的信任，是最真的。”
9. 售后服务的”三个层次”
周总把客户关系，分为三个层次：
第一层：交易关系
– 你给我钱，我给产品
– 履约即结束
– 容易替代（谁便宜选谁）
第二层：服务关系
– 有问题，响应快
– 有需求，能满足
– 有感情，但不多
– 不太容易被替代
第三层：伙伴关系
– 主动发现客户问题（巡检发现问题，不等客户报）
– 帮客户规划未来（需求 roadmap）
– 为客户的失败感到难过，为客户的 success 感到高兴
– 很难被替代——因为客户觉得你”懂”他
软佳在向第三层努力。
而华通，还在第一层——赵某每次来，就是”我们有个新功能，您要不要看看？”
10. 售后响应”黄金一小时”原则
周总后来制定了一个”售后响应标准”：
一级告警（业务中断）：
– 响应时间：5分钟内确认
– 支持人员到场：15分钟内（同城）
– 临时解决：30分钟内
– 根因分析：4小时内
– 根治方案：24小时内
二级告警（性能严重下降）：
– 响应时间：15分钟内确认
– 临时解决：2小时内
– 根因分析：24小时内
三级告警（功能异常，但不影响核心业务）：
– 响应时间：1小时内确认
– 解决时间：24小时内
“我们卖的不是软件，是’7×24小时安心’。”周总说。
客户买的是功能，但期待的是服务保障。
互动话题
你有遇到过”超出预期”的售后服务吗？是什么让你觉得”值了”？
> 基于真实医院场景改编，人物均为化名
立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html
手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）
支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语
说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。
你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。
