去年在公司推了一个双机房的项目。当时我们只有一个机房，那时我们做了一个假想，如果这个机房出问题会怎么办？比如机房光纤被挖断、机房失火、出现灾害（地震以及天津化工厂爆炸类似灾难）以及人为原因导致机房故障等等。
按照我们当时的情况，只有一个机房，一旦出现上述事件，那么对于我们来说就是灾难性的。所有的应用都无法提供响应，所有的数据都可能丢失。
尽管概率很小，但是一旦发生，后果就是不可想象的。所以我们着手开始做双机房的项目，为的就是某一天，如果一旦出现上述问题，我们不至于真的挂掉。其实做这个项目的时候，只是觉得机房有挂掉的可能性，但是这种概率却是极低的，内心并没有觉得这个事情真的会发生在我们身上，还存在着一丝侥幸的心理。
上周的某一天晚上，没有任何预兆，我们云上的机房突然之间大面积宕机，上百台机器同时宕机，包括应用服务器与数据库，真的就是机房挂掉了，这种比买彩票中奖概率还低的事情，真的让我们碰上了！！
当时已经接近凌晨，正准备要睡觉，突然之间手机收到了大批量的告警。仔细看了一下，都是机器宕机的告警，数量比较多。预感到这个事情会比较严重，第一时间联系了我们运维的负责人。运维同学响应也很及时，三分钟内给出答复，说是机房大面积宕机，目前正在联系厂商进行紧急处理。
目前我们主要的业务都跑在这个云机房上，两地三中心的项目正在进行中，当前处于一个过渡状态，云机房大面积宕机对我们业务产生了致命的影响，整个APP流程完全无法走通，连登陆都无法登陆。
上图是我们最终两地三中心的理想状态，在上海有两个机房同时支持业务，即使其中一个机房出现大面积故障，那么还有另外一个机房可以继续响应，不影响C端用户的使用。
但是现在阶段，我们只实现了一半，刚刚把上海的生产中心建设完成，另外一个同城生产中心还没建设完成。
这时候我们有两个选择，一个是切回我们的灾备机房，另外一个是等待云厂商恢复。
切回异地灾备中心的这个预案我们之前也做过，但考虑到这是一种极端的情况，出现的概率极低，所以我们只做了手工切换的方案。因为我们的数据库的主库已经都切到云机房，这时候要切回原来的备份机房，需要先手工把备份机房的所有数据库先改成master，然后上层所有业务的数据库配置都要修改回备份机房的配置，再上层的负载均衡要把所有流量切到备份机房，修改的点比较多，我们之前做了一个一键批量修改的工具，但是从没有在线上用过，风险比较大，不到万不得已不会选这个方式。
所以当时的选择是看看云厂商什么时间能恢复，如果云厂商真的在短时间内无法恢复，那么我们还是要切回原来的备份机房，这将是一条坎坷未知的路。幸好等了大概不到10分钟，云厂商告诉我们原因已经找到，并且所有机器已经陆续开始恢复，这在当时真是一个好消息，我们重点精力放在如何恢复云机房上。
随着云厂商陆续将机器恢复，我们需要做的是快速将机器上部署的业务服务尽快恢复，以及数据库、各种中间件恢复正常。大概1个小时左右，经过一系列的抢救，大部分的业务都已经恢复，大部分数据库也已经重新启动起来。APP已经可以重新打开，主流程已经基本恢复，整个下单主流程已经恢复。
但是由于挂掉的机器实在比较多，微服务调用关系也比较复杂，还是有一小部分机器由于各种异常原因没有完全恢复导致整个链路上还是有些不稳定。
主要体现在以下几个方面：
1.挂掉的服务比较多，正常情况下，机器重新启动后，上面部署的服务可以自启动，由于数量比较多，短时间内要确认是否都已经正常启动，以及是否可以正常对外提供服务响应。没有有效的手段可以快速验证，导致有个别漏网之鱼影响整个流程的稳定性。
2.redis集群挂掉后，一部分数据丢失，使得有些服务启动后无法从缓存加载数据导致某些业务流程异常。本质原因是这些模块要么是没有做服务的降级，从缓存取不到，降级到DB获取数据。要么是使用缓存场景不对，无法降级到DB，导致缓存数据丢失后，短时间内没办法从DB快速恢复缓存的数据。
3.微服务模式下，服务之间的调用关系比较复杂，服务的提供方会有多台机器提供服务，一个请求来了后具体由哪个后端服务的哪台机器来提供响应，这里就必须要有相应的路由策略。这次宕机后，很多服务的提供方不可用，路由机制会将此节点自动摘除，待到服务方恢复后，再将其加入到路由策略中，可以继续对外提供服务。这次宕机后，暴露了这个路由恢复检测机制的一些问题，导致之前被摘掉的机器，即使服务恢复后也没能及时的加回路由表中可以对外提供服务，引起了部分流程的异常。
4.由于异常宕机，数据库也受到一定影响。一个是大批量数据库突然宕机后，尤其是主库，很多写操作的请求可能处理异常，可能会造成数据丢失以及事务的不一致性产生脏数据。另外主库突然宕机，备库的binlog受损，导致备库也无法正常同步主库数据，对后续的数据采集等业务也造成比较大的影响。
回顾总结下这次事故，由于事发比较突然，并且是在凌晨，对研发同学的应急响应组织能力是个严峻的考验，幸好很多同学敏感度比较高，即使在深夜收到告警后也都起来及时进行处理，整个过程从0点开始，基本在凌晨1点恢复主流程，在凌晨3点将所有分支流程全部恢复，并且验证完毕。整个事故的恢复时间还是有提升的空间，处理过程中有很多方面可以吸取教训进行总结，也暴露了整体系统还是有很多不完善的地方，服务自启动机制、服务健康度快速诊断工具、监控告警机制、微服务的治理等等。
最后总结一句话：对系统要永远保持敬畏之心，服务保障永远在路上。
