确实挺有钱

这种蠢事我年少也干过，然而并没有卵用

有这功夫，还不如研究下穿衣打扮，运动健身，或许以后还有机会

DigitalOcean or Linode

QingCloud， UCloud

iOS 风格就不能用了么？

钱和希望

知乎不是 Python 么？

买买买

我这里有朋友缺人，加微信聊聊看？ bingwenshi

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

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

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

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

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

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

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

金额虽然不等，但肯定不会太大

你可以使用pyenv 给不同的项目设置不同的virtual env ，这样就可以愉快的使用python3了

1. 版权问题
2. 带宽和存储的费用

什么是小牛？ 可以吃么？

为何要删除呢 ？ 用PyEnv可以给项目指定不同的Python版本

楼主应该把房租，房间照片贴一下比较好