云服务一直在变化，无论是添加新功能还是修复错误和安全漏洞;这是与本地软件相比的一大优势。但是，每个更改也是引入错误和回归的机会，这些错误和回归是可靠性问题和云停机的主要原因。为了避免此类问题，Azure 使用安全部署过程分阶段推出更新，在逐渐变大的基础结构环上运行更新，并使用持续的、AI 支持的监视来检测在开发和测试期间遗漏的任何问题。
请参见：招聘工具包：云工程师（TechRepublic Premium）当微软去年推出Chaos Studio服务来测试工作负载如何应对意外故障时，Azure首席技术官Mark Russinovich解释了安全部署过程。"作为安全部署的一部分，我们通过金丝雀群集，这是一个内部 Azure 区域，我们在其中进行了综合测试，并且我们有内部工作负荷，这些工作负荷在服务发布之前对其进行了实际测试。这是新服务更新代码达到的第一个生产环境，因此我们希望确保在将其移出并实际接触客户之前，我们可以对其进行验证并对其质量有一个很好的了解。
在金丝雀区域之后，代码将部署到试点区域，然后是使用率较低的区域，然后是使用率较高的区域，然后逐步部署到所有 Azure 区域（这些区域在地理上分组为成对，更新首先转到每对中的一个区域，然后再转到另一个区域）。在整个部署过程中，他解释说，"我们让AIOps监控一切以寻找回归。
AIOps（使用大数据、机器学习和可视化来自动执行 IT 操作的技术）可以检测开发人员通过调试代码无法发现的问题，因为它们可能是由依赖项或交互引起的，这些依赖项或交互仅在代码处于实时状态并与其他 Azure 服务结合使用时才会发挥作用。
部署不当可能会使 VM 崩溃、速度变慢、预配速度变慢或停止通信，或者可能会影响监控代理、存储、遥测或控制平面上的操作;但这些问题也可能是由硬件故障、临时网络问题或服务 API 中的超时引起的，而回滚最新部署无法修复这些问题。Azure 上每天有数百个部署，大多数部署面向数百或数千个群集，所有这些群集都必须进行监视，并且部署可能需要很长时间（从 10 分钟到 18 小时不等）。在200多个数据中心和60多个区域中运行着数千个组件，当内存泄漏等问题可能在几天内不会出现，或者可能在许多集群中显示为非常微妙的问题，从而在整个区域中累积成重大问题时，人类操作员很难确切地找出导致特定问题的更改， 特别是如果它们是由与其他组件或服务的交互引起的。
微软使用的AIOps系统名为Gandalf，"从长远来看，它会观察新版本中的部署和健康信号，并找到相关性，即使它们并不明显，"微软说。Gandalf 会查看性能数据（包括 CPU 和内存使用情况）、故障信号（如操作系统崩溃、节点故障和 VM 重启以及控制平面中的 API 调用失败），并从跟踪故障的其他 Azure 服务中获取信息，以发现问题并将其追溯到特定部署。
它知道部署何时发生，并查看故障会影响多少节点、群集和客户，以建议新代码是否可以安全地在 Azure 中推出，或者是否应该阻止它，因为它会在 Canary 区域中引起问题，从而导致生产中的重大问题。
Gandalf 在 Azure 数据资源管理器（也称为 Kusto）中捕获每次部署前后一小时的故障信息作为流数据，这是为快速分析而设计的：Gandalf 通常需要大约五分钟才能做出有关部署的决定。它还会在部署后 30 天内跟踪系统行为，以发现长期问题（这些决策大约需要三个小时）。
SEE：iCloud vs. OneDrive：哪一个最适合Mac，iPad和iPhone用户？（免费 PDF）（TechRepublic）
这并不是微软用来使Azure更具弹性的唯一技术。"由新的回归有效载荷引起的内存泄漏将被甘道夫阻止。同时，我们有一个弹性机制来自动缓解已部署的节点，并出现泄漏问题，例如，如果没有客户工作负载，则重新启动节点，或者如果节点不为空，则实时迁移正在运行的虚拟机。
"AIOps有利于检测自然发生的模式，并根据历史数据和训练进行关联，"微软表示。它发现的问题是新的部署有效负载，但还有其他问题，例如 Azure 使用其他技术（如混沌测试）来查找的零错误。"零日错误可能由很少发生的工作负载触发，在以前的版本和新版本中都表现出来，并且是随机发生的，或者与新部署没有很强的相关性。混沌测试可以通过随机引入故障并测试系统按预期保持状态来捕获此类错误。
Gandalf 已经运行了近四年，最初是针对一些关键的 Azure 基础结构组件，阻止了原本会导致严重故障的部署。它现在涵盖了更多的Azure组件，包括热修补Azure主机;"我们正在为Azure主机资源运行状况创建整体监控解决方案，并阻止导致内存，磁盘空间等主机资源泄漏的推出，"微软表示。
"我们正在构建智能，以便在将组件部署到生产环境之前，使用 AIOps 来控制 Azure 基础结构组件的新版本的质量。关键思想是构建一个预生产环境，该环境可以为代表性的客户工作负载运行 A/B 测试。此预生产环境还具有生产环境中设置（硬件、VM SKU 等）的良好表示形式。该系统从甘道夫那里获得反馈，因此在启动时将避免在生产环境中捕获的类似问题。
甘道夫现在看到了更多的信号。"我们已经开始探索将整个 Azure 堆栈中的信号关联起来的想法，从数据中心（[如]温度、湿度）、硬件、主机环境到客户体验。而且，在关联故障方面，它变得越来越智能。"我们正在努力提高影响关键任务客户或高成本服务的故障的权重，"一位发言人说。
它还应用于对 Azure 中的设置以及组成服务的组件所做的更改。"除了有效载荷部署安全之外，我们还在构建智能，以使生产中的任何更改（设置）安全。
面向企业的 AIOps
甘道夫是微软保护Azure的一部分，与其他内部工具（如混沌工程）一样，该公司正在考虑将其中一些AIOps部署技术打包为服务，以保护客户工作负载。
Russinovich指出，Microsoft Defender for Cloud（以前称为Azure Security Center）和Sentinel cloud SIEM已经使用类似的机器学习技术进行安全保护。"AIOps在那里有效地运行，以查看数据并确定发生事件的位置。[方式]我们一直在使用AIOps查看Azure内部的遥测数据，以了解某个地方的硬件或软件是否存在回归或事件，这些都会出现在支持我们获得的监视数据的服务中，例如Azure Monitor，"他建议。
微软已经拥有与自己的内部服务以相同规模运营的Azure客户，大型组织已经在使用AIOps工具来管理自己的基础架构，因此为他们提供这些工具以在云规模上可靠地工作是有意义的。
评论专区