Flexera 中断历史

1. 2026年10月27日 UTC 17:00identified

   事件描述:我们正在调查影响Technopedia内容更新的延误. 数据平台,IT能见度,API服务使用的Technopedia内容自10月22日起因多次数据处理故障而不再被刷新. 因此,在受影响的服务中,客户可能看到过时的Technopedia内容。 优先事项:P2 恢复活动:我们的技术小组开展了恢复行动,以解决数据处理故障,并更新了基本内容。 目前正在制作目录,我们正在通过完成监测这项活动。 随着复苏的进展,我们将提供进一步的最新情况.

2. 2026年10月28日 UTC 01:44identified

   Technopedia内容更新仍在进行中。 我们的技术小组继续监测完成后的更新情况。 一旦完成处理,我们将确认,在受影响的服务中,可以获得最新的Technopedia内容,以确保恢复正常的内容更新操作.

3. 2026年10月28日 UTC 09:39identified

   Technopedia内容仍在更新中,并继续由我们的技术小组密切监测。 完成后,我们将验证所有受影响服务的最新内容,以确认恢复正常业务.

4. 2026年10月28日 UTC 10:35resolved

   Technopedia内容更新工作已经完成,验证确认,在受影响的服务中可提供最新内容。 正常内容更新操作已恢复,问题已解决.

自动翻译自官方事件更新。

1. 2026年10月22日 UTC 07:05investigating

   事件描述:我们正在调查一个影响英国南部地区Snow Atlas SAM核心功能的问题。 一些客户可能遇到访问用户功能的问题,在访问计算机细节时可能会出错. 优先事项:P2 恢复活动:我们的技术小组正在积极调查这一问题并评估影响的范围。 我们正在努力查明根源并恢复受影响的功能。 一旦获得更多信息,将提供进一步的最新资料.

2. 2026年10月22日 UTC 07:21monitoring

   我们的技术小组查明了影响支持受影响功能的服务部分的超时错误,并进行了有针对性的服务重新启动。 在这些恢复行动之后,用户和计算机细节功能在验证过程中正在成功响应. 我们正在继续监测服务行为,并进行最后验证,以确认持续稳定.

3. 2026年10月22日 UTC 07:38resolved

   继先前采取的回收行动之后,我们的技术小组完成了更多的验证和监测。 用户和计算机细节功能保持稳定,没有观察到其他问题。 正常运行已得到确认,目前认为这一事件已得到解决.

自动翻译自官方事件更新。

1. 2026年10月15日 UTC 22:37resolved

   事件简介:在澳大利亚地区预定的Flexera One IT资产管理2026R1.4生产发布后,我们遇到一个影响APAC的Flexera One IT资产管理服务的问题. 因此,在影响期间,客户无法进入Flexera One信息技术资产管理系统。 优先级:P1 影响开始:2026年10月15日11:34AM PDT 影响结束:2026年10月15日12:32 PM PDT 恢复活动:我们的技术小组确定了一个影响预定生产发布后服务组成部分的问题。 对受影响的组成部分进行了补救,以恢复服务供应。 追回后,APAC的Flexera One IT资产管理服务恢复正常运行,目前认为这一问题已经解决.

2. 2026年10月21日 UTC 23:40postmortem

   ** 说明:** Flexera One -- -- 信息技术资产管理 -- -- APAC -- -- 服务在2026R1.4之后无法使用 释放 **时间范围:** 2026年10月15日,11:34 AM PDT - 2026年10月15日,12:32 PM PDT □事件摘要 2026年10月15日,APAC区域使用Flexera One IT资产管理的客户遭遇服务中断,无法访问该应用程序. 中断发生在ITAM 2026R1.4生产放行完成后. 虽然最初可以提供服务,并在释放后正常运行,但申请随后无法进入。 技术小组调查了干扰情况并查明了影响申请初始化的失败。 进一步调查显示,生产环境仍然依赖先前的应用程序初始化进程,而向更新流程的过渡正在进行。 虽然应用程序在发布期间已成功初始化,但由于配置过时,替换程序无法完成。 受影响的替换情况无法顺利地完成初始化或通过必要的健康检查,使申请无法恢复正常运行。 技术小组纠正了生产配置,以参考更新的初始化过程,并进行了一次实例更新。 在这些变化之后,受影响的实例成功启动,ITAM服务可用性恢复到大约12:32 PM PDT. □ 根源 事故的原因是,在向APAC生产环境更新流程过渡期间,仍然依赖于先前的应用初始化流程的生产. 虽然中转和用户接受测试环境已经向更新的流程过渡,但APAC生产环境保留了参考了之前初始化流程的配置. 在2026R1.4生产发布期间,应用实例被使用更新后的程序手动初始化,使得ITAM尽管仍存在生产依赖性,仍然可以开始正常运行. 支持前一个进程的构成部分后来根据一项谅解缩减,即更广泛的过渡已基本完成。 当启动替换应用程序时,生产配置继续引导它们进入之前的初始化过程. 因此,受影响的病例无法顺利地完成初始化或通过所需的健康检查,导致服务中断。 经证实,事件的根本原因是生产仍然依赖以前的初始化过程。 修正生产配置以使用更新的初始化过程可以消除这种依赖性,并允许替换实例成功初始化. □ 补救行动 在事件应对期间采取了以下行动: 1. ** 启动的事件调查:** 技术小组调查了应用程序的无用情况并查明了影响APAC生产环境中应用程序的初始化和健康检查的故障。 2. ** 确定的问题:** 调查确定,生产配置继续参照以前的应用程序初始化进程,而不是更新后的进程。 3. ** 经更正的生产配置:** 生产配置经过了更新,以参考正确的应用初始化过程,消除了对上一个过程的依赖. 4. ** 重新提出申请:** 技术小组在配置更正后进行了一次更新,使替换实例能够成功初始化。 5. ** 经核实的服务回收:** 技术小组证实,受影响的情况正在顺利启动,应用程序健康检查正在通过,ITAM服务已恢复正常运行。 □ 未来预防措施 事件发生后,进行了回顾,以审查应用初始化过程、剩余的生产依赖性、释放认证程序以及改进事件发现和应对的机会。 下列纠正行动和改进活动已经完成或正在进行: 1. ** 制作配置更正:** APAC生产环境已经更新,以使用正确的应用初始化过程,取代了之前的配置. 2. ** 依赖性鉴定:** 已建立后续行动,在遗留平台组件缩小规模或退役前再加一个验证步骤,确保生产服务完全转型,前一个平台上不存在剩余依赖性. 3. ** 释放和应用健康检查审查:** 正在根据这次事件中发现的故障情况审查现有的应用健康检查、释放验证程序和释放后疗养测试覆盖率。 审查将确定是否存在任何覆盖差距以及是否需要额外的监测、验证或其他改进。 4. ** 扩大调查:** 我们将继续调查是什么引发了最初的申请,以便在发布后扩大规模,并确定是否需要采取任何额外的纠正或预防行动。 5. ** 客户通信改进:** 在这次事件中,我们找到了更及时地与客户沟通的机会。 我们的既定事件升级和沟通做法旨在确保在确定计划外的服务影响时主动通知客户。 从这一事件中吸取的教训已纳入我们目前的事件应对做法,以帮助确保这些程序得到一致适用,并确保在服务中断期间及时向客户主动提供最新情况.

自动翻译自官方事件更新。

1. 2026年10月8日 UTC 10:59investigating

   事件描述:我们正在调查一个影响 SAM Core内执照服务的问题。 用户可能无法加载许可证信息,在访问许可证服务功能时可能遇到错误信息. 联合王国的南欧和西欧已经确认了这一问题,技术小组目前正在评估影响的全面范围。 优先事项:P2 恢复活动:技术小组正在积极调查这一问题并审查受影响的服务。 目前正在进行进一步验证,以确定影响的全面范围并恢复正常的服务运作。 一旦获得更多信息,将提供进一步的最新资料.

2. 2026年10月8日 UTC 11:30monitoring

   我们确认,这个问题与最近部署的许可证服务有关。 已实施纠正性改变,并恢复服务功能。 我们目前正在验证服务健康和监测环境,以确保持续稳定。 进一步更新将在补充审定工作完成后提供.

3. 2026年10月8日 UTC 12:11resolved

   经过验证和监测一段时间后,这项服务保持稳定,许可证功能正在受影响地区顺利上载。 这个问题现在被认为得到解决.

自动翻译自官方事件更新。

1. 2026年10月8日 UTC 00:08investigating

   事件描述:我们正在调查一个影响澳大利亚客户在Snow Atlas中协议功能的问题。 客户在访问协议分页时可能遇到缺失或无法获取的数据,数据刷新操作可能失败. 优先事项:P2 恢复活动:技术小组正在积极调查这一问题并评估客户影响的程度。 目前正在努力查明问题的原因并恢复正常功能。 一旦获得更多信息,将提供进一步的最新资料.

2. 2026年10月8日 UTC 01:39resolved

   进一步调查发现,澳大利亚Snow Atlas系统的一个通信问题影响到支持协议的后端服务功能。 技术小组开展了恢复行动,包括重新启动受影响的服务部分,恢复通信和正常运作。 功能在多个客户环境中得到了验证,协议数据现在显示正确. 在回收和鉴定活动之后,我们没有观察到任何其他问题。 这个问题现在被认为得到解决.

自动翻译自官方事件更新。

1. 2026年10月7日 UTC 20:27investigating

   事件简介:我们正在调查影响海洋库伯涅斯客户的间歇性问题的报告。 一些客户报告说,它们收到了关于海洋库伯内特各组成部分及其集群之间连通性的警报。 技术小组正在积极调查影响的范围和任何相关的服务退化情况。 优先事项:P2 恢复活动:我们的技术小组正在积极调查所报告的行为,审查客户报告并核实受影响环境的范围和影响。 一旦获得更多信息,我们将提供更多最新情况.

2. 2026年10月7日 UTC 22:23investigating

   我们继续调查以前报告的断断续续的连接问题。 目前,自最初的撞击窗口以来,没有观察到其他事件。 技术小组正在积极审查现有的遥测和调查结果,以确定根本原因并验证影响的总体范围。 一旦获得更多信息,将提供进一步的最新资料.

3. 2026年10月8日 UTC 00:03investigating

   自最初报告的影响窗口以来,我们没有看到任何其他事件,服务稳定得到维持。 技术小组继续调查今天早些时候报告的断断续续的连接问题的根本原因.

4. 2026年10月8日 UTC 00:04monitoring

   根据自最初报告的影响窗口以来观察到的持续稳定以及没有报告的其他事件,我们正在将这一事件转到监测部门。 在监测服务稳定性的同时,技术小组继续调查根本原因。 一旦获得更多信息,将提供进一步的最新资料.

5. 2026年10月8日 UTC 02:24resolved

   自最初报告的影响以来,我们没有观察到任何其他事件,服务稳定性得到维持。 技术小组完成了对今天早些时候报告的间歇性连接问题的额外调查。 调查期间审查了多种潜在关联,最后分析仍有待进行。 根据观察到的持续稳定以及不再发生的情况,目前认为这一事件已得到解决。 技术小组将继续监测和调查活动,以进一步了解在报告的影响窗口中观察到的行为,分析完成后将提交一份正式的驻地协调员评估报告.

6. 2026年10月20日 UTC 17:50postmortem

   ** 说明:** Spot Ocean -- -- Kubernetes -- -- 间歇控制器连接性问题 ** 时间框架:** 2026年10月7日,11:20 AM PDT - 12:30 PM PDT ** 事件摘要** 2026年10月7日星期三,11:20AM PDT,多点海洋为Kubernetes环境经历了间歇性控制器连接警报. 事发期间,该平台临时将控制器心跳信息解释为已过时并暂停了受影响集群的缩放操作,作为安全措施. 受影响的控制员在事件中继续报告心跳信息. 然而,用于验证控制器连通性的时间戳在一个数据库组件内变得过时了,导致活性控制器出现暂时没有响应. 行为是间歇性的,目前的心跳信息随后在没有人工干预的情况下被提供,使得正常的缩放操作得以恢复. 技术小组审查了控制器心跳处理路径、数据库行为、服务遥测和相关基础设施信号,以确定为什么有效的心跳活动被解释为停滞。 事件发生后没有观察到其他事件。 在对服务稳定性进行持续监测和验证后,该事件被认为已得到解决。 ** 循环原因** 事件是由一个更古老的控制器心跳时间戳在数据库组件内覆盖一个更近期有效的时间戳所造成. 虽然受影响的控制器继续正常地报告心跳,但是过时的时间戳使得最近被存储的心跳显得比它老. 当平台评价了这个时间戳时,它超过了所配置的心跳阈值并触发了一个安全机制,暂时中止了受影响的集群的缩放操作. 推迟更新旧数据库的具体条件尚未最终确定。 然而,数据库更新进程没有包含防止更古老的心跳时间戳取代更新的有效时间戳的保障措施. 这使得延迟的心跳信息可以创造出积极报告控制器没有响应的外观. ** 补救行动** 在事件应对期间采取了以下行动: 1. 客户报告和服务行为审查:技术小组审查了报告的例子,以确认行为,建立影响窗口,并确定问题是否孤立或影响多种环境。 2. 主计长心跳活动核实:对主计长活动进行了审查,以确定受影响的控制员是否已停止报告。 调查证实,事发期间继续发送心跳信息. 3. 心跳处理路径调查:技术小组追踪心跳信息的生成、储存和评价情况,以查明当前心跳活动在何处被解释为已过时。 4. 数据库和服务健康评估:审查了相关的数据库性能、服务行为和基础设施遥测,以评估潜在的处理延误并排除更广泛的平台不稳定。 5. Timerstamp Reression Identification:调查确定,一个更古老的心跳时间戳已经覆盖了更新的有效时间戳,导致平台暂时将心跳解读为停滞. 6. 服务稳定性核实:技术小组在恢复后继续监测。 没有发现其他事件,在事件结束前,规模行动保持稳定。 ** 未来预防措施** 计划进行下列改进,以加强心跳处理和改进类似条件的检测: 1. 心跳时标保护: 将对数据库更新进程进行修改,以防止一个更古老的心跳时间戳覆盖一个最近有效的时间戳。 2. 改进诊断记录:将围绕心跳更新引入更多记录,以获取每次更新的来源、相关请求的背景、以往和新的时间戳值以及时间戳的来源。 3. 监测和警报:将利用额外的诊断信息制定新的监测和警报,以更快地确定时间戳回归和类似的心跳处理条件。 4. 数据库访问审查:将审查与心跳处理有关的数据库访问模式,以确定减少处理延误的机会,并优化在高负荷下的工作表现.

自动翻译自官方事件更新。

1. 2026年9月29日 UTC 11:08investigating

   事件描述:我们正在调查一个影响事件通报服务的问题,涉及多个生产环境. 客户在收到v2事件通知时可能会遇到延误或失败,包括通过电子邮件、webhooks、Slack和其他支持渠道发送的通知。 继续通过Flexera One控制台和API对事件进行记录并保持无障碍. 目前没有迹象表明核心平台的功能或事件数据受到影响。 优先事项:P3 恢复活动:我们的技术小组查明了这一问题并实施了服务恢复行动。 监测显示,误差率正在下降,各小组正在继续验证服务稳定性并评估影响的全面范围。 随着调查和追回工作的进展,将提供进一步的最新资料。 最新消息:进一步调查证实,这个问题对客户没有影响. 受影响的通知不打算公布.

2. 2026年9月29日 UTC 11:53resolved

   在密切监测各项服务以证实稳定之后,我们的小组没有观察到进一步的错误或问题再次发生。 这一事件现已得到解决.

3. 2026年10月13日 UTC 04:42postmortem

   ** 说明:** Flexera 的点 - 事件通知处理出错 ** 时限:** 2026年9月29日,2:06 AM PDT - 4:51 AM PDT ** 事件摘要** 2026年9月29日,Flexera在负责处理某些事件通知工作流程的通知处理组件中识别出提升了的应用错误. 自动监测发现出错活动增加,促使调查确定客户举报是否受到影响。 在调查期间,技术小组查明了在通知处理过程中发生的故障,并对受影响的事件、通知工作流程和潜在的客户影响进行了详细评估。 初步分析表明,这一问题有可能更广泛地影响通知的处理,在核实范围和影响时宣布了一起重大事件。 进一步的影响评估证实,受影响的通知不打算向客户公布。 在整个调查期间,事件信息继续被成功记录,并通过该平台提供。 没有干扰客户服务功能,没有丢失事件数据,也没有发现客户因这一问题而受到影响。 根据影响评估结果,事件优先级被降级,经验证确认客户服务未受影响后调查结束. ** 循环原因** 调查确定,一个通知处理工作流程在处理一些内部生成的事件时遇到了应用程序例外。 这些事件的编排方式是,它们不是为了向客户提供通知。 虽然例外情况导致申请错误增加并值得调查,但随后的分析证实,预计不会向客户分发受影响的通知。 因此,向客户提供通知、平台功能和获取事件信息的机会没有受到不利影响。 ** 补救行动** 在事件应对期间采取了以下行动: 1. 启动事件调查:技术小组调查通过自动监测和评估潜在客户影响发现的更高应用错误。 2. 进行的通知处理分析:审查了受影响的通知工作流程,以确定申请例外的来源并确定问题的范围。 3. 客户影响评估 完成:技术小组验证了受影响的通知类型,审查了事件公布行为,并证实所涉通知不是为客户提供的。 4. 系统验证和监测:对错误趋势、服务行为和通知处理进行了监测,以确认稳定运作,并证实客户服务没有受到影响。 5. 事件改叙完成:在确认不存在客户影响后,事件优先级被降级,事件得到正式解决. ** 未来预防措施** 在这次调查之后,我们查明了在业务警报涉及内部处理工作流程时提高影响评估速度和准确性的机会。 1. 改进的影响评估:审查内部通知分类和调查程序,以加快确定一个问题在未来事件中是否影响客户的功能。 2.增强通知工作流能见度:提高业务能见度入客户信息化和非客户信息化通知处理路径,支持更快地开展影响验证和事件应对活动.

自动翻译自官方事件更新。

1. 2026年9月28日 UTC 09:10investigating

   事件描述:我们正在调查一个影响APAC区域IT能见度的问题, 受影响地区的客户可能无法进入应用程序内的报告仪表板。 目前的调查显示,这一问题仅限于APAC区域,目前其他区域没有观察到影响. 优先事项:P2 恢复活动:我们的技术小组正在积极调查这一问题,以查明根本原因并恢复报告功能。 我们正在继续评估影响范围,监测服务健康,并酌情采取纠正行动。 一旦获得更多信息,我们将提供进一步的最新资料.

2. 2026年9月28日 UTC 09:26resolved

   影响APAC区域Power BI报告仪表板的问题已经解决. 初步调查表明,在最近升级之后,需要更新配置。 我们的技术小组完成了必要的补救,随后的鉴定确认,受影响的仪表板现已可以使用,并按预期运作。 所有服务已恢复正常运作,目前认为这一事件已得到解决.

3. 2026年10月26日 UTC 12:10postmortem

   ** 说明:** Flexera One -- -- IT可见度 -- -- APAC -- -- 报告仪表板不可用 ** 时间框架:** 2026年9月28日,1:38 AM PDT至2026年9月28日,2:15 AM PDT ‌ ** 事件摘要** ‌ Flexera在2026年9月28日星期一的1:38AM PDT发现了一个影响APAC地区客户使用Power BI报告仪表板的问题. 我们的技术小组迅速介入,初步调查证实,影响仅限于APAC,而其他区域则仍然作出反应。 进一步调查确定,与计划的身份和访问管理迁移有关的配置变化影响了报告服务所需的连接设置。 在应用这些修改时,报告服务的连接设置被重置为没有包含成功通信所需的完整服务地址的值. 因此,受影响的服务未能正确启动,导致APAC客户无法获得Power BI报告仪表板。 为了恢复服务,技术小组手动纠正了APAC环境中受影响的连接设置. 这恢复了报告和认证服务之间的沟通,使受影响的服务得以恢复。 修复后,验证确认,Power BI报告仪表板可访问,正常运行时间约为2:15 AM PDT. ‌ ** 循环原因** ‌ 事件发生的原因是在身份和访问管理迁移相关的配置变化中应用到APAC环境的连接设置不正确. 更改将报告服务的连接地址重置为没有包含与认证服务成功通信所需的完整地址的值。 因此,受影响的报告服务未能正确启动,使APAC区域的客户无法使用Power BI报告仪表板。 促成因素 * 配置不一致:所需连接地址以前已在环境中直接更新,但没有反映在部署配置中。 因此,随后的配置变化重新提出了不正确的数值. * 部署验证差距:部署过程没有在不正确的连接设置影响服务可用性之前确定这些设置。 * 变革协调和依赖性验证: 迁移过程并未充分顾及所有依赖服务的配置要求,导致在未事先对受影响的服务依赖进行验证的情况下进行端点变化。 ‌ ** 补救行动** 我们的小组为恢复正常服务采取了下列行动: * 修改了受影响的连接设置,以恢复报告和认证服务之间的沟通。 * 受影响服务恢复,验证确认,Power BI报告仪表板可以使用并正常运行。 * 该配置随后得到纠正,以确保今后部署时始终如一地维持所需连接设置。 ‌ ** 未来预防措施** ‌ 已经确定并正在采取以下行动来减少复发的可能性并增强服务的复原力: * 配置管理:确保一致管理服务配置的改变,以防止部署的设置和维护的配置之间出现差异。 * 部署验证:在部署前审查计划中的配置变动,以核实所需服务连接设置依然正确。 * 配置一致性:确保关键连接设置在适当的配置源中保持,不依赖于对单个环境的人工修改. * 改革协调:改进对计划迁移和配置变化的协调,包括验证受影响服务的要求和依赖性。 * 部署保障:加强部署前检查,在不正确的配置设置导致服务故障前发现.

自动翻译自官方事件更新。

1. 2026年9月25日 UTC 23:18investigating

   事件简介:我们正在调查一个影响到所有区域某些信息技术资产管理一体化和App门户网站服务的问题。 使用所受影响的API集成的客户可能会遇到认证失败,导致HTTP 401未经授权出错,这可能会使请求无法成功完成. App Portal 用户在提交请求时也可能遇到出错. 优先事项:P2 恢复活动:我们的技术小组正在积极调查这一问题并评估纠正行动。 调查和鉴定活动正在进行中,我们正在努力尽快恢复正常的服务功能。 一旦获得更多信息,将提供进一步的最新资料.

2. 2026年9月26日 UTC 05:31identified

   纠正后的热补剂目前正在等待建造过程的完成,建造过程耗时比预期的要长. 建设完成后,我国技术队伍将着手进行UAT验证后再推进生产部署. 该小组还正在努力确认部署计划、自主权和预期时间表。 随着这些活动的进展,将提供进一步的最新资料.

3. 2026年9月26日 UTC 12:30monitoring

   我们的团队成功实施了"热补",初步确认服务运行如所预期. 我们正在继续密切监测环境,同时等待受影响的客户的确认.

4. 2026年9月27日 UTC 05:39monitoring

   API正在按预期运行,之前观察到的错误不再被检测出. 事件仍在监测中,同时完成了进一步验证,并获得客户确认.

5. 2026年9月28日 UTC 17:14resolved

   在周末完成补救活动后,我们继续监测受影响的服务,以确认持续稳定和恢复。 现已收到客户验证,确认App Portal功能和API请求处理正常运行. 进一步调查发现一个影响服务部分内认证处理的问题,导致HTTP 401 受影响API请求的未经授权错误和通过App Portal提交请求时的错误. 我们的技术小组采取了纠正行动来解决这一问题,并在查明和解决了补救过程中遇到的一个单独问题之后进行了进一步的验证。 在补救和扩展监测之后,服务保持稳定,没有观察到进一步的问题。 将进行全面的根源分析,并分享事件后报告,详细说明作为调查的一部分确定的根本原因、补救活动和纠正行动.

6. 2026年10月8日 UTC 11:25postmortem

   ** 说明:** Flexera One – IT资产管理–所有区域– App门户网站出错和API请求失败 ** 时间框架:** 2026年9月24日,12:12 PM PDT — 2026年9月26日,4:38 AM PDT ** 事件摘要** 从2026年9月24日开始,大约12:12 PM PDT,客户使用以API为基础的与Flexera One IT资产管理\(ITAM\)的集成,经历了认证失败,返回了HTTP 401未经授权的回复. App Portal用户在提交请求时也遇到出错,依赖这些API的App Broker和Business Adapter等集成也受到影响. 在北美、欧洲和亚太地区都观察到了影响。 技术小组调查并确认,失败与客户证书或客户配置无关。 应用程序日志显示,认证这些请求所需的组件未能初始化. 进一步调查确定,在9月24日应对更早的ITAM菜单加载事件时,作为预防措施部署的热补丁引入了这种行为. 技术团队在测试中复制了行为,开发出一个矫正修补并验证. 在部署验证过程中,通过更新的热补补剂,查明并解决了次要组件装载问题。 在向生产公司部署更新的热接器后,技术小组核实API的功能正在按预期运行,并于9月26日大约4:38AM PDT恢复服务. 事件随后在获得客户确认的同时转入了延伸监测,并于9月28日收到确认. 恢复服务后,与主要事件分开报告并调查了孤立的间歇性认证故障. 技术小组确定了额外的连接处理条件和针对具体环境的配置条件,并部署了更多的热补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补补 持续到10月1日的监测和客户审查证实,这一问题已无法再重复,没有观察到进一步的情况。 ** 循环原因** 事件由9月24日应对更早的ITAM菜单加载事件时作为预防措施而部署的热接器有缺陷而出. hotfix从应用程序的认证组件中删除了依赖性,并更改了应用程序如何读取它用来连接到认证服务的配置. 已部署的配置中包含所需的设置。 然而,应用程序试图使用一种不支持在运行时装入配置的方法来读取它们. 因此,认证所需的组件无法被初始化,而要求认证的请求作为未经授权而被拒绝. 这产生了API出错,App Portal请求失败,这是客户经历的. 同样的行为也发生在生产前的验证环境中,当时热补丁被应用在那里. 由于受影响的API在此环境中没有被积极使用,因此在热补丁到达生产厂前没有被识别出来,具体错误提示尚未针对它们实施. 最初的修复解决了主配置缺陷. 在随后的验证和监测中,确定了额外的组件装载、连接处理和环境特有配置条件,并需要进一步的热补剂,才能确认持续稳定。 ** 补救行动** 在事件应对期间采取了以下行动: 1. 事件应对启动:在客户报告认证失败和API出错后,技术小组开始调查。 2. 范围和客户配置评估:技术小组确认,失败与客户资格或配置无关,并确认影响扩展到了多个区域。 3. 确定基本条件:技术小组确定,所需的认证设置已经存在,但无法在运行时读取,并在测试中复制行为。 4. 开发并验证的校正修复:应用代码被更新,以使用辅助方法读取设置。 验证测试确认认证出错不再发生. 5. 已部署的纠正措施已恢复服务:通过更新的热补丁,解决了在部署验证过程中发现的第二个组件装载问题。 在经过更新的热补丁被部署到Production之后,技术小组核实API的功能正在按预期运行. 6. 扩大监测和客户验证:技术小组监测整个周末的服务行为,并获得受影响客户的确认。 7. 事故后补救:在恢复服务后据报出现零星断断续续的故障后,技术小组进一步部署了热补并验证到9月30日。 监测和客户审查一直持续到10月1日,以确认这一问题不再发生。 ** 未来预防措施** 事发后,我们进行了回顾,以审查技术原因、热补真过程、监测能力以及造成客户影响的因素。 下列措施已经完成或正在实施: 1. 运行时配置校正: 应用软件已经校正,可以使用支持的方法读取其认证配置,另外在生产环境中安装并验证了额外的热补丁. 2. API监测和警报:正在对受影响的API增加错误率警报,以便在生产前和生产环境中检测认证失败,即使服务没有积极使用。 3. 热补真程序: 我们正在评估对依赖服务的额外检查,如API集成和App门户网站功能,作为Hotfix验证的一部分,然后批准用于生产.

自动翻译自官方事件更新。

1. 2026年9月25日 UTC 16:19investigating

   事件描述:我们正在调查一个影响到Flexera OneIT资产管理客户子集的问题。 受影响的客户在访问All Site视图和相关基于库存的视图时可能遇到库存数据缺失或结果空洞的情况。 这个问题仅限于北美的一小部分客户。 优先事项:P2 恢复活动:技术小组正在积极调查这一问题并审查与受影响功能有关的清单数据处理工作流程。 目前正在对影响范围进行验证,同时评估减缓和恢复备选办法。 一旦获得更多信息,将提供进一步的最新资料.

2. 2026年9月25日 UTC 18:50identified

   技术小组查明了最近影响清单数据处理的能力水平变化可能引发这一问题的原因。 目前正在开展恢复活动,包括旨在恢复正常库存数据处理的回滚和纠正行动。 技术小组正在积极开展工作,为受影响的客户进行补救和核实恢复。 一旦获得更多信息,将提供进一步的最新资料.

3. 2026年9月25日 UTC 21:22identified

   技术小组继续通过与此问题有关的补救活动开展工作,并积极执行旨在恢复正常库存数据处理的回收行动。 在执行期间,各小组遇到需要调整补救方法的其他条件,目前正在开展更新的恢复活动。 技术小组继续积极开展工作,并正在不断努力尽快完成补救工作并恢复受影响客户的正常服务。 我们赞赏你耐心地继续这些努力,并对持续的影响表示歉意。 随着取得有意义的进展,将提供进一步的最新资料.

4. 2026年9月26日 UTC 00:55identified

   技术小组继续通过与此问题有关的补救活动开展工作,并积极执行旨在恢复正常库存数据处理的回滚和纠正行动。 恢复活动仍在进行中,技术小组正在积极监测作为补救进展的执行情况.

5. 2026年9月26日 UTC 05:25monitoring

   我们的技术小组成功地完成了必要的补救活动。 封锁任务已经清除。 补救后验证确认相关数据库功能和程序在预期状态下运行. 各小组将继续监测环境,以确保稳定.

6. 2026年9月26日 UTC 07:13resolved

   所有验证检查均顺利完成,服务恢复正常运行. 这个问题现已解决.

自动翻译自官方事件更新。

1. 2026年9月24日 UTC 21:43identified

   事件简介:我们正在调查一个影响片点海洋的问题, 客户可能无法启动新的实例,因为提供实例失败。 因此,受影响的集群可能无法按预期规模扩大。 现有工作量仍在运作。 我们的技术小组正在积极调查这一问题的范围和影响。 优先事项:P2 恢复活动:我们的技术小组已查明了与最近影响提供实例的变化有关的潜在问题,并正在积极核实影响。 正在开展缓解活动,包括降低最近的变化,同时各小组监测恢复和服务行为。 一旦获得更多信息,将提供进一步的最新资料.

2. 2026年9月24日 UTC 22:16resolved

   进一步调查确定,最近影响实例提供行为的变化助长了这一问题。 技术小组完成了变更的回滚并验证回收。 回滚后,出错水平恢复到正常水平,并成功恢复了新的实例提供。 在整个事件中,现有事件和工作量仍在运作。 影响仅限于新的实例发射和集群扩大行动。 这个问题现在被认为得到解决。 在完成根源分析和事件后审查后,将分享一份详细的尸检报告,其中将记录事件的全部顺序、促成因素、经验教训以及确定的任何后续行动.

3. 2026年10月9日 UTC 06:33postmortem

   ** 说明:** AWS 的点出洋 -- -- 实例提供失败 **时间框架:** 2026年9月24日 中午12:00 PM PDT至2026年9月24日 2:54 PM PDT ‌ ** 事件摘要** ‌ 2026年9月24日,Spot Ocean for AWS经历了一个问题,阻止了部分客户发起新事件. 因此,在需要额外计算能力时,受影响的集群无法达到预期的规模。 在整个事件中,现有事件和工作量仍在运作。 这种影响仅限于提供新的实例和集群扩大行动。 技术小组确认,最近的软件变化在实例提供过程中引入了出乎意料的行为。 这一变动被退回,从而消除了供应错误并恢复了正常的服务运作。 在回滚后,查明并纠正了基本的软件问题。 更新后的功能经过了进一步的验证,以确保在重新纳入生产环境之前充分解决这一问题。 技术小组对回滚后成功启动实例进行了验证,客户验证证实,新的实例提供正在如所预期的那样运作。 事件于2026年9月24日2:54PM PDT解决. ‌ ** 循环原因** ‌ 事件由近期的软件变更所引起,在AWS实例提供过程中引入了出乎意料的行为. 这一变化影响到某些集群配置信息的处理方式,导致某些扩大业务的提供失败。 虽然修改旨在支持特定AWS资源的标记,但其行为也影响了其他被支持的集群配置. 在某些情况下,更新的标记逻辑导致重复的标记信息作为实例提供请求的一部分提交。 AWS拒绝了这些请求,因为标签信息不符合预期要求. 因此,Spot Ocean未能成功完成一些新实例的提供。 这主要影响到新的实例发射和集群扩大行动。 已经成功地提供了现有事例,因此在整个事件中继续正常运作。 基础功能此后被纠正,并正在进行额外的验证,以确保在恢复生产之前,在所支持的AWS集群配置中一致地更新行为工作. ‌ ‌ ** 补救行动** 我们的小组为恢复正常服务采取了下列行动: * 降低软件变化,恢复正常的实例提供。 * 查明并纠正了受影响功能中的根本问题。 * 对纠正后的功能进行了额外验证。 * 引入了其他保障措施,以控制方式推出更新后的功能。 * 验证了新的实例提供和集群扩大业务在退后运作时的预期效果。 ‌ ** 未来预防措施** * 扩大自动化测试,例如供应和集群规模化设想。 * 增加所支持的AWS集群配置的回归测试。 * 为缩放工作流程扩展端到端测试. * 改进对供应和规模化故障的监测和警报。 * 加强生产部署前对变化的验证。 * 对有控制地推出影响提供行为的变化实行额外保障。 * 扩大边缘病例和出错处理情景的测试范围.

自动翻译自官方事件更新。

1. 2026年9月24日 UTC 20:46monitoring

   事件描述:今天早些时候,一个影响不结盟运动区域Flexera One信息技术资产管理(ITAM)库存处理的问题影响到了一部分客户。 调查发现,正在成功地接收存货上传,但是没有为受影响的客户进行处理,导致在Flexera One ITAM中反映的存货数据出现延误。 追回行动已执行,库存处理已成功恢复。 库存档案继续正常处理;但是,其余积压案件仍在处理中,正在通过这一事件进行追踪。 优先事项:P2 恢复活动:技术小组实施了恢复库存文件处理的回收行动,并通过监测和伐木验证成功处理。 服务业务保持稳定,随着以往排队盘存文件的处理,积压的回收工作仍在继续。 技术小组正在积极监测恢复进度、服务健康和减少积压,同时继续进行验证活动。 此前与这起事件的前几个阶段有关的最新消息可参见下文相接的事件史. 随着积压的复原进展和鉴定活动继续进行,将提供进一步的最新资料。 https://status.flexera.com/incidents/5wrg6jl9bj2h (英语)

2. 2026年9月25日 UTC 08:15monitoring

   随着先前排队的库存文件的处理,后置日志恢复工作仍在继续. 积压水平现在在可接受的范围内,有一个组织仍然高于预期水平。 技术小组继续监测恢复、服务健康和加工活动,而验证工作仍在进行.

3. 2026年9月25日 UTC 13:28resolved

   事件期间所积累的积压已成功处理,处理水平已恢复到正常运行范围. 我们的小组已经完成恢复验证,这一事件目前正在得到解决。 关于根本原因和所采取行动的进一步详情将在死后报告中提供.

4. 2026年10月23日 UTC 17:27postmortem

   ** 说明:** Flexera One -- -- IT资产管理 -- -- NAM -- -- 生产发布活动后库存处理延误 ** 时间框架:** 2026年9月22日 7:05 PM PDT - 2026年9月25日 5:30 AM PDT ** 事件摘要** 2026年9月24日,技术小组开始调查有关延迟更新存货的报告,这些更新影响了北美地区使用Flexera One IT资产管理\(ITAM\)的一子客户. 虽然库存文件已成功上载并可供查阅,但一些客户在处理这些文件方面出现延误,无法在应用程序中反映最新的库存信息。 ITAM中显示的灯塔状态信息可能对受影响的客户来说也可能已经过时. 库存处理通常对其他客户继续进行。 这个问题发生在2026年9月22日ITAM 2026R1.3生产放行活动后. 调查发现,负责将上传的库存文件移交ITAM库存处理服务的进程出现中断。 虽然受影响的档案仍然存有,但并没有转交处理。 技术小组在调查期间还发现应用错误增加,尽管这些错误没有最终确定为中断的原因。 技术小组有的放矢地重新启动了受影响服务部分,恢复了库存档案的移交,并使先前受影响的客户得以恢复处理。 使更多的诊断记录得以支持进一步调查。 然而,在中断期间,库存文件大量积压,需要更多时间处理。 在恢复处理后,技术小组继续监测库存活动和积压的积压情况。 至2026年9月25日星期五,约5:30AMPDT,事件相关积压已恢复到正常运行水平,确认库存处理恢复. ** 循环原因** 事件发生的原因是,在不结盟运动区域进行ITAM 2026R1.3生产放行活动之后,库存处理工作流程中断。 虽然库存文件已成功上载并仍然可供储存,但负责向ITAM处理系统转发这些文件的组件却停止了为一组客户转移库存数据。 因此,受影响的库存文件没有处理,延误了库存更新。 这个问题并不影响所有客户,因为其他组织的库存处理通常仍在继续。 调查发现,应用程序错误和行为增加,表明受影响的处理部分没有如预期的那样恢复。 造成部分中断的确切技术条件仍在调查之中。 有针对性地重新启动受影响服务部分,恢复了受影响客户的库存处理。 积压工作随后得到处理,使库存更新工作恢复到正常水平。 ** 补救行动** 在事件应对期间采取了以下行动: 1. ** 启动的事件调查:** 技术小组调查了影响不结盟运动区域少数客户的库存更新延迟的报告,并审查了库存处理工作流程,以确定问题的范围。 2. ** 查明的库存处理中断:** 调查证实,存有上传的库存文件,但并未转交受影响客户的处理服务。 3. ** 恢复了受影响的服务组成部分:** 有针对性地重新启动受影响的服务部分,恢复了库存档案的移交,使先前受影响的客户得以恢复处理。 4. ** 启用的额外诊断记录:** 使更多的伐木工作能够获取更多的技术信息,并支持继续对潜在的处理中断进行调查。 5. ** 库存回收监测:** 技术小组监测处理工作恢复后累积的库存积压情况,并证实库存档案处理顺利。 6. **经核实的服务回收:** 技术小组证实,与事件有关的积压工作到9月25日已恢复正常运作,库存处理保持稳定。 ** 未来预防措施** 事件发生后,我们进行了一次回顾,以审查部分库存处理故障、现有库存交付架构、现有诊断信息以及提高处理可靠性和故障能见度的机会。 正在采取以下纠正行动和改进活动: 1. ** 库存处理结构改进:** 计划通过使ITAM能够直接从存储层取回上传的库存文件,而不是依靠现有的中间转发服务来简化库存处理一体化。 这一变动将消除处理路径上的额外依赖性,加强对处理、积压管理、能力和恢复的控制。 2. ** 改进故障诊断:** 将酌情评估和加强在部分库存处理失败时获取相关服务状态所需的诊断记录和遥测。 这将提供更好的技术信息,支持在出现类似情况时确定根源.

自动翻译自官方事件更新。

1. 2026年9月24日 UTC 14:08investigating

   事件简介:我们正在调查一个影响不结盟运动区域使用Flexera One IT资产管理(ITAM)的客户子集的问题。 受影响的客户在导航方面可能遇到问题,包括在ITAM接口中看不到菜单项,导致获取某些功能的机会有限. 优先事项:P2 恢复活动:我们的技术小组正在积极调查这一问题并努力恢复全部功能。 我们将继续在获得更多信息后提供最新情况.

2. 2026年9月24日 UTC 15:44investigating

   技术小组继续调查影响不结盟运动生产环境中Flexera One信息技术资产管理的问题。 目前的工作重点是查明在受影响工作流程中哪些地方出现故障。 团队正在审查应用行为,验证过程,服务互动,平台遥测,以及任何可能促成这一问题的近期变化或环境条件. 调查仍在进行中,并将在获得补充资料后提供进一步的最新资料.

3. 2026年9月24日 UTC 17:48investigating

   技术小组已取得进展,缩小了问题的范围,并正在集中处理装入用户访问和导航信息方面的应用组件。 目前的调查结果表明,这一过程中的一些请求没有如预期的那样完成,导致菜单项无法为受影响的用户加载. 目前仍在开展工作,以确定根本原因并核实适当的补救。 一旦获得更多信息,将提供更多最新资料.

4. 2026年9月24日 UTC 18:39monitoring

   技术小组目前正在观察稳定的服务行为,并大大减少与这一事件有关的错误。 受影响的应用功能通常根据目前的遥测和监测数据运作。 虽然服务稳定性已有所改善,但技术小组继续密切监测环境,以确认这一问题不再发生。 对根本原因的调查仍在进行。 我们将继续进行监测,并在获得补充资料后提供进一步的最新资料.

5. 2026年9月24日 UTC 20:33resolved

   技术小组证实,服务保持稳定,受影响的信息技术资产管理功能正常运行。 在调查期间,技术小组查明了影响负责用户访问和导航功能的应用程序组件的连接饱和条件。 这些条件是在撞击窗口期间观察到的,与受影响用户遭遇的故障同时发生. 服务功能被恢复,客户验证确认,受影响的ITAM页面和菜单项正在成功加载. 在经过一段时间的监测之后,没有再发生这个问题,现在认为事件已经解决了。 目前正在对该事件进行详细审查,以进一步核实促成因素并查明任何其他预防行动.

6. 2026年10月8日 UTC 11:23postmortem

   ** 说明:** Flexera One -- -- IT资产管理 -- -- NAM -- -- 菜单项目未装入 ** 时间范围:** 2026年9月24日 5:27 AM PDT — 2026年9月24日 10:48 AM PDT ** 事件摘要** 2026年9月24日,北美地区使用Flexera One IT资产管理\(ITAM\)的客户遭遇了间歇性的问题加载应用程序菜单项目并访问ITAM功能的部分内容. 一些客户遇到了部分上载或缺失的菜单,错误消息,以及不一致的应用程序行为. 技术小组调查了整个应用和支助服务中的问题,并查明了支持ITAM功能的组件中的异常连接利用率。 随着现有连接能力被耗尽,一些应用程序请求无法顺利完成,导致与认证有关的故障并阻止ITAM部分功能上载. 服务开始于大约10:46AM PDT恢复,而矫正热补剂的部署工作尚未完成。 最后一个相关的应用错误记录在10:48 AM PDT上. 技术小组继续调查其根本原因,同时监测环境和验证客户的功能。 事件后分析表明,受影响的服务器上的应用服务已重新启动,释放了所积累的连接,并允许建立新的连接。 矫正热补随后被作为预防措施部署,以解决连接处理行为,同时继续对根本原因进行调查。 在持续监测和客户验证后,技术小组确认ITAM功能已恢复正常运行。 ** 循环原因** 事件由ITAM 2026 R1.3出品期间引入的连接管理问题所引发. 应用程序认证流程的改变导致新的服务连接被反复地创建,而不是重新使用已存在的连接. 随着时间的推移,这些连接在受影响的应用组件中积累并用尽了现有的连接能力。 一旦该能力被用尽,新的申请请求就无法成功确定。 这导致与认证有关的故障,并阻止ITAM功能部分上载,导致菜单项缺失,错误信息,受影响客户间歇地失去访问权. 纠正这种行为的热补剂已经建立,并在生产部署之前列入释放部署计划。 由于生产尚未升级,该热器最初被指定用于验证环境。 原拟作为R1.3放出物的一部分被应用于生产,但在生产部署中并未被应用. 因此,上映时连通管理校正没有到位. ** 补救行动** 1. 启动事件调查:技术小组调查应用错误和ITAM功能断断续续的损失,以确定范围和根本原因。 2. 确定连接饱和度:对受影响应用组件的分析查明了正在耗尽现有连接能力的异常连接积累,使新的应用请求无法顺利完成。 3. 校正Hotfix确认:技术小组通过重新使用服务连接,而不是为每个请求创建新的连接,确定了纠正连接-处理行为的现有Hotfix. 4. 安装了矫正热补液:将热补液部署到生产厂,作为解决连接管理问题和防止进一步连接积累的预防措施。 5. 服务回收验证:技术小组继续监测应用行为,并在回收后验证客户功能,以确认ITAM服务已恢复正常运行。 ** 未来预防措施** 事件发生后,我们进行了一次回顾,以审查技术原因、释放和热补部署程序、监测能力以及造成客户影响的因素。 下列措施已经完成或正在实施: 1. 连接管理校正: 已实施纠正性变革,以确保适当再利用服务连接,并防止连接积累耗尽现有应用资源。 2. 生产部署验证:已在所有生产地区部署并验证了连接管理更正,以确保一致执行。 3. 释放和热固定工艺改进:正在加强释放程序,以便始终将释放部署计划中的热固定装置指定用于生产部署,包括在生产环境升级之前最初创建或验证的热固定装置。 4. Hotfix Profession Review:我们正在评价总体热器工艺的改进情况,以减少对生产热器的依赖并进一步降低未来生产释放中不包含必要纠正性改变的风险。 5. 加强应用监测:正在实施额外的应用一级监测和警报,以更好地及早发现断断续续的故障和异常出错情况,然后再对客户造成更广泛的影响.

自动翻译自官方事件更新。

1. 2026年9月24日 UTC 10:11investigating

   事件简介:我们发现一个影响不结盟运动区域Flexera One信息技术资产管理(ITAM)库存处理的问题,影响到一部分客户。 因此,一些库存上传的处理不成功,导致在Flexera One ITAM中显示的库存数据被延迟,无法反映最新上传的库存. 优先事项:P2 恢复活动:我们的技术小组正在积极调查这一问题,以找出根本原因并执行一项解决办法。 我们正在继续密切监测局势,并将随着调查的进展提供进一步的最新情况.

2. 2026年9月24日 UTC 12:27investigating

   进一步调查表明,这一问题似乎与负责向ITAM传输库存数据的部门有关。 我们的技术小组正在继续调查这一问题,并正努力查明根本原因和确定适当的补救措施。 我们将继续在获得更多信息后提供进一步的最新资料.

3. 2026年9月24日 UTC 14:32monitoring

   我们的团队进行了定向吊舱重新启动,随后成功地恢复了所有受影响客户的库存文件处理。 成功的处理通过日志和监测图表得到了验证。 我们将继续密切监测这些服务,以确保持续稳定,并在收到补充资料后提供进一步的最新资料.

4. 2026年9月24日 UTC 18:42monitoring

   我们的技术小组继续观察成功的库存文件处理和追回行动后的稳定服务业务。 通过监测进行的验证证实,受影响的清单文件处理成功。 正在恢复积压,随着文件的处理,库存处理队列继续减少。 技术小组正在积极监测恢复进展和总体服务健康,而剩余的积压工作已清理完毕。 我们将继续随着复苏的进展提供最新情况.

5. 2026年9月24日 UTC 20:32resolved

   这一事件无意中被标为解决了,并针对另一起事件作了更新。 随着剩余积压工作继续得到清理,库存处理回收工作仍在监测之中。 技术小组继续观察成功的文件处理和稳定的服务运作。 在新产生的事件中,将继续不断更新恢复情况并监测积压情况:https://status.flexera.com/incicents/vztp63wmxjjb 随着积压的恢复进展和恢复鉴定工作继续进行,我们将提供进一步的最新资料.

6. 2026年10月23日 UTC 17:25postmortem

   ** 说明:** Flexera One -- -- IT资产管理 -- -- NAM -- -- 生产发布活动后库存处理延误 ** 时间框架:** 2026年9月22日 7:05 PM PDT - 2026年9月25日 5:30 AM PDT ** 事件摘要** 2026年9月24日,技术小组开始调查有关延迟更新存货的报告,这些更新影响了北美地区使用Flexera One IT资产管理\(ITAM\)的一子客户. 虽然库存文件已成功上载并可供查阅,但一些客户在处理这些文件方面出现延误,无法在应用程序中反映最新的库存信息。 ITAM中显示的灯塔状态信息可能对受影响的客户来说也可能已经过时. 库存处理通常对其他客户继续进行。 这个问题发生在2026年9月22日ITAM 2026R1.3生产放行活动后. 调查发现,负责将上传的库存文件移交ITAM库存处理服务的进程出现中断。 虽然受影响的档案仍然存有,但并没有转交处理。 技术小组在调查期间还发现应用错误增加,尽管这些错误没有最终确定为中断的原因。 技术小组有的放矢地重新启动了受影响服务部分,恢复了库存档案的移交,并使先前受影响的客户得以恢复处理。 使更多的诊断记录得以支持进一步调查。 然而,在中断期间,库存文件大量积压,需要更多时间处理。 在恢复处理后,技术小组继续监测库存活动和积压的积压情况。 至2026年9月25日星期五,约5:30AMPDT,事件相关积压已恢复到正常运行水平,确认库存处理恢复. ** 循环原因** 事件发生的原因是,在不结盟运动区域进行ITAM 2026R1.3生产放行活动之后,库存处理工作流程中断。 虽然库存文件已成功上载并仍然可供储存,但负责向ITAM处理系统转发这些文件的组件却停止了为一组客户转移库存数据。 因此,受影响的库存文件没有处理,延误了库存更新。 这个问题并不影响所有客户,因为其他组织的库存处理通常仍在继续。 调查发现,应用程序错误和行为增加,表明受影响的处理部分没有如预期的那样恢复。 造成部分中断的确切技术条件仍在调查之中。 有针对性地重新启动受影响服务部分,恢复了受影响客户的库存处理。 积压工作随后得到处理,使库存更新工作恢复到正常水平。 ** 补救行动** 在事件应对期间采取了以下行动: 1. ** 启动的事件调查:** 技术小组调查了影响不结盟运动区域少数客户的库存更新延迟的报告,并审查了库存处理工作流程,以确定问题的范围。 2. ** 查明的库存处理中断:** 调查证实,存有上传的库存文件,但并未转交受影响客户的处理服务。 3. ** 恢复了受影响的服务组成部分:** 有针对性地重新启动受影响的服务部分,恢复了库存档案的移交,使先前受影响的客户得以恢复处理。 4. ** 启用的额外诊断记录:** 使更多的伐木工作能够获取更多的技术信息,并支持继续对潜在的处理中断进行调查。 5. ** 库存回收监测:** 技术小组监测处理工作恢复后累积的库存积压情况,并证实库存档案处理顺利。 6. **经核实的服务回收:** 技术小组证实,与事件有关的积压工作到9月25日已恢复正常运作,库存处理保持稳定。 ** 未来预防措施** 事件发生后,我们进行了一次回顾,以审查部分库存处理故障、现有库存交付架构、现有诊断信息以及提高处理可靠性和故障能见度的机会。 正在采取以下纠正行动和改进活动: 1. ** 库存处理结构改进:** 计划通过使ITAM能够直接从存储层取回上传的库存文件,而不是依靠现有的中间转发服务来简化库存处理一体化。 这一变动将消除处理路径上的额外依赖性,加强对处理、积压管理、能力和恢复的控制。 2. ** 改进故障诊断:** 将酌情评估和加强在部分库存处理失败时获取相关服务状态所需的诊断记录和遥测。 这将提供更好的技术信息,支持在出现类似情况时确定根源.

自动翻译自官方事件更新。

1. 2026年9月23日 UTC 10:05investigating

   事件描述:我们正在调查一个影响我们获得欧盟环境中的服务的问题。 欧盟的客户可能遇到获得服务的问题。 优先级:P1 恢复活动:我们的技术小组正在优先积极调查这一问题并努力尽快恢复正常服务.

2. 2026年9月23日 UTC 10:24monitoring

   这些服务已经恢复,而且现在正在按预期运作。 我们的小组正在密切监测该平台,以确保持续稳定.

3. 2026年9月23日 UTC 11:43resolved

   我们的小组继续监测该平台,并观察到这一问题没有再出现。 这一事件现在已经得到解决。 我们将继续进行调查,以确定根本原因并查明适当的纠正行动。 将在验尸报告中提供进一步详情.

4. 2026年10月26日 UTC 10:40postmortem

   ** 说明:** Flexera 1 - 欧盟 - 无法访问 ** 时限:** * 2026年9月24日2:51 AM PDT至2026年9月24日:3:18 AM PDT * 2026年9月25日,3:50 AM至2026年9月25日,4:30 AM PDT ‌ ** 事件摘要** ‌ 2026年9月24日2:51 AM PDT,客户在试图进入Flexera One欧盟生产环境时遭遇登录失败. 调查证实,欧盟身份和准入管理服务退化,使客户无法进入该平台。 调查发现,与单一组织流量增加有关的数据库连接大幅增加。 进一步分析确定,其他服务产生的再三下游请求也增加了认证和访问控制服务的负担。 3:18AM PDT,客户登录功能在没有直接技术干预的情况下被恢复,平台恢复了正常运行. 2026年9月25日,大约3:50AM PDT, 数据库连接量再次增加, 与同一组织的流量增加有关。 增加的载荷持续了约40分钟. 作为回应,资源管理服务实现了自动升级,以提高能力并增强平台稳定性。 ‌ ** 循环原因** ‌ 事件由流量出人意料地增加所引起,对欧盟认证服务和相关数据库连接的需求过高. 负荷增加影响了负责处理认证请求的服务,导致欧盟生产环境中的客户登录失败. 其他服务对认证和访问控制服务的重复请求,进一步加重了工作量。 此外,资源管理服务无法自动扩大规模,限制了其根据更高需求动态提高能力的能力。 在主动监测和警报方面存在的差距也限制了在客户无法进入之前识别退化的能力。 ‌ ** 补救行动** ‌ 我们的小组为恢复正常服务采取了下列行动: * 9月24日事件在没有直接工程干预的情况下得到解决,客户登录功能恢复为3:18AM PDT. * 9月25日,对资源管理服务进行了自动升级,以提高应对高需求的能力。 * 小组继续监测数据库连接和服务健康情况,以评估平台稳定性。 ‌ ** 未来预防措施** ‌ 已经确定并正在采取以下行动来减少复发的可能性并增强服务的复原力: * 自动缩放:审查所有生产区域资源管理服务的自动缩放配置,以确保能力适应工作量的变化。 * 数据库能力管理:审查数据库连接池设置,确保服务规模保持在数据库现有连接能力范围内。 *主动监测和警报:审查和采用对异常数据库连接增长、连接池饱和、服务耐用性、误差率和资源利用的警报。 * 交通监测:提高组织一级交通模式的能见度,以便在不寻常的要求激增影响其他客户之前予以识别。 * 交通管理:评估适当的限制费率和节流控制,以防止单一组织的过度交通影响整个平台的可用性。 * 载荷和容量测试:利用代表事故的交通模式进行载荷测试,以验证服务性能和数据库容量在高需求下.

自动翻译自官方事件更新。

1. 2026年9月23日 UTC 06:51investigating

   事件简介:我们目前正在调查一个影响Flexera One IT资产管理(ITAM)北美生产环境的问题,由于计划维护范围超出计划维护窗口,这一问题仍未解决。 维持活动仍在进行中,一个数据库的重建已经完成。 优先级:P1 恢复活动:我们的技术小组正在积极努力,以尽快完成剩余的维修活动并恢复服务。 数据库重建的ETA约为2小时. 我们的小组正在密切监测进展情况,并将在获得进一步细节后提供进一步细节.

2. 2026年9月23日 UTC 09:15investigating

   我们的技术小组已经完成了目前维修活动的主要阶段,并正在继续完成升级所需的其余处理工作。 这一过程比原先估计的时间要长。 在开展这些活动时,环境仍无着落。 各小组正在积极监测其余的处理情况并评价各种备选方案,以尽可能快和安全地恢复服务。 随着升级的进展和恢复时间表的更明确,将提供进一步的更新.

3. 2026年9月23日 UTC 11:47monitoring

   升级工作已成功完成。 我们的小组目前正在努力恢复服务并进行部署后验证.

4. 2026年9月23日 UTC 13:02monitoring

   升级工作已顺利完成,网站现已恢复上线. 我们的小组正在进行最后验证检查,以确认服务稳定性,然后宣布事件得到解决.

5. 2026年9月23日 UTC 15:57resolved

   服务已经恢复并正常运行。 恢复后,技术小组完成了扩大监测和验证活动,并确认了稳定运作。 这一事件现在被认为已得到解决.

6. 2026年9月30日 UTC 16:02postmortem

   ** 说明:** Flexera One – IT资产管理-北美 – 2026R1.3之后的服务无法使用 维修 ** 时间框架:** 2026年9月22日 9:00 PM PDT — 2026年9月23日 5:47 AM PDT ** 事件摘要** 2026年9月22日,Flexera为北美地区Flexera One IT资产管理公司进行了计划中的2026R1.3生产发布. 环境内部绝大多数数据库的升级工作都取得了成功。 然而,当预定的维护窗口于PMPDT9:00结束时,所需的数据库迁移操作仍在进行中。 由于在迁移完成之前无法恢复生产环境,信息技术资产管理在预定的维护期之后仍未恢复。 其余的迁移需要重建大量数据,包括大量数据。 这次行动成为完成释放的关键途径,耗时大大超过预期。 在初始索引处理阶段完成后,数据库仍需进行额外的排序和索引创建活动. 这项工作持续了几个小时,延长了整个移徙时间。 在调查期间,技术小组评价了现有的恢复方案,包括是否可以暂时将受影响的数据库从迁移路径中分离出来,以便环境的其余部分恢复服务。 由于部署的阶段和这种办法需要的额外恢复工作,最可靠的恢复途径是在恢复环境之前完成数据库操作。 一旦数据库迁移完成,技术小组开始恢复应用和支助服务。 在开办期间,又遇到了一个恢复服务的问题,需要人工干预才能继续恢复。 补救后,成功恢复了其余的应用和平台服务。 随后,技术小组完成了验证活动,确认了客户准入,并进行了扩大监测,以核查服务稳定性。 客户撞击于2026年9月23日以5:47AM PDT结束. ** 循环原因** 导致停用的原因是2026R1.3迁移期间发现的数据库指数配置差异,导致大规模指数重建操作,大大超过计划维护窗口. 事件后调查确定,受影响数据库内的索引与当前发布时预期的数据库结构不符. 该索引以前是使用一个旧的定义重新编制的,该定义没有包括随后的数据库设计变化。 在2026R1.3部署期间,迁移进程确定了这一差异并启动了必要的数据库操作,以使索引与目前的数据库定义保持一致。 由于所涉及的数据集规模特别大,因此由此而来的重建成为长期和资源密集型业务,大大地超过了计划的维护窗口. 一旦重建正在进行,剩下的处理时间无法可靠地预测,因此很难在行动继续进行期间提供准确的完成估计。 ** 补救行动** 在事件应对期间采取了以下行动: * 指数重建监测:指数重建和其余数据库升级活动通过完成不断监测。 * 评估了回收备选方案:评估了现有的恢复办法,以确定恢复生产环境的最安全和最可靠的途径。 * 数据库升级完成:在开始恢复应用程序之前完成了索引重建和剩余数据库升级活动。 * 恢复应用和支助服务:恢复应用和支助服务。 在遇到其他服务启动问题时,采取了有针对性的恢复行动。 * 服务回收核实:客户访问和应用程序功能得到确认,剩余背景处理得到审查,并完成了扩大监测,以核查稳定运行情况。 ** 未来预防措施** Flexera认识到这种停电的重要性和持续时间及其对北美地区客户的影响。 已完成全面根源分析和跨功能追溯,确定了以下预防措施,作为当前改进工作的一部分: 1. 数据库程序验证:各技术小组正在评估如何审查和维护数据库补救程序,以确保这些补救程序随着平台的发展与当前产品要求保持一致。 2. 部署前核查:正在评价放行验证程序,以确定如何在开始生产维护之前查明和评估出乎意料的数据库配置差异。 3. 高影响行动评估:技术小组正在评估如何在准备发布期间确定潜在的长期或资源密集型数据库业务,以便在部署之前更好地了解其预期持续时间和业务影响。 4. 释放准备状态和恢复规划:正在审查释放准备状态和恢复规划做法,以提高可能影响部署期限和服务恢复时间表的活动的能见度。 提供可靠和有复原力的服务仍然是一个优先事项。 目前正在将已完成的根源分析和追溯结果纳入技术和业务改进,以降低再次发生的可能性并强化未来维修活动的规划和执行.

自动翻译自官方事件更新。

1. 2026年9月22日 UTC 05:56investigating

   事件描述:我们正在调查一个影响我们澳大利亚地区使用斯诺地图集的客户子集的问题。 受影响的客户在看到最新的计算机信息和数据摄取方面可能遇到延误,也可能受到影响。 优先事项:P2 恢复活动:查明并解决了早先与DNS有关的问题。 然而,现在又发现更多的错误。 我们的技术小组正在积极调查这些错误,以确定其根本原因并恢复正常处理。 我们将继续评估影响,并在收到补充资料后提供进一步的最新资料.

2. 2026年9月22日 UTC 07:19investigating

   我们的小组进行了有针对性的服务重新启动,改善了处理的拖延。 监测表明,清单数据目前正在成功地得到更新。 其余错误仍在调查中,我们的小组正在努力查明根本原因,并执行一项永久性的解决方案.

3. 2026年9月22日 UTC 10:15monitoring

   补救行动解决了处理拖延和僵化的数据问题。 一些遗留问题仍然存在,目前正在由我们的技术小组进行调查。 这些小组正在监测服务,并在今后24小时内继续收集和审查记录,以支持调查。 我们将继续密切监测这些服务,并在获得更多信息后提供进一步的最新资料.

4. 2026年9月23日 UTC 07:05resolved

   我们的小组在一夜之间继续监测这些服务,并证实没有发现新的问题。 还成功地完成了更多的抽查。 这一事件目前正在得到解决。 有关根本原因和所采取行动的进一步信息将在死后报告中提供.

5. 2026年10月13日 UTC 12:49postmortem

   ** 说明:** Snow Atlas-APAC-数据摄入和处理延迟 ** 时间框架:** 2026年9月21日,5:48 PM PDT至2026年9月22日,3:15 AM PDT ‌ ** 事件摘要** 2026年9月21日星期一, PM PDT 5:48, 一期影响到澳大利亚东部(AE)地区的多家Snow Atlas租户, 受影响的客户在计算机页面上体验了过时的设备信息,而Snow Explaners显示的是“有错误的运行”状态。 在数据摄入过程中也发现了错误。 调查发现,澳大利亚东南地区与先前退役的基础设施有关的DNS记录已经过时。 这一记录干扰了与澳大利亚东部环境的连接,使清单数据无法按预期得到处理。 已过时的DNS记录被去除,使流量能够到达正确的终点并能够恢复库存扫描更新. 变更后,库存盘点开始进展,受到影响的连接服务状态随后于2026年9月22日3:15AM PDT恢复正常. 经过长时间的通宵监测后,连通服务保持稳定,9月23日12:05AM PDT宣布问题得到解决. 没有其他问题的报告,以前使用的澳大利亚东南基础设施已完全退役。 ‌ ** 循环原因** 事件由一出过时的DNS记录所引起,该记录在澳大利亚东南地区基础设施退役后还保留. 该记录引导流量远离澳大利亚东部环境的正确终点,干扰了清单数据处理所需的连接。 结果,库存更新被推迟,受影响的客户无法检索最新设备信息。 已删除了已过时的记录,恢复了与正确终点的连接,使库存处理得以恢复。 ‌ ** 补救行动** 我们的小组为恢复正常服务采取了下列行动: * 查明并删除了与以前退役的基础设施有关的过时的DNS记录。 * 恢复连接到正确的澳大利亚东端。 * 核实库存扫描和库存清点工作正在进行。 * 监测环境,以确认服务稳定性。 * 确认斯诺互联互通服务状况随后恢复正常,没有报告进一步的问题。 ‌ ** 未来预防措施** * 审查基础设施退役期间的DNS记录清理情况,以确保去除陈旧记录。 * 改进退役后的检查,以查明资源清除后留下的记录.

自动翻译自官方事件更新。

1. 2026年9月18日 UTC 13:03investigating

   事件描述:我们正在调查一个影响欧盟和APAC生产环境中库存数据处理的问题。 客户可能发现库存更新出现延误,导致库存数据不能反映最近的进口活动。 优先事项:P2 恢复活动:我们的技术小组正在积极调查这一问题,验证影响范围,并与相关依赖机构合作,以恢复正常的库存处理。 一旦获得更多信息,将提供进一步的最新资料.

2. 2026年9月18日 UTC 13:50identified

   我们的技术小组将这一问题追溯到最近的部署,并实施了补救行动。 初步核实表明,库存处理已恢复,技术小组正在积极监测处理活动和积压回收情况。 我们正在继续验证受影响环境中的恢复情况,并将在获得更多信息后提供进一步的最新资料.

3. 2026年9月18日 UTC 14:34identified

   技术小组完成了所需的配置更新,库存数据继续得到顺利处理。 已分配了更多的处理能力来加快积压的恢复,技术小组正在积极监测受影响环境中的吞吐量和积压量的减少情况。 恢复活动仍在进行中,随着积压处理的继续进行,将提供进一步的最新资料.

4. 2026年9月18日 UTC 14:39monitoring

   库存数据处理继续恢复,技术小组的积压量呈下降趋势。 其他处理能力依然存在,正在密切监测受影响环境中的恢复进展情况。 我们将继续监测积压的减少情况,并随着恢复的进展提供进一步的最新资料.

5. 2026年9月18日 UTC 18:52monitoring

   库存数据处理工作在以往实施的补救之后继续进行。 技术小组正在积极监测受影响环境中的加工吞吐量和积压回收情况。 技术小组正在继续评估恢复进展情况和有助于加快积压处理的任何其他行动。 随着回收工作的进展,将提供进一步的最新资料.

6. 2026年9月18日 UTC 19:49monitoring

   APAC在先前实施的补救之后完成了积压的回收工作,清单数据处理已恢复到该区域的预期水平。 欧盟继续开展恢复活动,技术小组正在监测处理工作量和减少积压情况。 正在评价其他回收措施,以便随着回收工作的进展而支持积压处理.

7. 2026年9月18日 UTC 21:55monitoring

   欧盟继续开展恢复工作,技术小组正在观察剩余积压工作正在减少的情况。 为支持欧盟的积压处理,还实施了其他恢复优化,技术小组继续监测吞吐量和总体恢复进展情况。 随着进展的继续,将提供进一步的最新资料.

8. 2026年9月19日 UTC 11:07monitoring

   恢复工作继续取得进展,其余积压案件稳步减少。 在欧盟环境中实施的其他优化正在有效支持积压处理。 我们的小组继续密切监测复原进展情况,并将酌情提供进一步的最新资料.

9. 2026年9月19日 UTC 19:09monitoring

   欧盟继续开展恢复工作,技术小组注意到,在以往实施的优化之后,积压工作继续减少。 根据目前的复原趋势,积压数量已大大减少,并继续朝着预期方向发展。 随着进展的继续,将提供进一步的最新资料.

10. 2026年9月20日 UTC 19:55resolved

    技术小组已证实,在以前实施的补救之后,欧盟的清单数据处理已恢复正常运作。 这一问题追溯到影响库存数据处理的部署配置问题。 应用了所需的配置更新,恢复了正常处理. 经过验证和延长监测,欧盟积压的回收工作已经完成,整个欧盟和APAC的库存处理保持稳定。 这一事件现在被认为得到解决.

11. 2026年10月23日 UTC 17:20postmortem

    ** 说明:** Flexera One -- -- 信息技术资产管理 -- -- 欧盟和APAC -- -- 部署配置问题后库存处理延误 ** 时间范围:** 2026年9月16日 2:00 PM PDT - 2026年9月20日 9:52 AM PDT ** 事件摘要** 2026年9月18日星期五,技术小组开始调查影响Flexera One IT资产管理\(ITAM\)欧洲\(欧盟)和亚太\(APAC\)区域的客户的存货更新延迟的报告. 最新的库存信息没有反映在申请中,一些客户报告说,他们最新的库存数据是9月16日。 这一问题影响到清单处理,而不是ITAM平台的普遍可用性。 初步分析表明,库存处理服务似乎良好,但收到的库存文件没有通过预期的处理工作流程取得进展。 进一步调查可追溯到9月16日进行的部署,在此期间,一个配置问题影响到负责处理库存数据的部门。 技术小组确定并纠正了部署配置,使库存处理得以恢复。 然而,在中断期间,库存文件大量积压,需要更多时间处理。 库存处理首先在APAC回收,9月18日大约12:21PM PDT清理了积压的积压. 欧盟区域需要更多的恢复时间,因为积压的文件数量很大。 技术小组调整了处理能力设置并随着库存档案的处理而继续监测积压情况。 9月20日,大约9:52AM PDT完全清除了欧盟剩余的积压。 随后的监测证实,库存处理已恢复到正常业务水平。 ** 循环原因** 事件发生的原因是在9月16日更新库存处理服务期间出现了部署配置问题。 在部署时,库存处理基础设施正在从应用环境过渡,需要不同的服务才能根据区域情况在每一环境中保持活跃。 这增加了维持正确生产配置的复杂性,在部署期间所需服务配置没有得到正确维护. 因此,欧盟和APAC区域库存处理工作流程被中断,使收到的库存文件无法处理并延误了库存数据更新。 一旦配置得到纠正,库存处理工作就恢复,在完全恢复正常业务水平之前,积压工作需要更多的时间来处理。 ** 补救行动** 在事件应对期间采取了以下行动: 1. ** 启动的事件调查:** 技术小组调查了关于欧盟和APAC区域清单更新延迟的报告,并审查了清单处理工作流程,以查明中断的来源。 2. ** 已查明的部署配置问题:** 调查将中断追溯到9月16日的部署,并查明影响受影响地区库存处理的不正确的服务配置。 3. ** 经更正的生产配置:** 所需的配置更新用于恢复受影响的库存处理服务,使收到的库存文件能够恢复处理。 4. ** 启动库存回收:** 技术小组监测了累积的库存档案并调整了现有处理资源,以支持在恢复处理工作流程后收回积压的工作。 5. ** 优化处理量:** 在欧盟恢复期间,技术小组查明了工作量增加造成的加工能力制约,并调整了加工货币,以提高吞吐量,同时保持服务稳定性。 6. **经核实的服务回收:** 技术团队证实APAC的积压工作已于9月18日清理完毕,随后欧盟的积压工作于9月20日完全恢复. 持续监测证实,库存处理已恢复正常运作。 ** 未来预防措施** 事件发生后,我们进行了一次回顾,以审查部署配置问题、应用程序环境、库存处理监测能力以及改进部署验证和业务可见度的机会之间的差异。 下列纠正行动和改进活动已经完成或正在进行: 1. ** 区域服务配置管理:** 已实施一个区域服务配置清单,以记录和维持不同部署环境中所需的服务配置,减少今后发布期间配置不一致的风险。 2. ** 部署验证改进:** 已实施部署核对表,以核实所需库存处理服务在部署活动期间是在适当环境中运行的。 3. ** 加强库存处理监测:** 已实施更多的监测和警报,以便及早查明库存处理的中断情况并加快调查和追回。 4. ** 改进处理出错:** 已实施监测仪表板,以提高异常应用响应模式的能见度,包括处理能力相关出错。 这些改进已有助于在以后的处理问题中及早发现和恢复。 5. ** 生产环境简化:** 目前正在进行的整合部署模式的工作将减少在环境和区域之间维持不同服务配置的相关业务复杂性,有助于减少类似配置相关处理中断的风险.

自动翻译自官方事件更新。

1. 2026年9月16日 UTC 09:04identified

   事件简介:我们目前正面临影响Flexera社区网站的问题。 由于持续的停电影响第三方服务供应商,客户可能无法进入Flexera社区门户,或可能经历间歇和不可靠的行为。 此外,客户可能无法通过社区网站创建、更新或与支助案例互动。 在此期间发送到支持@flexera.com的电子邮件,在基本故障解决之前,不得收到或处理. 这种第三方服务提供者的停电也影响到Spot支助小组主动监测能力,以发现任何客户环境问题以及Spot控制台内的一个聊天器部件。 优先事项:P3 恢复活动:我们的技术小组正在积极监测局势,同第三方提供者合作,追踪恢复工作。 我们将继续评估客户的影响,并在收到补充资料后提供进一步的最新资料.

2. 2026年9月16日 UTC 12:31identified

   服务供应商在试验环境中成功验证了固定装置,并已开始在所有受影响的情况下使用。 推出工作正在逐个区域进行,在完成部署的地区,服务正在恢复正常.

3. 2026年9月16日 UTC 19:25monitoring

   我们的服务提供者报告说,在部署缓解措施之后,服务遥测一直保持健康。 社区目前仍然可以进入,尚未确认持续的影响。 我们将继续监测环境,以确保持续稳定,同时完成最后验证活动。 我们将在获得补充资料后提供进一步的最新资料.

4. 2026年9月16日 UTC 22:00monitoring

   我们的服务提供商宣布,在成功缓解和扩大验证之后,基本事件得到解决。 社区仍可进入,尚未确认持续的影响。 在整个恢复期间的监测没有发现任何其他问题。 这一事件现在被认为得到解决.

5. 2026年9月17日 UTC 11:01resolved

   我们的小组在整个恢复期间继续监测这项服务,没有观察到其他问题。 根据服务的持续稳定性,目前认为这一事件已经得到解决.

6. 2026年9月30日 UTC 12:30postmortem

   ** 描述:** Flexera 社区服务没有 ** 时间范围:** 2026年9月16日,12:50 AM PDT至2026年9月16日,8:26 AM PDT ‌ ** 事件摘要** ‌ Flexera于2026年9月16日12:50 AM PDT, 事件中,客户可能无法进入Flexera社区,无法提出或管理支助案件,也无法通过社区获得对现有案件的答复。 发送到支持@flexera.com的电子邮件也可能在停用期间被延迟或不处理. 这个问题还影响到Spot控制台内的聊天台功能,该控制台依赖于受影响的服务。 此外,停电影响到Spot支援小组用来查明依赖服务通知的某些客户环境问题的主动监测能力。 服务供应商随后验证了一个固定装置,并开始按区域在受影响的地方安装。 随着缓解措施的部署,服务逐渐恢复正常。 部署后,服务遥测在客户环境中保持健康。 验证确认Flexera社区和Spot聊天台功能正常运行. 基础供应商事件随后被宣布解决,Flexera完成了最终验证并结案. ‌ ** 循环原因** ‌ 事件发生的原因是停电,影响到一个外部服务提供者支持Flexera社区和相关功能的服务。 服务中断影响了社区平台和相关整合的可用性和可靠性,导致客户支助个案功能和相关Spot能力暂时中断。 ‌ ** 补救行动** ‌ * 提供方补救:外部服务提供商在受影响的情况下验证并安装了固定装置。 * 服务验证:随着补救的部署,Flexera小组监测社区、聊天机器人功能和相关服务。 * 回收监测:对服务健康和功能进行了监测,以确认在补救后的稳定。 * 事件结束:在基本供应商问题得到解决并完成Flexera验证后,事件结束。 ‌ ** 未来预防措施** ‌ * 加强依赖性监测:继续监测支持客户服务的关键外部依赖性。 * 客户影响评估:继续评估包括社区、支助个案管理和Spot功能在内的综合Flexera服务外部服务中断的影响。 * 事故后监测:在恢复外部服务后,继续监测客户的剩余影响.

自动翻译自官方事件更新。

1. 2026年9月15日 UTC 23:05investigating

   事件简介:我们正在调查一个影响欧盟生产环境中的政策和自动化服务的问题。 欧盟的客户在使用政策时可能遇到故障,可能无法通过用户界面查看其政策. 影响仅限于欧盟区域。 优先事项:P2 恢复活动:我们的技术小组一直在参与并正在积极调查基础设施升级过程中遇到的问题,以查明根本原因并尽快恢复正常服务。 随着调查的进展,将提供进一步的最新资料.

2. 2026年9月16日 UTC 06:16monitoring

   影响欧盟环境的问题已经解决,用户界面的接入已经完全恢复. 虽然目前服务正常运行,但排队工作积压在停工期间积累,可能需要一些时间来处理. 我们的小组正在积极监测复苏情况,以确保清理积压工作,并继续按预期提供服务。 我们将继续密切监测环境,一旦处理工作完全恢复到正常水平,就予以确认.

3. 2026年9月16日 UTC 08:24resolved

   我们的小组继续密切监测这项服务,没有观察到新的问题。 在中断期间所积压的排队工作正在顺利地进行,并按预期继续减少。 根据自恢复以来观察到的稳定情况,这一事件现已得到解决。 我们将继续监测处理情况,以确保剩余的积压清理工作完全完成,该处继续按预期运作.

4. 2026年10月12日 UTC 12:02postmortem

   ** 说明:** Flexera -- -- 欧盟 -- -- 政策/认证 ** 时间范围:** 2026年9月15日 3:50 PM PDT至2026年9月16日 1:22 AM PDT ‌ ** 事件摘要** 2026年9月15日3:50 PM PDT,支持欧盟生产环境中自动化的基础设施升级导致网络连接中断,影响政策和自动化. 客户在用户界面中难以查看政策,与政策有关的业务失败. 调查发现一个遗留的网络组件的出乎意料的行为。 这中断了受影响服务所需的连接。 该小组确定了所涉部分,并将所需资源上线,恢复网络连接。 基本问题于9月15日10:13PMPDT解决. 其后,该小组继续监测服务恢复情况,并处理在中断期间所积压的工作。 一旦积压处理按预期取得进展并证实服务稳定,该事件于2026年9月16日凌晨1:22AM PDT宣布完全恢复. 这种影响仅限于欧盟的生产环境。 ‌ ** 循环原因** 事件由欧盟区域自动化基础设施升级期间遗留的网络组件出人意料的行为所引起. 这中断了政策和自动化所需的网络连接,导致无法提供服务,政策相关功能出现故障。 ‌ ** 补救行动** 我们的小组为恢复正常服务采取了下列行动: * 互联互通的恢复:查明所涉遗留部分,并在网上提供所需资源来恢复网络的连通性。 * 服务恢复:恢复连通性并解决影响政策和自动化的根本问题。 * 积压处理:监测在恢复服务后收回的积压处理。 * 恢复后验证:确认服务稳定性,并核实积压处理进展如所预期,然后宣布事件完全恢复。 ‌ ** 未来预防措施** * 移徙规划:重新安排了相应的美国移徙,增加了一个维护窗口,以便有更多的时间解决和复原问题。 * 更换遗留部分:正在更换遗留部分,作为基础设施现代化工作的一部分。 一旦更换完毕,预计在所有环境中都将消除这种具体的遗留依赖.

自动翻译自官方事件更新。