云服务的故障很严重。故障期间和故障之后的服务中断让事情变得更糟糕。微软的高管们对此非常了解,并且计划改进该公司处理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助手隐私保护能力严重不足。研究团队构建了首个隐私意识评估基准SAPA-Bench,包含7138个真实场景。测试结果显示,即使最佳模型的隐私风险感知能力也仅达67%,多数开源模型仅30%左右。研究发现闭源模型表现优于开源模型,明确提示可显著提升隐私感知能力。
英国研究人员开发出一项名为Fastball的三分钟检测技术,通过脑电图头戴设备分析大脑对图像的识别能力,能够在认知衰退早期发现记忆问题。研究涉及107名参与者,发现该技术可有效识别轻度认知障碍患者的记忆缺陷,比现有诊断工具提前10-20年发现阿尔茨海默病征象。该技术可在家中使用,为早期干预治疗提供可能。
香港理工大学等机构研究团队发现扩散语言模型存在"早期答案收敛"现象:高达99%的问题在推理中途就已得出正确答案,却仍继续无效推理。基于此发现,团队开发了Prophet方法,通过监控AI推理信心动态决定提前停止时机,实现3.4倍推理加速且几乎不损失准确性,为AI文本生成效率优化开辟新方向。