“服务器正在排查。”
这句话可能完全属实，却未必能缓解客户的着急。他还不知道今天的工作怎么办、哪些资料还能取到，以及下一次什么时候能得到消息。
技术故障发生时，经营者和客户往往在看同一件事的两面。一边想着哪里报错、怎样修复，另一边想着订单会不会漏、交付会不会晚。只修程序，没有解释业务影响，客户仍然处在失联感里。
举个设想：预约软件的登录服务出了问题，门店进不了后台，但预约数据没有损坏。对当天需要接待客户的店员而言，先拿到可信的预约安排，可能比立刻恢复统计图表更重要。
这就是业务连续性关心的事：部分系统不可用时，已有承诺还能怎样得到支持。它不要求任何时候所有功能都毫无异常，但需要区分什么必须先恢复，什么可以稍后处理。
Google 的事故响应经验把协调、沟通和实际操作分为不同职责，并强调先缓解影响。小团队未必需要照搬角色设置，但这几件事不能因为只有一个人就自然消失。资料：Google 事故响应指南
沟通也并不等于在原因未明时猜一个答案。清楚说明已确认的影响、正在做什么、何时再更新，往往比承诺一个没有依据的恢复时间更有用。事故记录还可以避免几个人反复尝试同一项操作，或让接手的人从头猜起。
恢复的边界同样重要。为了让页面能用就临时取消身份验证，可能把访问故障变成数据泄露；首页终于打开，也不代表积压订单、漏发消息和异常付款都已经处理完。
所以，系统恢复只是其中一个时刻，交易和工作重新对得上，还需要后续核对。那些事故中暴露的缺口，也只有变成实际改动并经过验证，才会改变下一次的处境。
对客户来说，一次可靠的故障处理，未必让他听懂了技术原因，却会让他知道：事情出了问题，但自己的那份工作仍然有人接着管。