阿里云故障之后的思考

相信IT界对于3月3日凌晨阿里云华北区域部分服务器故障的消息还不绝于耳吧,在那次事故中不幸中招的公司或者个人,肯定对此嗤之以鼻吧。

各家的运维接到报警然后介入自查自家服务,一通自查之后,发现不是自家服务的问题,是外部问题,这个时候可能客户的投诉电话已经打到公司客服部了,如何做好和其它部门做好沟通,尽早给用户一个合理的解释,首先是发布故障报告,让用户明白故障的原因以及解决方案。二是做好技术的解决方案。尽快恢复服务。这个时候是最考验一个公司流程的时候。如果你司自带故障自愈的流程,那任何的节点故障,都不用太过担心。

自云服务诞生以来, 各大云厂商公司已出现各种各样的问题。其中国外的亚马逊云、微软云,国内的阿里云、腾讯云、ucloud、七牛云,或多或少都出过不少的技术问题。当然有的问题是流量服务商的问题。

究竟我们从这些故障的报告中我们得出了什么样的结论呢?中心化的云服务上到底是否可控的呢?从数次出问题的情况来看,我们从中学到了什么?带着这些问题,本次博文我们来细细的探讨一番。

首先,不可否认的一点就是云计算技术的诞生确实推动了IT交付速度,让一部分公司只要关注自己的核心业务即可,不用在关注IT机房建设、机器上架、下架等一系列技术。从而为业务节省宝贵的时间、节省人力成本,早年博主所在游戏公司,为了上架一款网页游戏,我们自行去采购硬件服务器,然后安装操作系统,最后运维去机房把机器放到对应的机架上,开机然后公司远程去连接服务器,做相应的服务部署,测试等等一系列的动作,才能最终实现业务。这种动辄几周甚至数周才能完成的事情,在当今云厂商的努力下,已经实现了在页面点点点即可完成这系列的任务。从购买服务器到应用上线不过也就几个小时的事情。我们来对比一下应用上架时间数据:

上云:

应用上线1个小时到几个小时,

传统机房:

一周到数周,要根据公司的采购周期。

从上文的数据对比中,我们明显可以看到优势。

第二点我要说的就是运维人员的发展问题,其实云技术发展,推动了整个小型公司运维人员的发展。以前公司运维既要关注硬件运维,又要关注业务运维。那么现在有了云计算之后,许多公司的运维只需要关注自己的业务运维即可,不太需要关注底层的技术运维了。因为这些云厂商已经帮你做好了。不需要去关注了。这一点有非常大的优势所在。

第三点我想说明的是,云真的像某些厂商说的那样节省成本吗?对于非常小型的公司来说,确实可以节省非常多的成本,甚至在项目初期,运维技术人员都可以,因为这些岗位高级开发可以顺带帮老板完成。但是当你的服务器规模到了1000台之后,成本随之而来。一年上百万的甚至千万级的云服务器采购费用。这个需要专业的对比一下。请有需要的朋友自行对比。

第四点我想说明的是,云厂商中心化后,导致业务技术问题非常复杂,很多规模上来后很多不可控因素在里面,比如一线技术人员的水平,云计算技术的研发更新速度,bug修复等等一系列问题。博主之前使用某云RDS出现过bug,导致业务出现问题。这里也会存在一些不可控因素在里面。既然全面拥抱公有云也有些不可控因素,那么有没有一种折中的方案呢?当然业内早就提出混合云概念。这里就班门弄斧了。请专业的上场解答。

看来混合云以后会不错的把业务放在一个云服务商说不定哪天又搞个大事故 做不到多云厂商的容灾至少可以做个跨az的容灾,也不至于某个区域挂了影响服务,从阿里云部分区域故障来看,我们内部的监控容灾难道没有问题吗?如何做好容灾本来就是个老生常谈的问题了,区域服务不可用通过监控发现问题,并定位问题服务器,迅速找到对应替代方案。比如服务分钟级的故障转移,等区域故障恢复,是否自动恢复服务,这里面牵涉到太多的技术实现,和跨部门系统的交付。光是应用的故障转移,目前各家应该做的都比较好了,DB的故障转移目前还是个业界难题,所以在资源允许的情况下,尽量做好多区域容灾。

总结未来混合云的超融合架构肯定会流行起来的。期望早点有公司可实现起来。

好了不说了,说多了有人该骂人了。欢迎指点纠错,谢谢。***

点击量:11

发表评论

电子邮件地址不会被公开。 必填项已用*标注