首页 > 云计算 > 正文

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

2019-03-06 09:37:09  来源:

摘要:很多朋友经历了前几天阿里云3小时左右的故障,一次事故如一场战役,不管是在故障过程中的处理,还是故障后的总结,除了骂阿里云,我们自己有没有可以改进的空间呢?结合我司昨夜的处理过程,说一下自己的一点想法。
关键词: 阿里云
  很多朋友经历了前几天阿里云3小时左右的故障,我司的业务也受到了一定影响,技术的同事一起熬夜奋战,最终观察服务稳定运行了两个多小时,直到凌晨五六点多才逐渐登出VPN。

\
 
  一次事故如一场战役,不管是在故障过程中的处理,还是故障后的总结,除了骂阿里云,我们自己有没有可以改进的空间呢?结合我司昨夜的处理过程,说一下自己的一点想法。
 
  画外音:技术人,还是聊技术,决定不了别人,我们做好自己。
 
  一
 
  凌晨,收到运维负责人的电话,阿里云部分机房故障,并从阿里云同事收到反馈,问题仍在定位,恢复时间不确认。
 
  画外音:关键时刻,手机欠费了,运维负责人还帮我充了200话费,才打通,真曲折。
 
  整个过程中,我们能做什么呢?
 
  第一时间反馈业务方:例如客服,运营等,如果收到用户反馈,能够及时说明情况;
 
  确定影响范围:因为不是所有服务器都受影响,确定范围后好针对性检查;
 
  这里面,潜在的技术问题是:
 
  运维在第一时间收到服务器告警了么,研发与测试在第一时间收到站点与服务告警了么?为什么没有收到,是没有告警,还是告警覆盖缺失?
 
  画外音:如果让业务方先发现问题,反问技术部,服务怎么出问题了,是何等尴尬?
 
  能够快速确定受影响的服务器IP么?以及受影响的业务范围么?
 
  我们的运维同学立刻通过脚本,确定了大概有50来台服务器受影响。
 
  DBA同学也立刻确认了,RDS数据库服务没有受到影响。
 
  画外音:
 
  未来要自动化,可视化;
 
  除了能从前端发现A、B、C功能不可用,能从后端精准确定哪些服务,多大比例的流量受影响么?
 
  潜在的非技术问题:
 
  技术团队和业务方建立了反馈渠道么,沟通是否顺畅?
 
  有没有“线上服务第一”的意识,有没有“系统值班”的制度,还是说,关着手机睡觉?
 
  画外音:
 
  昨晚绝大多数二级,三级部门负责人都第一时间投入战斗,很赞;
 
  技术人,关着手机睡觉,是不可接受的。
 
  二
 
  过了一个多小时了,阿里云仍未反馈修复时间,这个时间大家都有点着急了,那除了干等着,我们自己能做些什么呢?
 
  因为只有部分区域的服务器异常,能不能申请一些新的服务器,将受影响服务器上的站点与服务重新部署,通过服务治理将流量切到新的服务上,是不是能恢复(至少部分恢复)呢?
 
  整个过程中,我们能做的是:
 
  申请新服务器;
 
  确认受影响的站点与服务、重新部署;
 
  服务治理,将流量迁移;
 
  这里面,潜在的技术问题是:
 
  (1) 能不能快速进行服务器扩容;
 
  画外音:昨晚我们迅猛购买了50台ECS,这是云的好处。
 
  (2) 知道了受影响的服务器IP,如何能够快速确定这些IP上部署了哪些站点与服务?这些站点与服务的上下游是什么,连带影响范围是什么?
 
  画外音:这是有待提高的地方,每个负责人都知道自己的IP上部署了什么,但并不可视化。
 
  (3) 如何快速站点与服务扩容与缩容,如何服务发现,如何迁移流量?
 
  画外音:服务治理,任重道远。
 
  三
 
  又过了大概半个小时,我们购买完服务器,梳理站点与服务的过程中,阿里云专家反馈,“问题定位有了关键进展,不出意外的话30分钟恢复”。此时我们内部评估,30分钟50台ECS的初始化,服务部署,流量迁移恐怕完不成,还是等阿里云好了。
 
  果真大概半个小时,阿里云专家反馈恢复了,这时我们要做的:
 
  确定站点与服务是否运行;
 
  确定日志是否异常;
 
  确定业务在线业务是否异常;
 
  一些容易遗漏的点的再三检查:例如MQ的消费,定时任务的执行。
 
  画外音:有些定时任务可能需要手动再次执行。
 
  这里面的很多工作,是通过手工,还是脚本自动化,还是平台可视化来判断与执行?技术平台的迭代,仍重而道远。
 
  四
 
  服务观察稳定后一段时机,大部分技术同学陆陆续续登出VPN下线了。朋友圈、微博上开始对阿里云进行声讨,都在提自己的优化方案:
 
  1. 是时候换一个云了;
 
  换一个云能解决问题么?用其他云的朋友,可以评论反馈下故障频率。
 
  我相信,各家有各家的问题,我甚至愿意相信,阿里云的故障率是相对较低的。
 
  2. 是时候自建机房了;
 
  自建机房能解决问题么?自建机房的朋友,可以评论反馈下故障频率。
 
  说实话,让我自建机房,我目前真没有信心做得比阿里云更好。
 
  3. 是时候多机房多活了;
 
  “多机房多活”不是四个字这么简单,需要多大的成本,需要多少技术基础服务支撑,需要多大的架构改造,有考虑过么?
 
  画外音:58同城15年做机房迁移时做过多机房多活,我还算有一定发言权。
 
  我相信,目前99.9%的公司,目前的业务阶段,目前的投入产出比,不适合做多机房多活。
 
  骂阿里云不解决问题,这次事故过程中发现的自身的问题,我们要继续去改进。
 
  特别是服务治理体系,可视化监控与运维体系,任重而道远。
 
  不为阿里云洗地,阿里云你影响了我们几个小时业务可用性,该陪的要赔,尽量加倍赔,让我们看到你的诚意。
 
  画外音:谁有XX云的接口人联系方式,请小窗我一下。
 
  末了,让我特别感动的一点,还是一起熬夜奋战的兄弟姐妹们。早晨,还有部分同学赶去公司,要把运营反馈的不一致数据,进行修正。
 
  我相信,因为有你们,业务一定能做成。
 
  我相信,大家的付出老板一定看得到,3/4月份的涨薪一定有你。

第三十五届CIO班招生
国际CIO认证培训
首席数据官(CDO)认证培训
责编:pingxiaoli

免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。