ICSE 是软件工程领域公认的权威国际学术顶会。自1975年创办以来，ICSE 大会持续为研究人员和相关从业者输送着软件工程领域中最新的理论创新、技术趋势与研究成果。本届 ICSE 大会接受了多篇来自微软亚洲研究院的成果，在云计算高速发展的当下，更需要研究员们不断深耕，发掘研究洞见，为云平台的高质量运行保驾护航。

Aegis: 云平台跨层跨组件的故障定位和归因系统

论文链接：https://www.microsoft.com/en-us/research/publication/aegis-attribution-of-control-plane-change-impact-across-layers-and-components-for-cloud-systems/

随着云计算的普及，云管理系统的控制平台变得愈发复杂并难以维护。控制平台需要时常更新软件版本（Rollout）来矫错提效，但这些 Rollout 的故障可能会带来严重影响。

为了避免事故，每个团队都会制定安全部署规则，并部署监控点以捕捉和定位异常。但目前监控点的定位缺少跨组件分析的能力，这导致了定位存在诸多盲点。要想实现跨组件分析，就需要克服高并发、领域知识缺乏等挑战，由于控制平台的 Rollout 处于云系统的不同逻辑层次，因此不能直接应用现有的系统异常定位方法。

为此，微软亚洲研究院的研究员们提出了一个端到端的 Rollout 故障定位和归因系统 Aegis，用以保障控制平台的平稳运行。Aegis 能够在不同计算层和服务组件上测量可靠性和延迟信号, 并将检测到的异常与代码更新事件相关联，进而对该因果关系进行评估。

图1：Aegis 架构图

Aegis 的核心是领域知识驱动的分析引擎和基于反事实的因果评估引擎。在相关性方面，Aegis 利用平台结构和组件之间的领域知识以及使用自定义权重，来指定故障类型和给定组件之间的依赖程度。在评估方面，Aegis 使用反事实归因的方法，对已部署和未部署单元的影响进行量化。

Aegis 已在微软 Azure 云平台的控制平台中运行了12个月，它已捕捉到多个组件的 Rollout 故障，包括纯代码错误、更改过程中缺少二进制文件、与另一个组件的协议不兼容等。捕捉后，Aegis 可自动发送警报给对应团队，准确指明导致问题的 Rollout 版本，并通过更新回滚来解决故障。Aegis 做到了补充现有监控点，并能提供全面的控制平台视图，为微软 Azure 云平台的高质量运行做出了卓越的贡献。

CONAN: 诊断云系统中的批量故障

论文链接：

https://conf.researchr.org/details?action-call-with-get-request-type=1&19178930d84a498d8ab1bcf858b191e4action_17426506610b09119fcce5ddc36f52316bc2e6f8200=1&__ajax_runtime_request__=1&context=icse-2023&track=icse-2023-SEIP&urlKey=6&decoTitle=CONAN-Diagnosing-Batch-Failures-for-Cloud-Systems

本文探讨了云系统中常见的批量故障（Batch Failure）问题。批量故障通常由一系列相同类别的实例组成（例如 API 请求、计算节点、VM 等），且通常在短时间内发生。云系统中的批量故障可能由多种原因引起，包括软件和配置更改、停电、磁盘和网络故障等。故障诊断工程师经常会检查实例的属性、运行时信息、环境和依赖关系等上下文数据以确定故障的根本原因。上下文信息通常以键值对的形式表示，例如 Application= “APP1” 、APIVersion= “V1” 和 Node= “N1”。诊断人员往往需要比较失败实例和成功实例之间的差异，以查找有用的键值对。

研究员们提出了一个名为 CONAN 的框架，用于自动从上下文数据中搜索对比模式。CONAN 可以灵活地应用于各种云系统故障诊断场景，处理大规模数据，以及度量不同场景中模式的显著性。例如，异常实例中普遍存在但正常实例中很少存在的模式，或在故障期间延迟提高的模式。此外，CONAN 支持多种数据类型，包括表格数据和控制台日志。相比现有方法，CONAN 具有更高的灵活性和可适应性，其优势在微软 Azure 云平台和 M365 的实践中已经得到了证明，极大地节省了工程师的时间并降低了故障对服务和客户的影响。

图2：CONAN 的整体架构

TraceArk：高准确且可解释的云服务系统异常告警方案

论文链接：

https://conf.researchr.org/details/icse-2023/icse-2023-SEIP/43/TraceArk-Towards-Actionable-Performance-Anomaly-Alerting-for-Online-Service-Systems

对于如微软 Azure 云平台、M365 等拥有成千上百个微服务的大型在线服务，能够及时准确地发出性能异常警告至关重要。针对这个问题，现行的研究方案主要分为两类。一类通过设置性能指标的阈值来确定异常情况，但由于系统非常复杂且处于动态变化中，固定阈值会出现大量误报。另一类追求告警准确性的方法主要采用端到端的深度学习模型，但因其可解释性不强，在实际产品中的效果有限。虽然工程师们能够理解异常报告的逻辑，但仍需花费大量时间做出具体诊断。

为了解决以上两类问题的痛点，研究员们提出了准确性高且可解释的异常告警方法 TraceArk。由于微服务系统产生的 trace 数据（包含服务的性能指标、服务之间的调用记录等），为系统的异常检测和诊断提供了重要参考，所以 TraceArk 首先对系统的 trace 数据进行详细地实证分析，在设计性能异常评估模型时（图3中 Anomaly Feature Extractor 部分）充分考虑了 trace 的结构特点对性能指标的影响，以及实际业务场景中异常的含义，从而提取多个和异常定义相关的特征。比如除了性能指标时间序列异常，工程师们也会关注该异常对于整体服务的影响优先级，对系统影响时间更长，影响范围更大的异常更值得工程师们及时响应。其次，TraceArk 将少量工程师经验（反馈）纳入告警决策模型的学习过程（即图3 Feedback 过程），使得 TraceArk 能够适应不同场景。为提高可解释性，TraceArk 采用了经典的树模型来评估异常的严重性，从而与告警同步输出异常的判断路径，便于工程师们进一步诊断。

图3：TraceArk 的整体构架

在开源异常数据集和 M365 Exchange 真实数据集上，TraceArk 都显著优于现有 SOTA 方法，F1值分别提高了50.47%和20.34%。同时，TraceArk 已在生产环境稳定运行四个月，将原有异常告警的精确度提高了2.3倍，并为工程师们提供了可解释的告警细节。

探究变量感知的日志解析

论文链接：https://arxiv.org/abs/2304.11391

自动化日志分析是故障诊断、性能监测等软件开发维护任务的重要手段，大多数自动化日志分析技术都建立在日志解析（log parsing）这一关键的前置步骤之上。以往的日志解析技术通常致力于识别并分离日志中的动态变量和静态模板。这样的日志解析方式有助于分析和梳理系统事件之间的关系，但是对所有变量一视同仁，可能导致变量所载信息的丢失。

为了研究日志中动态变量可能记录的信息类型及其重要性，研究员们在开源日志数据集上进行了抽样分析。对各类型变量调查结果取平均后显示，认为某类变量在日志分析中通常很重要（usually important）以及在一些情况下可能重要（can be important in some situations）分别超过四成。因此，如果日志解析技术能够同时识别变量类型，就可以根据具体任务的需要，在日志解析时自动识别并保留特定类型的变量，而无需频繁设计专用的正则表达式。

基于上述研究发现，研究员们提出了一个能够识别日志中动态变量类型的日志解析方法。这项技术采用监督式学习，需要人工标记的日志作为训练数据，即针对每条训练用的日志，标记出日志中每个词的类型（如哪些词是静态模板词，哪些词是何种类型的变量）。在开源日志数据集上的验证结果显示，通过人工标记少量数据 +Bi-LSTM 的训练即能以较高的准确率进行日志解析和辨别日志变量类型，同时也在识别并抽象所有动态变量的常规日志解析任务中取得了比其他方法更高的准确率。

图4：Variable-aware log parsing 的整体架构

深度学习平台质量问题的实证研究

论文地址：https://www.microsoft.com/en-us/research/publication/an-empirical-study-on-quality-issues-of-deep-learning-platform/

在微软内部，每天都有数百名开发者和研究员使用深度学习的生产平台 Platform-X，部署如广告和机器翻译等模型的训练工作任务。图5简要说明了 Platform-X 的工作流程。Platform-X 的系统架构和作业管理与公共的深度学习平台，如 Microsoft Azure Machine Learning、Amazon SageMaker 和 Google Cloud AI 非常相似。

图5：Platform-X 总览

对于 Platform-X，其核心任务之一是在面对意外的硬件和软件故障时，依据每位用户的服务级别协议（SLA）来保障相应的服务质量。尽管采取了许多质量保证措施，但实际上许多深度学习任务依然存在无法提交、运行非常缓慢、意外挂起，甚至失败等质量问题。这些质量问题不仅影响用户体验，还影响业务生产力，也给平台支持团队带来了沉重的运营和维护负担。因此，分析 Platform-X 中出现的质量问题，包括它们的症状、根本原因和缓解措施尤为重要。

关于微软内部深度学习生产平台 Platform-X 的质量问题，微软亚洲研究院的研究员们进行了综合实证研究。在仔细分析了360个真实的平台质量问题，并调查了它们的常见症状、根本原因和缓解措施后，研究员们的主要发现包括：

（1）28.33%的质量问题是由硬件故障引起的，包含三大类：GPU 故障，网络故障与节点故障。

（2）28.33%的问题源于系统故障。包括系统缺陷、资源过载、平台维护、瞬时服务中断、资源冲突、回归，六大类。

（3）用户方面的问题包含五个类别，分别是缺陷代码、违反规定、不合适的权限、软件不兼容、误操作。其中用户缺陷代码是最大的类别占15%，很大原因是用户本地测试环境和平台环境差异造成的。

（4）平台可靠性工程师会在问题上报后第一时间进行快速缓解。通过重新提交作业，改进用户代码，操作修正，系统重配置，软件回滚，自动愈合，系统热修复等典型措施进行缓解。如果作业失效和低速是由于硬件或平台问题造成的，用户无需修改配置，平台会自动重新提交作业到一组新的计算节点上执行。

这项研究结果为改善深度学习平台的服务质量提供了有价值的指导，它从开发和维护两个方面进一步启发了有潜力的研究方向和工具研发，同时将更好地指导深度学习平台的设计和管理，减少质量问题并提高其可靠性。

基于图神经网络的深度学习模型运行时性能预测

论文地址：https://www.microsoft.com/en-us/research/publication/runtime-performance-prediction-for-deep-learning-models-with-graph-neural-network/

与众多传统软件系统一样，深度学习模型也可以通过一组超参数配置选项 (如批量大小和丢弃率) 和神经网络架构选项 (如层数) 进行灵活配置。为了搜索满足特定要求的深度学习模型的最佳配置，开发人员通常会运行（例如通过自动化机器学习工具提交）大量训练作业来探索不同的配置。不同的模型配置可能导致不同的质量属性，其中运行时性能 (例如，GPU 显存消耗和作业训练时间) 是最重要的属性之一，因为它们会直接影响模型质量和开发生产效率。不当的模型配置可能会降低运行性能，从而导致运行失败或产出不满足需求的模型。

微软亚洲研究院的研究员们认为，预测深度学习模型的运行时性能对于提高开发生产力和减少资源浪费至关重要。然而，由于混合编程范式、框架运行时内部的复杂隐藏影响因素、庞大的模型配置空间以及不同模型之间的差异，造成深度学习模型运行时性能的精确预测面临巨大挑战。

对此，研究员们提出了 DNNPerf。基于图神经网络技术， DNNPerf 能够在训练运行之前有效且精确地预测深度学习模型的运行时性能。研究员们观察到：一个深度学习模型可以被表示为一个有向无环计算图；每个节点代表一个计算操作，称为算子(如矩阵乘法)；边传递张量并指定两个节点之间的执行依赖关系；模型训练的算法执行则被表示为在这样一个计算图上的前向和后向传播迭代过程。参考深度学习框架源码，仔细确认隐藏的性能影响因素后，研究员们根据节点和边的计算语义设计了一组与运行时性能相关的高效特征。节点特征包括算子类型 (例如，卷积)、超参数、浮点运算量，以及输入/输出/权重/临时张量的大小。典型的边特征包括边类型（前向或反向传播）和传递张量的大小。目标设备的相关特征也被提取为节点或边的特征，如每秒浮点运算量（FLOPS）、显存容量和带宽。此外，通过借鉴图注意力网络和边增强图神经网络的思想，研究员们提出了一种新的基于注意力机制的点边编码器ANEE以便更好且高效地编码节点和边的运行时性能特征。DNNPerf 的预测模型有赖于收集大量运行时性能的数据进行训练。最终研究员们设计了多项实验用于来验证 DNNPerf 对深度学习模型运行时性能的预测效果、对未曾训练过的模型预测的通用性以及不同优化选项对 DNNPerf 的影响，DNNPerf 的效果优于基准模型并具有良好的通用性。

图6：DNNPerf 的工作流程

基于事故感知的云系统重复客户工单检测

论文链接：https://arxiv.org/abs/2302.09520

在云系统中，事故（incident）通常是指预期外的服务中断或者服务降级。当客户受到事故的影响时，他们通常会向云服务提供商提交工单以寻求客户支持服务。在这个过程中，云服务提供商可能会收到许多重复的工单。为了提高工单的处理效率，识别出这些重复的工单非常重要。现有的工作主要通过对比工单的语义相似性来识别重复工单。然而，在云系统中，各个服务之间的依赖关系非常复杂，当一个事故发生时，不同客户感知到的症状可能完全不同。因此，云服务提供商可能会收到大量语义不同，但实际上是由同一个事故导致的工单。所以现有的仅基于语义理解的方法，无法真正识别重复的工单。

为了解决这个问题，研究员们提出了一种事故感知（incident-aware）的重复工单检测方法 iPACK。iPACK 融合了云系统侧的告警信息和客户侧的工单信息，将重复工单检测问题转化为一个“告警-告警”和“告警-工单”的两步关联问题。对于前者，研究员们提出了事故画像的方法，通过静态关联学习和动态告警图构建的方式，将同一个事故引起的告警进行关联；对于后者，iPACK 内含注意力交互网络，将告警与其导致的工单进行关联。通过这两步关联，iPACK 能够全面地聚合由同一个事故导致的重复工单。通过微软 Azure 云平台的真实数据上的验证结果表明，iPACK 能够超越现有方法，更准确、全面地定位重复工单，助力工单处理提速增效。

图7：iPACK 整体架构图