自己做游戏的网站线上渠道推广怎么做
运维的挑战与责任
在数字化时代，运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能，还要快速响应并解决故障，以减少对业务的影响。在这种背景下，运维团队急需工具和技术，能够帮助他们提高效率，减轻负担。AIOps（人工智能运维）应运而生，旨在通过应用人工智能和机器学习技术来自动化监控、预测、优化和故障排除过程。
AIOps当前技术与输出
AIOps核心功能包括事件聚合、异常检测、自动化根因分析等。这些技术能够帮助运维团队从海量的监控数据中快速识别问题，预测潜在故障，并自动化常见问题的解决过程。通过AIOps，许多组织已经显著提高了故障响应时间，减少了误报，优化了运维流程，提升了IT系统的整体可靠性和性能。
AIOps仍然存在挑战：故障根因与可观测性数据割裂
尽管AIOps技术取得了显著进步，但在故障根因分析方面仍面临一个重大挑战：故障根因与可观测性数据（如日志、指标、追踪）之间的割裂。AIOps系统虽然能够推荐可能的故障根因，但往往难以直接将这些推荐与具体的可观测性数据紧密关联。这就要求运维人员依靠自己的经验和知识，在海量的数据中寻找证据来验证这些推荐，这一过程既耗时又容易出错。
Gartner 魔力象限中领先象限做到的效果
Dynatrace 效果
Dynatrace 的AI故障推理效果和介绍详情可参见 Dynatrace 官方网站。
从 Dynatrace 的视频中，如果发生了故障之后，AI推荐出AI根因之后，用户仍然需要使用根据 Visual resolution path 去从众多的Trace以及各种可观测性数据中筛选出证据来证明这个AI的推断。
Dynatrace 做到全球最牛的地方，就是能够将各种可观测性数据融为一体，并以时间线为维度还原故障现场，这个本质上还是人为分析，所谓的AI推荐，给出的是关键节点。
如果没有这个故障根因推荐，用户使用 Dynatrace 怎么做呢？仍然是围绕着故障时间点，利用 Dynatrace 的 Visual resolution path 人为分析故障根因。
结论：故障根因的推荐聊胜于无，还是需要人为在可观测性数据中分析找证据。
Datadog 效果
Datadog 的 Watchdog RCA给出仍然是可能性，具体从可观测性中找证据来证明这点，仍然需要用户自己来做。
结论：故障根因的推荐聊胜于无，还是需要人为在可观测性数据中分析找证据。
可观测性盲区的存在导致AIOps的根因结论与可观测性数据存在割裂
举例说明：Dynatrace 的根因例子为节点CPU利用率达到100%，其实绝大多数运维人员都能识别出100% CPU利用率是有问题的。但是如果CPU利用率是50%，这个时候人是很难判断程序是否会受到CPU供给瓶颈，需要额外提供更多的数据去判断CPU利用50%的时候，程序的执行是否会受到调度器的影响，这取决于很多因素，比如机器上需要调度的程序多少，CPU调度器排队的长度等，总而言之，可观测性数据存在盲区。
可观性数据由于存在盲区，导致人都很难根据可观测性数据推理出故障，只能根据事后的结论去关联出CPU利用率50%在某些场景下也是存在可能性导致故障根因的（资深运维人员在判断这两点的时候CPU利用率为50%，是故障根因也是需要非常深厚的经验）。
可观测性数据盲区更详细的介绍，请参考之前的文章。
可观测性工具的盲区与故障排查困局
Log | Metrics | Trace的联动方式探讨
内核视角持续剖析解决AIOps的故障根因结论与可观测性的割裂问题
在之前的文章介绍了可以使用内核视角下持续剖析，能够形成基于北极星指标的排障体系。内核视角下持续剖析 VS 代码视角下的持续剖析
基于这个标准化排障体系进行故障根因推导的时候，就能够同时自动化关联相关指标。比如如果发现网络时间很长，这个时候就可以关联网络相关性指标，必要时还可以同步 DeepFlow 等关键网络事件及数据，提供证据证明网络确实有问题。
Kindling-OriginX 按照这套理论，针对故障根因，提出了可解释的根因报告。填平了AIOps的故障根因结论与可观测性数据的割裂鸿沟。