雷击引发青云服务中断故障始末

2015 年 6 月 6 日下午，因服务商“睿江科技”机房遭遇雷暴天气引发电力故障，青云广东1 区全部硬件设备意外关机重启，造成青云官网及控制台短时无法访问、部署于GD1 的用户业务暂时不可用。 与此同时，另一家云服务商 LeanCloud 也发生了长达 4 小时的服务中断情况。

事后青云通过官方微博发布了事故报告，除了审视自身需要改进的地方，对IDC 防雷能力也提出了疑问。LeanCloud 通过官方微博和官方报告也对自身事故原因进行了说明。

笔者对云服务故障上一次的记忆还停留在《公有云故障案例分析——Microsoft Azure 的飞来人祸》和微软《 Azure 的官方博客的说明》。针对此次事故，一位 IDC 的从业老兵认为：

云计算出问题一般都是两方面，一个是数据中心稳定否，一个是云平台自身系统稳定否。 在选择第三方数据中心方面，一般云服务商会在全国选定几个区域，每个区域选两家以上的 IDC，中间用裸光打通。当然，这是比较理想的状态，其成本较高。

那么，能否用自建数据中心的方式来解决稳定性的问题呢？该老兵的回答是：

目前第三方云服务商还没有实力自建 IDC。例如一个 T3 级别 1200 个机柜的数据中心，投入超过 2 亿并且需要 1 年以上的建设周期，一个柜子的运营成本每年要至少 10 万元人民币。因此，国内第三方云服务商目前以租赁 IDC 的服务为主。而选择一个可靠的数据中心尤为重要。

据了解，IDC 建设有严格的国标规范，其对不可抗力的要求远大于普通基础设施。以地震为例，IDC 的要求是抗里氏 8 级地震。除了国标，运营商对机房建设还有电信研究院把关。第三方机房的建设更多地会参考国际标准。因此在如何选择 IDC 服务方面，首都在线工程部经理刘铮介绍说：

IDC 机房的基础设施从地理位置、建筑承重、电力保障、空调效能、消防、安防等各个方面都有要求。选择 IDC 需要考虑机房位置、资源、建筑、空间、动力系统、制冷、安保、运维等方面综合考量。 国内 IDC 机房是这几年才发展起来的，大致分为三种。

第一种，是运营商机房。这类机房会严格遵守 IDC 的建设标准。电信运营有近百年的历史，积累了大量的实践经验。

第二种，是运营商合作机房，这类是指运营商和社会资金合作，按照运营商的标准设计、选型构建的机房。除了所有权外，基本等同运营商机房。

第三种，是中立机房，这类机房良莠不齐。有很好的机房，例如世纪互联 M5 机房，是完全按照先进 IDC 机房规范进行设计的。也有很差的。

目前看来，在中国市场由于运营商对网络的垄断地位，个人觉得采购成熟的运营商机房是个不错的选择。 而自建机房会明显增加云厂商大量的基础设施建设成本，同时也会增加采购运营商带宽成本。

但现有国内的数据中心都是上一代数据中心，为服务器托管所设计的，空间密度低，能提供的单机柜功率低，配套空调系统效能低。就我所知大部分国内机房单机柜支撑 10～20A 机柜也就是 2200w 至 4400w，这对现在的云计算系统而言，密度太低了。单机柜密度低会造成密度降低，增加云计算大量的光纤耗材成本，再设计云计算资源池时就会不得不迁就机房现有条件，分散布放计算节点，增大了 tor 与 eor 之间距离；存储方面也造成了分散，影响了效率，使得云计算资源设计难以模块化。而非模块化设计、非标准化设计会增加运维难度，增加故障隐患。国外的机房大多单机柜可以提供 48A、64A 甚至于更高。

至于青云此次事故中提到的 UPS 问题，刘铮解释说：

UPS 系统非常重要，是现有数据中心最容易出现故障的一环。目前国内大多采用的都还是电池方案；国际上除了电池外还有飞轮方案等 UPS 代替方案。理论上要求 N+1 甚至 N+N 的容量冗余、定期的电力巡检及维护、UPS 定期代载供电、电池的维护保养及更换。 机房动力系统是最关键的，对 IDC 选址要求至少两路供电，要有完备的柴油发电机组，现有油量储备至少支撑数小时供电，并有不间断的柴油供给。

来自 InfoQ 高效运维群的讨论主要观点如下：

• 机房整体崩溃的容灾切换方案和演练有必要加强。通讯基站都会做防雷，一个 IDC 不能因雷击就影响用户，雷击只是一个诱因。
• 现阶段国内云服务商还是以开发为主，并没有对网络、IDC、运维看的特别重要。
• 网络与 IDC 已成为运维的重要话题。运营商机房限制很多，多线融合是第三方 IDC 的优势，但网络是其瓶颈。
• 由于 IDC 互联成本太高，可以根据需求做 DPN＋DRaaS 对部分或整个 DC 做实时异地容灾。但互联互通将成为趋势，也是市场发展的必然。
• 异地容灾的成本也不容小觑。目前看来，冷备有问题、双活有门槛，云服务商需要看自己的业务需要，看 SLA。中断服务影响最大，所以稳定和高可用是架构设计第一要素。
• 做运维就是把更多的不可控变成可控。没做到高可用、实时异地容灾，设计上的单点故障也就难以解决。
• 现在的云产品只能谈可用性，还谈不上易用性。

随即，我们采访了 UCloud 联合创始人兼 CTO 莫显峰，老莫从选择 IDC 租赁的标准方面给出的建议是：

选择 IDC 的标准非常多，包括物业使用权、租约、变电站、油罐、柴发、空调、承重、链路拓扑 / 带宽等等，但这也不足以确保 100% 的可靠性。美国标准 TIA-942《数据中心的通信基础设施标准》，主要根据数据中心基础设施的可用性、稳定性和安全性分为四个等级：T1，可用性为 99.67%；T2，可用性 99.749%；T3，可用性 99.982%；T4，可用性 99.995%。年平均故障时间也从 0.4 小时到 28.8 小时不等，这意味着每年都可能存在各种原因的不可用。

对于青云本次 IDC 故障的警示以及第三方云服务商应该怎么规避此类问题，莫显峰认为应该从一下几个方面加强防范：

1. 选择合适的机房。
2. 建立同城多中心：同城多 IDC 之间用光纤直连，将客户的业务部署在多个机房，避免在某个机房出故障的时候，影响用户的业务可用性。
   3. 协助客户做好规划：完全规避 IDC 的问题是不可能的，因此理论上的 7*24 小时的业务必须在软件架构、应用部署上进行优化，例如：
   a、针对外网线路故障采用多线路灾备，故障发生时实现自动切换；
   b、针对机房故障包括电力故障和空调故障等，采用跨 IDC 数据库灾备，接入层冗余的模式进行容灾；
   c、针对城域网故障采用异地有损容灾、IDC 双活或多活等方案。
   4. 定期巡检、演习：提前发现并消除隐患，大多数市电突然中断是无法避免的，但是 UPS 和柴发确保能工作很重要。

至于大家讨论的各云厂商之间互联互通的理想，UCloud 认为网络互联是可以先行的第一步。“只要各家的 VPC 支持光纤 / 专线互通，即可实现灾备的能力。目前 UCloud 是支持光纤接入公有云的。”莫显峰如是说。

综上所述，首先事故本身是一个非常小概率的事件，人力所能及的是尽量降低其发生的概率，而无法绝对避免。IDC 行业有着严格的建设标准，判断一个机房的可用性要在较长的时间范围内看其可用时间的长短。发生事故并不等同于机房不靠谱或者云不靠谱。当然，事故发生后要彻底排查发生的原因，采取整改措施。

因此，从设备和管理两个层面去降低事故概率是十分必要的，云服务厂商也要不断提升云平台的灾难恢复速度。最后，我们对青云联合创始人兼 CEO 黄允松（Richard）进行了简短的采访，他对此次事故的回复如下：

InfoQ：以前 IDC 遭遇雷暴天气引发故障的案例也很多，在你看来能造成大面积影响的主要原因是什么？或者说，青云在 IDC 布局方面是否因受限于供应商而存在一些隐患？

Richard：机房遭遇雷击后，承载 QingCloud 设备所在区的两组 UPS 输出均出现了 2 秒钟的瞬时波动，从而导致了机柜出现瞬时断电再加电。UPS 厂家给出的书面判断是，雷击楼体后，对 UPS 主机造成干扰，UPS 浪涌保护器未生效，引起 UPS 并机线通信故障，电压回流造成电压高报警，逆变器过载关机，短时短路。 目前青云在全国共运行着 8 个区域，其中公有云的 4 个区是青云自营租用的，我们在每个省份都是选择当地最好 IDC 供应商，比如这次出问题的机房隶属广东睿江科技，这家 IDC 运营商在华南是绝对的领先者。这次事故机房是当地电信的枢纽机房，T3 等级，即便如此，也遇见了此次雷击引发电力闪断的巨大灾难。我们非常清楚云平台的服务能力一方面体现在软件技术实力，另一方面也取决于物理层面的稳定和可靠。我们已经下定决心自行投资运营数据中心，以将物理层面事故概率降到最低。需要强调的一点是，无论是云计算还是传统 IT，都依赖于数据中心基础设施的稳定运行，而作为云服务商，我们的系统承载着众多用户的业务，因此要在数据中心的可靠性方面再下大力气。

InfoQ：从发现故障告警到完全恢复服务青云大概用了不到 3 个小时，用户的受影响程度以及反馈如何？IDC 方面有没有新的报告出来？

Richard：其实总时间是 2 小时 31 分钟，其中大约有 1 小时 40 分钟花在了物理硬件加电、全云系统的自检过程（检查所有设备、所有用户资源的状态、数据完整性检验等），用于恢复全部用户云资源的时间很短，因为此处皆自动化了。但是前面的硬件加电、检查、云系统自检这些过程还依赖于人、属于半手动的过程，这个需要进一步的开发，使之皆能自动化进行。 因为是全体断电，所以对用户的影响是大的，这也是数据中心行业能有的最严重的故障了，所有在广东一区部署的应用皆受到了影响。那些新型应用架构、吻合云模式的应用（我们称之为 Cloud Native App）随着云平台恢复而立刻恢复，那些偏传统的应用通常需要用户登录进去启动一些服务、或做些操作。总体上来说，因为没有出现数据丢失，用户的反馈大多比较冷静和理性。特别值得一提的是，有一些很技术专业的用户甚至将这次事故视作一个机会来检视自己应用架构的合理与改良，真的很酷。极客邦转发的一篇就是例子。

IDC 在 6 月 6 日提供了官方报告，我们已经发出来了，后来也提供了一份纯技术分析文章，其实是对前份报告的电力细节描述，我们也已经通过邮件和社交平台发给了用户。

InfoQ：经过本次事故，青云会在哪些方面进行改进，能简单说说你们的改进措施吗？

Richard：首先我们真的非常抱歉，数据中心出了这种非常小概率的大故障，让那么多用户受到严重影响。我们已经决定要自己运营数据中心（第一个力争年内在北京启用），欢迎有意投资云计算产业的企业机构与我们洽谈。另外，我们的自营网络建设一期工程已进入尾声，会在 Q3 之前完成北京各区之间的光纤直连，实现同城环网，这将极大程度提高云平台的容灾能力；随后会逐步实现其他各区环网。 另外从平台技术角度，我们计划加入全面的硬件自动化，这将使得我们 100% 杜绝人力工作慢的问题，使得灾难恢复工作更加快速；还有对于平台自检过程需要优化，我们将在北京的机房设置 evil monkey 测试场景，将全机房断电列为日常测试项目，确保此类灾难能在 30 分钟完成全部恢复。