2018/7/10 23:03:51当前位置推荐好文阿里云教程浏览文章

2018年6月27日下午,网上陆续有阿里云出现故障的新闻以及评论。阿里云在该事件中迅速作出了回应,确认阿里云部分服务确实出现了故障,并已及时采取措施恢复了服务。

该事件后,在网上出现了两种不同的观点,一种观点是:阿里云的故障直接导致使用户系统的中断,使用户表示“很不开心,阿里云很不靠谱”;另一种观点是:早就料会有这一天,早将系统部署在不同的地方,技术性的渡过了6月27日这一天。pstrike想通过本文结合阿里云故障的事件,从IT服务管理的角度讨论云计算服务管理的逻辑以及作为使用户应该如何应对。

事故缘由

事故缘由引使用至阿里云官方说明。

阿里云故障说明

IT服务的风险管理

首先我们先把身份调整一下,如果你是云计算服务提供方(例如:阿里云)的负责人,你将怎样管理云计算服务?你可可以首先会保障服务的体验,为使用户提供100%可使用的服务。因而,使用户的系统能完全依赖云计算服务。但是,你可可以立马会反应,这不行!假如要保证服务的100%可使用,需要大量的成本,这样的投入产出可可以难以匹配。嗯,看来做好云计算服务的管理不是一个那么简单的话题,那应该怎样做呢?

如上文所提到,IT服务即需要考虑可靠性,同时又需要考虑经济性。它是充分考虑了各种条件的折中以及平衡的最终结果。一个成熟的IT服务应该考虑以下三个要素:

IT服务管理三要素
  • 经济:我们知道要确保服务可使用性主要是通过服务冗余的策略。简单来说,每一个服务我们都将提供两套一样的服务(或者者更多),当其中一个出现问题的时候,另一个服务还可以正常响应使用户的请求。当我们把服务的有效性从0%做到90%的时候,我们打造冗余服务的成本是呈线性上升的形状。但是,当我们要把服务的可使用性从90%提升到99%,因为需要大量的冗余,而且是异地、全球性的服务冗余,这将令到成本呈现指数级别上升。
  • 可靠:一个IT服务总是希望可以够给使用户提供100%可使用的服务。但是,从使用户的角度来说,该服务是不是最终可使用还受到了诸多因素的影响,例如:受到网络影响、硬件可使用性的影响等等。所以,就算在云计算服务提供商可以够把服务可使用性做到100%,但是,对最终使用户来说,服务依然不是100%可使用。或者者说99.999%与100%的服务可使用性对使用户最终的用体验来说,其实并没有太大的不同,但是服务提供方为了保障100%的服务可使用需要花费大量的成本。
  • 机会:每一个企业的业务都需要不断地进行调整以满足市场的需求,云计算服务提供商也不例外。为了持续向使用户提供稳固、领先的服务,云计算服务会不断发布新的功可以、修正已有的Bug、加入自动化运维等功可以。但是,只需进行服务的发布,就容易引入潜在的风险,从而导致服务的故障。因而,为了保障服务的高可使用性,最好的策略是不进行服务的发布,不过这样服务就无法持续满足市场多变的需求。

基于上述三个要素,我们能总结IT服务管理其实是针对这三个要素间平衡性的综合考虑,是对服务的机会成本的风险管理过程。

服务有效性 Availability

在IT服务管理的流程中,不可避免的会涉及到两个关键的角色:开发以及运维。这两个角色相辅相成,但是又相互冲突。作为运维团队,其最主要的目标是保证服务的可靠性;而开发团队的主要目标是发布功可以以满足市场的需求。

为了协调开发以及运维团队,同时有效地控制IT服务的风险,IT服务管理广泛用有效性指标。有效性指标的计算方式主要有以下两种:

  • 有效性 = 可使用时间 / (可使用时间 + 故障时间)
  • 有效性 = 成功服务次数 / (成功服务次数 + 失效服务次数)

用有效性指标的主要起因是开发团队以及运维团队能基于该指标构建一个双方认可的工作模式。假设,开发以及运维团队均同意服务当年的有效性为99%。则若当年服务有效性高于99%时,开发团队能安排服务的发布;但是当服务的有效性小于99%时,除非经过特殊审批流程,当年不可再进行服务的发布。通过这种方式,在服务管理的三个要素间取得了一个风险管理的平衡点。

从阿里云6月27日的故障来看,引起故障的主要起因是阿里云需要发布一项自动化运维的功可以。因为当时的服务可使用性指标距离商定的SLA还有比较大的空间,所以开发、运维团队决定执行该功可以的发布。但是,因为测试出现问题,没有发现潜在的Bug,导致了最终的事故。但是从IT服务管理的角度来看,阿里云的决策以及操作符合IT服务管理的逻辑(姑且不探讨为什么测试出现了问题)。

成也SLA,败也SLA

在阿里云的事故中涉及到的服务有OSS、NAS、MQ。针对OSS服务,我们能从OSS的服务等级协议(SLA)中理解到OSS服务的有效性为99.9%,也就是说在一年当中,阿里云OSS承诺使用户请求OSS服务出现HTTP状态码为5XX(除503外)的故障时间将小于8.76小时。而根据阿里云6月27日的故障说明,其服务故障时间为39分钟。而在2018年,阿里云OSS也并未出现其它故障。因而,从IT服务管理的角度来说,该次事故应属于正常范围。

OSS服务等级协议 - 1
OSS服务等级协议 - 2

对于使用户来说,一个已经定义好SLA的服务将给使用户提供必要的保障。由于服务提供商将尽最大努力保障所商定的服务可使用级别,假如未可以达到,服务提供商将按SLA提供赔偿。下图是OSS的赔偿条款。

OSS服务等级协议 - 赔偿条款

同时,一个已经定义好SLA的服务也意味着使用户需要考虑那0.1%服务不可使用的情况,而绝大多数使用户都不记得了这一点。其实,作为IT从业人员,他们深知一个服务是由许多部件组合在一起,一个部件出现问题将影响到整个服务。因而,他们完全可以够了解服务的可使用性难以达到100%。但是当阿里云出现故障时,为什么会有那么多使用户抱怨呢?

一方面,可可以是由于使用户对高可使用服务设计的经验不足;但更主要的起因可可以是云计算服务提供商(不针对阿里云,其它云产品也相似)为了突出其产品的健壮性,很少主动提及那0.1%的服务故障,并且提示使用户针对云服务所出现的服务中断、降级在应使用级别进行相应的高可使用设计。因而,使用户盲目地过度相信云计算服务的健壮性。

如何应对可使用性“仅”99.9%的服务?

当理解云计算服务提供商如何进行服务管理后,作为使用户应该怎样应对呢?以下一份checklist希望能帮到你。

  1. 通过云计算服务提供商的技术人员,全面理解将用到的服务
  2. 理解云计算服务的SLA
  3. 在系统架构过程中,考虑云服务失效的解决方法,多与云计算服务提供商的技术人员沟通,他们有很成熟的处理方案
  4. 通过自动化的工具对服务进行监控、通知、失效转移

总结

从IT服务管理的角度来看,出于对服务可靠、经济性、服务升级机会这三者的权衡,云计算服务的可使用性不可可以、也没有必要达到100%。所以,使用户在用云服务的时候,需要在业务设计、系统架构上就考虑云计算服务失效时的保障方法。其实,并不针对云计算服务,在IT系统中的每一个部件都有可可以出现失效的情况,而“Design for Failure”不失为一个企业在架构业务、系统时要时刻谨记的准则之一。

参考文献

  • 【故障说明】6月27日阿里云故障说明 - https://help.aliyun.com/noticelist/articleid/24180498.html?spm=a2c4g.789004748.n2.17.lFbKJC
  • 【异常通告】6月27日阿里云部分产品及账号登录访问异常通告 - https://help.aliyun.com/noticelist/articleid/24179443.html?spm=a2c4g.789004748.n2.18.vx5Rqo
  • OSS服务等级协议 - https://help.aliyun.com/document_detail/60175.html
  • Google SRE Embracing Risk - https://landing.google.com/sre/book/chapters/embracing-risk.html
  • Google SRE Service Level Objectives - https://landing.google.com/sre/book/chapters/service-level-objectives.html

pstrike 2018.07.10 于广州天河

【尊重版权:转载之前请先联络我】

网友评论