北京时间10月22日早上6点52分，GitHub.com出现大面积网站宕机。

从问题出现开始到解决的这24小时里，GitHub团队显然处于崩溃状态。

北京时间下午2点51分开始，状态消息不断在更新：再给我2小时！再给我1.5小时！再给我半小时！......

然而，“小时复小时，小时何其多”，承诺了太多，做到的太少，无奈，官方发布致歉函，表示真挚的歉意。

读完这段新闻，作为报道科技圈十余年的赛迪网记者来说，还是想和大家聊聊“多活”，那么什么是多活呢？青云QingCloud运营副总裁林源的解读很专业、明了：就是增强系统可靠性、提升业务连续性以及使业务运行不受故障/灾难影响。

但是，真正实现多活，并不简单。因为只要是设备、硬件，就有出故障的概率，“多活要做的就是必须规避任何的单点，包括一个数据中心内部的单点甚至是整个数据中心宕机的单点。而我们探讨的多活是业务上的多活，它会依赖部署在多个数据中心。”林源这样解读。

多活里有两个公认的技术指标：业务恢复时间（RTO）和数据的丢失量（RPO），这二者在不同的企业中的重要性是不同的，对于互联网企业来说，其更关注业务恢复时间；对于银行、保险等跟民生相关的企业，则不允许数据丢失。

不过理想的场景是，二者（RTO/RPO）都趋于零。

对于选择多活业务的企业，林源的建议是两类企业，其一是业务故障后会影响公司整体的业务，导致客户资金受损；其二是业务面向的客户数目比较广泛，影响较大。

具体来说，包括两大类别。第一种是大规模线上运营业务，比如电商网站、微信、微博等，业务的中断是不能容忍的，因为每天都有大量的客户在使用这个服务。第二种是银行、保险、重型制造等场景，银行IT架构需要符合银监会的规定，需要有两地三中心。

以上多活的好处已经毋庸置疑了，但是巨大的投入也让很多企业对于多活的选择望而却步，总结来说有硬件成本高、人力成本高以及前期部署投入成本高。

那么怎么解决呢？其实很简单，用青云的多活。

林源在三个层面做了解读：基础设施、基础架构以及分布式应用。通过这三个层面，可以让客户以更低的成本、更低的门槛部署他自己的多活业务。

在基础设施层面，“两地三中心”至少需城市、机房、光纤、网络。青云目前有三个大区提供多活服务：北京3区、广东2区、上海1区。

林源特别提到了多机房之间的互联问题，互联的带宽和延迟都有保障。每个数据中心之间是波分互联，大概是几百Gbps的通道，这就保证了多个数据中心之间的低延时性。

以一个银行业务为例，它在北京有两个数据中心做多活。当取款和转账时，这笔交易要同时写在北京的两个数据中心里。如果这两个机房之间的延迟很低，很快返回。从用户的体验来说，你转一笔账很快就成功了。如果两个机房之间的延迟很长，对用户体验来说可能是转账半分钟还没返回。

在采访中对于记者提出的多活与灾备的区别，林源强调了“真正”多活的概念，最简单的模式是双活，就是两个数据中心同时提供服务。任意一个数据中心宕掉不会影响另一个数据中心，所以它的RPO和RTO都有保障。这不是传统意义上的“灾备”概念。

而且这个多活的基础架构包含了友商经常不具备的私有网络和VIP多活的能力。

林源最后表示，青云的多活不光在公有云上使用，包括混合云、私有云，青云都有全面的交付能力。