Datadog 的工程师用自家产品 Insights 来观察和优化他们自己的 AI agent。Insights 会分析 agent 的运行记录，找出它在哪些地方花了过多 token、工具调用失败或任务没完成，并解释原因、估算影响、给出有依据的修复建议。例如它发现搜索工具一次返回太多内容，导致后续请求被重复计费；还发现请求顺序不对，使提示缓存无法复用，估算每月可省约 2734 美元。工程师随后把建议交给编程 agent 改代码，并通过重放原任务验证修复后 token 是否更少、回答是否仍然正确。这是 Datadog 的自用案例，节省数字为估算、尚未实测。
文中可用工具
- Insights分析 agent 运行记录，找出成本与可靠性问题并给出修复建议
- Agent ObservabilityDatadog 用于观测 AI agent 的产品，Insights 位于其中
- search_llmobs_spans在已记录的 trace 中搜索证据的工具
- update_insight用于更新已有 insight 的工具
- Fix with Bits把 insight 的证据与建议交给编程 agent 修改代码
展开详情收起详情：我们如何用 Insights 改进 Insights 背后的 agent⌄
原文发布：2026-10-30 08:00 · 首次收录：2026-10-31
Datadog 的几位工程师建议，AI Agent 的工作负载应优先考虑无服务器（按请求分配算力、空闲缩到零）而不是常开服务器。他们分析了超过 3.5 万次生产环境编程 Agent 会话，发现中位数会话只有 20% 的时间在真正调用模型或工具，其余时间都在等待，但沙箱资源一直占着，常开算力等于为闲置时间付费。做法是先给工作负载建一份「执行画像」，记录峰值并发、单次运行的实际计算时长与总耗时之比等，再据此判断用按需算力还是专用节点；长任务可以拆成可恢复的无服务器工作流，等待时释放算力、下一步就绪再继续。读者可以据此避免过早购买常开算力，并用上线后的真实数据再决定是否迁移，文中还提到可用 Datadog 的 Agent 可观测性、APM 和无服务器监控来测量这些指标。
文中可用工具
- Datadog Agent Observability观测 AI Agent 的运行，测量每次运行的总耗时和各步骤时长
- Datadog APM通过链路追踪查看模型、工具和应用层面的耗时
- Datadog Serverless Monitoring测量无服务器组件的执行时长、调用量、并发和 CPU 内存使用
- AWS Lambda文中举例的无服务器计算服务，增强指标可报告 CPU 利用率和 CPU 时间
展开详情收起详情：AI Agent 默认先用无服务器，让生产数据决定何时迁移⌄
原文发布：2026-10-29 08:00 · 首次收录：2026-10-30
OpenAI 此前报告了一种“自我复制提示注入”：攻击者把隐藏指令藏在 AI 智能体读取的内容里，诱导智能体照做，并把这些指令复制进邮件、文件或消息中，从而感染其他智能体和后续会话，像电脑蠕虫一样扩散。这次 Datadog 把 OpenAI 报告中的两个例子改造成针对测试智能体的模拟攻击，并用其安全产品 Datadog AI Guard 检查智能体读到的内容和发起的工具调用。结果 AI Guard 在看邮件或 CSV 时，就标记了被植入的内容不安全；当测试智能体把注入指令复制进回复或技能文件时，AI Guard 也判定这些操作不安全。需要注意的是，这是模拟环境中的演示，不是正式发布的新功能，也不能说明真实的拦截成功率；文章的重点是展示如何排查智能体最终回复里看不出来的可疑行为。
文中可用工具
- Datadog AI Guard评估 AI 智能体的输入、输出和工具调用，标记提示注入等不安全行为
- GPT-5.4 mini测试智能体所用的 OpenAI 模型
展开详情收起详情：检测 AI 智能体是否复制自我复制的提示注入⌄
原文发布：2026-10-29 08:00 · 首次收录：2026-10-30
Datadog 为语音智能体加了可回放的追踪功能。以前排查语音问题只能看文字记录，但文字看不出停顿、抢话、被中断等真实体验，也分不清音频和文字是否一致。现在用 OpenAI Realtime API 构建的应用可以自动把每轮对话的输入输出音频、转写、token 用量和工具调用记进同一条 trace，还能直接播放音频；同时提供一个「用户等首段回复音频多久」的指标，方便找慢的会话。做语音应用的开发者可以边听录音边看调用链，判断问题出在模型、工具还是打断环节，不用再只靠文字猜。Python 端需 ddtrace 4.13.0 及以上；ElevenLabs Realtime 支持和 Amazon Nova 2 Sonic 支持尚在后续或部分覆盖范围，具体可用范围原文未完全说明。
文中可用工具
- Datadog Agent Observability把语音对话的音频、转写、token 用量和工具调用记录在一条 trace 里，便于回放和排查问题
- OpenAI Realtime API用于构建实时语音智能体的接口，其会话可被自动追踪
- ddtracePython 追踪库，4.13.0 及以上版本可自动采集语音轮次数据
- ElevenLabs Realtime API原文称其支持将在 ddtrace 4.17.0 提供，尚未开放
- Amazon Nova 2 Sonic原文称 Python 和 Node.js 追踪器新增对其构建的应用的追踪支持
展开详情收起详情：使用 Datadog Agent Observability 追踪语音智能体⌄
原文发布：2026-10-29 08:00 · 首次收录：2026-10-30
Datadog 宣布自己在 Forrester 的 AIOps 平台评测里被评为“领导者”。以前工程师要自己翻告警、查问题、找根因；现在 Datadog 的 Bits AI 会帮忙定位问题并给出修复建议，还能在设定的护栏内执行修复，工程师保留最终控制权。支撑它的 Scout 1.0 模型刚进入预览，Bits AI 已有超过 1 万名付费客户。对读者来说，这意味着运维排障可能从“人工逐条查”变成“AI 先查、人来把关”，但 Scout 1.0 尚未正式开放。
文中可用工具
- Bits AI自动发现生产问题、调查根因并建议或执行修复
- Scout 1.0专为调查生产问题打造的模型，目前处于预览阶段
展开详情收起详情：Datadog 在 Forrester Wave™：2026 年第四季度 AIOps 平台报告中被评为领导者⌄
原文发布：2026-10-29 08:00 · 首次收录：2026-10-30
Datadog 推出了一个叫 Infrastructure Basic 的轻量监控档位。原来，对于不太重要的服务器（比如内部后台系统、开发测试机），团队要么用比实际需要更重的监控方案，要么另买一套工具，要么干脆不监控、留下盲区。现在这个档位只采集 CPU、内存、磁盘、网络、开机时长等基础系统指标，还能盯住指定进程是否在跑，并复用现有的告警通知工具。这样，次要服务器也能和重要系统放在同一个 Datadog 环境里统一查看，减少监控空档。目前该功能需要联系 Datadog 销售团队开通，新用户可先试用 14 天。
文中可用工具
- Datadog Infrastructure Basic轻量级主机监控档位，采集核心系统指标和指定进程状态，支持告警通知集成
- Datadog Agent部署在主机上的采集组件，在 basic 模式下只采集基础系统级数据
- Process Check监控指定的命名进程是否仍在运行
- ServiceNow接收监控告警并创建工单
- PagerDuty接收监控告警并触发事件通知
展开详情收起详情：按工作负载需求匹配监控深度：Datadog 推出 Infrastructure Basic⌄
原文发布：2026-10-28 08:00 · 首次收录：2026-10-29
Datadog 宣布支持通过其 AWS、Azure 和 Google Cloud 集成中的专用子集成来监控 Oracle AI Database@AWS、@Azure 和 @Google Cloud。过去，数据库托管在 Oracle 云上而应用跑在其他云里，出问题时常出现监控盲区，难以判断是应用还是数据库的锅；迁移后性能验证和跨账单的成本归属也很麻烦。现在每套子集成提供 50 多项开箱即用的指标和仪表盘，还能配合数据库监控（DBM）、应用性能监控（APM）和云成本管理（CCM）排查慢查询、对比迁移前后性能，并把 OCI 与云厂商的账单归一化后按团队归因成本。原文未说明具体上线时间或收费方式，以上能力均以已发布的产品功能形式介绍。
文中可用工具
- Datadog监控平台，提供指标、仪表盘和调查工具
- Datadog Database Monitoring (DBM)采集数据库负载指标、查询样本和执行计划，排查慢查询根因
- Datadog APM把应用请求与数据库查询关联起来，追踪请求链路
- Datadog Cloud Cost Management (CCM)汇总并归一化云与 OCI 成本，按团队归因花费
- Bits Chat结合指标、查询和日志自动定位性能问题并给出修复建议
- Oracle AI Database@AWS在 AWS 上运行的 Oracle 数据库服务
- Oracle AI Database@Azure在 Azure 上运行的 Oracle 数据库服务
- Oracle AI Database@Google Cloud在 Google Cloud 上运行的 Oracle 数据库服务
- Oracle Cloud Infrastructure (OCI)Oracle 的云平台，托管这些数据库并提供成本数据
展开详情收起详情：使用 Datadog 跨云监控 Oracle AI Database⌄
原文发布：2026-10-26 08:00 · 首次收录：2026-10-27
Datadog 的两位作者介绍了他们产品里叫“实验协议”的功能。原来团队做 A/B 测试时，指标、分流方式、放量节奏和分析方法都靠一份评审文档约定，每个实验的人都要手动重搭一遍，团队多了就容易各做各的。实验协议把已经评审通过的这套方法存成可复用的配置，新建实验时选一个已发布的协议，字段会自动带入草稿，还能按需修改。读者可以借此让同类实验有统一的起点，减少配置不一致带来的问题，也能在实验上线前就把主指标和防护指标定好。
文中可用工具
- Datadog Experiments运行 A/B 测试并管理实验协议的平台
- Datadog Feature Flags配合实验做变体分配，需传入匹配的 targetingKey
展开详情收起详情：规模化 A/B 测试的最佳实践：用实验协议统一标准⌄
原文发布：2026-10-26 08:00 · 首次收录：2026-10-27
Datadog 推出 Agent Observability 的新功能，帮企业搞清楚 AI 智能体的钱花在了哪里。原来云厂商账单只按 API 密钥和模型统计，看不出是哪个应用、哪一步工作流在烧钱，所以成本一涨就很难查原因——可能是流量变大、换了更贵的模型，也可能是缓存没用上、对话历史每轮都重发。现在这个工具把估算的 AI 成本直接挂到具体应用和请求链路上，打开 Cost 页面就能按应用对比花费和效率（比如每次请求成本、缓存命中率），还能钻取到单次最贵的调用，看它的执行链路。它还会自动指出可省钱的点，比如未被缓存的提示词前缀，估算能省多少并给出修改建议。对读者来说，这意味着 AI 成本问题能更快定位到技术原因，而不是对着账单猜。目前材料只说明这是 Datadog 的产品能力介绍，未说明具体定价和正式上线时间。
文中可用工具
- Datadog Agent Observability把 AI 智能体的估算成本关联到具体应用和调用链路，帮助定位花钱多的环节
- Cost page按应用、供应商或自定义标签查看 AI 花费和效率指标
- Cost Savings Opportunities找出可避免的花费并估算潜在节省、给出修复建议
- Most Expensive LLM Calls table按估算总成本给 LLM 调用排名，方便查看最贵的请求
- Execution Graph展示智能体、LLM 调用、工具和评估之间的连接关系
- Datadog Application Performance Monitoring (APM)与 Agent Observability 关联，把 AI 操作放回更完整的应用调用链中排查
展开详情收起详情：用 Agent Observability 优化 AI 成本⌄
原文发布：2026-10-22 08:00 · 首次收录：2026-10-23
Datadog 的两位作者写了这篇技术文章，讲怎么用真实用户监控（RUM）和合成监控两种数据来定义 SLO 的指标（SLI）。原来很多团队只用后端性能指标，难以反映用户真实体验；而如果单用 RUM，机器人流量和浏览器配置差异会带来噪声，单用合成测试又不够细。文章建议：合成 SLI 适合长期稳定地监测关键用户流程，RUM SLI 适合精确统计真实用户的关键操作，并按目标变化、监控盲区、低流量误报等情况给出了选用建议。文中提到过去一年客户自建合成 SLO 数量增长了 273%。读者可据此判断何时切换数据源，但没有给出具体落地步骤和产品开放状态。
展开详情收起详情：用 RUM 和合成监控 SLI 构建更好的 SLO⌄
原文发布：2026-10-20 08:00 · 首次收录：2026-10-21
Datadog 内部建了一个叫 Turnstile 的系统。原来他们的镜像签名只能证明镜像签名后没被改过，但挡不住更早环节出问题，比如代码合入时被塞进恶意改动、依赖被投毒、构建环境被入侵，这些镜像照样能带着有效签名上线。Turnstile 在软件从代码到镜像的每一步都生成加密签名的“证明”，记录是谁、在什么环境、经过什么审核，部署前再按环境策略检查这些证明，比如生产环境要求更严。这样安全团队能提前拦截不合格镜像，也不用对开发流程造成太多打扰。目前它是 Datadog 内部系统，文章没有说明是否对外开源或商用。
文中可用工具
- TurnstileDatadog 内部系统，为软件制品生成防篡改签名证明，并在部署前按环境策略检查
- in-toto开源框架，用来记录软件供应链中各步骤由谁执行、按什么顺序执行
- containerd容器运行时，Datadog 通过自定义插件在拉取镜像时验证签名
- SLSA提供源码和构建完整性威胁模型的标准框架，文章参考其原则
展开详情收起详情：超越容器镜像签名：Datadog 如何执行软件供应链策略⌄
原文发布：2026-10-20 08:00 · 首次收录：2026-10-21
Datadog 的产品经理 Kathy Lin 和技术作者 David Lentz 写了一篇文章，讲 Kubernetes 的旧设备插件模型怎么限制 GPU 使用效率。旧模型里，团队必须提前把 GPU 切好固定的分区，请求只能写数量、看不出显存大小和连接方式，结果经常是花钱买的 GPU 容量白白闲着，或者任务排队等资源。新的动态资源分配（DRA）让 Kubernetes 按每个任务的具体需求灵活挑选和分配 GPU，还能让多个任务共用同一块 GPU，把闲置容量利用起来。读者可以了解 DRA 相比旧模型好在哪，以及用 Datadog 怎么跟踪这些改进和省下的成本。文章目前是博文介绍，没有给出具体性能数字，也没有说明 DRA 功能是否已普遍可用。
文中可用工具
- Kubernetes Dynamic Resource Allocation按任务需求动态挑选和分配 GPU 等硬件，提升利用率
- Kubernetes device plugin model旧版 GPU 分配方式，把设备当作可互换的数量单位
- NVIDIA Multi-Instance GPU把一块 GPU 切成多个相互隔离的硬件实例
- Datadog跟踪 GPU 利用率改进和成本节省情况
展开详情收起详情：Kubernetes DRA 如何提升 GPU 利用率并降低成本⌄
原文发布：2026-10-15 08:00 · 首次收录：2026-10-16
Datadog 为它的 RUM（真实用户监控）产品加了一个叫“运维监控”的新功能。以前，团队能单独看到页面浏览、点击、报错这些零散事件，但很难直接回答“付款这一步到底成没成功、花了多久”。现在，你可以把“处理支付”这类由应用控制的关键步骤定义成一个“操作”，单独追踪它的成功率和耗时，还能用 SLO 设目标、用 Bits AI 查为什么变慢或报错，最后再把它放回整条用户旅程里看。这个功能随 RUM 免费提供，Bits Investigation for Operations 目前还在预览阶段。
文中可用工具
- Datadog Real User Monitoring (RUM)采集真实用户在使用应用时产生的浏览、操作、资源和错误等详细事件数据。
- Datadog MCP Server在不改动应用代码的情况下，通过 MCP 兼容的工作流来创建操作。
- RUM Operations API用编程或批量方式创建操作。
- Bits Investigation for Operations自动分析操作性能下降相关的信号，帮助排查原因，目前处于预览阶段。
展开详情收起详情：利用 RUM 运维监控，跟踪用户旅程中关键步骤的性能⌄
原文发布：2026-10-15 08:00 · 首次收录：2026-10-16
Datadog 推出了 Scout 1.0，这是他们第一个专门用来排查线上故障的 AI 模型，名字叫“站点可靠性工程”（SRE）模型，实际工作就是帮工程师分析生产环境出了什么问题。过去这类工作要么靠人盯着，要么用通用大模型来跑，但通用模型每次推理太贵，没法对每个告警都反复查。Scout 的做法是先用真实历史故障和遥测数据（不含客户数据）做模拟训练，再用强化学习让它学会查证据、验假设，从而把单次排查成本大幅压低。效果上，Scout 1.0 medium 在目标场景里能达到 GPT-6.1 Sol high 和 Claude Opus 5.5 high 的水平，成本却只有约三分之一到八分之一。目前 Datadog 内部团队和一小批客户已在封闭预览中使用，想试可以报名，正式版还没开放。
展开详情收起详情：Scout 1.0 发布：驱动 Bits AI 的全新 SRE 模型，以极低成本实现前沿性能⌄
原文发布：2026-10-15 08:00 · 首次收录：2026-10-16
Datadog 内部有数千个服务，以前对所有服务一视同仁地制定部署和可靠性标准，规模变大后成本太高，也不知道该把有限的可靠性投入放在哪里。他们用大语言模型读取几百篇最高严重级别的故障复盘文档，提取出哪些服务导致或被卷入事故，再结合 APM/RUM 错误链、生产流量和监控告警等信号，给每个服务打出高、低、未知的关键性等级和置信度。这样就能对真正关键的服务严格部署、收紧可靠性目标，对不关键的服务放宽标准，把精力集中在故障时最影响客户的地方。
文中可用工具
- Datadog APM应用性能监控，用错误链数据判断服务是否在关键错误路径上
- Datadog RUM真实用户监控，帮助连接入口到关键用户旅程
- Software Catalog用于校验模型提取出的服务名是否映射到真实服务，也用于统计生产流量
- Datadog On-Call判断服务的监控是否通知值班轮换，作为关键性信号之一
展开详情收起详情：Datadog 如何大规模定义服务关键性⌄
原文发布：2026-10-13 08:00 · 首次收录：2026-10-14
Datadog 在自带云（BYOC）日志功能里加了跨集群查询。有些公司因为数据必须留在本地或某些地区，就把日志分散存放在自己控制的多个 Kubernetes 集群里。以前要查一次故障，得挨个集群重复搜索再手动对比。现在用一条查询就能同时搜索多个选定集群，Datadog 会把各集群的结果合并展示，日志本身仍留在原处。团队和 AI 智能体因此能更快判断问题是局部还是全球性的，智能体还能少发几次工具调用、省一些 token。该功能已在 BYOC 日志中可用，具体哪些集群可查文中未说明。
文中可用工具
- Datadog BYOC把 Datadog 平台部署到用户自己控制的云环境里，日志数据保留在本地
- Log Explorer用来搜索和查看日志的界面，跨集群查询的结果会合并显示在这里
- Bits AIDatadog 的 AI 功能，BYOC 部署中可继续使用，原文未说明具体用途
- MCP Server让 AI 智能体通过 search_datadog_logs 工具查询 BYOC 日志
- search_datadog_logsAI 智能体用来搜索 Datadog 日志的工具，可指定索引、过滤条件和时间范围
展开详情收起详情：Datadog BYOC 推出跨集群查询，为团队和 AI 智能体统一数据⌄
原文发布：2026-10-09 08:00 · 首次收录：2026-10-10
Datadog 的政府版服务最近拿到了 FedRAMP High 认证，这意味着处理最敏感政府数据的团队，现在也能用 Datadog 来做事件响应了。以前，政府系统的告警、日志、截图等敏感信息，可能不敢放在认证环境里，事件处理会缺东少西。现在，值班呼叫、协调沟通、自动化处理、复盘等一整套流程，都能在 US1-FED 这个认证环境里完成，还能跟现有监控工具配合。对政府用户来说，好处是事件数据不用再挪出安全区，响应过程更完整，也更容易通过审计。文章说它是目前唯一有此认证的事件响应平台，但具体怎么开通、价格多少，原文没说明。
文中可用工具
- Datadog Incident Response在政府认证环境里做值班呼叫、事件协调、自动化处理和复盘
- Datadog On-Call自动呼叫负责出故障服务的值班团队，支持排班、升级和手机响应
- Slack在团队日常用的聊天工具里协调事件、发布更新
- Microsoft Teams在团队日常用的聊天工具里协调事件、发布更新
- Datadog Workflow Automation自动执行重复的响应步骤，比如收集信息、跑修复流程、建工单
- Jira把事件后续要做的任务导出到工作管理系统
- Datadog Synthetic Monitoring验证关键用户流程是否已经恢复正常
- Catalog管理服务归属信息，让升级逻辑跟上团队和服务的变化
展开详情收起详情：在 FedRAMP High 环境中运行事件响应⌄
原文发布：2026-10-08 08:00 · 首次收录：2026-10-09
Datadog 推出了可视化标注工具（Visual Labeler），让产品经理不用写代码就能给网页上的点击、点击等交互起名字。以前，自动采集到的操作名只描述页面元素本身，看不出用户真正想干什么，比如“开始结账”这种业务问题往往要工程师写代码或加自定义事件才能回答。现在你只需打开浏览器扩展，在自家网站上点选元素并命名，Datadog 就会把这个名字补用到留存期内已经记录的所有匹配交互上，历史趋势和漏斗当天就能用。标好的操作还能作为共享事件在漏斗分析、热力图和仪表盘中重复使用，减少不同分析师对同一行为各叫各名字的麻烦。
文中可用工具
- Datadog Product Analytics分析用户在网页上的行为，比如看有多少人开始结账
- Visual Labeler不用写代码，在网页上点选元素并给它起一个反映用户意图的名字
- Datadog Action Management集中定义和查找已标注的用户操作
- Datadog RUM原文未说明具体用途，仅提到共用同一套 SDK 和配置
- Datadog test recorder Chrome extension在浏览器中导航网站并选择要标注的元素
- Datadog Heatmaps把页面上的交互聚合成点击图，看哪些元素被点得最多
- Funnel Analysis用标注好的操作搭建漏斗，看用户从一步走到下一步的转化情况
- Notebooks共享漏斗图表，和团队一起看转化数据
- Error Tracking排查可能影响转化的报错
- Session Replay回放用户会话，了解漏斗流失时的具体情况
展开详情收起详情：在 Datadog Product Analytics 中用可视化标注定义 Web 应用用户操作⌄
原文发布：2026-10-08 08:00 · 首次收录：2026-10-09
Datadog 原有远程漏洞扫描器在主机规模扩大后，扫描全部主机需超过18小时，而扫描器的 SSH 凭证只有12小时有效期，凭证过期后无法继续认证剩余主机，导致部分主机漏扫。他们改用已经部署在各主机上的 Datadog Agent 收集安装的软件包版本，传给 Datadog Cloud Security 来识别已知漏洞，并用六个月新旧系统并行比对覆盖范围和检测结果。迁移后扫描新鲜度保持在99%以上，即99%以上范围内主机在过去24小时内完成过扫描，并继续满足 SOC 2 Type II、ISO 27001、PCI DSS 和 FedRAMP High 的审计要求。
文中可用工具
- Datadog Agent已部署在各主机上的采集程序，用来收集安装的软件包及其版本信息，并发送给 Datadog
- Datadog Cloud Security基于 Agent 收集的软件包信息识别已知漏洞，并成为主机漏洞发现结果的记录系统
展开详情收起详情：我们如何用 Datadog Agent 取代主机漏洞扫描器⌄
原文发布：2026-10-07 08:00 · 首次收录：2026-10-08
Datadog 推出 CI/CD Optimization，帮助平台和 DevOps 团队应对 AI 辅助开发带来的 CI 压力。AI 让代码产出变多，但流水线跑不完、测试结果不稳定、算力开销水涨船高，交付反而变慢。这个产品把流水线和测试数据与提交记录、日志、运行器及基础设施信息放在一起，帮团队找出瓶颈、自动重试不稳定的测试、只运行受改动影响的测试。对读者来说，这意味着查看合并请求的等待时间可能缩短，CI 账单也不会随代码量同步膨胀。文中提到 Betterment 把平均构建时间从近 40 分钟降到 10 分钟以内，The Browser Company 把 CI 流水线时间缩短了 50%。
文中可用工具
- Datadog CI/CD Optimization把 CI 流水线和测试数据与提交、日志、运行器等信息结合起来，帮助团队缩短反馈时间、减少不稳定测试影响并控制算力成本
- Flaky Management集中展示不稳定的测试及它们造成的流水线失败、浪费的 CI 时间和失败率，帮助团队优先处理最耗时的失败
- Auto Test Retries对失败的测试自动重试，直到通过或达到可配置的上限，避免偶发失败拖垮整个构建
- Early Flake Detection在新出现的不稳定测试进入默认分支前进行检测和拦截
- PR Gates在修复进行期间阻止已知的不稳定测试反复挡住无关的改动
- Flaky Management Explorer在流水线层面追踪不稳定测试造成的失败、浪费的 CI 时间以及自动重试和测试执行优化节省的时间
- Test Impact Analysis把测试映射到它们覆盖的代码，判断哪些测试受改动影响，跳过无关测试以减少流水线工作量
展开详情收起详情：使用 Datadog CI/CD Optimization 加快交付、提升可靠性并控制 CI 成本⌄
原文发布：2026-10-06 08:00 · 首次收录：2026-10-07