运营踏坑之2：有备无患

前两天，找一朋友聊天，没空搭理我。

太忙。

他的VOS系统及EIX被人攻击，因为VOS安装在阿里云上，阿里云检测到异常，直接将系统关闭了。

不是阿里的大客户，关闭系统来，阿里没二话，朋友也只能眼睁睁的看着系统服务中断而无法恢复，想尽办法找阿里云处理，无济于事。

想紧急恢复一套系统供业务使用，苦于无备份数据，干瞪眼。

最后只能等到攻击结束了，为此，基本干耗了一天。

晚些的时候，我跟他开玩笑说，今天这一次的损失，抵得上购买几套呼叫中心系统吧，厂家提供的服务，还是有价值的吧。

朋友说，以前做了备份，但一直没碰到事，不经历一次，完全感受不到它的重要性。

是啊。

有些事情，做了，不一定产生效益，但不做，总有机会让你痛到骨子里。

容灾备份这事，就是。

我们开发呼叫中心系统，一直都跟我们的客户强调备份的重要性。但备份这事，是要花银子的，不是每个人都愿意投入。很多客户都被我们追的有些腻歪了。

在几个月之前，我们有一伙伴，也是碰到不可预料的情况，系统中断服务，几个月都无法恢复，丢掉一大批客户。

这之后，我们再说备份这事，一句额外的话都不用多说。

阿里云出现故障，相信大家多多少少有所耳闻；而云计算的开山鼻祖，亚马逊云，技术相当的NB，前不久，也是出现一次重大事故。

摘录媒体报道片段：

2月28日上午（太平洋时间）AWS发生了服务宕机事件。事件的起因是AWS S3（云存储）团队在进行调试时输入了一条错误指令，从而导致S3不能正常工作，S3 API处于不可用状态。

美国东一服务区内最具人气的S3服务以及其它受影响AWS服务可能给Amazon带来高达10%的月度营收影响。根据粗略估算，这一服务水平协议违约可能造成数百万乃至数千万美元的损失。

S3于2006年发布，是 AWS 最早的诸多服务之一，官方曾称其具备99.999999999% 的持久性（durability）和 99.99% 的可用性（availability）。

S3拥有很多明星用户：Airbnb（处理超过10PB的用户图像）、Nasdaq（支持 FinQloud 的监管记录保留 (R3) 数据存储解决方案和 Query）、Netflix（分发数十亿小时的内容）。此次事故波及众多公司，外媒的统计名单中A-Z的26个字母全部占满，其中包括Adobe、Docker、GitHub、Slack、GE、Quora等知名公司。

为什么Netflix 重度使用 AWS，却在历次 AWS 的宕机中毫发无损？其实Netflix之前也深深地被云的「不稳定性」刺痛过，而如今他们的 Chaos Monkey（之后发展为 simian army）服务，会随时随地模拟各种宕机情况，扰乱生产环境。

数数，亚马逊官方宣称的，可靠性后面有几个9？

该来的，总是会来。常在河边走，哪有不湿鞋？

n多NB的大公司，在亚马逊的故障中，一样受损。

不在技术，而在意识。

运营中，任何一条规则的建立，一般都是伴随着血与泪的教训。

报道中，有一家公司，我们要向其致敬：NetFlix。

回到我们的行业，可靠性真的要做到万无一失么？

曾经写过一篇文章《通信系统可靠性真的需要做到99.999%？》，回答过这个问题，这里就不再赘述了。

如果有钱了，要向NetFlix学习，空调要买2台，开一台，备用一台，或者两台都开，负荷分担。

就算钱不够，也要建立备份的意识，建立定期备份、异地备份、快速恢复的机制。

做运营，该花的，不能省。

分享的越多，收获的也越多。欢迎分享。