Transcription
欢迎来到我们的 Azure 事件回顾。我是 David Steele。我是 Sami Kubba。我们在 Azure 通信团队工作。除了在重大中断后提供书面的事件后审查外，我们现在还举办这些回顾性对话。您即将观看一段直播录像，我们在其中邀请了通过 Azure 服务运行状况受到影响的客户加入我们的专家小组进行现场问答。我们讨论了可靠性作为一种共同的责任，因此这包括我们在微软的经验教训以及为客户和合作伙伴提供的更具韧性的指导。希望您喜欢接下来的对话。太好了。今天我们要谈论的事件是 Windows 在一月份推送的一个更新，这是一个安全更新，它破坏了某些应用程序依赖的 Windows 登录提示。因此，更新并安装了此更新的客户，他们使用 Windows 应用连接到他们的 Azure 虚拟桌面或 Windows 365，他们被困在无休止的提示循环中。没有数据丢失，没有东西被泄露，用户只是被困在无休止的提示中，无法访问机器，这种情况一直持续到我们回滚设置或他们在此处进行了一些更改。没错。听起来这对客户来说是一个有影响的问题。我们很乐意就此进行一次对话。我很乐意介绍今天加入我们小组的几位工程领导者。首先是 Paul McDaniel。Paul 是我们的首席软件架构师。感谢您加入我们，Paul。在我右边是 Gustavo Catalano。Gustavo 是我们的首席软件工程经理，Paul 和 Gustavo 都来自我们的 Azure 虚拟桌面团队，所以感谢您今天加入我们。Paul，有个小问题想问你。我们为什么不从那里开始？当然。Paul，我很好奇。当我想到 Azure 虚拟桌面或 Windows 365 时，它们本质上是同一个产品吗？如果我深入研究，它们是同一个东西吗？当用户连接到它们时，它们的行为方式相同吗？所有组件看起来都一样吗？它们是不同的产品，它们如何消耗发生在这里的一些更新？好问题。它们表面上看起来是不同的产品，所以很容易混淆，但它们共享许多相同的底层。所以基本上在底层，我们有 Azure 虚拟桌面，它有远程桌面和虚拟会话主机。然后客户可以使用 Azure 虚拟桌面来管理自己的 VDI。在此之上，我们有 Microsoft 的 Windows 365 产品，它更像是 SaaS，对吧？软件即服务，或者 Microsoft 为您管理 VDI，但它们确实是层层叠加的。所以，你知道，AVD 是驱动 Windows 365 的核心基础设施，而且它们非常互补。我们围绕它添加了一些有用的功能，使其更像一个 SaaS 产品。我喜欢它底层使用的是 AVD。是的，是的，是的，但明白了。Windows 365 部分是 SaaS 产品，Microsoft 将为您处理很多事情。因为它们基本上共享相同的 VDI 基础设施，所以您有一个类似的应用程序，对吧？所以 Windows 应用用于连接两者。您可以使用 Windows 应用连接到您的 Windows 365，使用 Windows 应用连接到您的 AVD。无论旧应用程序 MSRDC，它在此次 PIR 中出现，对吧？MSRDC 也可以连接到两者，作为统一的一部分，我们正在将一切都迁移到统一的 Windows 应用，所以我们在这次 PIR 中看到了一点。好的，这很好理解。所以这基本上是这里的一些底层。那么关于更新呢？通常，对吧？人们熟悉 Windows 更新。您能帮助我们从 AVD 和 Windows 365 的角度来看待这个问题吗？更新通常如何工作？安全更新与常规更新有什么区别吗？是的，是的。这总是会影响我们，对吧？我们一直在运行服务。所以我们有一个服务，您有 Windows 365，它有一个更新系统，我们在此系统中推出常规更新和维护，我们有回滚和监控系统。在此之下，您有 Azure 虚拟桌面，我们有常规的安全部署，带有监控和回滚。然后您有 Windows，它在这里影响了我们，对吧？这是一个完全不同的领域，它也有带有监控和回滚的更新系统，所以 Windows 是这里有趣的话题。所以正如大家所知，它有一个月度发布，有“补丁星期二”，对吧？大块内容在那里出来。通常，实际上，我们使用，我们称之为 STP，安全部署。安全部署，我们已经谈过了。完美。所以 Windows 有 STP，安全问题在这里变得很有趣。所以基本上当安全问题出现时，我不知道正确的说法是什么，像是禁运，像是坏人。是的。您听说过零日攻击之类的，对吧？所以当安全更新出现时，我们非常小心，确保在有修复程序之前不披露威胁是什么。所以在那“补丁星期二”上，真的没有准备，对吧？没有人提前知道威胁的披露是什么。然后当修复程序出来时，它不会缓慢推出。大多数，对吧？“补丁星期二”是缓慢推出的。这个立即对所有人开启，因为您不希望有些人知道，哦，什么？您希望每个人都获得安全修复。Gus，也许我可以让你加入。所以当我们发布这个 KB，这个更新时，Windows 消耗了它，所以大多数 Windows 完全没有问题，但 Azure 虚拟桌面有问题。是它们消耗它的方式吗？所以再次，大多数人，如果我理解正确的话，他们会自动更新这些东西，而 Azure 虚拟桌面也自动更新这些东西，但 Windows 的行为存在差异。确实存在。所以就像 Paul 提到的，对于安全更新，它们会推送给所有人。我们不希望有些人比其他人先收到。所以最终发生的是它附带了一堆安全更新，我们特别加强了凭据 UI。凭据 UI 是自 Windows 7 以来大多数人看到的凭据 UI。它通常用于 Kerberos 等内容，而这个 KB 中的特定流程出现了一个问题，我们以前从未见过。如果他们使用 Windows 帐户管理器，即 WAM 对话框，如果您最近打开了 Teams，网页的身份验证，那就是那个的样子，大多数人都没有问题。所以很难发现这个问题，因为您必须设置一个特定的身份验证流程，然后您就会遇到问题，例如，如果您使用的是 UB Key 或回退到 Kerberos，那么您就会遇到特定问题。而且就像 Paul 提到的，我们有两个应用程序。我们有新的、闪亮的 Windows 应用，还有 MSRDC。两者之间的一个关键区别是 MSRDC 作为 MSI 部署，而 Windows 应用作为 MSIX 部署。如果您不熟悉 MSIX 技术打包技术，它运行在类似沙盒的环境中。这就是这里的关键区别，它导致了 Windows 应用与 MSRDC 的区别。明白了。所以客户，即使您使用的是 Azure 虚拟桌面或 Windows 365，如果您通过远程桌面客户端或 Web 客户端使用它，您就不会遇到该问题，但如果您使用的是 Windows 应用，因为它的打包方式，您会遇到这些凭据。正确，Windows 应用和一组特定的同步协议。那个。是的，那才是有趣的地方，因为在事件后审查中，我们说，嘿，您必须同时具备所有三个条件。必须是，如果您处理 Windows 365，您必须使用 Windows 应用，并且它必须提示您进行身份验证。您能详细说明一下第三点吗？难道不是每个人都会被提示进行身份验证吗？不。所以，如果您设置了大多数现代身份验证，比如我们最新的协议 RDSAD auth，大多数时候人们想要单点登录，对吧？他们不想坐在那里一遍又一遍地输入凭据。如果您有单点登录，它会弹出 Windows 帐户管理器，然后您甚至看不到提示，如果您登录到同一台机器，如果您在客户端机器上以同一用户身份登录，您甚至看不到该提示。它只是全程 SSO。明白了。Microsoft IT 一定很擅长这个，因为我很少被要求输入密码。正确，这实际上是使内部工作更困难的原因之一。我们使用了最新最好的无密码技术。所以内部工作更难让我们遇到这个问题。我们必须去设置一个特定的身份验证环境，其中没有启用 SSO，然后我们更有可能遇到问题。明白了。这很好。Paul，如果我可以让你加入。所以我们已经发布了这个更新，数百万、数十亿台 Windows 机器运行正常。AVD 有问题。那么我们如何处理这个更新呢？我们当时决定不回滚东西，因为正如您所说，外面有坏人，而且有一个问题，但我们引入了这个新的 KIR。您能告诉我们这是什么吗？以及为什么我们决定这样做，而不是完全回滚整个 KB？好问题，像这样的事情总是很棘手的，就像您指出的那样敏感。所以在这个案例中，我们很早就得到了信号，我们知道它是什么，就像敏感的安全性质。所以我们召集了微软的所有同事，通过其他团队，把他们都召集到一个作战室，对吧？而且由于安全的性质，我们从不告诉人们，我们给他们信息让他们自己做决定。所以我们从不告诉任何人，不要安装那个 KB，不要更新，但我们立即发布了沟通，说这个更新有问题，所以人们知道了，他们可以自己做决定。然后我们去，好吧，我们必须找到一种方法，让那些接受更新的人可以选择性地回滚。所以这就是 KIR - KIR 是什么？对吧？它是一个已知问题回滚，KIR 允许客户选择性地回滚一项。不是整个包，不是整个更新，而是回滚一项。所以在这个案例中，我们就是这样做的，我们做了 KIR。我想事件发生在星期二，对吧？补丁星期二，所以星期三早上很早，我们整夜都在工作。我们已经准备好了 KIR，所以那时客户获得了能力，KIR 基本上是一个安装包，它是专门针对您的操作系统设计的。所以它有点，你知道，特别。您必须知道您拥有哪个操作系统，您拥有哪个版本的操作系统，然后为您拥有的操作系统安装那个特定的东西。安装后，它会启用一些新的组策略，您可以打开或关闭该功能。酷，所以这不仅仅是指导，这是您应该做的，它还包括要下载的内容和必须运行的组策略命令。您必须做一些事情，是的，是的，是的。好的，但我们提前提供了指导，我们说，供您参考，这是正在发生的事情。但从那时起，事情并非一帆风顺，对吧？没有什么自动化的。对，但当我们通过我们不同的渠道发布这些指导并试图分享哪些是正确的已知问题回滚时，那里有一些沟通上的失误，对吧？所以我们分享的是错误的说明还是错误的链接，这只发送给了一些正在使用这些更新的 AVD 客户。所以如果您是客户，并且您正在通过门户网站阅读这些更新，我们发送了错误的指导或错误的链接，您能帮助我们理解吗？哦，天哪，我们很震惊，对吧？就像我说的，我们星期二整夜都在工作，我们意识到了这件事的严重性，所以我想是星期三早上 4 点。所以我们所做的是，由于其严重性，我们不确定星期二晚上哪两个修复程序我们需要回滚。而且制作 AKAR 需要很长时间，对吧？我们必须为每个操作系统构建它们，我认为我们构建了十几种不同的版本，而且我们主动构建了两个，因为我们不确定是哪个。大约在凌晨三四点，我们确定了我们需要的确切版本。但您已经看到了灾难的根源。我们有两个版本，现在是凌晨 4 点，所以另一件有趣的事情是我们谈到的所有层，对吧？我们实际上有三种沟通方式。Windows 365 通过 Microsoft 管理中心进行沟通。AVD 通过 Azure 门户进行沟通。Windows 通过其 Windows 健康消息进行沟通。明白了。所以您有三个不同的地方，您必须协调好，而我们只是有点搞砸了。我想 Windows，如果我没记错的话，Windows 健康有所有正确的链接，我认为是 Azure 门户和 Mac 只是在几个链接上搞砸了错误的部分。客户问我们发生了什么。没有什么不对或坏的，或者类似的东西。就像如果您应用了错误的链接，您就关闭了一个部分，这没关系。这没关系。它只是没有缓解您的问题。明白了。我想是星期三中午，所以也许你知道大约五个小时后，我们做得慢了一点，因为我们想仔细检查每一个链接。我们星期三早上做了一些事情，我想我们立即发布了沟通，说链接有问题，给我们一些时间。所以我们通知了人们。然后大约中午，我们做了一些沟通，说所有的链接都好了。明白了。那天我值班。我记得。我记得我们一起讨论过这件事。我知道。六个小时后，我们把修正后的版本发出来了。好的，这很好理解。所以那只是已知问题回滚的临时修复。好电话。这只是关闭了那个安全修复，甚至客户对此也有疑问。关闭这个安全吗？是的，是的，是的。这是一个临时缓解措施。对。这样做很重要，因为那个 KB 包含大量其他安全修复，对吧？我们只想关闭这个特定的修复。正确。这就是为什么我们从不回滚 KB，我们只是根据情况的变化来调整它们。正确。然后我们谈到了多种缓解措施，我在 17 日发布了一个带外更新，然后后来我们将其发布在一个新的 KB 中，或者有一个完整的更新，这样客户就不必进行选择性的外科手术式，你知道，查看所有三个因素。您能向我们介绍一下那里发生了什么，以获得更持久的缓解措施吗？正确。所以就像 Paul 所说的，我们先做了 KIR，客户部署起来非常困难。然后一旦我们收到信号说它对客户来说运行良好，我们就决定进行带外更新。他们仍然必须去 Windows 更新目录，下载正确的 KB。特别是对于托管设备，应用此方法存在一些麻烦。非托管设备？非托管设备。因为如果您有托管设备，带外更新很容易。人们可以勾选一个框，但对于非托管客户，您需要跨千台不同的自带设备进行操作，这有所不同。但我们也收到了反馈。就像即使对于托管设备来说，带外目录更新也很困难。好的。我们听到了反馈。我们听到了反馈。是的。继续。一旦我们进一步确认，是的，能够应用带外更新的人都成功了，那么在下一周的 Windows 更新中，我们通过 Windows 更新进行了一个可选更新。所以现在您不必去网站，找出哪个 KB。您只需转到 Windows 上的常规设置应用，转到 Windows 更新，查找可选更新并获取它。而在那之后的一周，在二月的“补丁星期二”，它就完全自动了，您不必做任何事情。明白了。所以这些基本上是相同的修复。更多的是关于我们如何将这些位发送给所有合适的人。酷。这很好理解。好的，所以我们遇到了这个小插曲，我们有了临时修复，我们现在已经应用了永久修复。Paul，也许这是一个很好的机会，让我们转向讨论我们的经验教训和修复，对吧？听起来我们有几个。最突出的大问题，或者我们在事件后审查中提到的第一个问题是，嘿，我们想将此场景或类似场景加入我们先进的基于 AI 的自动化事件检测系统。这样我们就可以更快地做出反应，更快地告知客户。这看起来是什么样的？正确，正确。这个问题，你知道，我们总是有优点和缺点。我们实际上，所以我们处理问题的方式是检测，对吧？检测时间，然后缓解时间，我们以此来衡量自己。我们很早就检测到了这个问题。所以我想说大约在星期二下午两三点钟，我们就知道有问题了。好的。但我们还不知道影响范围或程度，所以我们花了一些时间，我们立即参与了。直到下午 6 点左右，当我想亚洲是的时候，时区有时对您有利，有时对您不利。那时我们意识到情况更加严重。所以，你知道，我们有我们的严重性级别，所以我们增加了严重性，然后在星期二晚些时候，我们将严重性全部提高了。所以这个新的 AI 系统我们正在谈论的将帮助我们评估影响。好的。比如我们应该多快，你知道，应该更快地升级严重性。好的。所以我们正在朝着这个方向前进。我们正在将它集成到这个系统中。我们有一个很棒的，我认为它叫做 Brain。Brain 是 Azure 内部的一个很棒的 AI 系统，它能帮助我们。是的，现在我们已经将一些场景集成到 Brain 中，只是为了帮助我们检测，让我们知道有一些场景我们可以集成到 Brain 中，它们会自动通知客户。您知道我们是否能够进行自动通信，还是这步太快了？我会去查一下。我喜欢那个。我不知道。但至少我们会知道更多。我们肯定会知道。我们会触及大局。也许我们能够让客户知道。这很有帮助。酷。也许 Gus，我们正在与 Windows 团队合作，以尽早发现这些故障模式。我理解当 KB 发布时，您总会遇到一些小问题，具体取决于场景，但我们正在努力解决这个问题。我们在微软使用的一种方法叫做“狗食”，你知道，我们吃自己的“狗食”，看看效果如何。我们还没有在 AVD 上对 KB 进行“狗食”并使用它们吗？我们正在进行“狗食”。就像我之前提到的，微软采用了最新最好的安全身份验证协议，而这正是我们在这里遇到的问题，我们需要在设置方式上拥有更多样性。我们需要部署不同的租户，具有不同的配置。所以我们正在确保我们测试客户拥有的所有不同配置。我们目前在一定程度上这样做，但我们主要关注 Windows 的服务器端。历史上，回归问题最常来自那里。现在我们正在扩展我们的测试用例，确保我们涵盖我们拥有的每一个身份验证协议，包括那些显然使用密码的旧协议，因为我们希望人们走向无密码世界。听起来有很多排列组合。有很多复杂性。有很多，这需要-这是一个很大的测试领域。没关系，我们会做的，我们会做的，我们会做的。但您说得对，这就是复杂性。所以这是为了测试，以便意识到它并首先防止问题。那么当涉及到沟通时呢？因为我在事件后审查中也读到，我们说我们希望能够直接向 Windows 应用发送沟通。当我想到这一点时，等等，我们的大部分沟通都发送给管理员，他们负责管理这些 VDI 基础设施。能够告诉 Windows 应用中的用户也有帮助吗？是的，我们注意到的一件事是我们希望更早地做到，我们发布了带外更新和带有特定说明的 KIR，而用户只是收到一个神秘的错误。他们必须去联系他们的 IT 管理员，尝试向他们朗读错误代码，IT 管理员必须去查找它。我们希望能够为用户提供更清晰、更简洁的消息，说明他们需要采取哪些步骤。对，这是我们，不是您。我们知道这一点。类似的东西。是的，是的，而且希望能够更快地沟通，因为我们以前从未真正做过，所以我们花了一些时间才弄清楚，回顾性地思考，我们应该在第一天就那样做。是的，我熟悉那些带有非常长代码的错误消息，我们正在努力解决。减去 21734。（都笑了）很难查找。Paul，客户有什么可以做的吗？我的意思是，如果客户正在使用 AVD 或 Windows 365，并且他们遇到了这种情况，我现在明白了，似乎总是最好使用最新的更新，就像勾选那个框一样，这是有道理的。如果存在问题，您可以使用这些 KIR，这些已知问题回滚，这总是好的，但客户是否可以做些什么来解决它，如果他们再次遇到这些类型的问题，是否有其他方式可以进入，或者他们只是-他们必须等到我们缓解？像这样的事情很棘手。通常有一些事情您可以做，比如使用 Canary Builds，或者，你知道，预测试。这些更棘手。Gus 提到过，对吧？如果他们能够迁移到更现代的身份验证协议，他们可以做一些事情。如果他们能够采用 SSO，那都是很棒的事情。我们鼓励每个人都无密码，总的来说。我不确定还有什么。还有一件事要学，对吧？或者下次的补救措施。我们提到了一点关于托管和非托管，对吧？就像那是什么意思？在我们的世界里，在 VDI 中是不同的，因为您有会话主机，对吧？就像您的远程计算机所在的地方，但然后您有客户端，所以您在这里有两个机器，您的远程计算机通常由 IT 管理，对吧？人们喜欢这样。然后您有客户或员工，您的用户，对吧？他们自己带着设备。也许是他们家里的笔记本电脑，也许他们在咖啡馆，也许他们在别的地方，也许他们在手机上。这就是远程桌面的魅力所在。所以这些设备往往是自带的，非托管的。这就是我们陷入的困境，就像 Gus 所说的，我们非常擅长管理服务器、会话主机，但非托管设备就靠自己了。所以当我们最初使用带外目录进行此操作时，我们收到了非常响亮的反馈。带外目录几乎不可能应用于非托管设备。用户必须知道他们使用的是哪台机器，非常特定的 Windows 版本，他们必须下载一个包，他们必须运行复杂的脚本。当时我们还没有为这些非托管机器准备好现成的剧本。所以这是我们现在又一个经验教训，我们有一个新的剧本，在这种情况下，我们知道非托管设备有问题。您看到我们使用了剧本。那是两次发布。我们在星期六进行了带外更新。我想是接下来的星期六，接下来的星期二，我们使用了这个新剧本，并使用 Woo 将所有内容推送到非托管设备。所以如果再次发生什么事，我们将有一个快得多的方法。不会需要两周时间来获得缓解。很高兴看到我们如何能够更快地做出反应，并且我们可以-这对我们来说是一个很好的学习，对客户来说也是尽快采取这些措施。Gus，最后一点，因为我们之前已经提到过。就客户而言，试图首先避免陷入这种境地，我们在 PIR 中提到了单点登录或 RDSAAD auth 之类的内容。我开玩笑说，我很少被问到密码的原因是，这对客户来说是一个很好的最佳实践吗？这能避免这种情况吗？客户需要考虑权衡吗？总的来说，使用更现代的身份验证协议，我们从被攻击一次又一次的历史中学到了，现代身份验证协议是防钓鱼的。即使凭据被盗，它也是有时限的，所以您必须再问一次。您可以应用条件访问策略。它们在很多方面都更安全，而且越来越多的客户正在使用越来越现代的协议。总的来说，我们将构建新功能并使其越来越稳定，总的来说，我们建议客户应用这些。酷。好的，这很好理解。所以我们已经谈过了一些关于 Azure 虚拟桌面方面的经验教训，也许客户在如何运行他们的身份验证方面也有一些经验教训。我把最后一个问题留给了我的联合主持人 Sami，因为 Sami 负责我们的事件通信团队，我们在沟通方面做得怎么样？Paul 已经谈过了那些错误的链接和失误，但还有其他关于我们沟通的思考吗？如果我反思一下，我认为这在很多地方都很棘手。首先，正如 Paul 提到的，沟通在三个不同的地方，你知道你有 Windows 和 KB 以及关于没有回滚的东西。你有 Windows 中心，Microsoft 管理中心，然后你还有 Azure 门户。如果您生活在所有这些生态系统中，管理起来确实很棘手。通常来说，在 Azure 中，当我们遇到问题时，通常是因为 Azure 进行了更改。所以我们的检测和监控都围绕着 Azure 部分。当 Windows 进行更新时，实际上 Windows 大部分时间都很好，但 Windows 与 Azure 的交互，这是一个非常独特的情况。我们根本看不到它发生。我们花了一些时间才召集起来。现在我们确实很快地进行了沟通，但再次，我们正在争夺信息，坐下来，在战争的迷雾中，阐述这三种独特的情况必须结合起来。这不仅仅是，你知道，您无法登录，您必须使用 CredUI 加上这个，加上这个，所以我认为这真的很难。这就是为什么当我们发出沟通时，它不清楚。我们不习惯沟通不属于 Azure 但属于我们生态系统边缘的东西。我对 AI OPs 之类的东西的到来感到非常兴奋。我们的大部分中断今天都是由 Brain 自动沟通的，这太棒了。就像在高 70% 甚至 80% 的情况下，我们在 15 分钟内就能沟通到影响。所以一旦我们有了这些 SLI，并且我们能够快速沟通，我们就可以在很大程度上沟通到门户网站，而这正是客户应该获取我们沟通的地方。但当我回顾 PIR 时，尘埃落定后，就容易多了。这就像反思并说，好吧，发生了什么。我们必须始终努力做得更好，尤其是在提供细微信息方面，这可以在中断中产生巨大差异。但是的，这些将是我的一些想法。是的，很好。感谢您的反思。感谢两位今天加入我们。感谢 Paul。感谢 Gustavo。我真的很感激您能加入这些会议。最终，我们举办这些会议是为了在重大中断后重建信任。我们知道这些中断对我们的客户有多大影响，所以我们只是想出现并提供帮助，并讨论我们如何始终从中学习和改进。感谢您观看本次 Azure 事件回顾。在我们云的运行规模下，事件是不可避免的。正如微软一直在学习和改进一样，我们希望我们的客户和合作伙伴也能从中学习，并通过 Azure 良好架构框架提供大量可靠性指导。为了确保您在发生中断后收到事件后审查以及加入这些直播问答会议的邀请，请确保您已设置 Azure 服务运行状况警报。我们非常专注于尽可能透明，在这些重大事件后出现并承担责任。无论是中断、安全事件还是隐私事件，微软都在大力投资于这些事件，以确保我们赢得、保持，有时甚至重建您的信任。感谢您的加入。