反向思考:阿里云这次故障里,有哪些措施面对故障发挥了好的作用?

[云计算] 季雨林 2018/6/28 8:59:38

首先,强调下中立理性思考的立场,虽然我做阿里云推广,但不是为了说阿里云好话推广阿里云。

我是做技术出身,毕业后待过 2 家公司都不出实习期就离职了,后来在一加汽车服务公司做 GPS 平台 5 年多,这期间经历过项目发展过程的多种问题,因此本文不是在说谁好谁坏,我个人经历的项目,并发设备经历过从 0 到 10 万,从物理机房到物理机房虚拟化,再到全云平台。深刻体会过每次故障处理过程的困难。借此机会探讨下如何涉及、部署这种高并发项目,今天侧重部署方面,谈谈


先用我自身举例,经历过的几个故障有(自建物理机房时期):

1,运营商跨网故障,移动手机卡发往联通机房时候,在省节点跨网交换数据处中断。 

最终找移动解决,耗时接近 3 天。后来针对线路特点,加了个移动光线,移动卡发回的数据,走移动线路,用户访问网站走联通线路,解决方式算是有效,最后上云直接依赖 BGP 线路

2,物理机房时期:本市修地铁,挖断了联通光纤,半夜 3 点左右,我的外部监控发出报警,早上大约 5 点修复。 

我当时能做的只有打完联通某些部门电话后(而且没有客服电话,是我联系业务中,存下的某些部门电话),坐等。。。

3,地域性 dns 故障,某个城市到我们机房省份,经常出现不上线的情况,其他城市正常。

 最后没有什么有效解决方案,通过配置,客户端设备改为不再使用域名,换成 ip,从此绑在了 ip。负面结果是后来上云总是没法彻底迁移设备数据。

4,线路距离故障,某个省到机房总是很高延迟,经常飘红。 

没有效解决办法,这个故障的最终用转移到云上,华东机房方式解决。实现全国范围综合延迟都兼顾。

5,gps 业务的特点,高并发写入,硬盘写坏了 

好在 raid10 的存在,接近 1T 的数据库还健在运行,最终只能停机更换硬盘,半夜对外中断服务,周期很长。(最快的解决方法就是转移到另外一台机器,1T 数据万兆网卡内网传输,光拷贝过程就用了很久)


目前,关于本次阿里云故障,我总结到的有:

1,再高的可用性,都是存在不可用的时段。

我们自己的小网站不必多说,稍微一点维护,就要先关掉网站,这期间的时间都算所影响在线时长。本次阿里云故障假设按照半小时算,今年假设再没有其他故障,可用性就已经跌落到 4 个 9,99.99%

2,赔付协议 很多人在故障期间都提到了怎么赔偿问题,居然真的有人说不会赔偿,显然不太可能,赔付协议是个很早就制定好的。防止的就是这种情况出现,而且今年还重新修订过一些细节。

3,网站首页单独负载

很多人都留意到了,阿里云故障期间,首页可以正常打开,只是其他功能和子页面故障,推测是针对首页高访问的一个优化方案,似乎是独立发布了首页,这个算是我在本次故障中的最大发现

4, 

5, 

6, 。。。


本帖子的用意在于:欢迎各位运维大佬,指导下大项目发布过程要做的储备,以及优势,欢迎各位补充^^



原文地址: https://www.opengps.cn/Blog/View.aspx?id=129 文章的更新编辑依此链接为准。欢迎关注源站原创文章!

评论

暂无评论!

发表评论:

用于接收作者回复信息
点击更换验证码 - openGPS提示