2018年6月27日下午，网上陆续有阿里云出现故障的新闻以及评论。阿里云在该事件中迅速作出了回应，确认阿里云部分服务的确出现了故障，并已及时采取措施恢复了服务。
该事件后，在网上出现了两种不同的观点，一种观点是：阿里云的故障直接导致用户系统的中断，用户表示“很不开心，阿里云很不靠谱”；另一种观点是：早就料会有这一天，早将系统部署在不同的地方，技术性的度过了6月27日这一天。pstrike想通过本文结合阿里云故障的事件，从IT服务管理的角度探讨云计算服务管理的逻辑以及作为用户应该如何应对。
事故缘由
事故缘由引用至阿里云官方说明。
IT服务的风险管理
首先我们先把身份调整一下，假如你是云计算服务提供方（例如：阿里云）的负责人，你将怎么管理云计算服务？你可能首先会保障服务的体验，为用户提供100%可用的服务。因此，用户的系统可以完全依赖云计算服务。但是，你可能立马会反应，这不行！如果要保证服务的100%可用，需要大量的成本，这样的投入产出可能难以匹配。嗯，看来做好云计算服务的管理不是一个那么简单的话题，那应该怎么做呢？
如上文所提到，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服务管理的角度来说，该次事故应属于正常范围。
对于用户来说，一个已经定义好SLA的服务将给用户提供必要的保障。因为服务提供商将尽最大努力保障所约定的服务可用级别，如果未能达到，服务提供商将按SLA提供赔偿。下图是OSS的赔偿条款。
同时，一个已经定义好SLA的服务也意味着用户需要考虑那0.1%服务不可用的情况，而绝大多数用户都忘记了这一点。其实，作为IT从业人员，他们深知一个服务是由许多部件组合在一起，一个部件出现问题将影响到整个服务。因此，他们完全能够理解服务的可用性难以达到100%。但是当阿里云出现故障时，为什么会有那么多用户抱怨呢？
一方面，可能是因为用户对高可用服务设计的经验不足；但更主要的原因可能是云计算服务提供商（不针对阿里云，其它云产品也类似）为了突出其产品的健壮性，很少主动提及那0.1%的服务故障，并且提醒用户针对云服务所出现的服务中断、降级在应用级别进行相应的高可用设计。因此，用户盲目地过度相信云计算服务的健壮性。
如何应对可用性“仅”99.9%的服务？
当了解云计算服务提供商如何进行服务管理后，作为用户应该怎么应对呢？以下一份checklist希望可以帮到你。
- 通过云计算服务提供商的技术人员，全面了解将使用到的服务
- 了解云计算服务的SLA
- 在系统架构过程中，考虑云服务失效的处理方法，多与云计算服务提供商的技术人员沟通，他们有很成熟的解决方案
- 通过自动化的工具对服务进行监控、通知、失效转移
总结
从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 于广州天河
【尊重版权：转载之前请先联系我】
