内容归档
按栏目浏览往期内容，用关键词、分类和日期找到需要的信息。
一位安全负责人（CISO）在一次模拟的勒索软件攻击推演中，展示了企业被勒索后最初72小时要面对的决策。问题在于：很多公司以为把服务器从备份恢复好就万事大吉，但实际上恢复系统只是让技术重新运转，业务恢复还要花更长时间——验证数据、重连依赖、处理积压订单、应对法律和客户影响。文章建议提前定好谁能断网、找好取证伙伴、准备声明模板，并借助AI辅助调查更早发现攻击。原文没有给出可直接使用的具体工具名称，具体产品细节也未说明。
提供的材料未提及具体可用工具。
Datadog 发布官方介绍，讲如何把 Databricks 上的分析、数据工程和 AI/ML 工作负载接入 Datadog 统一监控。原来用户只能分别看 Databricks 自带指标和下游基础设施，成本和数据质量难以串起来。这次通过三条数据采集路径（集群上的 Agent 抓 Spark 指标与日志、轮询 Databricks API 拿任务运行状态、查系统表获取成本与血缘），把作业健康、花费、数据质量和日志汇总到一个界面。读者可以据此设置作业失败告警、查看 Spark 查询瓶颈、获得集群规格优化建议，并配合云厂商集成定位底层问题；相关功能已可用，但文中未说明具体版本或价格限制。
Databricks 官方发了一篇指南，讲怎么收集 Databricks 和它底层 Spark 的运行数据（比如性能、成本、用量）。之前这些数据分散在各处，用户不容易统一查看和排查问题。这次介绍的方法主要是用系统表来查询日志、成本和性能指标，再配合 Spark UI、作业通知和 REST API，就能做分析和告警。不过要注意，系统表的数据不是实时的，延迟随 schema 不同，所以不能拿它做秒级告警；实时监控得靠作业通知和 API。
Databricks 的技术写作者 Aaron Kaplan 和产品经理 Ryan Warrier 写了一篇文章，教大家怎么监控 Databricks 平台上的数据工程、分析和模型服务任务是否健康、跑得快不快、花销有没有失控。原来很多团队用 Databricks 跑批处理、流式管道和 SQL 查询，但任务失败或变慢往往发现太晚，账单也容易悄悄涨上去。他们建议盯住几类关键指标，比如任务运行结果是成功、失败还是超时，任务跑了多长时间，有多少子任务出错，以及管道里有没有数据质量报错；这些指标来自 Databricks 自带的系统表。文章只是系列博客的第一篇，讲了平台架构和指标清单，没有给出具体告警阈值或现成仪表盘，系统表也标注为 Beta 状态，读者需要自己根据这些指标搭监控。
提供的材料未提及具体可用工具。
标准 Kubernetes（K8s，一个管理容器化应用的开源平台）功能强大，但运维负担重：搭建一套生产集群要配置控制面、网络、存储、安全、可观测性等多个组件，还要持续维护。K3s 是 Rancher Labs（现属 SUSE）推出的轻量发行版，把控制面和许多组件打包成一个不到 100 MB 的单一二进制文件，默认用 SQLite 存储，最低只需 512 MB 内存和 1 个 CPU 核心即可运行；而标准 K8s 通常至少要 4 GB 内存和 2 个 CPU 核心。因此 K3s 更适合边缘计算、物联网设备（如树莓派、零售终端、工业电脑）等资源受限场景，标准 K8s 则适合需要最大灵活性的复杂集群。需要注意的是，文章只给出了选型思路，没有提供两者性能或成本的对照数据。
提供的材料未提及具体可用工具。
Anthropic 给 Claude Code 加了一套叫 mods 的新功能：mods 就是一些用 JavaScript 或 TypeScript 写的小函数，可以挂到 Claude Code 内部的事件上，用来改提示词、拦截或改写工具调用、处理权限请求、替换界面部件，甚至加新功能。以前开发者只能通过设置、CLAUDE.md、hooks 和 MCP 服务器调整 Claude 的行为，但没法改变 Claude Code 自身的界面和功能。现在 mods 已随 Claude Code 2.1.287 及之后版本默认启用，还能打包成插件分享给别人装，不过 mod 代码在本机运行，Anthropic 建议只装可信来源的。
Stacklok 创始人 Craig McLuckie 在 CNCF 博客上提出，目前多数 AI agent harness（即围绕 AI agent 的上下文、文件系统、子 agent、权限等支撑层）太“本地”，只适合单个开发者在笔记本上跑，难以支撑数百个会话，会话容易中断，体验也无法在不同客户端或设备间迁移。他认为应当把 agent harness 当作云原生分布式应用：把 agent 循环与底层基础设施和服务分开，就像 Kubernetes 教会业界“容器里的单体仍是单体”一样。对读者来说，这预示未来 AI agent 的支撑层可能像云服务一样可扩展、可迁移，而不只是本地玩具。目前这只是观点和倡议，尚未说明具体落地产品。
提供的材料未提及具体可用工具。
GitHub 周四公测了 Copilot 的“computer use”功能：Copilot CLI 和桌面应用现在能像人一样操作 macOS 和 Windows 上的软件，能读屏幕内容，也能点击、打字、滚动和拖拽，连那些没有接口、只能靠图形界面操作的老软件也能用。但 GitHub 自己建议：如果任务能用 API、MCP 服务器、终端命令或专门浏览器工具完成，就优先用它们，因为那样结果更可靠。这项功能目前在公测阶段，需要手动开启，macOS 上还要单独授予辅助功能和屏幕录制权限；敏感窗口内容可能被智能体读到，企业管理员也可用策略限制。
Harness 发布博客文章，解释工程师为什么常常忽略云成本：传统 FinOps 工具把成本数据放在独立的财务仪表盘里，开发者得中断写代码去查，而且反馈往往要等 30 天才来，和日常交付节奏脱节。文章提出的做法是把成本信息“左移”进 CI/CD 和 IaC 流程：在合并请求合并前就评估这次改动是不是申请了没批准的实例类型、会不会超预算，超了就自动拦截或交给负责人审批；同时用 Harness Cost Management Agent 在服务级别做实时成本可见性。对平台团队来说，意义在于不用牺牲开发速度也能让开发者对云支出负责。目前文中提到的产品能力和模式来自厂商博客，具体发布时间和可用范围原文未说明。
GitHub 博客发表了一篇文章，讲的是 AI 正在改变开发者的干活方式，光会写代码已经不够了。文章建议开发者重点练三件事：一是学会“指挥”AI 智能体，把问题说清楚、给对上下文，而不是自己一行行写；二是不轻信 AI 的第一版答案，可以让另一个 AI 模型来挑毛病，再自己拍板；三是把省下的时间用来想更大的问题，比如判断用户需求、权衡架构方案、定义成功标准。对读者来说，这说明以后的核心竞争力可能不是你写代码有多快，而是你能不能判断 AI 写得好不好、该不该上线。文章只给了方向性建议，没有给出具体数据或发布日期。
DigitalOcean 最近上线了 DigitalOcean Managed Agents，目前处于公开预览阶段。过去要让 AI 智能体在云端跑起来，往往得自己搭服务器、管权限、配推理环境，比较麻烦；这次它把这些打包成托管服务，用隔离的微虚拟机运行智能体，对工具访问做统一管控，并提供免运维的 AI 推理。对开发者来说，可以少操心底层设施，把精力放在智能体本身的功能上。
作者 Daniel Curtis 提出，AI 代码生成正在改变前端组件复用的经济账。过去团队要花钱维护一套共享的 UI 组件包，现在只要把设计系统、设计令牌、规范和测试准备好，让模型按需生成标准界面即可，维护整套组件库的必要性因此下降。他的建议是别丢掉设计系统和测试这些真正保证一致性的核心，而是把组件从“预先做好反复用”转向“按需再生成”。文章只是观点文章，没有给出具体工具、数据或落地案例。
提供的材料未提及具体可用工具。
InfoQ 的编辑 Artenisa Chatziou 发布消息：QCon 旧金山 2026 大会将邀请 Airbnb、OpenAI、Netflix、Honeycomb 等公司的工程实践者，分享他们如何在 AI 智能体承担越来越多工作的情况下，构建、运维和演进自己的生产系统。目前这只是一则预告，具体议题、日程和举办时间等细节原文未说明，因此还无法确认哪些内容会公开或开放观看。对读者来说，这提供了一个了解大公司真实工程经验的机会，但暂时没有可以直接上手使用的工具或方案。
提供的材料未提及具体可用工具。
Ian Cooper 做了一场演讲，讲的是当系统靠“消息”互相通知、而且规模很大时，怎么管好这些异步接口。他把消息机制拆成三个基础点：地址（消息往哪送）、绑定（用什么方式送）、契约（消息长什么样）。原来的问题是消息散落各处、难以发现和统一管理；他介绍用 AsyncAPI、CloudEvents、schema 注册表，加上自动化 CI/CD 流水线来解决发现、治理和开通的问题。这些做法来自 Just Eat Takeaway 的真实工程实践，对需要维护事件驱动系统的团队有参考价值。
Uber 的工程团队重新搭建了外卖应用 Uber Eats 的搜索流程，并报告称用户从下单搜索到看到结果的整体等待时间减少了一半。此前搜索链路较长、各环节串行执行，加上广告数据与检索逻辑交织，导致响应偏慢。这次他们改进了衡量首屏展示的方法、精简了检索环节、让多个数据获取步骤并行执行，还重新设计了广告数据并优化了底层基础设施，同时借助智能体编程流程辅助开发。对普通用户来说，这意味着在 Uber Eats 里搜餐、加载结果会更快。团队表示还在探索微批处理、基于商品的检索和 HTTP multipart 流式传输，但这些尚未开放，处于探索阶段。
提供的材料未提及具体可用工具。
Spring AI 社区发布了一个模块化 RAG 示例，把 TypeSafe 的 Jev 模型接入检索增强生成流程。传统做法直接把用户问题和相似文档片段塞给模型，问题在于用户口语化提问会带入噪音、相似文档未必有用、检索内容可能被人恶意植入指令。新方案在检索前用两次大模型调用改写并扩展问题，检索后用 JevDocumentFilter 和 JevDocumentReranker 过滤、重排文档，再交给模型生成答案。整套流程通过一个 advisor builder 配置，配套有可运行的 05-1-modular-rag 示例模块，方便与朴素版本对比。需要 TypeSafe API Key，过滤和重排依赖 Jev 模型。
Dynatrace宣布完成对Arize的收购。Arize是开发AI应用跟踪、评测和实验工具的厂商，Dynatrace则擅长监控应用和基础设施运行。此前，开发和运维AI时用的工具是割裂的，出问题很难追责。这次合并把两边打通，希望实现从开发到运行、再到持续优化的全程监控，帮企业看清AI为何出错、花了多少钱。目前Arize AX和Dynatrace平台继续单独提供，Phoenix保持开源；具体整合计划还没公布。
Datadog 把开源工具 Supply Chain Firewall 接入了自家的 Code Security 产品。原来这个工具只能在开发者电脑上拦截已知的恶意软件包，一旦每台机器各管各的配置，就容易失控，也没法知道哪些规则真正生效。现在可以在 Datadog 里集中设置允许和禁止名单，装到电脑和 CI 流水线里的防火墙都会自动同步，还能对已经装过的包回头复查，发现是恶意的就报警。此外新增了一个 GitHub action，让 CI 流程也能在安装前拦截。这些功能目前处于预览阶段，需要申请才能使用。
销售副总裁让一个连着 Snowflake 的 AI 智能体查上季度收入，结果数字不对。检查发现管道任务全部按时跑完、日志也没报错，但底层表已经连续好几天少了约 22% 的行，还有三个关键字段几乎一半是空的，全程没有任何告警，等发现时报表和决策已经受影响。这篇文章讲的是：管道跑成功不代表表里的数据是对的，还要直接对表本身做检查，比如数据是否按时刷新、行数是否异常变化、字段空值或分布是否漂移、有没有重复记录，并用管道信息帮忙定位是源头、调度还是转换逻辑出的问题。这样能更早发现“管道正常但数据悄悄变坏”的情况，避免拿错数据做决策。
提供的材料未提及具体可用工具。
Datadog 的工程师把 Apache DataFusion（一个用来执行查询的引擎）从只能在一台机器上跑，改造成了可以跨多台机器跑同一个查询，这个项目叫 Distributed DataFusion。原来他们有很多不同系统各管一摊，数据没法方便地合在一起查，而 DataFusion 虽然好用但只在单机上执行，遇到超大数据量就慢。新框架把查询拆到多台机器上并行处理，同时让数据以流式方式传输，避免中间结果落地，小查询仍留在单机跑以免浪费。代码已开源，用 Rust 写，可在 GitHub 和 crates.io 获取，Apache 2.0 许可；在 12 节点集群的公开测试里，部分重型查询最多快了 10 倍，成本不变。