在 太平洋标准时间(PST) 时间 2013 年 2 月 22 日下午 12:29，所有地区都出现了服务中断，致使客户使用 ">HTTPS 访问 Windows Azure 存储 Blob、Table和Queue时受到影响。全球范围内的可用性在 PST 时间 2013 年 2 月 23 日凌晨 00:09 得到恢复。
我们就此服务中断向受影响的客户表示道歉，并主动向这些客户退回服务费用，大致措施如下。
我们特此提供有关该中断所关联的组件的详细信息、中断的根本原因、恢复过程、我们在此事件中吸取的教训，以及我们在为客户提高服务可靠性方面正在进行的工作。
Windows Azure 概述
在剖析该服务中断的细节之前，为了更好地了解事件背景，我们首先分享一下有关此事件所关联的Windows Azure 内部组件的一些信息。
Windows Azure 在全球各个数据中心和地理区域内运行许多云服务。Windows Azure 存储作为一种云服务在 Windows Azure 上运行。每个地理区域包含多个物理存储服务部署，我们称之为印章。每个存储印章有多个存储节点机架。
Windows AzureFabric Controller是管理硬件的资源配置和管理层，它管理硬件, 并为 Windows Azure 平台上的云服务提供资源分配、部署和升级以及管理功能。
Windows Azure 使用称为机密存储的内部服务来安全地管理运行服务所需的证书。该内部管理服务可自动存储、分发和升级系统中的平台及客户证书。此外，该内部管理服务还可自动处理系统中的证书，避免微软员工直接访问机密信息，从而符合有关规定并确保安全性。
服务中断的根本原因分析
Windows Azure 存储使用单独的安全套接层 (SSL) 证书，为每个主要的存储类型的客户数据通信提供安全保护：Blob、Table和Queue。利用这些证书，可通过 HTTPS 对表示客户帐户的所有子域(例如myaccount.blob.core.windows.net)的流量进行加密。内部和外部服务利用这些证书来加密自/到存储系统的流量。这些证书源自机密存储，存储在每个Windows Azure 存储节点的本地存储介质，并且由Fabric Controller部署。用于 Blob、Table和Queue的证书在所有地区和印章的证书都相同。
上周使用的证书的过期时间如下所示：
*.blob.core.windows.net
PST 时间 2013 年 2 月 22 日星期五，下午 12:29:53 *.queue.core.windows.net
PST 时间 2013 年 2 月 22 日星期五，下午 12:31:22 *.table.core.windows.net PST
时间 2013 年 2 月 22 日星期五，下午 12:32:52
到达证书过期时间后，证书变为无效，使用 HTTPS 与存储服务器建立的那些连接被拒绝。自始至终，HTTP 事务仍正常运行。
尽管证书到期对客户造成了直接影响，但用于维护和监控这些证书的过程中出现中断才是根本原因。此外，由于各个地区的证书完全相同并且暂时彼此靠近，它们是存储系统的单个故障点。
存储证书未更新的原因详情
事件背景是，作为机密存储正常操作的一部分，每周都会对正在管理的证书进行扫描。提前 180 天向管理服务的团队发送提示即将过期的警报。从此时起，机密存储将向掌控该证书的团队发送通知。该团队收到通知后将更新证书，在计划用于部署的新内部版本服务中包括更新的证书，并且在机密存储的数据库中更新证书。该过程每月会对Windows Azure 中的许多服务定期执行几百次。
这一次，机密存储服务通知了Windows Azure 存储服务团队上述证书将在指定日期内过期。在 2013 年 1 月 7 日，存储团队更新了机密存储中的三个证书，并将它们包含在以后版本的服务中。但是，该团队未能将包含证书更新的版本标记为即将发布的版本。
后来，包含时间关键证书更新的存储服务版本的发布被延迟到标记为更高优先级的更新之后，并且未在证书过期截止日期之前及时部署。此外，由于已在机密存储中更新证书，因此未向团队提供其他警报，这是我们警报系统中的一个缺陷。
恢复存储服务
该事件在 PST 时间下午 12:44 通过正常监控检测到，并且诊断原因为证书已过期。截止到 PST 时间下午 13:15，工程团队已对问题进行分级并建立了多个工作流来确定恢复服务的最快路径。
在正常操作过程中，FabricController会将节点推动到所需的状态，也称为“目标状态”。
服务的服务定义会提供部署的所需状态，这会使Fabric Controller能够确定作为部署一部分的节点（服务器）的目标状态。服务定义包含角色实例及其端点、配置和失败/更新域，以及对其他项目的参考，例如代码、虚拟硬盘 (VHD)
名称、证书指纹等。
在正常操作过程中，指定服务将更新其内部版本以包括新证书，然后利用Fabric Controller通过对所有节点系统地运行更新域和部署服务来部署该服务。该过程旨在以能让外部客户体验到无缝更新并且满足发布的服务级协议 (SLA)
的方式更新软件。尽管这些工作的一部分可以并行执行，但将更新部署到全局服务的总时间需要好几个小时。
在此次 HTTPS 服务中断过程中，Windows Azure 存储服务仍正常运行并为使用 HTTP 访问其数据的客户工作，而且一些客户通过临时移至 HTTP 快速缓解了其 HTTPS 问题。在为其他用户恢复服务的过程中我们非常谨慎，以便不影响使用 HTTP 的客户。
在分析了用于恢复 HTTPS 服务的多个选项后，选择了两种方法：1) 对每个存储节点上的证书进行更新，以及 2) 完全更新存储服务。第一种方法经过优化用于尽快恢复客户服务。
1) 更新证书
开发团队完成了更新证书以验证补救方法和恢复服务所需的手动步骤。该过程由于Fabric Controller尝试将某个节点恢复为目标状态而变得复杂。在 PST 时间下午 18:22，团队制定了成功更新证书的过程并进行了测试。汲取从以前中断获得的经验，我们提前花时间对修复进行了充分的测试和验证，以避免出现影响其他服务的复杂情况或二次中断。在测试修复的过程中，发现了多个问题，并在对生产部署进行验证之前进行了更正。
验证该自动更新过程后，我们于 PST 时间 19:20 将其应用到美国西部数据中心的存储节点，并成功在 PST 时间晚上 20:50 恢复了该地区的服务。我们随后将其推广到全球的所有存储节点。该过程在 PST 时间 22:45 完成，并为大多数客户恢复了 HTTPS 服务。在 PST 时间 2013 年 2 月 23 日 00:09，其他监控和验证也已完成，并且 Azure 仪表板标记为绿色。