由阿里云宕机引发的思考

https://mbd.baidu.com/newspage/data/landingsuper?context=%7B%22nid%22%3A%22news_8964230537733801569%22%7D&n_type=1&p_from=4

---

 

阿里云最近几次故障：

2019/3/3，凌晨，华北2地域可用区C部分ECS服务器等实例出现IO HANG，持续约3小时。

2018/10/11，16:40开始，阿里云华东一区部分服务器故障。

2018年7月，中午出现故障，宕机近1小时。

2018/6/27，16:21开始，自动化运维上线新功能触发未知代码bug导致MQ、NAS、OSS产品部分功能异常，持续约1小时。

2017年9月，阿里云由于产品升级出发了bug，导致大规模故障。

2017年6月，阿里云的香港机房瘫痪12小时，引发大面积服务异常。据可靠消息表示，当时由于机房所在楼层断电，导致服务器瘫痪。

 

---

 

我们从云服务使用者的角度来反思这次事故

第一：应急预案

1.首先通知业务相关干系人

每种业务是否有对应的接口人相应接口人的联系方式是否正确2.到达一定级别，开始对系统降级

是否有降级方案降级方案是否可用降级方案是否进行过演练。千万不要降级方案平时没有用过，出事的时候拿过来用。降级这种事，你做技术的心里都没底，让领导替你背这个锅。所以，降级方案也要演练！！！！

3.实施兜底方案

如果真的后端不行了，你前端不能给人家一个大白板，404,500；你好歹给用户一个‘你好/欢迎’也可以啊，至少让人知道你没跑路

4.流量迁移

快速把故障区域的流量迁移到其他可用区域

第二：问题发生时，故障检查

1. 确定核心前端和后端服务是否正常运行；

2. 确定业务在线业务是否异常；

3. 后台执行的任务是否正常：例如MQ的消费，定时任务的执行。

4. 确定日志是否异常；

5. 梳理故障服务器上部署的哪些服务,这些服务的影响范围

第三：暴风过后，怎么搞

1,系统预警生效了么？

值班人员有没有值守岗位核心关键系统，必须要制订值班制度

运维、研发人员是否在第一时间收到告警如果没有收到，那么是为什么没有收到，是没有告警，还是告警覆盖缺失？

如果收到，是否按应急预案进行操作

2.换一个云服务商？

换一个云能解决问题么，云厂商承诺99.99% 的安全可靠性,但是各家有各家的问题,用了才知道

没有绝对的安全和可靠，这些都是相对的，。

不可行

3.不要云服务商的，自己搞一套机房

投资成本：这个成本是否在可接受范围可用性：自己托管在IDC机房的安全性和可靠性真的比云厂商高吗？维护成本：需要一个庞大的团队来搞这事

4.异地多活，千万不要有单点故障存在。

我认为这是一个靠谱的方案，这也是平时做方案的时候一个重要的策略

在生产系统中，核心的重要的系统一定要部署在两台以上，避免出现单点故障。部署在2台以上那就可以把这2台部署在同一地域下的不同可用区，因为不同的可用区之间的电力、网络是独立的，而内网又是互通的，所以部署在同一地域下的不同可用区是最最经济实用的。

这次的故障就发生在可用区C，如果你的业务部署在两个不同的可用区，那么这次故障是不会给你带来太多麻烦的。所以，核心业务要部署在不同的可用区内，

5.数据备份

数据备份有冷备、热备、本地备份、异地备份，更重要的是数据备份要具有可用性，而且一定要有可用性，不然出了问题就直接准备逃命吧。

总之，在云平台上部署业务，并不是买几台云服务器部署上去就高枕无忧了，要根据自己的业务情况选择不同的方案。

最后，数据一定要备份！！！ 要备份！！！要备份！！！！！！

再最后，数据备份一定要可用！！！ 要可用！！！ 要可用！！！！！！