阿里云9月1日事故的记录
事件经过
事情发生 9.1 11:40
9月1日上午11点多钟，我正登录服务器进行维护工作，因为前一天在服务器部署了新的seafile，还有搜索等功能需要手动开启。大约到了11:40的时候，朋友让我帮他测试一个IP的路由路径，我就在服务器上运行了mtr测试。然而mtr刚发送了几个数据包，就自己退出了。我很奇怪地再运行一次，系统却提示我无法运行mtr，没有那个程序。这还真是奇怪的事情，前几秒还在运行的程序，现在就没了。我以为是不是PATH环境变量出什么问题了，运行which mtr也找不到。于是决定重新安装一个，直接apt-get安装。结果问题又来了，apt-get提示我程序配置出错，要运行dpkg --configure修复。我再按提示运行，却看到提示说dpkg命令也不存在了。
我意识到服务器出现问题了，本着“重试、重启、重装”的三重原则，我选择了重启服务器。结果悲剧地无法启动了，连接管理终端发现机器卡在Booting from Hard Disk...就不动了。我的第一反应是保护自己的数据，马上到阿里云后台的磁盘管理中创建了一个磁盘快照。然后提交工单寻求技术支持。
提交工单 9.1 12:16
12:16我提交了工单，等着十几分钟没有回应，不过因为是个人网站，我就没有打电话催促。此时我还不知道阿里云发生了线上事故，只以为我的云服务器硬盘坏掉了，不过考虑到阿里云宣传的多重备份的硬盘管理策略，加上我又做了一个快照，我并不太担心自己的数据丢失。于是我提交完工单就和同事吃饭去了。
客服回复 9.1 12:50
回到办公室的时候，已经是下午一点多钟，阿里云工单有了进展，客服在12:49接手工单，在12:52给出事故原因：因云盾升级触发bug，导致少量文件被系统误删除。我们已经第一时间启动系统回滚。被误删除的文件正在陆续恢复，您无需进行手动恢复操作，请耐心等待。对您带来的不便我们深表歉意。
好吧，这时候我觉得阿里云的服务还不错，事故原因合情合理，客服也代表公司表达了歉意。甭管多大的软件公司，谁能不出点差错呢，这次也就和以前杀毒软件病毒库升级误杀系统文件导致开不了机一样。既然让我不要操作，我就不管了。
论坛炸锅 9.1 15:40
我本以为恢复一个误删的文件并不难，对于那些没重启的机器，既然云盾能把文件删了，自然可以统一往下分发文件；对于已经重启启动不能的云服务器，阿里完全可以用程序启一个等同系统的实例然后把用户的文件系统挂上去，再参照前面的方法恢复。
阿里云总共能用的系统镜像也没几个，统一恢复工作应该不会超过一个小时就能完成。结果事实证明我毕竟还是too young，时间过去了三四个小时，还是没有完成恢复。v2ex和阿里云官网论坛上哀鸿遍野，无数人在诉说自己被老板被客户骂到快死掉的过程。
等待了三个多小时后，阿里云工单上终于回复：您好，问题目前还在恢复中，有进一步进展，我们会随时和您反馈，对您带来的不便我们深表歉意，还请您耐心等待。
阿里云的官网则挂出了公告
尊敬的客户： 因云盾安骑士server组件的恶意文件查杀功能升级触发了bug，导致部分服务器的少量可执行文件被误隔离。系统在第一时间启动了回滚，目前被误隔离的文件已基本恢复。我们正在回访个别尚未恢复的客户，协助尽快恢复。对于受影响的客户，我们将立即启动百倍时间赔偿，并避免类似失误再次发生。我们深知这一失误对您业务带来的影响和损失，再次致以最深刻的歉意。
统一恢复完成 9.1 18:37
18:15阿里云工单回复Windows系统已经恢复，Linux系统还需要时间。18:37再次更新，说全部恢复完毕，并让我如果有问题随时反馈。然而我的服务器还是挂着的，我在18:43反馈了服务器的实际情况，表示并没有修复，不同意关闭工单，要求进一步处理。
收到阿里云通知邮件 21:09
时间又过去两个多小时，收到了阿里云的通知邮件：
如果您的ECS机器云盾进程已经退出，我们无法下发文件进行修复，请通过以下方式开启： Windows机器请启动 Alibaba Security Aegis Detect Service 服务 步骤： 1）打开计算机管理 2）选择 “服务” 3）找到 Alibaba Security Aegis Detect Service 服务并启动 4）如果找不到该服务，请尝试查找并启动 Alibaba Security Aegis Update Service 服务 Linux 机器 方案1： service aegis start 方案2： 进入/usr/local/aegis/aegis_client目录，选择高版本子目录，例如（aegis_00_79) 进入该子目录，运行 AliYunDun 进程
工单上并没有任何解释或者回复，我留言表示服务器挂了无法启动阿里云盾的进程。
最终解决方案 9.2 00:05
午夜钟声敲响不久，阿里云给出了适用我的最终解决方案：
如果您重启了主机,后台就无法正常恢复被隔离的文件了. 当前建议: 1. 登录主机控制台,对系统盘打个快照,等待100%完成, 2. 回滚系统盘至之前正常使用的快照点. 打快照的目的是如果当前系统中有重要数据,回滚后如果系统正常了,我们可以把您打的快照挂载到正常系统中,供您做数据恢复.
问题解决 9.2 01:04
终于在凌晨一点多的时候，问题得以全部解决，网站数据恢复成功，重新对外提供服务。
事件反思
客服回复不及时
遇到突发事故，阿里云的客诉量肯定大幅上涨，这个可以理解。但是阿里云似乎并没有采取什么有效手段来增加人手，及时回应客户的工单。提出问题后长达几个小时没有任何人回应，客服电话长时间无法接通，让客户自己干着急。
缺少必要的技术建议
我在个人网站一直挂掉，苦等到下午三点多钟的时候，同事反应公司的服务器也出现了系统命令丢失的问题。我的个人服务器在青岛，公司的服务器在北京，原本我以为只是阿里小范围测试时出现的问题，没想到居然北京机房也被波及。我立刻阻止他重启服务器，告诉他重启很可能会马上挂掉，因为操作系统的程序都被误删除了。然而阿里云的公告和故障申诉的工单中都没有提示用户这一点。
相信吐槽最多、损失最大的是商业用户，他们不指望你赔偿多少倍的云服务使用时间，就希望能尽快恢复服务器运行，甚至有的用户可能丢失一部分数据也可以接受。阿里云的技术人员完全有能力在事发一小时后整理出一份处理意见表，说明这次事故导致的系统程序损坏、用户数据损坏、系统无法启动等几种情况分别要怎么处理，可以最快恢复对外服务。
既然下午三点的时候云盾的误杀行为已经停止，进入恢复数据的阶段。此时投入应急的机器，配合客户紧急迁移业务程序到新的云主机上来恢复服务也不是不可行的。以我们公司的情况为例，用着阿里云的四台ECS，开几台新的云主机上线部署一次也就半小时到一小时的事情。
论坛上有人分享通过自行回滚到前一天的快照已经恢复服务，而阿里云官方在工单上要求用户不要操作，然后在长达十几个小时之后才给出回滚到前一天的快照，人工恢复数据的处理方案，真的是耗时太久了，损失也太大了。
经历这件事情知道云服务商宣传的99.999%的可靠度也就是个统计数字，自己中奖了就已经后悔莫及，经常备份数据或者设置备用机房才能让业务更安全。
最后发现今天各新闻网站全然没有报道此次事故，不知道是因为事故太小还是因为阿里太大。现在只好坐等阿里的100倍赔偿。