"除了小型但常见的硬件故障之外，我们在Azure中看到的服务可靠性问题的主要原因是什么？改变。云的价值主张之一是它在不断改进，提供新的功能和特性，以及安全性和可靠性的增强。但由于平台在不断发展，变化是不可避免的。这需要一种与box产品或传统IT方法非常不同的方法来确保质量和稳定性，即进行长时间的测试，一旦部署了某个东西，就可以避免更改。这篇文章是我在7月份的博客中开始的系列文章中的第五篇，该系列文章分享了我们如何确保Azure的可靠性支持您最关键任务的工作负载的见解。今天，我们将介绍我们的安全部署实践，这就是我们如何管理变更自动化，以便所有代码和配置更新都经过明确定义的阶段，以便在回归和bug到达客户之前捕捉它们，或者，如果它们确实通过了早期阶段，则会影响尽可能少的数量。我们计算工程团队的Cristina del Amo Casado撰写了这篇文章，因为她一直在推动我们的安全部署计划 在本地运行IT系统时，您可能会尝试通过使用镀金硬件、锁定服务器机房和扔掉密钥来确保完美的可用性。从软件方面来说，它通常会阻止尽可能多的更改—避免对操作系统或应用程序应用程序应用更新，因为它们太过关键，并将用户的更改请求推后。每个人都小心地在系统周围走动，这"没人呼吸！"这种方法扼杀了系统的持续改进，有时甚至会损害那些被认为过于关键而无法定期修补的系统的安全性。正如上面提到的，这种方法不适用于像Azure这样的超大规模公共云中的变更和发布管理。考虑到部署服务更新和改进的需要，以及我们对您在安全漏洞面前迅速采取行动的承诺，更改是不可避免的，也是有益的。由于我们不能简单地避免变化，微软、我们的客户和我们的合作伙伴需要承认，变革是意料之中的，我们为此做好了计划。微软将继续努力使更新尽可能透明，并将安全地部署这些更改，如下所述。话虽如此，我们的客户和合作伙伴也应该设计为高可用性，使用平台发送的维护事件以根据需要进行调整。最后，在某些情况下，客户可以在适合其组织的时间控制启动平台更新。安全更换在考虑如何在整个Azure数据中心部署版本时，塑造我们流程的一个关键前提是假设部署的更改可能会带来未知问题，并以能够以最小影响发现所述问题的方式进行规划，并在问题出现时自动采取缓解措施。虽然开发人员可能会认为它完全无害，并保证它不会影响服务，但即使对系统进行的最小更改也会对系统的稳定性造成风险，因此这里的"更改"指的是各种新版本，它包括代码更改和配置更改。在大多数情况下，配置更改对系统行为的影响较小，但是，正如代码更改一样，没有配置更改可以避免激活潜在代码缺陷或新代码路径的风险。Azure中的团队遵循类似的流程来防止或至少最小化与更改相关的影响。首先，通过测试和集成验证，确保变更在部署开始前符合质量标准。然后在签准之后，我们以渐进的方式推出变更，并持续测量健康信号，这样我们就可以相对隔离地检测到是否存在与测试期间未出现的变更相关的任何意外影响。我们不希望一个导致问题的变化永远进入大规模生产，所以我们采取措施确保我们能够尽可能避免这种情况。逐步部署为我们提供了一个很好的机会，可以在问题造成广泛影响之前，以较小的规模（或较小的"爆炸半径"）检测问题。Azure通过一个安全部署实践（SDP）框架来实现变更自动化，该框架旨在确保所有代码和配置更改都经历特定阶段的生命周期，在这种情况下，健康指标会在检测到任何退化的情况下触发自动操作和警报。这些阶段（如下图所示）降低了软件更改对现有Azure工作负载产生负面影响的风险。这显示了我们的部署管道的简化，从左边开始，开发人员修改他们的代码，在他们自己的系统上测试代码，并将其推送到登台环境中。一般来说，这个集成环境是专门为需要一起测试其特定组件的交互的Azure服务子集而设计的。例如，计算、网络和存储等核心基础架构团队共享一个集成环境。每个团队在该环境中对软件运行合成测试和压力测试，反复迭代直到稳定，然后一旦质量结果表明给定的版本、功能或更改可以投入生产，他们就将这些更改部署到金丝雀区域。金丝雀地区我们公开称金丝雀地区为"早期更新访问计划"地区，它们实际上是成熟的Azure区域，拥有绝大多数的Azure服务。其中一个canary区域构建了可用区域，另一个没有可用区域，两个区域形成一个区域对，这样我们就可以验证数据地域复制能力。这些金丝雀区域用于全面、生产级、端到端验证和大规模场景覆盖。它们托管一些第一方服务（针对内部客户）、几个第三方服务和一小部分外部客户，我们邀请这些客户加入计划，以帮助增加所涵盖场景的丰富性和复杂性，所有这些都是为了确保金丝雀地区具有代表我们公共Azure区域的使用模式。Azure团队也会在这些环境中运行压力测试和合成测试，并定期在区域或可用区域级别执行故障注入或灾难恢复演练，以实践在现实生活中发生这种情况时将运行的检测和恢复工作流。这些练习单独或一起，试图确保软件在变更影响到Azure中广泛的客户工作负载之前具有最高质量。试验阶段一旦来自canary的结果表明没有检测到已知的问题，就可以开始逐步部署到生产，从我们称之为试验阶段开始。这个阶段使我们能够尝试改变，虽然规模相对较小，但硬件和配置更加多样化。对于核心存储服务和核心计算基础设施服务这样的软件，这一阶段尤其重要，因为它们具有硬件依赖性。例如，Azure提供了带有GPU的服务器、大内存服务器、商品服务器、多代和类型的处理器、Infiniband等等，因此这可以快速更改，并可以检测小规模测试中不会出现的问题。在这一过程中的每一步，彻底的健康监测和延长的"烘烤时间"使潜在的故障模式浮出水面，增加我们对变化的信心，同时大大降低客户的总体风险。一旦我们确定试验阶段的结果是好的，那么部署系统就可以通过允许变更逐步地扩展到越来越多的区域来进行。在部署到更广泛的Azure区域的整个过程中，部署系统努力尊重可用性区域（一个区域中只有一个可用性区域）和区域配对（每个区域与第二个区域"配对"以进行georedundant存储），因此更改首先部署到一个区域，然后部署到其对。一般来说，只有在没有负面信号出现的情况下，这些变化才会展开。安全部署实践考虑到Azure在全球的规模，整个推出过程是完全自动化的，并由策略驱动。这些声明性的策略和过程（不是开发人员）决定了软件推出的速度。政策是集中定义的，包括监控软件质量的强制性健康信号，以及上述不同阶段之间的强制"烘焙时间"。在每个阶段让软件处于不同的时间段并进行烘焙的原因是为了确保将更改暴露在该服务的全谱负载下。例如，不同的组织用户可能在早上联机，游戏客户可能在晚上联机，客户的新虚拟机（VM）或资源创建可能会在较长的时间内发生。全球服务，不能采取逐步部署到不同的集群、地区或服务环的方法，也实行与SDP一致的渐进式推出版本。这些服务遵循多阶段更新其服务实例的模型，通过azuretrafficmanager逐步将流量转移到更新的实例。如果信号是正的，随着时间的推移，会有更多的通信量偏离更新的实例，从而增加了信心，并且随着时间的推移，可以解除将部署应用于更多服务实例的障碍。当然，Azure平台还可以同时向所有Azure部署更改，以防有必要减轻极其严重的漏洞。虽然我们的安全部署政策是强制性的，但在某些紧急情况下，我们可以选择加快部署。为