在 太平洋标准时间(PST) 时间 2013 年 2 月 22 日下午 12:29，所有地区都出现了服务中断，致使客户使用 HTTPS访问Windows Azure 存储 Blob、Table和Queue时受到影响。全球范围内的可用性在 PST 时间 2013 年 2 月 23 日凌晨 00:09得到恢复。
我们就此服务中断向受影响的客户表示道歉，并主动向这些客户退回服务费用，大致措施如下。
我们特此提供有关该中断所关联的组件的详细信息、中断的根本原因、恢复过程、我们在此事件中吸取的教训，以及我们在为客户提高服务可靠性方面正在进行的工作。
Windows Azure 概述
在剖析该服务中断的细节之前，为了更好地了解事件背景，我们首先分享一下有关此事件所关联的Windows Azure 内部组件的一些信息。
Windows Azure 在全球各个数据中心和地理区域内运行许多云服务。WindowsAzure 存储作为一种云服务在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服务中断过程中，WindowsAzure 存储服务仍正常运行并为使用 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仪表板标记为绿色。
2) 完成更新
在更新证书的同时，该团队还做了通过更新的证书对存储服务进行完全更新的安排，并推广到全球。
此更新的目的是为所有存储节点提供最终且正确的目标状态，并确保系统处于稳定、正常的状态。该过程自 PST 时间 2 月 22 日夜里 23:00开始，在 PST 时间 2 月 23 日晚上 19:59按计划完成，并未影响客户的可用性 SLA。
改进服务
发生一次事件后，我们始终会花一些时间分析该事件，并寻求方式来改进工程、运营和通信过程。为了了解尽可能多的情况，我们进行了根本原因分析并分析事件的所有方面，以便为我们的客户改进平台可靠性。
该分析分为四个主要区域，审视事件生命周期的每个部分，以及在其之后的工程过程：
· 检测 – 如何快速找出失败原因并优先进行恢复
· 恢复 – 如何减少恢复时间并降低对客户的影响
· 预防– 系统如何避免、隔离故障并/或从故障中恢复
· 响应 – 如何在事件中为客户提供支持
检测
我们将扩展我们的证书过期监控，使其不仅包括机密存储，还包括生产端点，以确保证书不会在生产期间过期。
恢复
我们的恢复过程正确地发挥了作用，但我们会继续采取措施来提高部署机制的性能和可靠性。
我们将落实特定机制来执行关键的证书更新，并定期履行这些机制，以便再次发生此类事件时提供更快的响应。
预防
我们将改进检测生产中部署的证书是否即将过期的过程。距离到期日期不足 3 个月的任何生产证书都将产生运行事件，并将被视为服务影响事件来对待和跟踪。
我们还将自动执行任何关联的手动过程，以便跟踪包含证书更新的内部版本服务并正确地设定优先级。在自动化项目完成之前，各团队已检查涉及证书的所有手动过程。
我们将检查我们的证书并寻找机会按服务、地区和时间来划分证书，使未捕获的过期不会造成广泛传播的全球性事件。此外，我们将继续检查系统，并解决任何单个故障点。
响应
Windows Azure 服务仪表板的多级故障转移过程按预期发挥作用，并为事件中受影响的客户提供了关键事件处理状态信息更新。在事件期间有 59 个事件处理过程相关信息的更新，但我们将继续提高我们的能力，从而为问题和更新提供准确的 ETA。
我们尽最大的努力在Windows Azure 仪表板上实时发布我们所了解的信息，并继续寻求方式来加强客户交流。
服务信用
我们认识到该服务中断对受影响的客户具有重大影响。鉴于该事件的性质和持续时间，我们将为受影响的客户主动提供 SLA 信用。信用将涵盖所有受影响的服务。在发生中断期间正在运行以下受影响服务的客户，对于受影响计费周期内这些服务相关联的任何费用都将获得 25% 的服务退款。
· 存储
· 移动服务
· 服务总线
· 媒体服务
· 网站
受影响的客户还将针对任何数据传输使用收到 25% 的退款。该退款将根据我们的 SLA 计算，并反映在随后的发票中。有其他问题的客户可以联系Windows Azure 支持了解更多信息。
结论
Windows Azure 团队在未来几周内将继续检查以上概括的发现结果，并采取一切可能的措施来继续改进我们的服务。
对于该中断对客户造成的影响，我们在此表示诚挚的道歉和遗憾。我们将继续努力开展工作，提供可用性更高的服务。
-Mike
本问翻译自: http://blogs.msdn.com/b/windowsazure/archive/2013/03/01/details-of-the-february-22nd-2013-windows-azure-storage-disruption.aspx