场景
我的很多可靠性直觉来自医疗 IT，而不是产品分析看板。那些系统从一个角度看都很普通：临床应用、服务器、网络设备、终端、报表路径和内部工具。但后果模型并不普通。系统一旦出问题，就会表现为患者流转变慢、前台工作受阻、临床记录延迟，或者让本来已经在维持服务运转的人承受额外压力。
这种环境让我不再把可靠性看成抽象概念。它不只是 SLA 数字或监控面板上的绿色状态，而是队伍能继续向前移动，还是因为技术系统已经成为诊疗流程的一部分而开始堆积。
服务恢复时，事故只完成了一半
一次存储事故让我很具体地理解了这一点。一个与电压相关的问题影响了基础设施组件，并带来临床系统中断的真实风险。当时的首要任务不是写一份完美的复盘，而是按照应急预案执行，支持切换到备用服务器，并在要求的恢复阈值内恢复服务。
服务在 10 分钟阈值内恢复了。在当时，这是最可见的成功。但更重要的工程教训发生在服务恢复之后。并不是用户又能工作了，这个事故就算结束。
后续变成了很实际的预防工作：UPS 和供电稳定性检查、双电源方案考虑、磁盘健康检查，以及更强的数据库备份安排。这些都不戏剧化，而这正是重点。好的事故响应应该把一次失败转化为一种朴素机制，让下一次失败更不容易发生、更不混乱，或者更容易恢复。
先表达不同意见，再遏制风险
另一个可靠性教训来自一次服务器更换。两台临床系统服务器已经到达服务寿命末期，支撑的是一个面向患者的儿童保健系统。我的建议基于容量需求、软件方确认和运营风险。最终选择的是一个成本更低的硬件复用路径。
这个故事不成熟的版本，是把它讲成一种个人证明。这不是有用的教训，也不是现实组织的运作方式。一旦决策路径明确，我的工作就是尽可能让被选中的路线更安全：记录风险，保持正式汇报链路完整，和技术相关方重新确认假设，并定义黄色和红色时间预警阈值，让团队知道计划什么时候会变得不安全。
之后，切换被安排在低流量窗口，并和相关软件及基础设施侧一起测试，同时准备回滚方案。切换完成后没有造成重大即时中断。被复用的硬件后来在峰值负载下暴露出限制，所以这不是一个干净的胜利故事。真正有用的部分是风险遏制：可见的风险、有时间边界的阈值、监控和恢复流程，而不是模糊地期待更便宜的路径能表现得像更安全的路径一样。
可靠性也意味着移除重复失败路径
同样的模式也出现在更小的运营工具里。静态 IP 跟踪原本依赖纸面和电子表格，这让冲突处理和查询都比必要的更慢。我做了一个基于 C# / ASP.NET / SQL Server / IIS 的内部工具，用来记录 IP、MAC、设备、科室和资产信息，并把它和设备及终端数据的定期检查结合起来。
结果不是一个炫目的系统，但它对运营很有意义：约 900 条 IP 记录和 500+ 条资产记录，查询和分配时间从约 5–6 分钟降到 1 分钟以内，重复 IP 冲突接近归零。这类工具也是可靠性工作的一种。它移除了一条重复失败路径，而不是要求团队记住更多规则。
这如何体现在我现在写的代码里
我不会说现在的软件项目承载着和真实临床环境一样的风险。它们没有。但偏好是一致的。在 IdeaSense AI 里，长时间的富化工作不应该只因为系统技术上能做到，就放在用户的关键确认路径上。在 Locus 里，本地执行和文件系统信任边界必须是显式的，而不是靠一个友好的界面来暗示。
这是我从医疗 IT 留下来的可靠性教训：恢复服务之后继续往前走，直到下一次失败更不容易发生；当风险证据要求表达不同意见时，就表达不同意见，然后投入把被选中的路径做得可承受；只要一个重复的运营错误可以变成工具或护栏，就把护栏建出来。