121 Harness incidents · 2026年3月 — official updates, affected components, duration and resolution details.
我们目前正在调查这一问题.
在初始化阶段,关于VM基础设施的CI管道正在失败,因为任务交给了预定库外的代表
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
□ ** 摘要** 2026年10月19日,大约从12:10 AM到12:55AM PDT,Prod4上的客户遭遇错误并间歇地无法获得Harness管道服务. 严重的管线处决导致CPU和管线服务记忆使用量急剧上升,短期内,所有服务案例都无法得到。 Harness工程在垂直和水平上都对服务进行了分级,从而恢复了服务. 正在推出针对基本行为的解决方案。 □** 轮回原因** 10月19日,大量同时行刑,且执行图非常大,促使集群资源急剧增加. 服务储存并取回了这个完整的执行图,用于可视化目的并进一步推动通往下个州的管道. 由于CPU和内存的急剧上升,我们在Prod4上的自动扫描器在缩放资源方面花费了比平时更长的时间. 作为固定的一部分,执行图更新现在将逐步处理出图表变化而不是完整的图表. 它正在分阶段推出,并将尽早完全推出。 □**影响** * 受影响用户:Prod4上的客户。 * 症状:哈内斯平台没有管道功能。 * 数据:没有数据损失。 * 建议的变通办法:客户不需要。 机能工程解决了这个问题. * 影响持续时间:全程缺勤约20分钟,性能退化25分钟。 恢复后,与客户保持平台稳定性。 □** 补救** ** 即时** Harness 工程既将管道服务垂直的\(每个实例增加资源),又横向的\(更多实例), 并且取消了不健康状态下的事件。 案件数量稳定,恢复正常服务。 系统将保持扩大,直到修复工作完全展开。 ** 永久固定和行动项目** 为了防止这些问题再次发生,哈妮丝 1. 调整自动愈合/缩放过程,使影响微乎其微。 2.优化执行图流,使大图能更快地被处理.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
。 。 。 。 。 。 。 .
自动翻译自官方事件更新。
目前我们正经历HTTP 429(速率限制)错误, 当Harness Cloud建立访问 Maven Central, 这可能会影响建设执行. 我们的团队正同索纳特公司积极合作,以尽快解决这一问题。 随着我们的进展,我们将提供进一步的最新情况.
这一事件已经得到解决.
tldr:\(有 maven Central 限制的短暂速率) 详细情况如下
自动翻译自官方事件更新。
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
我们正在继续调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
一项措施已经执行,我们正在监测结果。 我们确认这个问题已经解决了.
这一事件已经得到解决.
# 1. 总结 2026年10月6日,含有IaCM级的管线在Prod1上无法开通约两小时. 受影响的用户在管道试图制定其执行计划时看到了一个错误。 没有使用IaCM阶段的管道在整个过程中继续正常运行。 其根本原因是处理IaCM阶段执行的服务存在内部伐木缺陷:在具体而罕见的计时条件下,该服务本身的伐木系统最终可能会无限期地等待下去,这反过来又使负责编制管线执行计划的更广泛进程停滞不前. 这个问题是由一个客户的管道异常地大爆发的木材活动所引发的。 我们解决了即时影响,将服务推回之前的稳定版本,目前测试中有一个永久的代码固定. # 2. 影响 * 在Prod1上使用IaCM级的所有管线大约两小时无法开通。 * Prod1集群的多个客户受到影响。 * 未使用IaCM阶段的管道没有受到影响,继续正常运行。 * 没有因这一事件而丢失数据。 * 作为用来解决这一事件的回滚的副作用,暂时恢复了对一名客户的不相干固定\(预计在长期运行的管道中某一认证标志仍然有效多长时间\). 当天晚上又重新应用了这个装置. # 3. 根源 负责IaCM管道阶段的服务通过一个内部队列记录其活动:日志信息被放入队列,一个单一的背景工作者不断从中读取并写出消息. 另外,该服务有一个过滤器,可以将某些日志消息的严重性重写回同一队列上. 在一个特定的,狭义的时间条件之下,这造成了一个僵局,如果队列恰好在重写的消息被重新提交时完全满了,负责释放队列上的空间的一位工人会自己被卡住等待空间解开,这个条件是永远无法解决的,因为这是唯一能够解开该空间的东西. 一旦发生这种情况,需要记录任何内容的服务的所有其他部分也都陷入了等待状态,从而进入了使用IaCM级的任何管道的管道计划创建过程。 # 4. 决 定 * 服务恢复到最后的稳定版本,解决了立即发生的事件。 # 5. 预防行动 1. ** 优化基本缺陷**: 优化并调制了日志过滤器,这样一来,在生成日志行的线程上会发生重写一个消息的严重性,而不是通过同一背景工人的队列重新提交,从而完全消除了僵局的条件. 2. ** 加强对伐木队健康的监测**:增加指标并提醒这一内部排队,以便这一阶层的饱和状态自动贴上我们待命小组的网页,而不是依赖客户报告。 3. ** 评估极限,用非常大的管道进行高压力测试**:
自动翻译自官方事件更新。
2026年10月7日,从协调世界时08:00到协调世界时11:00(下午1:30到4:30,PM IST),Prod 7集群上的一些管道处决在"政策"(OPA)分级评价中间歇性地出现故障.
自动翻译自官方事件更新。
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
页:1 Prod 2上的客户在启动时偶尔会遇到几个验证步骤的故障. 受影响的步骤在发射后不久就失败了,并发出一条信息,表示持续核实\(CV\)无法到达内部的Harness服务. 这个问题源于最近的一项服务更新,该更新引入了连接集成,以提高性能和可靠性,并采用与接收服务超时不相容的留置设置。 没有丢失或损坏客户数据。 * 客户影响 使用CV校验Prod-2上的步骤的客户在事件窗口中发现间歇性步骤故障. 失败率很低——大多数处决在整个窗口都顺利完成. 未使用 CV 校验步骤的管道不受影响 。 根原因 : 最近的CV服务更新引入了连接集合到内部平台组件,持续时间比该组件闲置的超时时间长. 闲置时间足够长的连接被服务器静默地关闭;CV服务没有检测到这一点,也没有对这种故障的再试逻辑,导致它们作为校验步骤出故障而直接浮出水面. 这个问题是断断续续的,因为它只影响到那些恰好闲置到过期的连接。 缓解 连接保持时间被缩短到属于接收服务的闲置超时范围. 失败立即降到了接近于零,在任何生产环境中都未观察到任何此类进一步失败。 下一个步骤 为防止再次发生,哈妮丝将: * ** 连接处理:** 引导默认的保持- 静态并允许对连接失败进行自动重试, 从而透明地处理 stale- 连接错误 。 * ** 在逐步启动时添加复原力:** 在校验步骤开始时,对内部服务呼叫采用反向重试,因此孤立的瞬间故障不会作为即时步骤故障而浮出水面。 *** 改进提醒:** 加强内部连接出错率监测.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
我们正在继续调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
这一事件已经得到解决.
□ 总结 2026年10月6日**星期二**,在**Prod1**中使用**OpenTofu插件**的IaCM管断断续续地失败了一个生产账户 受影响运行成功注入了秘密,后步骤超时或认证失败. 同一管线在重试时经常成功,配置不变. 典型的死刑失败持续了大约90分钟。 其他哈尼斯模块没有受到广泛影响。 我们没有客户数据丢失的报告。 在象征生命中完成的管道不受这一缺陷的影响。 □ 根源 IaCM阶段铸造一个小时后失效的认证符. 政策检查后来长期拒绝代号,因此步骤超时或认证失败. 一个小时的寿命是固定的。 大约90分钟的跑道越过了一小时的地标,这就是为什么故障出现在更长的管道上,并且常常在较短的重试中被清除. 同一账户中的一组单独的计划错误来自客户工作空间的证书设置,并且不在本次事件之外. □ 影响 * ** 产地:** 使用IaCM插件与OPA sdk交谈的IaCM管道. *** 客户经验:** 秘密注射后间歇性超时和认证故障,运行时间超过约一小时。 *** 环境:** Prod1,一个生产账户 * ** 数据:** 未报告数据损失。 □ 补救 * ** 立即:** 打开了受影响的Prod1账户的状态页面,并运出一个临时的IaCM管理器更改,用于在插件修补时对所观察到的失败进行一个类别. * ** 常设:** 装入了 OpenTofu 插件热补丁, 所以符号过期是可配置的 。 在生产过程中,寿命被提升到大约6小时,所以长长的管线不会活得超过象征. hotfix在QA中被验证,并被部署到Prod1. 我们对造成的破坏表示歉意。 如有进一步问题,请联系哈妮丝支持联系人.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
我们正在继续监测任何其他问题.
核实了固定办法并解决了SSO问题.
□ Okta 应用程序 SP- 启动的 SSO 登录失败 总结 在协调世界时2026年10月5日,18:18至协调世界时2026年10月6日,00:26之间,一些哈尼斯客户无法通过SAML Single Sign-On\(SSO\)向哈尼斯托管的MCP服务器签约. 主要Harness门户网站用户认证仍然全面运作. 受影响的用户看到登录错误,或者被重定向到无效的SSO页面而不是完成登录. 这个问题由Harness身份服务HarnessID的版本升级被打破而来. 我们用一连串的热补丁把它修好了,SSO登录系统完全恢复了所有受影响的客户. # 影响 用户通过SAML SSO签名到Harness MCP无法完成认证. 现有的依赖于SSO的MCP会话无法刷新,因此一些用户不得不再次签名,不能. 大部分事件期间,非SSO登录Hosted MCP的工作. 没有丢失或披露客户数据。 使用自己通用的 SAML 2. 0 应用程序配置的客户没有受到影响。 # 根源 2026年9月29日,"Harness"应用程序的更新版被发布到奥克塔融合网. 更新增加了对多个响应\(ACS\) URL 注册的支持, 这样运行 Harness 的客户可以配置多个回调 URL 。 Harness在它向Okta发送的SAML认证请求中包含了一个Assertion ConsumerServiceURL值. 在本次更新之前,Okta没有在未配置额外的ACS URL的情况下验证该应用实例的值,而是将SAML的断言还给应用程序的默认ACS URL. 更新后,这一验证在所有现有的应用程序中开始活跃,包括客户从未配置额外ACS URL的情况. 由于请求的值没有出现在实例的已注册列表中,奥克塔返回了一个HTTP 400错误. 更新的应用程序通过Okta的标准OIN出版审查,其中包括针对已出版的集成的现有设施进行后相兼容性核查. 对于没有配置额外的ACS URL的事件,验证行为的这一变化在审查期间没有被浮出水面,因此在发布时已经到达了客户. 补救 ** 立即反应** 在状态页面上发布了两个工作变通:来自Okta\(IdP启动的登录\)的Harness平板的签名,或者在Harness Okta应用程序的附加ACS URL域中注册应用程序的Okta SSO URL. 与每个报告受影响的客户直接接触并验证其注册。 ** 决议** 有意避免将应用程序回滚至前一版本,因为这只会将同样的干扰推迟到下一期发布. 每一个受到影响的客户都被解锁通过ACS URL注册,我们正与Okta合作,使ACS URL的验证再次成为条件,这样没有附加ACS URL配置的事例的行为与以前完全一样,不需要客户行动. # 行动项目 为防止这些问题再次发生,哈妮丝将采取以下行动项目: 1. 与 Okta 合作恢复有条件的 ACS URL 验证,因此没有配置额外 ACS URL 的事例行为与以前完全相同,不需要客户行动. 2. 在Harness文档中发布Harness OIN应用程序的专用配置指南,包括回复\(ACS\)URL要求. 3. 在Okta自己的审查之外,为今后对已公布的Okta应用程序的任何更新,增加针对现有客户配置的独立放行前核查步骤。 4. 迁移用户认证到Harness ID,这完全消除了对这一验证行为的依赖.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
我们通过已出版的Harness Okta应用程序找出了一个仅适用于SP启动登录的问题。 在最近对该应用程序进行更新之后,当配置的SSO URL从附加ACS URL中缺失时,这些登录尝试返回了HTTP 400出错. Okta的通用 SAML 2.0 配置不受影响 。 立即解决方案 : 使用境内流离失所者启动的登录。 从奥克塔的Harness应用平板开始登录. 或者说 将您的 Harness SSO URL 添加到已发布的 Harness Okta 应用程序中的额外 ACS URL 中 .
这一事件已经得到解决.
# 1. 总结 2026年9月29日起,通过Okta整合网络\(OIN\)中已公布的Harness应用程序签入Harness的客户无法完成由SP发起的SSO登录. 受到影响的用户从Okta处收到一个HTTP 400错误,而不是被签入. Okta对已公布的Harness应用程序现有装置的响应\(ACS\)URL进行了验证。 首份报告一小时内就公布了变通办法,每个受影响的客户都被解禁。 # 2. 影响 * 影响仅限于客户使用Okta整合网络公布的Harness应用程序进行SP启动的登录\(从Harness\开始登录)。 这些尝试从奥克塔返回了一个HTTP 400错误。 * IdP启动的登录从奥克塔的Harness瓷砖开始,一直持续工作。 * 客户使用自己的通用SAML 2.0应用程序配置在Okta没有受到影响。 * 没有丢失或披露客户数据。 # 3. 根源 2026年9月29日,"Harness"应用程序的更新版被发布到奥克塔融合网. 更新增加了对多个响应\(ACS\) URL 注册的支持, 这样运行 Harness 的客户可以配置多个回调 URL 。 Harness在它向Okta发送的SAML认证请求中包含了一个Assertion ConsumerServiceURL值. 在本次更新之前,Okta没有验证该值用于没有配置额外ACS URL的应用程序实例,而只是将 SAML 断言返回到应用程序默认ACS URL. 更新后,这一验证在应用程序的所有现有实例上开始活跃,包括客户从未配置额外ACS URL的情形. 由于请求的值没有出现在实例的注册列表中,奥克塔以HTTP 400出错拒绝了认证请求. 更新后的应用程序通过Okta的标准OIN出版审查,包括对照已出版的集成的现有设施进行后向相容性核查. 对于没有配置额外的ACS URL的事件,验证行为的这一变化在审查期间没有被浮出水面,所以发布时会到达客户. # 4. 补救 ** 立即反应** 在状态页面上发布了两个工作变通:来自Okta\( IdP- 主动登录\) 的 Harness (Harness) 牌入; 或者在 Harness Okta 应用程序的附加 ACS URL 域中注册应用程序的 Okta SSO URL 。 支助直接与每个受影响的客户进行接触,并核实他们的注册。 ** 决议** 有意避免将应用程序回滚至前一版本,因为这只会将同样的干扰推迟到下一期发布. 每一个受影响的客户通过ACS URL注册被解锁,我们正与Okta合作,使ACS URL验证再次成为条件,这样,没有配置额外ACS URL的事例的行为与以前完全一样,不需要客户行动. # 5. 行动项目 为了防止这些问题再次发生,我们正在研究 ** 行动项目** | -- -- QQ 与 Okta 合作恢复有条件的 ACS URL 验证, 因此没有配置额外 ACS URL 的例行为与以前完全相同, 不需要客户动作 。 | QQ 在 Harness 文档中发布 Harness OIN 应用程序的专用配置指南, 包括回复\ (ACS\) URL 要求. QQ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ QQ 迁移用户认证到 Harness ID , 这可以完全消除对这一验证行为的依赖. |
自动翻译自官方事件更新。
我们目前正在调查这一问题.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
页:1 2026年9月29日大约**11:37 AM到3:01 PM PDT\(18:37–22:01 UTC\)**之间,使用Harness CI自办的Linux云跑道的客户在**prod1/prod2\(us-west1\)** 管道执行中经历了断断断续续的联网故障——主要是Git/网络在获取源代码时超时. ** 循环原因** 这主要是由于我国的NAT饱和,由于临时云提供商的计算能力而加剧,防止了那里新的VM供应。 影响 * 运营自营Linux CI的客户在我们西部建造1号楼,看到** 不间断地建造/管道故障**,而不是完全停电。 * 观察到的客户端错误包括Git获取超时,例如`未连接到github.com端口443:连接超时' ** 补救** * ** 即时:** 从饱和的我们-西向中央1\(部分受中央1能力所限;重新启动受影响的云NAT网关,稳定了输油管联网)路径上重新平衡ARM的建设-VM载荷. ** 行动项目** 1. 确保增加NAT网关/IP能力\(正在进行中) 2. 改进NAT饱和度检测并提前提醒客户撞击. 3. 评估跨区域能力突发事件,使单一区域的计算不足不会阻碍减少故障.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
一项措施已经执行,我们正在监测结果.
我们正在继续监测任何其他问题.
这一事件已经得到解决.
** 概要** Prod-2上的客户在持续核查管道的故障率上升。 核查工作未能完成或报告出错,因为CV数据收集人员无法与协调其工作的平台服务沟通. 这是由于一个意外的交通高峰 进入我们的后端系统 通过扩大受影响的平台部分恢复了服务。 没有发生数据丢失或腐败。 ** 客户影响** 对Prod-2进行持续核查的客户在事故窗口期间发现核查管道工作失败或超时。 在此期间发生的相当一部分核查工作以操作失败而告终。 不使用CV的管道继续正常运行. ** 循环原因** 大型自动供给运行在一个短窗口中创造了大量持续的CV监测人员,这超越了共享平台组件. 同时发出的外出电话突然增加,使每个服务实例的现有网络连接都耗尽了。 ** 缓解** 提高了CV服务的最大缩放限度,使其能够扩大能力以满足需求. 推广工作完成后不久,失败就停止了。 ** 下一步** 为防止再次发生,哈妮丝将: * ** 增加容量头室并增加提供护栏:** 提高CV服务缩放限值,在爆破负荷下保持头室,并对监测服务的批量供应实行限速. *** 恢复能力:** 增加指数回转和紧张度,用于工人复试,并使用可重复使用的连接池来减少间接费用并避免在高通量下发生瞬间故障。 *** 改进监测和警报:** 加强对异常的每个账户工人增长率的警示,从而发现类似情况并更早采取行动.
自动翻译自官方事件更新。
2026年9月28日,我们在导出步骤中观察到了从Harness文件站复制文件的问题,文件被复制为无效/空文件. 因此,所有使用Filestore API的管道在事件窗口期间被封锁. 这个问题的起因是地物旗的推出,一旦发现问题,就重新出现。 所有的手术都恢复正常了.
页:1 2026年9月28日,Prod-2上的一些客户在使用管道表达式来读取文件存储器内容的CD管道步骤上遭遇了故障\(例如:``\. 受影响的表达式返回无效而不是预期的文件内容,导致依赖步骤失败或行为不正确. 这个问题被追溯到一个平台更新,它收紧了对文件存储API的授权检查. 更新内容被回滚,文件存储表达式此后一直正常运行. * 客户影响 * 只有Prod-2上的通过表达式读取文件存储内容的管道步骤受到影响。 不使用文件存储表达式的管道没有受到影响 。 * 受影响的表达式决定无效,导致依赖于配置或设置文件的步骤会失败或产生不正确的输出. * 没有修改文件存储内容。 没有披露任何文件、秘密、证书或文物,也没有丢失任何数据。 根原因 : 作为正在进行的安全举措的一部分,Harness在几个平台的API上进行了更严格的授权检查,包括服务于文件存储内容的API. 当一个管道评价一个文件存储表达式时,一个内部的Harness服务呼叫另一个来取回文件. 新的授权检查失败,导致请求被拒绝,表达方式回落无效。 缓解 一旦平台更新被确定为原因,便被卷回了整个生产环境. 文件存储表达式自回滚后已正确解决. 无需客户采取行动。 * 预防措施和下一步措施 * ** 影响APIs的审计:** 审查所有实行更严格授权检查的API,以确保内部服务对服务电话得到正确核算。 *** 改进试验范围:** 强化自动测试套件,将文件存储表达式评价纳入整个管道执行路径
自动翻译自官方事件更新。
我们目前正在调查影响Palo Alto网络防火墙保护环境的客户的连接问题。 这些防火墙正在阻断与Harness API的连接,这可能导致: - 输油管处决失败 - 无法部署应用程序 - 访问Harness平台功能时断断续续的超时 - 与第三方工具整合失败 - 代表与Harness平台的连接 这个问题不是由哈尼斯服务中断引起的,而是由你的网络方面防火墙规则引起的. 我们建议客户 给我们的DNS端点破例.
现有缓解措施:网络安全政策阻碍的交通便利 我们已查明一个问题,即有些客户可能无法进入Harness,因为Harness流量被Palo Alto网络安全控制归类为“AI-Platform”,随后被客户防火墙/INET政策所封锁。 如果你正经历这个问题: 请与贵组织的网络/防火墙/网络安全小组联系,要求通过你的Palo Alto防火墙政策允许必要的Harness流量. 作为缓解措施,客户可以允许“AI-Platform”类URL用于所需的Harness端点,或者根据其安全政策,将受影响的Harness域/FQDN添加到其组织的已核准/允许清单中。 在更新防火墙政策后,应恢复对Harness的访问. 重要:防火墙政策由客户网络/安全团队管理. 如果哈尼斯端点被帕洛阿尔托错误分类,客户也可以请求帕洛阿尔托网络进行URL类审查.
2026年9月23日, io被Palo Alto网络团队归类为AI平台服务. Palo Alto Networks于8月向客户发送了关于重新分类的通知. 这一变化可能会将AI平台服务置于与app.harness不同的政策下. io之前的规则分类,计算机和互联网信息. 所采用的政策取决于客户设置。 客户应与其内部网络小组和Palo Alto Networks讨论这种分类和警报.
。 。 。 .
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
总结 2026年9月22日,我们三个出站网关在一个地区变得不健康,开始拒绝一小部分新的出站网关尝试. 同一天,这个问题得到了彻底解决,没有再发生或后续影响。 其根本原因是这些网关上内部交通监测缓冲器饱和,导致其健康检查反应过慢并明显不健康。 # 影响 * 一个区域只有三个网关事件受到影响;同一区域的其他区域和其他网关没有受到影响。 * 没有连锁故障,这个问题通过单一回合的网关重启得到了完全解决,之后没有再发生后续问题. # 根源 我们的外出网络网关有一个内部组件,用于监测网络流量,以获取业务能见度。 在持续的高流量下,这个组件的内部缓冲器会变得饱和,从而产生足够严重的后压来减缓网关自身的健康检查反应,超出我们负荷平衡器允许的超时. 一旦超时,负载平衡器标记受影响的网关不健康,并开始拒绝一部分预定给他们的新连接。 在整个事故期间,实际数据包转发继续正常进行。 这具体是一个健康检查和监测缓冲问题,而不是网关核心转发能力的失败。 # 决断 3起受影响的网关事件被手动重新启动,清理了饱和监测缓冲,并立即恢复了正常的健康检查行为. 重启完成后即停止拒绝连接,无需进一步干预。 # 预防行动 行动** | -- -- 将目前所有网关的交通监测方法替换为更有效、更低的管理方式,这种方式不能饱和,并且在任何客户可见的影响之前就发出警报。 在固定的时间表上实施自动、定期地替换长期运行的网关实例,因此任何实例都无法累积这一事件中与年龄有关的退化。 | 将网关实例迁移到网络优化的基础设施中,其网络能力大大增强,更适合持续的高通量流量。 · 提高现有监测缓冲器的利用率,同时推出较长期的替换。 • 特别加强对网关健康检查后期反应的警示,以便在出现客户之前及早发现退化的迹象。 |
自动翻译自官方事件更新。
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
与前一根本因相同.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
这一问题已经确定,一个解决办法正在实施之中.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
□ 总结 2026年9月21日,Prod 2的客户出现退化,然后基本无法使用部署仪表板约3小时. 造成这一问题的原因是,这些仪表板后面的一组分析查询读取的数据远远超出需要,从而耗尽了为它们服务的数据库的能力。 受影响服务的滚动重启完全恢复了仪表板,平台自此稳定. □ 客户影响 Dashboard页面在协调世界时14:48至18:11之间缓慢加载或超时. 管道执行和部署记录运行在不同的基础设施上,并继续正常运作。 没有发生数据丢失或腐败。 □ 根源 仪表盘查询在用来将最大的表格分割为周段的列上缺少一个时程过滤器,因此每个查询都读取了所有历史数据,而不只是请求的期间. 正确性从未受到影响——仪表板返回了正确的结果;只有读取的数据量过多才能产生正确的结果. 随着数据量的增加,这些读取的成本超过了数据库所能服务的内容,对失败的查询的回覆会增加更多的负载,因此在服务重新启动之前,条件还不清楚. □ 缓解 * 对受影响的服务进行了滚动重新启动,从而停止了重试周期,使数据库能够完成尚未完成的工作 * 确认的仪表板延迟和数据库连接使用恢复到正常水平 □ 下一步 为防止再次发生,哈妮丝将: * 将缺失的时间段过滤器添加到受影响的仪表板查询中,这样每个都只读取请求的期间 * 用有限度的后退式复试取代立即复试 * 通过增加数据库连接使用情况和每克执行费用提醒,改进检测
自动翻译自官方事件更新。
