唉，互联网就是抵不过传统行业的一铲子啊……

物理层的东西出问题了,才知道它的存在

哈哈哈哈，青云蹲了

额，怎么这么喜感来着

这个属于正常现象，我司还有机房着火的情况呢。


这种都是有概率可以算的，良好的架构可以不受影响。

雷击…这概率…

互联网其实很脆弱。

@luo362722353 机房雷击概率还挺大的，不过断电是非常不应该的。

机房一般接入的是10kv的双路市电。两路都挂了，还有UPS抗到柴油发电机启动。

当然分级不同，可能青云用的低等级的机房

@9hills

其实我怀疑是他们的处理方式。
停电以后启动UPS他们就开始给机器关机了，或者设置的关机指令就自动发出去了。

青云之前网络也挂过吧

互联网很脆弱，美国一句话，伊拉克的.iq就消失了╮(╯▽╰)╭

广东每年都有人遭雷击身亡，所以广东机房被雷击并不算低概率事件

我项目直接停了……

吃我洛阳铲

我反正一直不敢用青云广州机房，莫名恐惧。

然后有一次领导要部署上青云广州机房，我说考虑南方用户的话其实更推荐香港机房。领导因为一些政治见解不答应。

(这时候该怎么办呢，笑笑就过去了对吧。

@phoenixlzx 你老板又不傻，HK一闹运动就是大陆全境掐断HK网络访问。几率不比雷击小

@baskice 这个我倒是没见过。不过领导的意思是他不喜欢那边人，而不是担心闹运动会被掐网线。

机房应该都有UPS，柴油发电机，我在移动的机房看到的这都是标配啊，断电了也至少能支持24小时以上。想不明白啊

@wy315700
实际上并没有下关机指令 至少从我这边看到 虚拟机是非正常中断 这个真有密集写业务的情况是很致命的 不知道宿主机是什么情况

坐标广州 想跟大家说一下IT设备遭受“雷击”的体验

最近一个星期 广州（包括附近地区）基本每天都下雨 而且经常是雷雨
我们公司 有一堆物流设备是由西门子的PLC控制的 试过两次所有PLC都断电
两个计算机机房没事 可能是因为有做防雷工程吧

估计青云也是被机房/IDC坑了
如果有做防雷工程 应该有防雷所的验收报告和年检报告

上周六在车库咖啡有个沙龙，青云的主讲人还在幸灾乐祸阿里的那一铲子，没想到这么快就落到自己头上了。

@gaoqr2001 所以说不能乱立flag……

@gaoqr2001 那啥，装X遭雷劈，果然如此

怎么跟中奖概率似的

@hezhile 通讯机房、数据中心机房的防雷设计都应该是机房的可靠性设计中的重要一环。

机房都应该环路供电，甚至三路供电，由三个不同发电厂的出线接入。就算整体断电，还有ups，不过ups的作用是给你充分的关机时间，而不是让设备顶到机房供电恢复，如果用ups顶着，那么机房的空调系统谁来供电？空调系统中断，机房的温度就和烤箱没啥区别了，这温度还想着服务器正常工作？后续的黑启动等预案才是重要的。

雷击不可怕。但是雷击就导致电力中断，这个不知道机房怎么说，防雷、UPS都没用上？

断电也并不可怕，但是断电之后的恢复过程，太长，青云系统启动就花了一个多小时。主机启动后，像青云提供的负载均衡器、MySQL服务还都有些问题，需要发工单人工解决。到业务完全正常使用花了太长时间。

另外青云基础网络里10.开头的内网IP，重启后就全变了，不知道有没有云上的朋友赶回来改代码里的配置的。

@littlehz

比较讨厌的就是这种非正常中断导致各种业务 不管是青云的业务还是我们运行在上面的业务都可能存在写入错误 自检 重启等等过程 哪怕个万一就有可能挂掉 也不知道为什么UPS在备电切换的时候一点作用都没有

内网IP这个的话 如果是托管网络 记得青云说过内网IP会变 需要使用DNS 不然有自行建立虚拟网络
记得Azure也存在类似的情况

@master

是啊，断电这种事情，非正常中断，很容易导致数据异常。所以我对重要的业务数据只敢使用MySQL等传统SQL数据库存储，一些很核心的逻辑甚至还要开启事务等方式操作，毕竟这种数据库系统还算成熟，binlog日志也很完善。对于不重要的数据才使用NoSQL存储。

我主要想说的是，青云这次断电之后，恢复所花的时间太长太长，无论这套系统多么复杂、庞大，启动就需要一两个小时时间，怎么都不能接受的。启动完了，又发现青云提供的部分PaaS服务，并不能完全正常使用，依然需要工单联系解决。

内网IP变化这倒不是多大的事，既然提醒过，也是按照建立路由器私有网络来的，但是如果基础云能够保持足够的稳定当然更好。

这次断电暴露出来青云的很多问题，希望青云能够在这个事故中充分检查问题、修复，并在公开场合告知所有用户。要不然外人看来，青云断电一下，恢复就花两三个小时，会觉得这套系统很脆弱，把之前宣传的技术佳、超好用、秒级计费这样的优势一下给雷劈没了。

@littlehz

并不是每个云计算都会或者都有能力自建数据中心
包括Azure在国内交给世纪互联 AWS没记错是用了光环新网还有网宿

这种时候很多问题就受制于所用的数据中心到底放了多少水，数据中心自身的问题很多时候就会放大云计算本身的缺陷，比如青云这种因为意外重启一下业务要这么久

其实一开始因为业务主要面向广东一带用户打算用青云广东一的时候最担心的就是这个睿江科技是不是真的可靠。但真的以前没怎么接触过广东一带的BGP，所以也就只能将信将疑得用着了

@billwang UPS是顶到柴油发电机启动。一般也就几十分钟，再多顶不住了

@9hills 呃，我们的机房还真没有配备发电机，直接拉了三路电厂的电。不知道得多大功率的柴油发电机才能供得了那么大的机房电力。

@9hills
@billwang
有了发电机的话还要为发电机做安全防护，

初中的时候，我们学校就是有自己的发电机的，每次停电了就用。
结果某一天，彭的一下，爆炸了，浓烟滚滚。
当时我刚好在距离发电机10米左右的地方打乒乓球，吓坏了。。

@billwang
@wy315700
我参观过机房。。大概有四个集装箱那么大，两台冗余

机房按照国际标准分为Tier 1-4四级，都要求有发电机的，你们的机房或许是因为接入了三路市电，可靠性足够不需要了。发电机平时就是放在那里定时开机检查，纯浪费。

修正下，一个发电机差不多一个集装箱。放到外面看起来还是蛮震撼的

@master

公告已经出来了，http://weibo.com/p/1001603851162049741565

看这个公告的内容，睿江科技还是在敷衍，遇到雷击，谈理论上如何，小概率，很难防，出现电力波动，视物理设备电源情况是否重启。并没有承诺机房接下来如何检查问题，如何避免，要改善哪些设备，要怎么调整电力系统配置。

青云还可以，会进一步检查问题，这次事故之后，下次遇到这种极端情况如何优化，如何更快的恢复。但如果机房运营商没有更好的服务意识的话，恐怕以后还会遇到这种极端情况。

@9hills 恩，反正有异地容灾呢，重要系统有应用级别冷备，不过恢复起来肯定没有阿里那样迅速。

说到发电机，我就想起2012年AWS美东1区的那次大规模故障。印象太深刻了，当时坑了一大堆著名网站。
然后亚马逊的报告是这样说的
The generators and electrical equipment in this datacenter are less than two years old, maintained by manufacturer representatives to manufacturer standards, and tested weekly.
虽然那堆发电机一直表现得无比正常 还是出事了。。。

参考来源 google "2012 aws outage generator"

感觉还是阿里那种异地双活比较强壮（没有吹牛的话）

@9hills 机房标准里是不要求一定有发电机的...
发电机的防火隐患是一，需要放置于多空旷的地方都是有消防和环评要求的。二是实际的输出质量也很参差不齐，工地用的柴油发电机和专业市电应急供电发电机的输出和价格都天壤地别。
比如银行，对可靠性的要求比互联网公司还要高，但除了总行的数据中心可能配置发电机，下面的省市一级的分行，基本上是配置3个小时ups，然后断电后就叫发电车...

我好奇，以阿里的体量，如果不是异地双活的话，能差多少成本。

@hezhile 上次不是证明了异地双活是吹牛B的么。核心的东西还是没办法异地双活

关于2015年6月6日青云QingCloud广东1区（GD1）机房电力故障的进一步说明


尊敬的用户：

因广东1区（GD1）所在IDC遭遇雷暴天气引发电力故障，昨天下午QingCloud广东1区全部硬件设备意外关机重启，造成QingCloud官网及控制台短时无法访问、部署于GD1的用户业务暂时不可用，对此我们深表歉意。现将事故完整过程报告给您：

13:48，我们收到GD1硬件及网络告警，并发现官网及控制台无法访问；工程师马上进行系统状态检查，发现GD1所有硬件设备出现重启；随即我们与GD1所在的IDC运营商沟通询问机房情况，同时排查其他可能导致设备重启的原因，并着手恢复管理服务（KS）；其间，我们收到大量用户反映GD1业务中断；

14:08，操作切换DNS以恢复官网及控制台；

14:23，我们从IDC运营商处获知由于机房所在地区出现雷暴天气，机房因雷击引起UPS异常，机柜瞬时断电再加电，从而导致了青云的全部物理设备异常关机与重启；

14:38，GD1的管理服务恢复，Bots系统恢复，开始恢复用户主机；用户可以访问GD1资源；DNS完全生效，官网及控制台访问恢复；

15:15，内网DNS Server恢复；系统持续检查环境和帮助用户恢复业务；

16:19，GD1业务完全恢复，进一步检查后，于16:30分发布恢复公告。

本次严重故障从设备重启到用户业务恢复共耗时2小时31分钟，系统数据和用户的业务数据未出现任何丢失。

业务恢复后，我们同IDC运营商“睿江科技”就事故原因和技术细节进行了持续沟通，并责成睿江科技出具真实、严谨的故障报告，力求全面了解机房电力系统和防雷系统发生故障的真实原因，以便在未来规避类似事件的再次发生。

截止目前，我们已经获取睿江科技提供的《关于20150606XX机房故障说明-青云》报告一份（附后），其中就雷击引起的电力故障进行了初步说明。通过报告，我们可以了解到的信息如下：

1. 电力系统：直击雷导致电力系统出现瞬时浪涌，UPS启动自我保护（报告中提到的“UPS瞬时波动”），从而释放电流导致瞬间断电。
2. 防雷系统：机房配备了强电、弱电、UPS及列头柜四级防雷，雷击主要是直击雷和感应雷两种，本次发生的是直击雷，现有防雷设施很难防护，从而导致雷电直接影响到电力系统，导致UPS断电保护。

但我们对其中的细节披露和专业解释仍存在以下疑问：

1. 目前建筑防雷系统已经非常成熟了，都是可以防感应雷、直击雷和侧击雷的。专业的IT基础设施中的四级防雷系统更应该是如此，本次事故中机房的防雷系统为何未能成功防护直击雷？
2. 专业的IT设施防雷系统同民用防雷系统相比防护标准更加严格，本次事故的发生究竟是因为防雷系统失效还是因为防雷标准达不到专业IT设施标准？
3. 防雷系统中包含浪涌保护器，在正常情况下，防雷系统和浪涌保护器会释放掉因雷击产生的瞬时脉冲，从而保证UPS不会产生瞬断。那么昨天的事故中是否存在浪涌保护器失效，未能释放掉因雷击产生的瞬时脉冲，进而导致UPS的断电保护？

就上述疑问，我们正在同睿江科技进行持续沟通以获得真实可信的故障原因分析，也会向您完整、透明地披露相关信息。后续我们也会给出相应的赔偿方案，青云QingCloud团队再次对此事故对您造成的影响深表歉意，也感谢大家对我们的理解与支持。

针对本次恶劣天气导致的事故，我们通过重新审视了故障发生和排除的全过程，认为我们的技术能力和服务能力还有以下些可以进一步改进的地方：

1. 故障信息和故障排除进展的通告要更加及时。在昨天的事故中，我们首先将精力更多地投入到故障定位和排除上，在14:20才给出第一个故障通告，导致很多用户因缺乏信息产生焦虑。我们充分认识到及时、透明的信息通告的重要性，因此向您检讨在本次故障通告方面做的不够及时。为此我们制定了未来紧急情况下保障信息通知更加及时、准确的方案。我们会在第一时间通过网站、控制台及“青云QingCloud服务健康状态监控”网站（http://status.qingcloud.com）发布和更新系统异常及故障排除进展的通告，也会更及时地通过短信和邮件等形式向受影响的用户推送相关信息，以保证您能更及时和准确地了解服务状态。我们非常理解在出现故障时用户面临着巨大的业务端压力，因此由衷地感谢您在了解故障信息后对我们给予的理解和支持；
2. 在任何故障情况下，保障官网及控制台正常访问。目前我们的官网及控制台是通过DNS切换的方式确保在所在区出现网络不可达或系统故障的情况下尽快恢复访问。未来我们会制定更快速有效的办法进一步确保官网及控制台的正常访问；
3. 在出现全部设备重启等极端故障情况下，更快地恢复管理服务和业务系统。本次在设备重启后，我们是通过Bots系统和人工操作结合的方式恢复了GD1的管理服务和用户业务，未来我们会编写更加智能的软件脚本，保障在极端情况下，业务系统能够更快速地恢复，将可能造成的损失降到更低；
4. 提高IDC服务保障水平。我们会同目前公有云四个区所在机房分别就电力、暖通、网络等各个专业系统的基础设施水平、运营管理流程规范等方面进行更加严格和全面的检查，并同IDC运营商一同定期进行灾难演练，最大程度避免基础设施故障的发生；同时进一步加强同IDC运营商之间的信息沟通效率，确保第一时间了解任何异常情况；
5. 容灾保护能力提升。将实现关键业务的容灾能力作为长期努力的目标，通过连接各个区的环网的建设和运营等手段实现更好的容灾能力。

综上，我们会全面review故障处理流程，以应对机房断电等最极端的事故为标准进一步提升QingCloud系统的可用性，让信息传递更加及时和透明，通过自动化手段提高切换和业务恢复速度，让曾经发生的故障成为我们不断进步的和提高服务能力的源泉。

再次，向您表示深深的歉意，也希望在您的支持和帮助下，不断提升我们的服务水平。

青云QingCloud