ITPub博客

首页 > 云计算 > 公有云实践 > 复盘阿里云故障,除了骂,还能做些什么?

复盘阿里云故障,除了骂,还能做些什么?

原创 公有云实践 作者:58沈剑 时间:2019-03-22 11:39:39 0 删除 编辑

分享技术,传播正能量。

很多朋友经历了上次阿里云3小时左右的故障,我司的业务也受到了一定影响,技术的同事一起熬夜奋战,最终观察服务稳定运行了两个多小时,直到凌晨五六点多才逐渐登出VPN。

一次事故如一场战役,不管是在故障过程中的处理,还是故障后的总结,除了骂阿里云,我们自己有没有可以改进的空间呢?结合我司昨夜的处理过程,说一下自己的一点想法。

画外音:技术人,还是聊技术,决定不了别人,我们做好自己。

凌晨,收到运维负责人的电话,阿里云部分机房故障,并从阿里云同事收到反馈,问题仍在定位,恢复时间不确认。

画外音:关键时刻,手机欠费了,运维负责人还帮我充了200话费,才打通,真曲折。

整个过程中,我们能做什么呢?

1. 第一时间反馈业务方:例如客服,运营等,如果收到用户反馈,能够及时说明情况;

2. 确定影响范围:因为不是所有服务器都受影响,确定范围后好针对性检查;

这里面,潜在的技术问题是:

1. 运维在第一时间收到服务器告警了么,研发与测试在第一时间收到站点与服务告警了么?为什么没有收到,是没有告警,还是告警覆盖缺失?

画外音:如果让业务方先发现问题,反问技术部,服务怎么出问题了,是何等尴尬?

2. 能够快速确定受影响的服务器IP么?以及受影响的业务范围么?

我们的运维同学立刻通过脚本,确定了大概有50来台服务器受影响。

DBA同学也立刻确认了,RDS数据库服务没有受到影响。

画外音:

(1)未来要自动化,可视化;

(2)除了能从前端发现A、B、C功能不可用,能从后端精准确定哪些服务,多大比例的流量受影响么?

潜在的非技术问题

1. 技术团队和业务方建立了反馈渠道么,沟通是否顺畅

2. 有没有“线上服务第一”的意识,有没有“系统值班”的制度,还是说,关着手机睡觉?

画外音:

(1)昨晚绝大多数二级,三级部门负责人都第一时间投入战斗,很赞;

(2)技术人,关着手机睡觉,是不可接受的。

过了一个多小时了,阿里云仍未反馈修复时间,这个时间大家都有点着急了,那除了干等着,我们自己能做些什么呢?

因为只有部分区域的服务器异常,能不能申请一些新的服务器,将受影响服务器上的站点与服务重新部署,通过服务治理将流量切到新的服务上,是不是能恢复(至少部分恢复)呢?

整个过程中,我们能做的是:

1. 申请新服务器

2. 确认受影响的站点与服务、重新部署

3. 服务治理,将流量迁移

这里面,潜在的技术问题是:

1. 能不能快速进行服务器扩容;

画外音:昨晚我们迅猛购买了50台ECS,这是云的好处

2. 知道了受影响的服务器IP,如何能够快速确定这些IP上部署了哪些站点与服务?这些站点与服务的上下游是什么,连带影响范围是什么?

画外音:这是有待提高的地方,每个负责人都知道自己的IP上部署了什么,但并不可视化。

3. 如何快速站点与服务扩容与缩容,如何服务发现,如何迁移流量?

画外音:服务治理,任重道远。

又过了大概半个小时,我们购买完服务器,梳理站点与服务的过程中,阿里云专家反馈,“问题定位有了关键进展,不出意外的话30分钟恢复”。此时我们内部评估,30分钟50台ECS的初始化,服务部署,流量迁移恐怕完不成,还是等阿里云好了。

果真大概半个小时,阿里云专家反馈恢复了,这时我们要做的:

1. 确定站点与服务是否运行

2. 确定日志是否异常

3. 确定业务在线业务是否异常

4. 一些容易遗漏的点的再三检查:例如MQ的消费,定时任务的执行。

画外音:有些定时任务可能需要手动再次执行。

这里面的很多工作,是通过手工,还是脚本自动化,还是平台可视化来判断与执行?技术平台的迭代,仍重而道远。

服务观察稳定后一段时机,大部分技术同学陆陆续续登出VPN下线了。朋友圈、微博上开始对阿里云进行声讨,都在提自己的优化方案:

1. 是时候换一个云了;

换一个云能解决问题么?用其他云的朋友,可以评论反馈下故障频率。

我相信,各家有各家的问题,我甚至愿意相信,阿里云的故障率是相对较低的。

2. 是时候自建机房了;

自建机房能解决问题么?自建机房的朋友,可以评论反馈下故障频率。

说实话,让我自建机房,我目前真没有信心做得比阿里云更好。

3. 是时候多机房多活了;

“多机房多活”不是四个字这么简单,需要多大的成本,需要多少技术基础服务支撑,需要多大的架构改造,有考虑过么?

画外音:58同城15年做机房迁移时做过多机房多活,我还算有一定发言权。

我相信,目前99.9%的公司,目前的业务阶段,目前的投入产出比,不适合做多机房多活。

骂阿里云不解决问题,这次事故过程中发现的自身的问题,我们要继续去改进。

特别是服务治理体系,可视化监控与运维体系,任重而道远。

不为阿里云洗地,阿里云你影响了我们几个小时业务可用性,该陪的要赔,尽量加倍赔,让我们看到你的诚意

画外音:谁有XX云的接口人联系方式,请小窗我一下。

末了,让我特别感动的一点,还是一起熬夜奋战的兄弟姐妹们。早晨,还有部分同学赶去公司,要把运营反馈的不一致数据,进行修正。

我相信,因为有你们,业务一定能做成。

相信,大家的付出老板一定看得到,3/4月份的涨薪一定有你

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31556838/viewspace-2639056/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
58速运CTO,互联网架构技术专家,“架构师之路”公众号作者。曾任百度高级工程师,58同城技术委员会主席,高级架构师,58到家技术委员会主席,高级技术总监,目前主要负责58速运技术部。

注册时间:2018-09-30

  • 博文量
    34
  • 访问量
    22706