Transcription
欢迎来到我们的 Azure 事件回顾。我是 David Steele。我是 Sami Kubba。我们在 Azure 通信团队工作。
除了在发生重大中断后提供书面的事后审查外，我们现在还主持这些回顾性对话。
您即将观看一个直播录像，我们在其中邀请了通过 Azure 服务健康受影响的客户加入我们的专家小组进行现场问答。
我们围绕可靠性作为共同责任进行了讨论。这包括我们在微软的经验教训，以及为客户和合作伙伴提供更具韧性的指导。
希望您喜欢接下来的对话。
太棒了，今天的重点事件是 Azure Kubernetes 服务，有时我们也称之为 AKS。这是一个问题，使用新 Ubuntu 映像的客户，该映像具有我们实际添加的安全功能，导致密码在大约 90 天后自动过期。一旦密码过期，新节点就无法启动。因此，每当客户尝试进行扩展操作或创建新操作或重启时，操作都会失败。现在，已经运行的 Kubernetes 服务没问题。缩减规模没问题，但任何新的操作都会有问题。
没错，这听起来是个大问题。这对客户来说影响很大。因此，我想介绍两位加入我们今天小组的工程领导者。在我右手边，有 Brendan Burns。Brendan 是我们 Azure 云原生和资源管理部门的公司副总裁。感谢您的到来，Brendan。我们还有 Ye Wang。Ye 是代表 AKS 的首席软件工程经理。非常好。
那么，Brendan，我们能否从您开始？微软作为一个公司，一直非常公开地表示我们如何优先考虑安全，我想知道您能否介绍一下 Kubernetes 如何看待安全，以及我们如何看待、如何采纳这些原则并将其应用于 Kubernetes 服务。
当然，我想，我学到的关于安全的第一件事是，它是一个旅程，而不是一个目的地，对吧？这意味着我们不断修改和进行更改，以提高 Kubernetes 服务和 AKS 的安全状况。这包括我们如何配置 Kubernetes，如何配置我们部署到集群中的组件，以及在这种特定情况下，如何配置运行在集群机器上的操作系统。当然，作为其中的一部分，我们咨询行业内的专家，以了解安全最佳实践是什么。这结合了我们自己的专业知识、开源社区的专业知识，以及在这种情况下，制定了操作系统安全标准的标准机构的专业知识。这一点很重要，因为安全无疑是关于保护服务，但也有许多扫描器和安全解决方案是我们的客户使用的。因此，我们希望确保我们能够匹配这些扫描器正在寻找的最佳实践，以便当他们的 CISO 查看报告时，一个我们认为安全的集群就是一个扫描器供应商也认为安全的集群。
好的，太棒了。从最初的立场来理解这一点很好。那么，Ye，也许我们请您加入。让我们快进到 1 月 22 日开始的事件本身。客户当时感觉如何？Sami 给了我们一个简短的概述，但客户会有什么感觉？他们会遇到什么？他们会看到什么错误或症状，他们一开始会知道原因吗？
在事件发生当天，客户在他们的 AKS 集群的扩展操作上会失败，这意味着他们无法将新节点添加到他们的集群中。因此，如果他们在那段时间流量很大，他们就无法分流这些流量，然后可能会看到应用程序失败。然后，我们最初只是通过一个客户向我们报告此事件来检测到这个问题，与此同时，我们已经检测到扩展操作的服务质量有所下降。然后我们分析了问题，发现这是由于 VHD 上的密码过期问题引起的，该问题由自定义脚本扩展程序运行。然后我们立即着手修复我们提供 CSE 脚本的服务，然后通过脚本化密码的过期。然后，对于任何试图创建新代理池的客户，都将解除此问题的阻碍。
明白了，这就是我们如何缓解它。我认为，Brendan，我们快进到我们是如何首先破坏它的，对吧？就像您提到 CIS 和行业标准一样。我们认为这个密码过期功能听起来是个好主意。也许我们没有完全理解它会带来的影响。
当然，我认为有两个方面。一个是 CIS 和其他标准基本上是清单，对吧？因此，当您浏览它时，您只是逐项检查清单，并确保所有这些都应用于我们的映像，并且我们一直在这样做，以改进运行 CIS 扫描器在我们的机器上的报告。在这种特定情况下，其中一项是说，“嘿，root 密码，也就是机器上管理员用户的密码，应该在一段时间后过期。”这是为了增加凭据被泄露的难度，以及诸如，如果它们被泄露，它们将在某个时间点被轮换。我认为我们没有necessarily 考虑到的是，如果该用户被用作机器设置的一部分，而事实证明，它实际上被用作机器启动和设置的一部分。因此，导致失败的不是密码过期本身。而是密码过期与以该用户身份尝试执行的操作相结合，然后由于密码已过期而失败。因此，我认为我们既没有necessarily 考虑到安全加固试图实现的具体目标，因为实际上，CIS 标准本身已经随着时间而改变了。但我们也未能理解我们有一个脚本与此 root 用户之间的依赖关系，而这最终导致了问题。
太棒了。当您描述检测方式等时，听起来非常巧妙。战争的迷雾已经散去，但听到它的内容，这是一系列独特的事情必须对齐。我们检测到了，您说我们没有检测到，但我们知道客户提出了问题。我们如何回溯并追溯到他们从 90 天前应用的一个更新？然后我们如何缓解这样的事情？就像看看我们整体的响应，我们该如何处理，当一切都未知的时候？
是的，我们实际上查看了客户失败的操作，然后我们获得了具体的错误消息，例如，root 账户的密码已过期。然后我们将所有当前的失败消息关联起来，所有这些都指向一个特定的 VHD 版本，该版本已被发布。然后我们回溯到该 VHD 版本的特定发布，然后我们发现我们包含了一个新的更改，即添加了密码过期日期。这就是我们如何找出问题所在。然后，关于我们如何为客户修复，我们立即着手修复为集群提供脚本的服务，然后我们只是删除了密码的过期日期。因此，例如，一旦客户的集群获得此新脚本的更新，他们的问题就会消失，然后他们的扩展操作将立即解除阻塞。这就是为什么我们最初与客户进行沟通，并说，对于那些想立即进行缓解并解决问题的客户，他们可以启动节点映像升级，然后升级他们的脚本，这样他们就可以立即解决问题。但仍有一些客户受到影响，但他们当时并没有立即采取行动。因此，他们现有的操作不受影响。因此，他们将来可能会受到影响，他们并不 really 渴望在那时进行繁重的节点映像升级。因此，他们指示我们，例如，你们是否有任何其他替代方法来缓解未来影响？这就是我们从服务方面着手的地方。然后我们正在对我们的服务进行热修复，以提供替代的缓解措施，我们可以直接从服务器端将此修复程序应用于客户的集群，而无需客户干预。
好的，所以他们不是在用完路，但他们可能在 5、6、7、8 天后用完，那时——
确切地。
好的。
所以这是我想要稍微深入探讨一下的分歧，因为我们基本上提供了这个作为问题期间的临时解决方案。我们告诉客户，“如果您需要这样做，这里是如何做的。”但我认为有些客户有点困惑，因为我们缓解了问题，然后又重新激活了它。我只是想理解，这是因为我们通过向客户解释如何解除阻塞来缓解了它。
是的。
然后我们重新激活了它，然后又看了一遍，并决定我们可以代表他们自己修复它。
正是如此。然后我认为这还取决于客户当时的实际需求，因为有些客户，例如，对于最初向我们报告事件的客户，他们面临着立即向其集群扩展新资源的压力。所以他们正在寻找的是立即缓解。这就是为什么我们提供，例如，热修复 CSE 脚本服务，然后为客户提供指导，如果您现在正在进行节点映像升级，您的问题就会解决。然后，您可以立即扩展新节点。但还有其他客户，他们并不面临立即的危险，例如，遇到问题，但他们有成千上万个集群需要管理。因此，客户在每个集群上进行节点映像升级，然后在例如下周内，这是不合理的。因此，我们正在接受客户的反馈，然后我们正在从服务器端着手，以便在无需客户干预的情况下为客户修复。
是的，我认为这突显了一个我们并不总是谈论的非常有趣的事情，那就是我们认为一次中断就像状态页面上的一个绿点或一个红点，对吧？这是非常二元的。我认为在这种情况下，我们说明了这样一个事实，即，显然，如果客户受到影响，那就是一次中断。显然，如果他们试图运行的服务无法正常工作，那就是一次中断，对吧？但如果他们可能在三天内受到影响，那是在状态页面上的红点吗？那是在状态页面上的绿点吗？我们希望有快速的事件响应，所以我们希望我们这边宣布一次中断，因为我们知道可能存在问题，我们需要 24/7 工作直到有解决方案。这是否意味着我们将其重新标记为已激活？很难说。我认为您至少应该与客户沟通，告诉他们，“嘿，那里潜藏着危险。我们将采取行动来尝试修复它，”以便他们了解潜在的风险。但我认为这表明中断的概念不一定是这种绿色或红色的东西，而是一个连续体。
当我们思考从这次中断中学到的东西时，我们能够提供一次性的解决方案，说，“嘿，这就是如何摆脱困境”，这很好。您提到了客户，这对少数几个客户来说很好。如果我有成千上万个客户，并且我需要大规模部署和策略，我将依赖微软来做到这一点。我们是否从 AKS 中学到了更广泛的关于如何再次缓解此类事情的经验？这些事情是常见的，还是不常见的？我们是否依赖其他映像或 CIS 的规则？我们是如何管理所有这些学习并大规模应用我们的策略的？
嗯，我认为我想要分享的一个学习是，我认为这需要客户基本上向我们抱怨，“嘿，我无法大规模地做到这一点”，我们才开始进行大规模解决方案，对吧？所以我认为未来要吸取的教训之一是，我们可能应该始终同时进行。让我们尽快向受影响的客户提供缓解说明，但同时也要转向大规模解决方案。我认为这很复杂，我们将在最后稍微介绍一下，但事实是，如果您启用了节点自动升级，我们就无需采取行动。我们就无需采取行动。我们就无需在幕后进行热修复和缓解。因此，在某种程度上，我们建议每个人都应该启用自动升级。因此，我们正在进行特殊的带外、非正常活动，为那些想要我们修复的人进行热修复，但总的来说，他们不希望我们自动升级他们的节点。因此，这里有一些有趣的细微差别，我们正在学习。
一个快速的后续问题。我知道在 IT 领域，一切都有权衡。有哪些权衡？为什么客户不想使用自动升级？我的意思是，您已经向我推销了。说这很棒，这听起来像一个解决方案，但人们选择退出，为什么？
当然。因为事实是，当然，偶尔，我们尽量让这种情况尽可能罕见，而且显然，目标是永远不要发生，但偶尔，操作系统升级会让你崩溃。
好的。
对吧？也许是因为它包含了一个新的内核，而那个内核有一个 bug。也许是因为它包含了一个新版本的命令行工具，而您调用的标志发生了微妙的变化，对吧？在我从事这个行业的过程中，我见过很多这样的情况。这是一个补丁更新，从 0.0 到 0.1。就像字面上什么都没有改变，哎呀，我们把一切都搞砸了。
好的，在这种情况下它会救您，但有时它会毁了您。
对，所以我认为争论是，总的来说，自动升级会比它破坏您更多次地修复您。但有些人很偏执，或者我应该说不是偏执，而是有判断力，但他们有不同的观点，并且想要掌控一切。其中一部分也是掌控一切的部分。我想知道升级正在发生。我想在升级过程中密切关注我的系统。当然，我们提供维护窗口等服务来帮助提供自动升级以及您知道它即将发生的能力。但仍然有人想要掌控一切。但我认为随着时间的推移，随着我们进行更多的自动升级，随着人们对自动升级的信心越来越高，人们会更愿意勾选那个框。然后当然，当人们看到像安全更新这样的繁琐工作时。
是的。
对吧？就像自动升级消除了这种繁琐的工作。所以人们还可以从系统中获得其他权衡和优势。
而且，还有一些其他合法的理由让客户选择不选择自动升级。在某些罕见的情况下，一些客户运行的特定应用程序对节点映像有特殊依赖。然后，例如，特别是当 Kubernetes 版本升级或某些版本的节点映像从一个内核升级到另一个新内核版本时，某些依赖项可能会发生变化。然后一些客户可能会面临风险，例如，当依赖项发生变化时，他们的应用程序将以不同的方式运行。因此，对于这些客户，他们将需要大量的测试周期才能进行升级，然后才能进入下一个新版本。因此，他们无法接受，例如，我们自动为他们升级 Kubernetes 版本或节点映像。所以这是另一个，例如，许多客户选择退出自动升级的主要原因。
是的，很高兴了解我们讨论了各种选项，具体取决于客户，取决于场景，这里是相关的优缺点。而且，Brendan，我喜欢您谈论我们的学习和修复，关于我们是否提供临时解决方案，我们是否自己修复它？但这两者都是被动的，对吧？那是问题出现之后。我敢肯定，很多观看并对我们的学习和修复感兴趣的客户都想从中吸取教训，那就是我们如何才能避免首先陷入这种情况？我们如何才能避免进行密码过期这样的更改，并避免首先破坏人们？这是一个更难的问题。
是的，我认为在这种特定情况下，这是一个更难的问题，因为如果我们引入了一个故障并且它立即导致了故障，那是一回事，对吧？我们有安全的部署。我们有一系列的测试。我认为，在这一点上，我很有信心，如果我们破坏了扩展并且立即导致了故障，我们内置的测试就会发现它，对吧？但显然，我们的客户期望我们快速推出升级，对吧？因此，如果我们等待并进行了 90 天的压力测试，以等待这个密码过期，以找出它是否已损坏，这意味着我们 90 天都不会发布安全更新。这意味着我们不会，所以存在着您等待多久才能发现问题以及您能多快推出新软件之间的张力。因此，在这种情况下，当原因和结果之间存在滞后时，可能很难检查。现在，实际上，还有另一个方面，那就是我们不了解存在依赖关系，对吧？所以我们不了解这个 root 用户和特定脚本之间存在依赖关系。我认为实际上我们可能假设不存在。因此，有时，我们学到的一个教训是，我们需要将这些假设编码并写下来，并弄清楚我们正在做的事情是否与我们正在操作的假设相符。因此，我认为这是另一个很好的学习机会，那就是能够审计并说，例如，我们正在使用的用户是谁，对吧？我们正在做什么系统，这可能有助于抓住这个问题？而且在检测方面，我认为我们应该，正如您所说，继续努力进行异常检测，并尝试找出相关性，在这种特定情况下，这是一种基于日期的相关性。如果我们能看到，嘿，在这个特定日期创建的集群，扩展的失败率突然是 100%，对吧？这是一个非常强的信号，我们可以使用。但当然，您可以尝试关联的维度太多了。理解起来有点棘手。
我真的很想谈谈这一点，因为在中断之后，我们经常听到工程师说，“我们将改进监控。我们将添加这类监控。”但它带来了很多噪音，也带来了很多负担。而且我认为，根据我所学到的，我们创建强大的 SLI 并实现自动回滚或自动缓解的方法是获得清晰的信号。但当我们添加监控时，获得信号与噪声比是很困难的。然后听到这些必须与 90 天内的特定映像和扩展等相结合的独特情况，当然，与与此同时进行的各种部署相关联，您如何平衡信号和噪声？
嗯，我认为有趣的是，例如，我们不应该再添加任何监控了。
好的。
对吧？我们已经有了监控。我们监控扩展的服务质量。我们需要的是，或者会找到东西的是相关性，它将从，嘿，扩展的服务质量下降了 0.1，或者服务略有下降，因为如果您查看进行扩展的广大客户，失败的数字非常小。然后有效地将受众缩小到，正如我之前提到的，嘿，所有在 90 天前创建的集群，如果您查看它们的扩展成本，它是零，对吧？那么您如何找出如何对人们进行分组呢？在某种程度上，这是一个相当奇怪的群体，对吧？就像所有在特定日期创建的集群。我的意思是，这不一定是一个特定的客户，也不是一种特定的硬件。就像许多其他可能导致其他问题的维度都不是这样。因此，您如何拥有一个可以发现这些事物的自动化系统，或者您如何拥有一个列表，例如，如果我们这样切分，失败率是多少？如果我们这样切分，失败率是多少？这就是必需的。但正如我所提到的，安全是一个旅程，我认为异常检测和此类异常检测系统也是一个旅程。因此，我们一直在努力，同时也在与专注于广泛异常检测的中心化团队合作，以提高他们发现隐藏在噪声中的这种信号的能力。
很高兴了解不同的切分方式。当然，我们不是在谈论人类与表格的交互。我们有 AI 来帮助我们分析一些信号。
当然，是的，确切地。
我喜欢一开始您谈论 CIS 和标准以及我们如何朝着这个方向努力。但根据这次谈话，听起来您是在说我们没有完全或彻底理解它带来的影响。
对。
不一定是我们对正确的前进方向有分歧。CIS 在“什么看起来好”方面是否有任何演变？
是的，我认为，我的意思是，我们不会有分歧。我们不反对密码过期这个想法，我们不认为这是一个破坏性的改变，对吧？虽然我也想说，在最近版本的 CIS 中，我们看到他们更关注意图。有时这些标准非常具体。而他们试图实现的目标是隐藏的。
当然。
对吧？他们试图实现的是，如果您的 root 密码被泄露，影响会持续多久，对吧？但他们没有写下来。他们写的是在某个时间段内密码过期。因此，实际上，在这种特定情况下，他们现在已经放宽了指导，并回到了我们之前的位置，即如果 root 没有密码，没有人可以登录 root，就这么简单。而这实际上是一个更安全的地方。因此，我认为这是其中的一部分。但同样，我认为值得理解的是，即使进行了这次密码过期更改，如果我们没有一个依赖于该用户的脚本，我们就不会破坏任何人，对吧？因此，这真的是，我认为密码过期响应 CIS 基准是原因。
（发言者）或者至少是触发条件。
触发器，对吧？但原因是这个我们不了解的依赖关系。我认为这是值得理解的部分，以便将来，我认为，老实说，我经历过的每一次中断，我都觉得我们真正试图理解的是我们不知道的这些依赖关系，对吧？几乎每一次中断，我总是告诉人们，例如，没有人早上醒来然后说，“我今天要推出一次中断。”它来自于您不了解的连接，您没有考虑到的依赖关系，以及一个更改。它不可能在这里产生影响，但它确实产生了。
是的，是的，说得好。这真的很酷。我的意思是，我觉得我们已经涵盖了许多不同的领域，从 AKS 到理解不同的架构组件。客户沟通方面怎么样？我们做得怎么样？我们是否在停机期间让客户及时了解情况？所以当这种情况发生时，需要一点时间。需要客户提出问题，我们才能采取行动。因此，第一次沟通花了大约两个小时。现在，正如您所暗示的，谁会受到影响？明天、一天后、一周后会受到影响的人。因此，与正确范围的人沟通需要一点时间。此外，由于我们遇到的那种通过临时解决方案缓解的问题，然后又重新激活它，然后又这样做，这对客户来说有点断断续续。我认为总的来说，很多时候，当客户遇到这些控制平面问题时，很多时候我们有 BRAiN，它有我们的 AIOps 系统与客户沟通。因此，客户会尝试创建或扩展资源。他们会收到一条消息说，“嘿，这是 Azure 的问题，不是您的问题。”您不需要去更改您的配置、您的 ARM 模板或任何类似的东西。这是我们的责任。但我们在查看，我们没有日期，但我们在查看，而不是客户操作失败，然后在 5、10、15 分钟后通过 Azure 服务健康收到沟通，为什么我们不能向客户展示错误消息中的问题？因此，而不是 ARM 说，“X 百个错误”，我们可以说，“这是我们的问题，不是您的问题。我们可以在其中提供临时解决方案。”同样，与 ARM 团队有一些工作要做，以便能够发送这些消息并能够编辑它们，以便客户能够实时收到它们。但当我们展望未来时，我们今天进行沟通的方式，特别是对于控制平面，我认为对于许多客户来说，遇到错误然后事后才被告知他们遇到了错误是没有帮助的。有时我们想广泛传播，我认为这是一个很好的时机来说，“嘿，一两天后，您可能会遇到错误。这里有一个临时解决方案。我们正在努力进行长期缓解。”但对于大多数控制平面中断，我们真的想达到即时故障。
感谢您观看本次 Azure 事件回顾。
在我们云运行的规模上，中断是不可避免的。
正如微软一直在学习和改进一样，我们希望我们的客户和合作伙伴也能从中学习，并通过 Azure Well-Architected Framework 提供大量可靠性指导。
为确保您在发生中断后收到事后审查以及受邀参加这些直播问答会议，请确保您已设置 Azure 服务健康警报。
我们非常专注于尽可能透明，并在这些重大事件后出现并承担责任。
无论是中断、安全事件还是隐私事件，微软都在这些事件上进行大量投资，以确保我们赢得、维持，有时甚至重建您的信任。感谢您的参与。