这一次,除了骂阿里云,还能做些什么?

开发 开发工具 前端
很多朋友经历了前几天阿里云3小时左右的故障,一次事故如一场战役,不管是在故障过程中的处理,还是故障后的总结,除了骂阿里云,我们自己有没有可以改进的空间呢?结合我司昨夜的处理过程,说一下自己的一点想法。

很多朋友经历了前几天阿里云3小时左右的故障,我司的业务也受到了一定影响,技术的同事一起熬夜奋战,最终观察服务稳定运行了两个多小时。

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

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

[[258832]]

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

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

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

  • 及时反馈业务方:例如客服,运营等,如果收到用户反馈,能够及时说明情况;
  • 确定影响范围:因为不是所有服务器都受影响,确定范围后好针对性检查;

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

  • 运维立刻收到服务器告警了么,研发与测试立刻收到站点与服务告警了么?为什么没有收到,是没有告警,还是告警覆盖缺失?

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

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

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

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

画外音:

  • 未来要自动化,可视化;
  • 除了能从前端发现A、B、C功能不可用,能从后端精准确定哪些服务,多大比例的流量受影响么?

潜在的非技术问题:

  • 技术团队和业务方建立了反馈渠道么,沟通是否顺畅?
  • 有没有“线上服务第一”的意识,有没有“系统值班”的制度,还是说,关着手机睡觉?

画外音:

  • 昨晚绝大多数二级,三级部门负责人都立即投入战斗,很赞;
  • 技术人,关着手机睡觉,是不可接受的。

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

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

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

  • 申请新服务器;
  • 确认受影响的站点与服务、重新部署;
  • 服务治理,将流量迁移;

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

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

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

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

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

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

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

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

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

  • 确定站点与服务是否运行;
  • 确定日志是否异常;
  • 确定业务在线业务是否异常;
  • 一些容易遗漏的点的再三检查:例如MQ的消费,定时任务的执行。

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

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

服务观察稳定后一段时机。朋友圈、微博上开始对阿里云进行声讨,都在提自己的优化方案:

1. 是时候换一个云了;

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

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

2. 是时候自建机房了;

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

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

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

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

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

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

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

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

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

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

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

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

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

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

 

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2018-04-10 11:14:00

2019-04-12 11:25:24

华为

2024-05-15 10:14:00

CRDT数据类型协同编辑

2019-06-05 13:00:00

2019-11-08 16:05:54

Promise前端链式调用

2019-09-12 09:40:34

秒杀系统高并发

2024-03-11 08:47:30

CRDT数据类型协同编辑

2015-05-20 17:09:47

云存储数据云端化

2018-07-23 16:13:27

Google欧盟Android

2016-03-31 17:01:26

桂林甲天下

2021-07-03 08:59:49

动态代理JDK

2018-08-07 14:45:52

编程语言JavaScripthtml

2016-11-08 07:58:02

乐视难关科技新闻早报

2016-01-06 11:15:03

VR

2014-07-18 17:14:16

小米苹果雷军

2021-03-11 12:15:37

Kubernetes云原生容器

2019-11-05 11:17:11

Java虚拟机技术Java 堆

2021-08-29 08:14:30

GPU CSS gpu

2020-07-06 14:39:18

知识图谱思维

2017-01-15 11:17:20

点赞
收藏

51CTO技术栈公众号