北京
“我们建这个系统最初的想法，就是给Azure造一个数字孪生，这样才能搞清楚云上不同资源之间到底是什么关系。”Azure CTO Mark Russinovich最近在一篇博客中这样写道。他口中的系统叫Brain，是微软内部使用的一套集中式AIOps平台，负责持续监测Azure的整体健康状态，并且在越来越多的场景里开始自主行动——宣布宕机、暂停有问题的部署、通知受影响客户。
Russinovich身兼Azure副首席信息安全官和公司技术院士，这次破例坐下来和The New Stack聊了聊Brain的来龙去脉。按照微软官方的说法，Brain是运行在Azure资源图谱（ARG）之上的一个智能层，这两者叠加在一起，构成了一个实时的Azure健康数字孪生。它可以像活体地图一样，随时反映出整朵云里各种微妙的依赖关系和故障传导路径。
有意思的是，虽然如今的Brain用上了各种机器学习算法，但这个项目其实远在生成式AI爆发之前就已经起步了。Russinovich回忆，最关键的基石就是ARG，“没有这张图谱，后面的一切智能都无从谈起。”最初的目标很纯粹：把Azure内部各种资源的拓扑关系数字化，让团队能理解每一台虚拟机、每一个服务之间的连线。很快，一些被Russinovich称为“鲸鱼客户”的超大规模用户找上门来，他们在成百上千个租户和订阅里管理着庞大的云资产，很需要一种能跨全局做简单查询的工具，比如想知道“我所有的Linux虚拟机都跑在哪些版本上”。于是，这个内部数字孪生被推向了公众，成为一项正式服务。
而Brain真正意义上的起点，其实是在图谱上做根因分析。Russinovich解释说：“很多时候你只要顺着依赖链摸过去，就会发现一堆服务其实都挂在了同一个已经出问题的下游服务上。”团队由此萌生了一个念头：能不能让Brain基于这张关系图，跑一套机器学习驱动的算法，自动去锁定故障的根因？差不多在同一时期，微软不断撞上一类令人困扰的测量偏差问题——某个服务团队自己的健康指标明明全绿，客户那边却在报障。究其原因，要么是团队压根没去量客户端的真实体验，要么就是把数据按过大的范围做了聚合，掩盖了只影响某个特定客户群的问题。
于是微软决定下一道硬标准。“我们决定统一衡量健康的方式，”Russinovich说，“于是搞出了一套服务等级指标（SLI）。”但让Azure内部各个服务团队真正通过遵守固定模式的共享库去上报这些SLI，是一项极其复杂的工程，前后花了好几年时间。Russinovich形容这个过程像“一大堆事情并行推进，最后慢慢咬合在一起”，背后是惊人的数据工程投入，以及尽可能让一切保持在自动化轨道上的持续努力。
回过头看，Brain的演化轨迹几乎就是微软对云可靠性理解不断加深的一面镜子。从一个图谱查询工具，到根因分析引擎，再到如今能够自主拍板做决策的AI中枢，它并没有取代运维人员，而是把那些需要靠人力反复交叉验证的环节，逐步交给了实时数字孪生和算法。对“鲸鱼客户”们来说，这意味着当Azure某处真的出了故障时，他们不再是最后知道的人，而是在问题被正式确认的同一刻就能收到通知，有时甚至在业务侧感知到波动之前。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
