引言

缓存是工程师优化分布式系统时首先采用的工具之一。我们会缓存已完成的响应（如数据库查询结果或 HTTP 响应体），以避免重复执行昂贵的任务。然而，传统缓存未能解决一个经常被忽视的低效源头，即重复的进行中请求（duplicate in-flight request）。

当多个客户端几乎同时请求同一资源时，缓存未命中会触发相同的计算会并行开始执行。在单进程的 JavaScript 应用中，通常会通过在内存中存储进行中请求的Promise来缓解该问题，使后续调用者可以等待同一个结果。在其他语言和运行时中，可通过不同的并发原语实现类似效果，但底层假设是相同的，也就是共享内存和单一执行上下文。

在分布式、无服务器或边缘环境中，这一假设就难以成立了。每个实例都有自己的内存，任何形式的进行中请求去重都仅限于单个进程的生命周期和范围之内。

工程师通常会在缓存之外引入第二种机制，比如，锁、标记（marker）或协调记录（coordination record），以跟踪正在进行的工作。这些方法难以进行推理，并且经常退化为轮询或粗粒度的同步。

本文提出了一个不同的模型，那就是将已完成的响应和进行中的请求视为同一缓存条目的两种状态。借助 Cloudflare Workers 和 Durable Objects，我们可以为每个缓存键分配一个单一、权威的所有者。该所有者可以安全地持有正在进行工作的内存表示，允许并发调用者等待它，然后在工作完成后将条目转换为已缓存的响应。

该模式并没有引入单独的协调层，而是将缓存和进行中请求去重统一在单一抽象之后。尽管它依赖于并非普遍可用的运行时特性，但在支持按键单例执行的环境中提供了一种简洁且实用的方法。

深入分析该问题

从宏观层面来看，问题不在于缓存本身，而是在于缓存条目存在之前发生了什么。

考虑一项代价高昂的操作：数据库查询、外部 API 调用或 CPU 密集型计算。在分布式边缘环境中，多个客户端可能在非常短的时间窗口内请求同一资源。如果缓存尚未包含该键的值，每个请求都会独立触发相同的工作。

因为边缘运行时会有意地进行水平扩展，这些请求通常由不同的执行上下文处理。每个上下文都观察到相同的缓存未命中，并且会继续执行，就好像它是第一个请求者一样。结果就是冗余的工作激增，而缓存本应防止这种情况发生，但由于缓存只有在第一个请求完成后才能发挥作用，因此这种现象难以避免。

作为应对措施，很多系统引入了额外的机制来跟踪进行中的工作。一个缓存用于已完成的结果，而另一个结构（有时是内存映射，有时是分布式存储）用于标记请求为“进行中（in-flight）”。这种分离迅速增加了复杂性。请求的生命周期现在必须在两个独立系统之间协调，必须仔细处理竞争条件、失败和超时。

按照进程进行内存去重部分缓解了这个问题，但是这种方法仅限于单个运行时实例的范围内。在无服务器和边缘环境中，实例的生命周期很短，并且在设计上是隔离的。两个同时请求不同节点的请求即使它们在逻辑上是相同的，也无法共享彼此的进行中状态。随着流量增长或地理分布更广泛，这种优化的效果迅速降低。

它造成的结果就是，在单体或长期存活服务中表现良好的模式，但在水平扩展最激烈的环境中却崩溃了。

缓存结果的缺失和第一次计算完成之间的这个时间差恰好是传统缓存策略无能为力的地方，也是进行中请求去重在分布式运行时中变得既必要又特别困难的地方。

为何 Durable Objects 是合适的方案？

上一节所述的困难是现代无服务器和边缘平台设计的直接结果。隔离的执行上下文、短暂的进程和水平扩展都是它们的特性，而非缺陷。因此，任何针对进行中请求去重的解决方案都必须在这些约束下工作，而不是试图绕过它们。

Cloudflare Durable Objects提供了一套小但关键的保障措施，使得这一点成为可能。

首先，Durable Object 实例是一个按键存在的单例（per-key singleton）。对于给定的对象标识符，所有请求都路由到同一个逻辑实例，无论它们来自哪里。这立即消除了所有权的模糊性：对于给定的缓存键，只有一个地方可以存放进行中的状态。

其次，Durable Objects 提供了跨请求共享的可变内存。与传统 Worker 不同，Durable Object 可以在请求之间保留内存状态。这允许它持有正在进行的工作的表述，例如一个正在进行的计算，而无需外部协调。

第三，对 Durable Object 的请求是按顺序处理的。这种串行执行模型消除了在检查或更新进行中状态时需要显式锁定的需求。检查是否已经有计算正在进行中，如果没有的话，则创建它，并且它能够附加额外的等待者，这些都可以在单一执行上下文中确定性地进行。

综合这些特性，Durable Object 能够充当进行中和已完成缓存条目的权威所有者。调用者不再需要询问“这个请求是否已经在其他地方开始了？”，而是简单地将请求转发给负责该键的对象并等待结果即可。

重要的是，这种能力不是支持最终一致性的键值存储可以模拟的。KV 系统非常适合持久化已完成的结果，但它们无法在避免使用轮询或外部信号的情况下，表示执行中的过程或允许多个调用者等待同一块内存中的操作。相比之下，Durable Objects 对进行中工作的支持成为了首要的关注点。

这并不意味着 Durable Objects 在所有情况下都适用。本文描述的模式依赖于它们的单例和内存保证，因此只适用于提供类似语义的运行时。在这些保证能够达成的环境中，Durable Objects 提供了一个干净且最小的基础，可以统一缓存和进行中请求去重，而无需引入额外的协调层。

突破 Cloudflare 的适用性

尽管本文中的示例使用了Cloudflare Workers和 Durable Objects，但底层模式并不是特定于 Cloudflare 的。重要的不是平台本身，而是上述的运行时保证。

运行时至少要提供：

• 按键单例执行：给定键的所有请求都路由到同一逻辑实例。

• 该实例在请求间能够共享内存状态。

• 串行请求处理，或等效的无需显式锁定的保证。

Cloudflare Durable Objects 明确满足这些要求，使它们成为一个方便且定义明确的示例。其他环境中也可以找到类似语义的功能，尽管通常以不同的名称或具有不同的权衡：

• 基于 Actor 的系统，比如基于Akka或Orleans构建的系统，通过 Actor 身份和消息串行提供可类比的保证。在这些系统中，Actor 可以自然地拥有给定键的进行中工作和已缓存的结果。

• 有状态无服务器平台和“持久执行”模型也开始出现，不过其 API 和功能保证差异显著。它们的共同点是，并非所有无服务器计算都必须是无状态的，有限且范围明确的状态可简化某些协调问题。

相比之下，那些仅提供无状态函数并结合最终一致性键值存储的平台无法整洁地实现这一模式。没有单一权威所有者和共享内存执行上下文，进行中去重不可避免地退化为轮询或分布式锁。

因此，本文所述模式应理解为依赖于运行时。它并不是传统缓存的通用替代方案，而是在执行模型支持的情况下才可行的针对性技术。

一个最小化的实现

在运行时保证确立后，实现本身就特别简单了。我们的目标不是构建一个通用的缓存，而是展示一个单一抽象如何同时处理进行中请求的去重和响应缓存。

以下示例展示了负责单个缓存键 Durable Object。该键的所有请求都路由到同一对象实例：

export class CacheObject{  private inflight?: Promise<Response>;  private cached?: Response;  async fetch(request: Request): Promise<Response> {    // Fast path: return cached response if it exists    if (this.cached) {      return this.cached.clone();    }    // If no computation is in-flight, start one    if (!this.inflight) {      this.inflight = this.compute().then((response) => {        // Store completed response        this.cached = response.clone();        // Clear in-flight state        this.inflight = undefined;        return response;      });    }    // Await the same in-flight computation    return (await this.inflight).clone();  }  private async compute(): Promise<Response> {    // Placeholder for an expensive operation    // e.g. database query or external API call    const data = await fetch("https://example.com/expensive").then(r => r.text());    return new Response(data, { status: 200 });  }}

该对象维护两种状态：

• inflight，表示正在进行的计算。

• cached，存储可用的已完成响应。

当请求到达时，对象首先检查是否存在缓存的响应。如果没有，它会检查是否已经有计算正在进行中。如果有的话，调用者只需等待同一个 Promise。如果没有，对象就会启动计算，并将结果 Promise 存储在内存中。

由于 Durable Objects 按顺序处理请求，无需显式锁或原子操作。检查和创建进行中 Promise 的逻辑在单一执行上下文中能够确定性地执行。

从调用者的角度来看，这就像一个普通的缓存一样。不同之处在于，即使缓存最初是空的，并发调用者也不会触发重复的工作。一旦计算完成，所有等待的调用者都会收到相同的结果，后续请求直接从缓存响应中提供服务。

此示例有意省略了持久化、过期和错误处理。这些问题可以在不改变核心思想的情况下分层进行处理。比如，可选择将已完成的响应存储在键值存储中以实现持久性，但关键是，进行中的状态永远不会离开内存，从而保持了该模式的简洁性和正确性。

该方法的优势

该模式的主要优势是将两个相关的关注点合并为单一抽象。它不将进行中请求去重和响应缓存视为独立的问题，而是将其建模为同一缓存条目的不同状态。

这会带来多项实际的优势：

• 首先，它消除了缓存无法发挥作用的情况下的重复工作。通过允许多个并发调用者等待同一个正在进行的计算，系统避免了在缓存未命中期间出现的冗余请求激增，这正是传统缓存最无能为力的场景。

• 其次，该方法简化了系统设计。没有必要引入第二个协调层、分布式锁、与缓存数据分开存储的“进行中”标记。所有与请求合并、执行和结果重用相关的逻辑都集中在一个地方，由单一的运行时实体拥有。

• 第三，它与 JavaScript 应用的编写方式自然对齐。等待共享 Promise 是惯用且易于理解的模式，Durable Objects 使此模型可扩展到单个进程之外，而不必改变思维模型。调用者与缓存的交互，就像在本地进行一样，尽管它的执行是分布式的。

• 第四，该模式可水平扩展而不丧失正确性。随着流量增长或地理分布更广泛，请求仍路由到每个键的同一权威所有者。行为不会随着更多边缘节点的添加而退化，这与按进程优化的常见情况不同。

• 最后，该模型可增量扩展。过期策略、已完成响应的持久化、指标和重试均可添加，而不改变核心控制流。基本思想就是，一个所有者、一个进行中请求的计算、一个缓存结果的思路保持不变。

这些特性使该模式适用于重复工作成本高且请求并发不可预测的工作负载，如边缘 API、聚合端点或昂贵的上游集成。

权衡与限制

尽管优雅，此模式并非普遍适用。其有效性在很大程度上取决于底层运行时的执行模型，并引入了需仔细考虑的权衡项。

• 最显著的限制是运行时依赖。进行中请求的去重需要具有共享内存状态的单一权威所有者。如果没有按键单例执行，就无法整洁地实现该模式。如果试图使用最终一致性的键值存储来模拟它，必然会导致轮询、分布式锁或其他形式的协调，从而破坏原有的简洁性。

• 实现本身可能是平平无奇的。虽然最小化示例很小，但生产就绪版本必须考虑错误传播、重试、超时、驱逐和内存限制。必须小心确保失败的计算不会使系统处于永久的“进行中”状态，并且缓存的响应能够正确失效。

另一个重要的考虑因素是相关性。在许多架构良好的系统中，重复的进行中请求已经很少见了。幂等的上游 API、自然地请求分散或粗粒度的缓存可能使进行中请求的去重变得无关紧要。在这些情况下，引入该模式可能会增加复杂性，而不会带来有价值的好处。

还有一个就是扩展方面的权衡。将给定键的所有请求路由到单一所有者引入了一个自然的序列化点。对于单个键非常热门的工作负载，这可能会成为瓶颈。在这些情况下，分片策略或替代缓存方法可能更合适。

最后，该模式并不替代传统的缓存策略。它是对它们的补充。已完成的响应可能仍需要持久化在键值存储或 HTTP 缓存中，以在进程驱逐或冷启动时生存下来。然而，关键在于，持久化应该只适用于已完成的结果，将进行中的状态移入外部存储会抵消该方法的好处。

因此，该模式应被视为一种针对性的优化，而非默认的架构选择。如果运行时支持它并且工作负载证明它是合理的，那么统一响应缓存和进行中请求去重可以显著减少冗余工作。当这些条件不满足时，更简单的设计通常会更明智。

结论

本文概述了一个在分布式 JavaScript 运行时中统一响应缓存和进行中请求去重的模式：通过依赖于按键单例执行和共享内存状态，可以将正在进行的计算及其最终结果视为同一缓存条目的两种状态，从而消除重复性的工作，而无需引入轮询或外部协调。

需要强调的是，这种模式主要是一种设计提案，而不是经过实战验证的方案。虽然底层原语（Durable Objects、Promise 和串行执行）是众所周知的，但这里描述的组合尚未在生产系统中得到广泛验证。关于运维行为、可观测性和长期性能特征的问题仍然存在，并且需要进一步探索。

尽管如此，该模式的价值可能在于它清晰地揭示了缓存与执行之间的关系。它表明，进行中请求去重的困难并非分布式系统所固有的，而是我们通常使用的执行模型所致。当运行时能够为每个键提供单一的权威所有者时，问题就大大简化了。

随着无服务器和边缘平台的不断发展，有状态执行模型变得越来越普遍。这样的模式表明，重新审视长期以来的假设，比如，缓存和协调之间的严格分离，可能会产生更简单、更具表现力的设计。无论这种特定方法是否证明了广泛的实用性，还是仅仅作为一种小众优化存在，它都凸显了未来运行时和应用架构的重要方向。

原文链接：

https://www.infoq.com/articles/durable-objects-handle-inflight-requests/

如果你曾经值过班，那么你肯定知道这么一种情况。凌晨两点，电话打来，你猛然惊醒，抓起笔记本电脑开始排查。你先是检查服务仪表板，接着是分析依赖关系图，然后是查看日志，最后再查看来自三个不同监控工具的指标。半小时后你发现，这不过是虚惊一场：阈值设置过严，金丝雀部署触发了可以自动恢复的告警，或是网络瞬态波动导致了短暂峰值。

但你不能就这样回去睡觉。你得等等，观察一下。你必须确保告警窗口干净利落地关闭了，而且没有任何其他告警被触发。等你确信问题已经真正解决时，你已经失去了一小时的睡眠时间，更大的问题是几乎睡意全无。

这种场景在各地运维团队中屡见不鲜。我们不断地调整告警阈值，试图找到一个完美的平衡点：过于敏感会被误报淹没，过于宽松则会错失真实事件。这种动态变化会导致告警疲劳——工程师被大量无需处理的告警淹没。随着时间推移，这会削弱人们对告警的信任度，并降低对真实问题的响应速度。关于告警疲劳的研究表明，这种响应迟滞现象普遍存在：安全监控领域的调查发现，超过半数的告警属于误报，而 IT 运维领域也呈现出类似的模式。这并非配置问题，而是监控复杂分布式系统时面临的一个根本性挑战。

为了优化告警规则，团队经常要花费无数个小时，他们应该这样做。但根本问题仍然存在：我们需要监控的范围超出了我们手动维护和解释的能力。

我们不愿谈论的监控悖论

对于现代系统，一个现实是它们会一直不停地增长。每增加一个新功能都会有更多的日志需要解析，更多的指标需要跟踪，更多的仪表板需要维护。最初简洁明了的架构与直观的监控，逐渐演变成了一个需要持续投入精力的庞大的生态系统。

随着系统的增长，维护负担也在增加。仅仅是保持可观测性基础设施的更新就需要花费团队大量的时间。新服务需要配置监控工具，仪表盘需要持续更新，流量模式变化时需要调整告警阈值。依赖关系不断变化，监控方案也必须随之调整。虽然这些工作都是例行公事，却也不可或缺，它们消耗了本可用于开发功能或提升可靠性的宝贵时间。

一个典型的微服务架构会产生巨量的遥测数据：来自数十个服务的日志，来自数百个容器的指标，跨多个系统的跟踪信息。当事件发生时，工程师会面临一个相关性问题：哪些信号至关重要？它们如何关联？近期发生的哪些变化可能解释这种行为？

AI 队友加入

初次接触可观测性 AI 代理的概念时，我是持怀疑态度的。这听起来像是供应商炒作与流行词汇的结合体。但随着技术的日趋成熟，早期应用方案的陆续出现，其潜力正变得越来越清晰。

关键转变在于将这些系统视为队友而非替代者。具体而言，这些队友擅长处理事件响应中人类厌烦的那些环节：在海量数据集中进行模式匹配，记住以往的每一个事件，并在周二凌晨两点保持警觉。

智能可观测性意味着你的监控系统不仅仅是收集指标和触发告警，还要能理解它所看到的信息。它能够：

• 留意不符合常规模式的现象：不仅仅是超出阈值，还有行为中那些微妙的变化，在情况变得严重之前发现事情不对劲。

• 串联技术栈中的各个点，将数据库延迟峰值与那些认证错误和六小时前的部署关联起来。

• 生成有实际用处的错误信息摘要。想象一下，提供这样的错误信息，“在下午 2:15 部署后，认证服务延迟增加了 200%；与新的 Redis 连接池配置相关”，而不仅仅是“错误率超过阈值”。

• 记住制度性知识。每一个事件都能教会可观测性代理一些东西。关于缓存的那个奇怪问题？代理会记住你是如何修复的，并在下次出现类似的问题时提供建议。

• 在规定的范围内采取行动。在适当的监督下，智能可观测性可以执行你基于定义好的策略预先批准的安全补救步骤。

传统监控与这种方法的区别在于：一个只发出告警，而另一个会分析告警的含义。传统监控告诉你有东西越过了阈值。代理辅助的可观测性会帮助解释发生了什么变化，可能与什么相关，以及接下来应该查看什么。

生产环境中究竟发生了什么

向智能可观测性的转变改变了工程工作开展的方式。在每次处理事件时，工程师不用首先花二十分钟手动在仪表板上关联日志和指标，而是可以审查 AI 生成的事件摘要，其中链接了部署时间、错误模式和基础设施变化。事件工单自动填充了上下文信息。根因分析现在从一个清晰的假设开始，而不像以前那样需要先进行广泛的调查。工程师仍然需要做出决定，但他们是基于分析数据而不是原始信号。

这节省了时间，减少了认知负荷，让你最好的工程师们可以把更多的时间投入到功能建设上，而不是用在救火上。

实际路径

如果你正在考虑采用智能可观测性，下面是一个分阶段采用的步骤。

第一阶段：只读学习

首先，将现有的遥测数据（日志、追踪信息、指标等）输入到一个处于观察模式的智能代理中，它会分析实时和历史数据，学习模式并标记异常，但不触发告警或执行操作。

这个阶段的目标是建立信任。团队看到智能代理提供了合理的建议。你捕捉到了本来可能会错过的异常。工程师们开始在深入分析日志之前查看智能代理生成的摘要信息。

第二阶段：启用上下文感知分析

这个阶段关乎让智能代理理解你特有的环境，并利用这些知识进行智能调查。它有两个协同运作的关键组件。

添加操作上下文

向智能代理提供专有知识：运行手册、服务所有权文档、架构图、依赖关系图和过往事件报告。这些信息将智能代理从一个通用的模式匹配器转变为一个理解特定系统的工具。

现在，当它检测到异常时，它有一个上下文。它不再简单地显示“检测到高错误率”，而是能具体说明：“（通信团队负责的）通知服务出现高错误率。该服务依赖于邮件网关和消息队列。最近部署记录：v1.8.2 版本于 3 小时前部署”。

启用智能关联

有了这个上下文，智能代理现在可以关联日志、指标和追踪信息中的相关信号。它将模式与过去的事件做匹配，并根据系统的实际拓扑和历史信息提出调查路径。

下面这个例子是一个成熟的智能代理生成的分析结果：

智能代理不做决定。相反，它正在做工程师手工操作通常需要 20 分钟才能完成的仪表板跳转、日志搜索及其他相关工作。它提供了一个连贯的叙事和可操作的调查步骤。

第三阶段：根据运营经验定义自动化

在观察和咨询模式下运行智能代理几周后，你会发现某些规律。有些事件会重复发生。特定的诊断步骤会反复出现。有些补救措施简单直接且风险低。这时，你就可以定义哪些工作流程在什么条件下可以自动化。

关键是从实际的操作经验出发，而不是理论。查看事件历史并问这样的问题：我们反复采取了哪些行动？哪些是安全且可预测的？哪些可以在低风险时段自动运行？

常见的自动化选项包括：

• 重启不健康的 Pod 或容器，它们未能通过健康检查

• 运行标准诊断脚本，收集分析数据

• 流量高峰时段，在预设的边界内扩展资源

• 在发生异常时触发日志收集或性能分析

但自动化需要有所限制。在启用任何自动化操作之前都应定义清晰的策略：

• 何时可以自动运行？也许只在非高峰时段，或者最初只针对非关键服务，或者从不在部署窗口或主版本发布期间运行。

• 什么需要升级？高严重性事件、面向客户的服务或代理的置信度低于某个阈值时，必须始终由人工介入处理。

• 什么需要审计？每个自动化操作都应该记录其背后的逻辑依据、触发操作的上下文和操作结果。这有助于建立责任机制，并随着时间推移不断完善自动化规则。

• 谁可以控制或暂停自动化？需要有一个简单的方法，让工程师可以在需要时（如维护、测试或敏感时期）禁用自动化。

从一两个低风险的自动化开始，观察它们在一周或两周内的表现。随着信心的建立和规则的完善，逐渐增加更多的自动化操作。我们的目标不是无人操作，而是要消除重复的劳动，使团队可以专注于需要人类判断的复杂问题。

集成的真实情形

你可能不需要替换任何东西。大多数智能可观测性平台都集成了现有的监控和可观测性工具。无论是使用开源解决方案还是商业平台，智能代理通常都可以与你当前的技术栈协同工作。

可以将其视为是在现有基础设施之上增加一个智能层，而不是推倒重来。

当它正常工作时

在管理平台可靠性和观察团队如何应对监控挑战时，你会发现某些特定的模式。随着组织尝试使用智能可观测性系统，往往会出现类似下面这样的改进：

• 事件解决速度更快（例如，“我们的事件解决时间从平均 45 分钟减少到 18 分钟，而这仅用了三个月”）。

• 提升值班生活质量（例如，“我现在可以一觉睡到天亮。智能代理处理日常事务，只有在遇到需要人类判断的事情时才会叫醒我”）。

• 提升学习便利性（例如，“每个事件都会增加制度性知识。团队的新成员可以要求智能代理：‘告诉我过去的五次数据库事件是什么以及如何解决的’”）。

• 提高主动捕获能力（例如，“在问题变成事件之前就发现并修复了它们。这种转变可能令人感到陌生，因为团队正从被动地响应事件转向主动地预防。”）。

• 工程时间从调试转移到分析（例如，“工程师花在浏览日志上的时间减少了，花在分析模式和验证修复上的时间增加了。这切实提升了运维效率。团队从救火模式转变为真正地改善系统”）。

缺点

以下是实践中通常会遇到的几个挑战：

• AI 不会在第一天就神奇地理解了你的整个系统。智能代理需要时间来学习正常的模式应该是什么样子，所以早期的建议可能会偏离目标。它可能会做出不相关的关联，或提供明显没用的建议。经过数周的学习之后，洞察力才会真正变得有价值。

• 设置上下文比你想象的更耗时。听起来，向智能代理提供运行手册、架构文档和专有知识很简单，但从中可以看出有多少关键信息只存在于人们的头脑中或过时的文档里。预计要实实在在花些时间来组织和上传这些上下文。

• 真实存在的学习曲线。团队需要了解如何配置、信任和验证智能代理的行为，并为此预留时间。

• 文化阻碍。会有一些工程师不信任 AI，也会有一些人担心工作保障。直面这个问题，明确说明增强团队能力与人员替代之间的区别。

• 调试调试器比调试系统本身更难。当智能代理判断错误时，问题可能出在信号、上下文和学习模式的组合方式上，而不是任何单一的指标或日志文件中。这会降低透明度，因此可解释性很重要。

一种用于评估智能可观测性的简单检查方法

如果不确定智能可观测性是否适合你，那么可以问下你的团队下面这些问题：

• 在事件处理期间，我们是否反复运行相同的诊断命令？

• 我们是否花费了大量的时间来关联多个工具之间的信号？

• 误报是否导致我们错过了真正的问题？

• 如果我们的初级工程师能够即时访问高级工程师积累的事件知识，他们是否能更快地响应事件，降低风险并减少混乱？

• 我们是否花费了更多的时间灭火而不是预防？

如果有两个或更多问题的答案是“是”，你将从中获益。

未来展望

系统变得越来越复杂，数据量在不断增加，停机成本变得越来越高，而人脑并没有变得更大或更快。

智能可观测性的目标不是要取代工程师，而是为他们赋能：大规模地识别模式，保留以往事件的知识，并在毫秒（而非分钟）内对信息作出反应。

从小处开始，逐步建立信任。让系统自己证明自己。可靠性的未来不是人类也不是 AI，而是拥有 AI 的人类，使他们在工作中的表现更好。

也许，只是也许，我们都可以多睡一会。

免责声明：本文所表达的观点和意见仅代表作者个人立场，不代表其雇主机构的观点、政策或实践。所有示例和建议均基于行业普遍做法及个人经验。

原文链接：

https://www.infoq.com/articles/agent-assisted-intelligent-observability/

GitHub 的工程师近期排查发现，用户反馈意外出现了“请求过多（Too Many Requests）”错误，其根源在于部分滥用防护规则在触发其生效的安全事件结束后，仍被意外长期启用。

据GitHub说明，受影响的用户并非产生了高流量请求，只是“发起了少量常规请求”，却依然触发了防护机制。经调查，这些早期为应对安全事件制定的规则，其依据的流量特征在当时与滥用行为高度相关，但后续却开始匹配部分未登录用户的合法请求。GitHub 表示，这类检测机制结合了行业标准的指纹识别技术与平台专属的业务逻辑，而“多维度信号组合偶尔会产生误判”。

GitHub 还量化了这套多层级检测信号的实际运行表现。在匹配到可疑指纹的请求中，仅有一小部分会被拦截，只有同时触发业务逻辑规则的请求才会被阻断，这类请求约占指纹匹配请求的 0.5%~0.9%；而误判请求在总请求量中的占比则极低，约为每 10 万次请求仅出现数次。尽管如此，GitHub 在博文里强调，该问题对用户造成的影响仍不可接受，并以此次事件揭示了一个更普遍的运维问题：应急防护规则在安全事件发生时通常能正常发挥作用，但随着威胁模式的演变以及合法工具和使用场景的变化，这些规则会逐渐 “失效脱节”。

GitHub 此次复盘的核心结论之一就是，多层级防护体系会增加定位故障根本原因的难度。工程师需要跨多层基础设施追踪请求链路，才能确定拦截行为发生在哪个环节，而实际排查的难点在于，每一层基础设施都具备合理的限流、拦截权限，要定位具体是哪一层做出的拦截决策，就必须对多个采用不同数据格式的系统日志进行关联分析。

图片来源：GitHub

为了解决当下的问题，GitHub 对所有防护规则开展了全面复核，对比每条规则当前的拦截范围与最初设计的防护目标，移除了已经没有实际防护意义的规则，同时保留了针对现存威胁的防护措施。从长期来看，GitHub 表示正投入资源完善防护规则的生命周期管理体系，打造更完善的跨层级可观测的能力，实现限流与拦截行为的源头追踪；将应急防护规则默认设为临时生效；新增事件后复盘机制，推动应急防护规则向可持续、精准化的解决方案演进。

尽管 GitHub 的博文聚焦于规则生命周期管理与跨层级可观测性，但这种采用“纵深防御”架构的请求处理流水线，在其他处理互联网流量的大型平台中也十分常见。例如，Vercel公开的请求处理生命周期中提到，请求会经过其防火墙的多个防护阶段，覆盖网络层（L3）、传输层（L4）和应用层（L7），后续还会针对项目级策略增加 Web 应用防火墙（WAF）防护环节。Vercel 还指出，各防护层级间存在反馈机制，若某条 WAF 规则触发了持续性拦截动作，上游防护层会提前拦截后续的同类请求。

这种分层防护的设计并非仅存在于边缘流量管理领域：Kubernetes的API服务器安全模型也采用了明确的阶段式设计，准入控制器会在身份认证、授权校验完成后，数据持久化之前拦截请求，形成一套结构化的校验链路，后续可在此基础上不断叠加新的策略与安全检查规则。

这些案例共同揭示了大型系统中一种普遍的设计权衡：多层级防护机制能提升系统的抗风险能力与灵活性，但也会增加防护规则“脱离其设计背景，依然失效存在”的风险。GitHub 的此次经历也印证了，纵深防御体系的长期有效性，不仅取决于防护规则的部署层级，更在于随着系统与使用模式的演变，能否清晰把控每条规则的设计初衷、实际影响与生效周期。

原文链接：

GitHub Reworks Layered Defenses After Legacy Protections Block Legitimate Traffic

LinkedIn重新设计了其静态应用安全测试（static application security testing，SAST）流水线，以便在基于 GitHub 的多仓库开发环境中提供统一、可强制执行的代码扫描能力。该举措源于公司的安全左移（shift-left）战略，也就是通过在 Pull Request 中直接提供快速、可靠且可落地的安全反馈，增强 LinkedIn 代码与基础设施的安全性，帮助保护用户与客户。

从宏观层面来看，SAST指的就是通过分析源代码，在开发生命周期早期识别潜在的漏洞。在 LinkedIn 的规模下，传统方案依赖多个相互独立的扫描器与定制化集成，导致覆盖度不均、流水线健康状况可见性有限，并给开发者带来额外的负担。此次重新设计旨在标准化扫描能力、简化接入流程，并将安全更深度地嵌入开发者工作流，同时避免引入性能瓶颈。

在设计初期，LinkedIn 工程师确立了核心指导原则，那就是优先以开发者为中心的安全设计，最小化对工作流的干扰；具备可扩展性，允许其他团队添加规则或集成；具备高韧性，避免故障影响开发者；具备可观测性，能够在大规模场景下监控覆盖范围与性能表现。

新架构基于GitHub Actions进行编排，并整合了两款核心扫描引擎CodeQL与Semgrep，选择它们是因为二者覆盖范围互补且易于扩展。LinkedIn 工程师实现了自定义工作流，用于管理规则执行、编排扫描流程并处理扫描结果。所有漏洞发现结果均基于SARIF标准进行规范化，并补充元数据，为开发者与安全团队提供清晰的修复指引与可落地的上下文信息。

使用 CodeQL 的 GitHub Actions 工作流的宏观概览 (图片来源：LinkedIn博客文章)

LinkedIn 工程师最初希望使用 GitHub Required Workflows 来强制执行安全流水线，并在数万个仓库中实现定时扫描，但该功能不支持定时任务与自动部署。因此，工作流文件必须被推送到每个仓库才能可靠地传播变更，这在大规模场景下会带来一定的挑战。

为了解决该问题，LinkedIn 在每个仓库中部署了轻量级的桩工作流（stub workflow），将实际执行委托给集中维护的中心工作流。这种设计使得扫描逻辑、强制策略与可观测性埋点的更新能够即时生效，无需修改单个仓库。同时，还有一套漂移管理系统（Drift Management System） 持续校验桩工作流的存在与否与配置情况，新仓库也会自动预置该文件。这套组合方案确保了 LinkedIn 多仓库环境下的统一覆盖与强制执行，在大规模场景下保持可靠性与开发者工作流效率。

强制机制通过GitHub仓库规则集（repository rulesets）来实现，也就是阻塞 Pull Request 合并，直到静态分析完成且漏洞处于可接受的风险阈值内。为避免扫描器故障或基础设施异常中断开发者流程，LinkedIn 构建了多重安全机制，包括紧急停止开关（kill switches）与自动降级策略。在故障场景下，系统会注入空 SARIF 报告以解除阻塞的合并请求，同时仍会采集遥测数据用于事后分析。

阻塞模型的流程（图片来源：LinkedIn博客文章)

正如 LinkedIn 的工程师所强调的：

我们从碎片化的生态系统，转向了一套统一、原生基于 GitHub 的安全流水线，在不拖慢开发者速度的前提下，提供一致的覆盖度与可落地的安全反馈。

该 SAST 流水线会收集详细的执行指标、故障报告与接入统计数据，使安全团队能够监控覆盖范围、可靠性与组织级影响。LinkedIn 指出，SAST 只是整体应用安全战略的一部分，该战略还包括依赖项扫描与密钥检测，共同构成一套覆盖代码与基础设施的一体化安全防护体系。

原文链接：

LinkedIn Leverages GitHub Actions, CodeQL, and Semgrep for Code Scanning