最近两天，青云经历了上线以来最艰难的一次考验。北京2区（PEK2）的两台汇聚层交换机的堆叠出现了 ARP TABLE 混乱，引致了局部内联机器丢包，大量PEK2用户在7月22日和23日经历了两次长时间网络中断。我们通过彻底更换新交换机修复了该故障，恢复了服务。在此，我们向所有受到事故影响的用户表达最真诚最深刻的歉意。

我们向您完整、如实地还原本次故障的全程如下：

7月22日

• 12:47，我们收到大量北京2区（PEK2）内网网络告警，具体表现为PEK2网络内部大量物理服务器无法正常连通，出现丢包，导致大量PEK2用户网络中断。 经初步判定，问题锁定在内网汇聚层交换机，我们随即安排工程师至IDC现场处理。
• 工程师抵达后，对全部环境及交换机进行检查，发现物理服务器及交换机的状态及配置并无异常，但表现的状态为内部网络随机不可达。根据故障状态，工程师进一步判定此问题为汇聚层交换机ARP TABLE混乱所致。
• PEK2部署有两台H3C S5820V2交换机为 IRF2 堆叠使用。经过对两台交换机进行重启操作，至2015年7月22日15时15分，故障排除，内网恢复正常，用户业务逐渐恢复。
• 故障排除后，我们的工程师团队一方面帮助用户解决因网络中断导致的技术问题，一方面同网络设备厂商H3C保持沟通以确定设备故障的根本原因。同时，为彻底避免故障复现，我们决定更换该设备，并连夜联系了Cisco安排新设备23日入场，并计划于24日凌晨进行设备替换。

7月23日

• 13:15，PEK 2再次出现网络故障。我们即刻进行问题定位，初步认定是22日的故障再现。通过重启设备，网络于13:30恢复。
• 13:50，交换机混乱再次导致PEK2内网故障，我们随即重启设备并取消堆叠，但是网络在短暂恢复后再次故障。
• 14:30，在多次尝试仍无法保证网络稳定后，我们决定暂停PEK2的服务并决定尽快更换设备。
• 15:57，在新设备部署的同时，我们定位到这个故障是由H3C两台堆叠设备中的一台引起的。我们将其下线，并临时由另一台设备承载业务，服务恢复。
• 18:50，两台Cisco汇聚层交换机完成部署，新旧设备切换。在提前告知用户的情况下，网络因设备切换中断1分钟，随后PEK2网络恢复正常，本次硬件设备故障彻底排除。用户资源和数据未丢失。

本次网络中断完全因罕见的硬件故障导致，设备供应商H3C公司的工程师确认问题原因为一台S5820V2出现MMU硬件故障，导致Buffer调度出现紊乱，出口cell出现拥塞，导致报文无法转发。重启后能够暂时恢复转发，但运行一段时间后，故障会重新出现。同时，在一台设备故障后，S5820V2的IRF2分裂检测机制未触发，设备堆叠的冗余能力失效。H3C公司已提供正式报告（附后）。为避免相同问题出现，我们已决定陆续更换QingCloud系统中使用的全部该款设备，并马上对系统中所有硬件设备进行健康性排查。

我们深知，作为基础云服务商，我们的系统承载着保障用户业务连续的重大责任，也寄托着所有用户的信任。因此除了自身软件系统的稳定性与可靠性保障外，确保

数据中心基础设施、硬件设备和传输网络的可靠性和稳定性也是我们义不容辞的责任。正式上线的2年来，青云经历过各种不可预期的外部故障和事故的考验，在重重困难中，我们努力成长，汲取了教训，积累了经验，也收获了那么多用户的认可与信任。磨难让我们加倍努力也更加坚强。在未来，我们会采取包括加大资金投入在内的所有措施，不遗余力地加强各个方面的保障能力，全力守护用户业务的稳定。

对所有受到本次网络故障影响的用户，我们决定返还您一个月在PEK2的全部消费金额作为赔偿。 虽然赔偿并不能挽回对您的业务造成的影响，但我们希望通过这种方式体现我们最真诚的歉意，也希望您能够一如既往地信任我们。有您的理解与支持，青云必不辱使命。

就6月6日广东1区（GD1）因雷暴引发的电力故障技术细节，我们同IDC运营商睿江科技进行了进一步沟通，并获得对方关于事故的补充说明。

根据补充说明，本次事故是由于“雷电击中楼体引发强地网电位，浪涌保护器未生效、UPS 受强干扰故障，多个因素叠加而成。 ”针对本次事故，睿江科技将采取以下整改措施：

1. 整个机房重新进行防雷的技术评估，推进所需的防雷改造，防雷器的检查和增补。
2. 重做 UPS 设备内部防雷器的检查与防雷评估。
3. 抓紧和推进 UPS 故障应急维护机制，应急响应制度和措施的制定与执行，培训维护人员的应急处理规范和行为。 管理是主要的安全保障之一。

QingCloud会积极参与和监督机房的整改工作，全力提升基础设施服务水平。保障用户业务是我们高于一切的目标，我们会尽最大可能从故障中吸取教训，提供更好的服务。

青云QingCloud

附：睿江科技补充说明