云服务的故障很严重。故障期间和故障之后的服务中断让事情变得更糟糕。微软的高管们对此非常了解,并且计划改进该公司处理Azure故障的沟通方式。
我注意到微软已经越来越少地使用Azure状态页面来通知用户云服务故障,这种情况已经持续了一段时间了。早在今年三月份,美国东部地区出现了几个小时的故障——这是微软最活跃的区域之一,状态页面上就没有关于此次故障的消息——而推特上对此事的抗议和吐槽也很少(这是云服务故障的另一个重要的晴雨表)。
事实证明,这种安静是设计的结果。微软一直在努力让其云用户进入其个性化的Service Health页面,而不是面向公众的Azure状态网站。而且,该公司在推特上的Azure支持帐户一直在尝试引导用户查看这些页面,并且/或者在用户需要有关故障的最新信息时直接向该帐户发送消息。 (说服用户摆脱推特的束缚也有利于让我们这些令人讨厌的记者更难跟踪故障的情况,从而减少了“Azure故障”标题出现的数量。)
在本周的博客中,负责Azure故障沟通流程的首席项目经理Sami Kubba介绍了微软目前的状况以及该公司在故障沟通方面的一些打算。他的帖子是微软一系列文章的一部分,这个系列的文章介绍了微软努力改进Azure可靠性、性能等工作采取的一些措施和方法。
他指出,微软的目标是在故障出现的15分钟之内,通知所有受到影响的Azure订阅用户。微软使用人类和自动通知机制来完成这项工作。他表示,通过服务运行状况(Service Health)发出的自动通知在上季度微软故障沟通量中已经占到了总量的一半以上。Kubba表示,微软的目标是继续减少公司通知用户故障的时间。
他补充表示:“扩展我们对基于人工智能的操作以自动识别相关受影响的服务,并且在问题得到解决之后,尽快发送解决方案消息,我们目前还处在这个进程的早期阶段。”
Kubba承认,微软目前只通过公共Azure状态页面来通告“广泛的”故障——这意味着影响了多个区域和/或服务的故障。微软通过Service Health直接与受影响的客户进行内部沟通,并用这种方式解决了目前95%的故障。Kubba表示之所以会有这么高的比例,主要是因为绝大多数故障只会影响很小一部分订阅用户。
Azure Service Health是一套体验,可为Azure服务问题提供个性化指导和支持,包括故障甚至是计划内的维护。AzureService Health由Azure状态、Service Health服务和Resource Health组成。
Kubba表示,微软正在努力在该公司其他的云产品(包括Microsoft 365和Power Platform)中推广这种故障通告系统,从而使之保持一致。客户目前已经可以在推特上看到M365状态帐户,它将用户引导到该公司的门户,并在故障出现时直接将消息发送到那里。
正如我过去所指出的,此系统适用于管理员以及具有管理员访问权限的云帐户用户。但是,在故障出现的时候,除非IT部门在内部向用户发出通告,否则仍然会有很多用户会到推特上发问,看看是否有其他人也遇到了同样的情况,并且询问Office 365故障到底是何时发生的之类的问题。
Kubba确实表示过,在比较小的故障之后,客户可以要求事后报告(比较大的故障将有公开的执行报告),他表示该团队一直努力使事情变得更加透明,并且向用户展示微软为了解决与当前故障同类型的问题会采取的具体步骤。
好文章,需要你的鼓励
英特尔携手戴尔以及零克云,通过打造“工作站-AI PC-云端”的协同生态,大幅缩短AI部署流程,助力企业快速实现从想法验证到规模化落地。
意大利ISTI研究院推出Patch-ioner零样本图像描述框架,突破传统局限实现任意区域精确描述。系统将图像拆分为小块,通过智能组合生成从单块到整图的统一描述,无需区域标注数据。创新引入轨迹描述任务,用户可用鼠标画线获得对应区域描述。在四大评测任务中全面超越现有方法,为人机交互开辟新模式。
阿联酋阿布扎比人工智能大学发布全新PAN世界模型,超越传统大语言模型局限。该模型具备通用性、交互性和长期一致性,能深度理解几何和物理规律,通过"物理推理"学习真实世界材料行为。PAN采用生成潜在预测架构,可模拟数千个因果一致步骤,支持分支操作模拟多种可能未来。预计12月初公开发布,有望为机器人、自动驾驶等领域提供低成本合成数据生成。
MIT研究团队发现,AI系统无需严格配对的多模态数据也能显著提升性能。他们开发的UML框架通过参数共享让AI从图像、文本、音频等不同类型数据中学习,即使这些数据间没有直接对应关系。实验显示这种方法在图像分类、音频识别等任务上都超越了单模态系统,并能自发发展出跨模态理解能力,为未来AI应用开辟了新路径。