题目背景
图1. IT系统
IT系统是各类业务及服务以及其运行的基础设施与环境的总称。图1勾勒了IT系统的大致轮廓，包括各种各样的业务和相应的服务，这些业务涉及到人民生活的衣食住行方方面面。另外，支持这些业务和服务运转的基础设施和环境也属于IT系统，包括机房的电力设备、机柜、空调等等⼀系列的设施。
图2. 服务依赖关系示意
现代的IT系统复杂性极高，大的系统会包含几⼗万的服务和节点，非常庞大。 当⼀个服务发生问题时，往往有大量的其他服务跟着出问题，我们就是要在这样纷繁复杂的系统当中确定问题发生的位置。这并不简单⸺有的复杂故障往往需要耗费非常多的精力去排查问题。
好的方面是，我们有非常丰富的对系统的监控数据可以作为发现系统故障的参考。总结起来，我们有三大类数据⸺指标、日志、追踪⸺可以用来排查系统的故障，如图3所示。
图3. 三大数据源
指标是⼀种可以最快速发现系统异常的观测数据。 因为⼀般指标数据可以非常直观地用图表的形式展示出来，很多情况下我们用肉眼就可以分辨系统当中是不是出现异常情况了。⼀旦哪个指标，就像我们图4中的绿线所展示的这样，有了⼀个突然的变化，那可能就要引起警觉了，这有可能是系统有故障的⼀个提示。那就要去详细地查看系统是不是真的有问题，这时候就用到了日志。
日志是对系统中单个节点或者说单个组件运行状态的观测记录，它是内容最为详实的单点运行记录。日志是分级别的，⼀般来说，运行的正常记录可以是info级别的日志，有⼀些问题但是还不至于影响功能的，可能会打成warning级别的日志，再严重⼀些的事件，会影响到运行和功能的，就打成error级别的日志。 日志中记录了组件的动作和提示信息，比如说数据库执行了⼀次查询操作，耗时多少毫秒；主机进行了⼀次内存清理；服务进行了⼀次业务调用结果返回的结果格式错误了等等。通过逐步去查看每个节点的日志，我们就能够⼀步⼀步定位到故障报错的具体位置。这个过程往往是很繁琐的，因为我们要逐步地顺藤摸瓜。那我们就可能需要追踪数据来辅助缩短这个过程。
追踪数据记录的是⼀次请求的完整调用过程，涉及到多个服务、多个接⼝之间的调用关系、耗时、成功与否等信息。追踪数据可以形成像左下角这张图中展示的调用关系，这样我们就能清楚地看出来，⼀个服务可能受到哪些服务的影响，哪个机器上执行的请求失败得最多，这样我们在排查问题的时候，正常的调用模式我们不用去管，只沿着有问题的调用模式顺藤摸瓜即可。这样可以减少⼀些运维⼈员查看日志的频率和数量。
传统运维发现故障的方法总结起来就是，从指标发现异常，用日志深挖故障，用追踪数据确认传播关系。这个过程循环下来，就是传统运维发现故障的手段。
图4. 指标、 日志、追踪数据长什么样子
精简版解释
当IT系统出现故障时，运维⼈员必须能够快速及时地发现故障，并对故障进行应急响应或修复。单⼀数据源 (指标，日志，追踪) 中往往无法提取到充分的特征来判定故障，从而导致对故障的漏报或误报。IT系统多源数据故障发现，是指在IT系统中收集来自多个数据源的数据，并通过分析这些数据来发现故障的过程。这种故障发现方法可以在⼀定程度上弥补通过单⼀数据源进行故障发现时面临的故障特征缺失。但相比于基于单⼀数据源的故障发现，通过分析多源数据发现IT系统的故障仍需解决诸多难题：
• 场景适应性：多源数据在不同场景下的信息密度有差异，这对算法模型的适应性提出了较高的要求。
• 数据复杂性：不同源数据之间的数据粒度、数据信息分布不均匀，给数据分析带来挑战。 同时多源数据包含大量噪声，这可能会掩盖故障特征的表现。
本赛题要求参赛队伍基于包含指标、日志、追踪的多源数据，采用合理的机器学习技术估计IT系统中故障源发生故障的概率。
数据情况
总体情况
1. 数据来源
云智慧混沌工程支持系统当中的⼀个具有30多个微服务的K8s架构的系统。该系统可以模拟数个不同的业务流程。
2. 注入故障方式
通过ChaosBlade对系统注入故障。比赛选手并不知道具体的故障是什么，比赛要求比赛选手找到故障源，但无需确定具体的故障类型。
3. 注入的故障类型
• 网络/端口丢包造成主机/服务无响应 (初、复)
• 网络/端口拥堵造成主机/服务响应变慢 (初、复)
• 主机/服务的CPU使用率增高造成服务卡顿 (初)
4.每个数据源的数据格式
初赛
• 8个故障源，包括5个服务和3个主机
• 9个标签，包含8个故障源和⼀个“NO_FAULT”类 (无故障类)
• 26440个数据集，其中训练集21160个，测试集5280个
• 总数据量：1.5T
• 单个数据集包含的数据时长：20分钟
• 简化的指标数据：为简化选手识别指标异常的难度，同时减少数据量，初赛时我们只在每个服务和主机上挑选了与故障相关的最关键指标。
• 初赛故障类型：
◦ 网络/端口丢包造成主机/服务无响应
◦ 网络/端口拥堵造成主机/服务响应变慢
◦ 主机/服务的CPU使用率增高造成服务卡顿
复赛
• 23个故障源，包括20个服务和3个主机
• 24个标签，包含23个故障源和⼀个“NO_FAULT”类 (无故障类)
• 13068个数据集，其中训练集10890个，测试集2178个
• 总数据量：1.8T
• 单个数据集包含的数据时长：20分钟
• 完整的指标数据：全部113个指标，涵盖了系统各组成部分的资源消耗指标和性能指标。
• 复赛故障类型：
◦ 网络/端口丢包造成主机/服务无响应
◦ 网络/端口拥堵造成主机/服务响应变慢
◦ 主机/服务的CPU使用率增高造成服务卡顿
决赛现场评分标准的说明
1. 算法实用性考察 ( 15 分)
评委主要参考以下维度进行评分 ：
算法工程化能力：
选手的算法是否具备工程化能力，如何处理增量学习 (在新数据到来时更新模型) 、离线训练和在线推理的结合、推理性能优化、是否考虑了分布式架构以提高效率等。此外，评估算法是否能够应对实际的落地问题，如数据质量问题、异常处理等 。
模型的泛化能力：
考察选手的模型是否能够在不同资源数量和不同故障类型的情况下表现出良好的泛化能力。评估数据特征的持续挖掘和构建能力，以及模型在连续性数据上发现故障的能力和确定故障时间的能力等 。
模型的运行效率：
评估模型的训练效率 (在何种时间内完成模型训练)、推理效率 (模型在给定数据上的推理速度)、模型的切换或加载效率 (从存储加载模型的速度) 等 。
模型的可解释性：
模型的可解释性是指模型的决策过程能够被理解和解释的能力，这样有助于提高模型的决策结果的可信赖度，便于调试和优化模型效果。选手的模型构建过程、推理过程的可解释性也是模型落地应用的关键因素 。
2. 算法创新性考察 ( 15 分)
模型创新性：
主要考察选手在算法表现中的各个环节中，是否有区别于常规方法的创新点。值得注意的是，需要甄别选手的创新点是否确实有助于提升效果，有疑点的话可以在提问环节进行追问，避免有选手“说一套，做一套”的现象发生。
应用创新性：
考察选手算法的总体框架设计 (从离线数据处理、特征构造、模型训练到模型加载、在线推理、模型在线切换/增量学习) 的合理性；
考察整体设计能否扩展到分布式环境中，处理更大规模的数据。
3. 复赛成绩【仅供参考】 ( 70 分)
复赛成绩归一化到 0-70 分，以复赛最终榜单所有获奖队伍最低成绩为 0 分基准点，Top1 成绩为 70 分满分基准点，按下边公式线性归一：
扫一扫
956
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
