青云挂了？这。。。

挂了！！

又是一铲子。。？

是哦，
502 Bad Gateway
nginx/1.1.19

可以放问了

所以说。。
中国搞idc
拼的是背景……

最近这些接二连三的故障 跟 宽带大提速有关系吗？各地都在加紧升级基础设施？

现在可以访问了。
不过刚刚是什么情况。

客服说是遭雷劈了

目前我的广东1区的机器还是挂的，官网能打开，控制台什么都出不来。问客服只说给雷劈了。
从监控报警到现在已经快要1个小时了，不知道还要多久

遭雷劈...

@zixincao
遭雷劈了。。这理由。
@master
刚刚我也没测试服务器，只是官网能打开而已。坐标武汉。
现在用本地服务器测试。

微博上收到私信说：「我们广东一区所在的IDC遭受雷击，导致突然断电。现电力已恢复，青云的物理设备正在重启中。任何消息我们会第一时间通知。」

@master
http://status.qingcloud.com/

2015-06-06T14:20:00Z+08:00 故障

同意宽带提速的解释，同时防火墙也升级了吧

@chrishine 雷电把电线劈了，这个概率还是挺大的。。。。

机房被雷击，UPS 又出故障，导致整体断电

@Had

他的状况监控只说了API和控制台，没说主机。

我这边DNSPod的监控是13：50分就收到故障通知了，百度的监控是14：00发的故障通知。

上述两个监控我用的都是免费版，本身监控的间隔时间就比较长了。

天谴

上次 linode 在旧金山的机房宕机也是雷击

应该有买雷击保险……

目测是好了

@master 不行，我们的官网依然是挂了，访问超时，广东1区

UPS形同虚设

@laoyuan 机房的UPS作用是保证断电以后服务器能正常关机，一般UPS配置是半小时或者一小时的。

@laoyuan
记得之前SAE也搞过一次因为市电切换时的供电问题导致大规模故障，然后各种服务抽了得有一整天。

@wy315700
但其实哪怕是闪断 UPS也依旧没能发挥作用
很多机房对UPS放的水可能并不仅仅是能维持时间方面的问题

我比较想知道青云如何应对这件事，事后补回宕机时间？

@neoblackcap

要是说网络断，机器还正常运转，其实都还好说。
这种机器也挂掉的情况 是不是大家机器上的数据库之类的业务 在非正常关闭 或者在内存缓存被迫清空的情况下面对暴风般的查询能活好 这真是问题了

真不知道青云要怎么回应这个问题了

事后补的那么点时间真没什么意义

@master UPS真的不是干这个的，要说停电以后继续工作，要么像FACEBOOK那样装发电机

@wy315700 UPS 不就是用来支撑断电到柴油发电机启动这段时间的供电么。这么大机房还能没有发电机么

@wy315700

你有看我回复吗？很多时候的断电根本就没有半小时、1小时 就只是闪断
问题是这样的情况 UPS都形同虚设 那你怎么指望UPS让你能坚持到把机器都关机 或者坚持到发电机能发出电呢

断电、UPS起来、柴油发电机就位或者切换到备用线路。
一般IDC都会有两路市电从两个不同的方向进来。
当然在天朝，很多“一般”都会“灵活处理”。

确实断了。北京联通。502

@master 不知道他的UPS是怎么配置的，
不过其实机房的机器最容易坏掉的时候是断电后来电的那一刻，大量的机器启动，电流波动非常厉害

请远离国内一切云。尽量使用IBM，azure，aws的服务。

@Yamade
aws 在锅内稳定么？IBM的没试过，azure 倒是想试试。

雷击？浪涌保护呢？

之前玩的一个ipad游戏，其后台就在AWS
有一天忽然登不上去了，最后解释说机房被洪水冲了。。。

@RangerWolf AWS每个地区都是可以配置多个可用区的，估计是那家厂商没做这方面的工作

@0bit AWS多个可用区是什么意思，负载均衡？

@millken http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html

抱歉，感谢大家的关注和支持，事故发生后我们一直在努力解决问题，恢复服务，检查系统上，没来得及跟大家沟通

坦白的说，这是青云目前遇到最大的一次事故，我们还是尽力在最短时间内恢复了所有服务(2小时31分钟)

虽然这次事故来的猝不及防，但我个人还是对我们工程师的技术水平更有信心了，至少我们在尽量短的时间内恢复了用户的服务

以上是个人的想法，下面是我们正式的事故说明

关于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

http://mp.weixin.qq.com/s?__biz=MjM5NDcyNzkwMw==&mid=205593940&idx=1&sn=0d44b30dfd60c6cff5f9d75d45e66f8c&key=c468684b929d2be2409931339a20dc1985353a0355d4d49fcca94b74fc639fed5d51a303060d59b9bbcb94eae3ee960b&ascene=0&uin=MjMyNzA5NjUwMA%3D%3D&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=0gWcbzyvsWbpRNiTfRQGU2Olz5fKfe5n3BnSrjdr69EhUjm%2B48Qzrfox4bI1A2wa

详细说明

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

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

@bingwenshi 机房有很大的责任，关键时候，这些防护保障措施都没有用上。这次还好，似乎没有数据丢失，如果再有这样的情况数据丢失了呢？
但是青云恢复速度快吗？不快，两个多小时系统才得以恢复，像MySQL等PaaS服务在系统恢复后依然存在一些问题，基本上过了三四个多小时才完全恢复。虽然青云工程师们在忙着处理解决问题，但这种停电事故还是暴露了青云系统中存在很多不完善的地方，一是启动速度过慢，二是很多地方并不能自动启动恢复，需要人工干预完成的。需要人工干预，那就又延长了恢复的时间。

@RangerWolf 是被洪水冲了还是洪水攻击 (flood attack)？

@bingwenshi
还是觉得你们被机房坑了

直击雷其实是最好防御的！
只要是合格的建筑物防雷工程 都能保证建筑物在顶部遭受直击雷的时候 把雷电通过避雷针等防护装置 引导到深插入地下的地线那里
（我记得帮我们做防雷工程的人是这样子说的）
你们可以要求那家机房运营商 提供从防雷工程施工方案 到防雷所验收 和每年防雷年审的资料
（不过 如果是收买了防雷所的话。。。）

@cyr1l 当时没注意这个细节~ 学习了 谢谢！

@littlehz @hezhile 我们也对IDC 给的解释表示质疑，我们工程师会进一步跟他们沟通

RDB 的恢复确实有点慢，这次是第一次重大事故，处理的时候比较谨慎，担心出现二次事故，以后我们会努力改进

TenxCloud时速云正式发布，致力于打造最好的容器云平台之一，现在可以免费试用！

又看到打码，哪个机房都不敢说？