当故障真实发生后，带来的影响不仅仅是技术层面的，更多的是业务层面的，比如用户和商家的批量投诉，交易量下跌，广告资损等等。而这些影响又会产生巨大的外部压力，并传递到技术团队，这时如果没有很好的故障应对机制，技术团队就很容易陷入慌乱，不知所措。需要做以下两方面准备：
1、业务恢复预案
第一原则：优先恢复业务，而不是定位问题。这就需要我们事先有充足的预案准备以及故障模拟演练，通过稳定性平台的建设，与能够预见到的，以及经历过的故障场景相结合，当发生故障时能够第一时间执行对应的恢复预案。
同时，预案的执行不能仅仅在故障发生时才执行，而是应该把故障模拟和恢复演练放在平时。也就是如果我们在日常系统稳定的状态下都不敢执行预案，或者执行了没效果，那真到了故障发生后，在更为复杂的状况下，预案 100% 也是不敢做的，因为这种异常状态下，还要考虑执行了预案是否会导致次生故障。
关于故障模拟，可以分为不同层面来梳理，比如：
- IDC 层面，如电力切换、UPS 切换、核心网络设备切换，单设备故障等，这些故障是可以通过人为破坏进行模拟的，模拟手段相对简单，但是破坏力和影响面会很大，所以做之前一定要准备充分。我们会定期 1~2 个月做一次类似的模拟演练，涉及机房配合的，也会提前跟运营商约定好时间；
- 系统层面，如 CPU、磁盘 IO、网络 IO、网络时延、丢包等异常场景，这些都有开源或 Linux 系统自带的工具支持，比如 Stress 工具模拟 CPU 升高，dd 模拟磁盘 IO，tc 模拟网络问题；
- 应用层面，最典型的就是 RT 升高，抛出异常，返回错误码等等，这里还是会用 Spring 的注解功能，在运行时模拟异常状况，然后有针对性地看各种限流降级和开关预案策略能否生效。
2、有效的组织协调
故障发生后的排障和恢复操作，往往需要多个技术团队协作完成，这时就需要有一定的应急机制，来确保相关人员能够快速响应和高效协作。同时，因为对业务造成的影响导致业务团队会承受很多外部压力，这时也需要有统一的口径对外反馈，比如大致原因（对外不用详细），影响面以及预估恢复时长等等，从而确保信息的透明，避免各种不着边际的猜测对公司信誉造成的影响。
出现一个严重故障后，技术支持通常要做如下几个关键事项。
- 确定故障影响面及等级。故障会通过监控、告警、业务反馈或用户商家投诉几个渠道反馈过来，这时技术支持会根据故障定级标准，快速做出初步判断，确认影响面，以及故障等级。
- 组织应急小组。对于无法马上恢复或仍需要定位排查的故障，会直接将相关技术团队的主管和骨干开发人员召集到一起，通常是专用的会议室，并确认故障处理主要指挥者，通常是受影响业务的技术负责人。
- 信息通报。完成上述第一步后，通常会给相关技术和业务团队通报故障初步信息，包括登记、影响面、故障简述以及主要处理团队和责任人。完成第二步，组织起应急小组之后，每隔一定时间，如 15~30 分钟要对进展做一次信息同步。同时，如果等级和故障信息有变，也要同步出来，直至故障排除，业务恢复。为了保证沟通的顺畅，技术支持并不与处理故障的人员直接沟通，而是通过指挥者沟通，这样确保高效沟通，同时也确保处理故障的人员能够相对地专注在故障处理上，而不是响应来自各方的询问，甚至是质问。
整体总结下来，故障应急过程就是：功夫要下在平时，注意建设各种工具和平台，同时要尽可能地考虑和模拟各种故障场景。这就像一支军队在平时一定要做各种军事演习一样，然后就是临场发挥。当故障真正出现时，要有完善的应急机制，马上能够有效运转起来，而不是慌乱无措。