Anaplan 中断历史

1. 2026年10月27日 UTC 13:22investigating

   我们目前正在调查一个问题,导致一些客户在进入Anaplan平台时遇到问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年10月27日 UTC 14:52identified

   我们的供应商已经查明一个第三方问题,影响到一些客户,在最近的软件升级后,他们的交通通过外部供应商防火墙。 受到影响的客户可能注意到以下行为: 标准 HTTPS 错误 我们的小组正在积极监测供应商的补救努力,以确保服务完全稳定。 我们将在60分钟后或决议通过后提供进一步的最新情况.

3. 2026年10月27日 UTC 15:03monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

4. 2026年10月27日 UTC 15:41resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

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

1. 2026年10月26日 UTC 10:55investigating

   我们目前正在调查Me1地区获得模型的机会的退化。 用户无法通过Anaplan UI导航到模型. 影响 : - 模型导航通过UI:受影响的——用户无法通过标准的UI导航浏览或打开模型. - 模式通过快捷链接访问:可用——有直接快捷方式或书签链接到模式的用户仍然可以访问. - 已运行的会话:未受影响——目前登录到模型中的用户不受影响。 - 不受影响。 我们正在努力查明根源并尽快恢复通航。 我们将在30分钟内提供最新情况,或一旦我们得到更多信息.

2. 2026年10月26日 UTC 10:57monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

3. 2026年10月26日 UTC 11:25resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

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

1. 2026年10月16日 UTC 14:44investigating

   我们目前正在调查影响客户进入Anaplan平台能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年10月16日 UTC 14:57investigating

   我们正在继续调查这一问题.

3. 2026年10月16日 UTC 15:07monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

4. 2026年10月16日 UTC 15:40resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

5. 2026年10月27日 UTC 21:01postmortem

   ** 导言** 在协调世界时14:25至协调世界时2026年10月16日15:05之间,用户无法登录到平台或访问他们的模型. 这一中断持续了40分钟,影响到下列地点的客户: *我们1:数据中心-美国东部 *我们2:数据中心-美国西部 * eu1:数据中心-荷兰 *eu2:数据中心-德国 *eu4:云-欧洲. *我们5:云 -- 美国东部 *我们7:云 -- 美国 *页1:云 -- -- 日本 ** 循环原因** 事件由行政搜索用户角色启动资源密集查询后引发. 此项请求是在选择了空角色超链接后提出的,该超链接开始了广泛的数据同步进程,没有成功过滤重复记录. 由于处理这些重复记录,我们的认证系统使用率极高。 这耗尽了现有资源并导致平台接入服务无法响应。 ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 我们暂时缩小认证服务,以减少负载,使系统恢复,并增加处理能力. 一旦认证系统稳定下来,服务便恢复到满负荷。 此外,我们还为我们的支助小组实施了业务准则,以避免在拟定永久解决办法时触发资源紧张的搜索选择。 到协调世界时15:05,该问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: * 我们更新了行政界面,以显示纯文本的空角色,防止资源繁忙的查询被触发。 * 我们正在优化系统的查询逻辑,以便在同步过程中高效地复制用户记录。 * 我们正在将用户更新同步在背景中自动化,以防止这些进程影响活跃的用户会话. * 我们正在提高全球所有区域的处理能力和配置复制品,以提高整个系统的复原力。 我们为这个问题可能对你的企业业务造成任何影响而道歉。 我们正在不断加强我们的系统和程序,以确保今后避免干扰你的业务和用户。 如果您还有其他问题或问题, 请访问我们的[支持] (https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F)网站 。 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

1. 2026年10月7日 UTC 15:42investigating

   我们目前正在调查一个在试图加载模型时造成间歇性错误的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年10月7日 UTC 15:58identified

   我们已查明了这一问题的可能原因,我们现在的重点是尽快恢复服务。 目前,我们还没有时间解决。 我们将在30分钟内或在决议通过后提供进一步的最新情况.

3. 2026年10月7日 UTC 16:28identified

   我们已经查明了事件可能的原因,并正在积极努力尽快恢复服务。 还没有解决时间。 我们将在30分钟内,或在决议通过后立即发布进一步的最新资料.

4. 2026年10月7日 UTC 16:59identified

   我们正在继续调查这一事件,目前正在采取多条恢复步骤,以尽快恢复服务。 我们的工程组正在积极介入,并优先全面恢复。 我们将在30分钟内提供我们下一次最新情况,或者,如果我们有重大进展要分享,我们将更早提供。 我们感谢你的耐心,并对可能造成的任何不便表示歉意.

5. 2026年10月7日 UTC 17:32identified

   我们做了一些改变并正在取得积极进展。 虽然这个问题尚未完全解决,但错误的数量已大大减少。 我们的工程队继续通过恢复步骤来工作,以实现全面恢复。 我们将在30分钟内提供我们下一次最新情况,或者,如果我们有重大进展要分享,我们将更早提供。 我们感谢你的耐心,并对可能造成的任何不便表示歉意.

6. 2026年10月7日 UTC 17:46monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

7. 2026年10月7日 UTC 18:02resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

8. 2026年10月16日 UTC 18:22postmortem

   在协调世界时2026年10月7日星期三14:41到协调世界时17:47之间,试图访问我们2中的模型的客户:数据中心-US West可能经历了间歇地加载延迟,网络出错,以及HTTP500出错. ** 循环原因** 事件由自动维护更新所引发,导致一个基础设施主机上出现出乎意料的网络接口重置. 网络接口初始化后,出乎意料的软件行为阻止了网络流量正常的路由. 虽然网络接口报告与监测系统的连接状态良好,但司机停止转发网络流量。 这一无声故障使该服务器上的虚拟机失效,包括主要的区域DNS缓存和认证服务。 这些主要线路服务的损失增加了其余服务器的流量,导致平台间歇性延误和超时. 由于恢复受影响的系统依赖于暂时无法提供的内部服务,补救工作进一步放缓。 ** 恢复** 为了减轻客户影响并恢复平台稳定性,我们立即动员团队隔离网络退化源并保护活跃的用户会话. 我们首先安全地将活跃的客户工作量从受影响的基础设施转移出去。 同时,我们实施跨平台的紧急交通改道配置,严格通过健康的路由系统绕过受损的网络组件和线路请求. 一旦交通通道稳定下来,我们安全地将主要网络线路服务迁移到另一个健康的基础设施。 这成功重建了正常的网络通信,使查询响应时间和系统出错率回到了协调世界时17:17的基准水平. 迁移后,我们密切监测了平台流量,验证了模型的响应能力,并证实跨区域数据进口正在顺利完成. UTC下午17:47分全面恢复服务. ** 更正和预防行动** 为防止平台再起并提高其复原力,我们正在采取以下纠正行动: *为了解决这一事件的触发器,我们永久地取消了导致网络接口重置的自动更新功能. * 我们正在启动一个跨基础设施主机的操作系统升级,以永久解决导致司机停止转发网络流量的软件缺陷,尽管报告存在健康的连接状态。 * 我们正在增加路由能力并移动关键网络系统,以建立独立的基础设施。 这将确保网络路线在平台活动期间保持充分的独立性和复原力。 我们为这个问题可能对你的企业业务造成任何影响而道歉。 我们正在不断加强我们的系统和程序,以确保今后避免干扰你的业务和用户。 如有其他问题或关注,请访问我们的[支持]网站(https://support.anaplan.com/)。 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

1. 2026年9月17日 UTC 11:18investigating

   目前我们正在调查影响客户经营Cloudworks集成能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年9月17日 UTC 11:29identified

   我们已查明了这一问题的可能原因,我们现在的重点是尽快恢复服务。 目前,我们还没有时间解决。 我们将在30分钟内或在决议通过后提供进一步的最新情况.

3. 2026年9月17日 UTC 11:35resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

4. 2026年9月24日 UTC 18:19postmortem

   2026年9月17日协调世界时11:13,我们eu3的客户:Cloud - 欧洲地区经历了延迟和难于访问预定的CloudWorksTM集成. 虽然CloudWorksTM用户界面仍然可供浏览,但安排和手工集成暂时无法使用。 ** 循环原因** 地下云层基础设施内部的临时网络中断中断了支持调度机制的内部服务器之间的通信。 这种网络波动导致内部调度系统进入自动安全模式,以防止任何数据不一致. 在此状态下,调度服务断开,无法处理和执行已排定的集成. ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 我们执行了标准恢复协议,以恢复调度服务器之间的连接,并重新启动CloudWorksTM服务组件. 成功重启后,小组核实,预定的整编工作恢复了正常运作并正在顺利完成。 到协调世界时11:29,这个问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: * 我们正在优化我们的自动化基础设施维护和服务器重建程序,以防止在系统更新过程中干扰预定的操作。 * 我们正在采取战略举措,将我们的日程安排平台迁移到具有自动化自愈能力的高度弹性基础设施。 我们为这个问题可能对你的企业业务造成任何影响而道歉。 我们正在不断加强我们的系统和程序,以确保今后避免干扰你的业务和用户。 如有其他问题或关注,请访问我们的[支持]网站(https://support.anaplan.com/)。 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

1. 2026年9月16日 UTC 12:24investigating

   目前我们正在调查影响客户经营Cloudworks集成能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年9月16日 UTC 12:35monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

3. 2026年9月16日 UTC 12:41resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

4. 2026年9月24日 UTC 18:09postmortem

   2026年9月16日 UTC中午12点07分,我们公司的客户5:Cloud - US East region在完成CloudWorksTM集成运行时遭遇了延误. ** 循环原因** 在我们的通信基础设施上,一个预定的维护窗口中,与CloudWorksTM服务的主动连接被暂时中止。 由于连接处理限制,服务在维护完成后并未自动恢复. 这使得加工组件处于无响应状态,使得集成无法完成并导致资源消耗增加. ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 我们重新启动并扩大了时间安排和处理组件,这立即恢复了正常的时间表完成情况。 至协调世界时12:36,该问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: * 我们正在改进连接处理机制,以确保处理服务能够在任何维护活动期间自动和优雅地重新连接到信息基础设施。 * 我们正在评估自动恢复机制,以便在没有人工干预的情况下主动发现和解决时间安排暂停。 我们为这个问题可能对你的企业业务造成任何影响而道歉。 我们正在不断加强我们的系统和程序,以确保今后避免干扰你的业务和用户。 如有其他问题或问题,请访问我们的支助网站。 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

1. 2026年9月10日 UTC 17:22investigating

   我们目前正在调查一个导致一些客户无法装入模型的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年9月10日 UTC 17:37monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

3. 2026年9月10日 UTC 18:04resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

4. 2026年9月21日 UTC 18:01postmortem

   2026年9月10日 UTC下午16点56分,我们7:Cloud - 美国地区在试图装入新的工作空间时可能遭遇了延误. 现有的工作空间会议没有受到影响。 ** 循环原因** 最近更新了我们内部工作空间资源分配服务配置,缩短了请求后端基础设施的响应时限。 在某些情况下,区域内短暂的基础设施延误超过了这一限度,导致服务一再重新启动。 这阻止了系统建立新的工作空间连接和延迟模型加载. ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 我们实施了应急配置改变,以禁用反应时限,使工作空间资源分配服务稳定下来。 该系统一旦应用,成功处理了积压的连接请求,服务恢复正常. 至协调世界时18:02,该问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: * 我们正在审查和调整我们工作空间资源分配服务的反应限度,以建立一个更安全、更具复原力的配置,以适应短暂的基础设施延误。 * 我们正在加强对新工作空间连接和加载过程的合成监测试验范围,以更好地及早发现工作空间分配问题。 我们为这个问题可能对你的商业运作产生的影响道歉。 我们正在不断加强我们的系统和程序,以避免干扰你的业务和用户。 如有问题或关切,请与我们的[支助]小组联系(https://support.anaplan.com/).

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

1. 2026年9月7日 UTC 13:26investigating

   我们目前正在调查影响客户进入Anaplan平台能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年9月7日 UTC 13:33investigating

   我们已查明了这一问题的可能原因,我们现在的重点是尽快恢复服务。 目前,我们还没有时间解决。 我们将在30分钟内或在决议通过后提供进一步的最新情况.

3. 2026年9月7日 UTC 13:35monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

4. 2026年9月7日 UTC 13:46resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

5. 2026年9月16日 UTC 22:19postmortem

   2026年9月7日 UTC下午1:00,客户遭遇无法访问Anaplan平台. 客户在试图访问用户界面时遇到重定向回路和空白页,集成被退化. ** 循环原因** 后端系统更新我们的认证系统 无意中将符号验证重定向到不正确的端点. 问题在发布前并未发现, 因为测试环境中有终点, 故障出现在没有终点的生产中。 因此,系统无法取回验证客户会话令牌所需的钥匙,也无法验证客户请求。 ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 在发现发布后认证错误后,我们立即触发了认证系统回滚到上个版本. 这恢复了正确的符号验证终点,认证错误被恢复到正常水平. 会话符号验证被恢复,客户重新进入了平台. 至协调世界时13:35,该问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: * 我们正在纠正认证系统配置,以使符号验证使用正确的端点。 这使得会话符号验证无法被系统更新重定向到不正确的端点. * 我们在部署过程中增加了验证检查,以确认更新的依赖性在发布前活跃于生产环境中。 这样就无法部署依赖于生产中没有的配置的更新。 我们为这个问题对你们行动的影响道歉。 我们致力于上述改进,以防止类似的干扰。 如果您有问题或问题,请联系支援小组.

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

1. 2026年9月3日 UTC 14:56investigating

   我们目前正在调查影响客户进入Anaplan平台能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年9月3日 UTC 15:12identified

   我们已查明了这一问题的可能原因,我们现在的重点是尽快恢复服务。 目前,我们还没有时间解决。 我们将在30分钟内或在决议通过后提供进一步的最新情况.

3. 2026年9月3日 UTC 15:16monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

4. 2026年9月3日 UTC 18:04resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

5. 2026年9月9日 UTC 08:38postmortem

   ** 导言** 2026年9月3日,从协调世界时14:51到协调世界时16:17,in1:Cloud-India region不通. 在此期间,客户无法进入或绕行平台. ** 循环原因** 2026年9月3日,我们在印度地区服务的安全证书计划延期期间,采用了不完整的证书捆绑. 这导致认证和验证服务无法验证安全连接,导致平台无法访问. ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 我们把自定义配置恢复到平台管理的安全证书服务,成功恢复了连接验证. 至协调世界时16:17,该问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: * 我们正在彻底审计我们环境中的所有安全证书,以优化我们的配置管理并使其标准化。 * 我们正在向管理下的证书服务过渡,以尽量减少手动配置要求。 * 我们正在对所有未来的安全证书更新进行自动全链验证检查,以确保部署前完全完整。 我们为这个问题可能对你的企业业务造成任何影响而道歉。 我们正在不断加强我们的系统和程序,以确保今后避免干扰你的业务和用户。 请访问我们的[支持网站] (https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F). 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

1. 2026年9月1日 UTC 09:49investigating

   目前我们正在调查影响客户经营Cloudworks集成能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年9月1日 UTC 10:25investigating

   谢谢你耐心地继续调查这个问题。 目前,我们还没有时间解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

3. 2026年9月1日 UTC 11:06investigating

   谢谢你在我们调查这个问题时 继续耐心 我们确认了一个影响多个区域云工作一体化的问题。 这仍然是一个最优先事项,我们还没有估计的时间来解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

4. 2026年9月1日 UTC 11:45identified

   谢谢你在我们调查这个问题时 继续耐心 我们看到, " 云工作 " 一体化在所有区域都开始并成功完成;然而,我们继续密切监测局势。 在我们努力尽快解决这一问题时,我们将每30分钟分享进一步的最新情况.

5. 2026年9月1日 UTC 12:19monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

6. 2026年9月1日 UTC 12:42resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

7. 2026年9月10日 UTC 22:10postmortem

   2026年9月1日 8:00 UTC至12:20 UTC期间,我们的客户:数据中心 - US East, us2:数据中心 - US West, eu1: 数据中心 - 荷兰, eu2: 数据中心 - 德国,eu4: Cloud - 欧洲,我们5: Cloud - US East,我们7: Cloud - US, and ap1: Cloud - 日本地区可能经历了延迟CloudWorksTM集成和间歇性API错误. ** 循环原因** 更新我们的API服务,旨在增加内部处理能力,导致生产负载下的异常行为. 由于这种行为,服务资源使用量出人意料地增加到了极限. 这种节奏的请求处理导致内部服务之间的网络解析超时. 因此,整合进程和API请求断断续续地无法与内部后端组件连接. 此外,虽然恢复更新解决了主要资源问题,但这样做消除了启动延误的固定办法。 这给恢复期间一些API请求造成了临时连接困难. ** 恢复** 我国工程组立即启动事故应对程序,隔离延误源并恢复服务. 我们恢复了API的改变,重新启动了内部网络解析服务以清理超时,并扩大了受影响地区的一体化服务能力。 为了解决由回滚重新引入的启动初始化延迟问题,我们管理了初始化负载,并通过将启动延迟修复从原始更新中分离出来并成功重新部署,实施了固定前置方法. 至协调世界时12:20,集成处理和API服务已稳定,至协调世界时17:24,该问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: *我们正在重新开发API处理码,以解决导致这一事件的潜在资源瓶颈,确保能够在高负荷下安全优化平台能力. * 我们正在加强我们的系统启动配置和健康检查参数,以防止初始化延误造成服务中断。 * 我们正在加强我们的网络监测和可观察性衡量标准,以加深内部名称分辨率和网络性能的能见度。 我们对此问题可能对你的商业业务产生的影响表示歉意。 " `我们正在不断加强我们的系统和程序,以确保今后避免干扰你的业务和用户。 如有其他问题或关注,请访问我们的[支持]网站(https://support.anaplan.com/)。 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

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

   目前我们正在调查影响客户经营Cloudworks集成能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年9月1日 UTC 09:28monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

3. 2026年9月1日 UTC 09:47resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

4. 2026年9月10日 UTC 22:09postmortem

   2026年9月1日 8:00 UTC至12:20 UTC期间,我们的客户:数据中心 - US East, us2:数据中心 - US West, eu1: 数据中心 - 荷兰, eu2: 数据中心 - 德国,eu4: Cloud - 欧洲,我们5: Cloud - US East,我们7: Cloud - US, and ap1: Cloud - 日本地区可能经历了延迟CloudWorksTM集成和间歇性API错误. ** 循环原因** 更新我们的API服务,旨在增加内部处理能力,导致生产负载下的异常行为. 由于这种行为,服务资源使用量出人意料地增加到了极限. 这种节奏的请求处理导致内部服务之间的网络解析超时. 因此,整合进程和API请求断断续续地无法与内部后端组件连接. 此外,虽然恢复更新解决了主要资源问题,但这样做消除了启动延误的固定办法。 这给恢复期间一些API请求造成了临时连接困难. ** 恢复** 我国工程组立即启动事故应对程序,隔离延误源并恢复服务. 我们恢复了API的改变,重新启动了内部网络解析服务以清理超时,并扩大了受影响地区的一体化服务能力。 为了解决由回滚重新引入的启动初始化延迟问题,我们管理了初始化负载,并通过将启动延迟修复从原始更新中分离出来并成功重新部署,实施了固定前置方法. 至协调世界时12:20,集成处理和API服务已稳定,至协调世界时17:24,该问题已完全解决. ** 更正和预防行动** 我们正在采取以下行动来防止再次发生: *我们正在重新开发API处理码,以解决导致这一事件的潜在资源瓶颈,确保能够在高负荷下安全优化平台能力. * 我们正在加强我们的系统启动配置和健康检查参数,以防止初始化延误造成服务中断。 * 我们正在加强我们的网络监测和可观察性衡量标准,以加深内部名称分辨率和网络性能的能见度。 我们对此问题可能对你的商业业务产生的影响表示歉意。 " `我们正在不断加强我们的系统和程序,以确保今后避免干扰你的业务和用户。 如有其他问题或关注,请访问我们的[支持]网站(https://support.anaplan.com/)。 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

1. 2026年8月27日 UTC 10:22investigating

   我们目前正在调查影响加拿大客户使用Anaplan平台能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年8月27日 UTC 10:52investigating

   谢谢你耐心地继续调查这个问题。 目前,我们还没有时间解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

3. 2026年8月27日 UTC 10:57identified

   我们已查明了这一问题的可能原因,我们现在的重点是尽快恢复服务。 目前,我们将在30分钟后或在决议通过后提供进一步的最新情况.

4. 2026年8月27日 UTC 10:58monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

5. 2026年8月27日 UTC 11:08resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

6. 2026年9月3日 UTC 15:52postmortem

   2026年8月27日 UTC10:22,我们ca1的一些顾客: Cloud - Canada 区域经历了间歇性地进入平台的问题. 在此期间,用户在尝试登录时可能遇到出错. 影响不尽相同,取决于处理每项请求的哪个部分——有些请求成功,而另一些请求不成功。 ** 循环原因** 在标准系统更新后,加拿大地区的单一交通线路组件在配置重新装入后进入了不一致状态,并未能正确重建其线路指令. 该部分开始断断续续地拒绝或误导客户请求. 该部分的健康检查核实了它的可用性,但未能反映其路径配置的正确性。 因此,它仍然活跃并继续服务于交通。 这导致一些请求成功,而另一些请求则不成功,取决于哪个部分处理连接。 ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 视察队将问题隔离到单一的交通线路部分,并重新开始。 这重新分配了其余健康部分的所有交通流量。 到协调世界时11:08,这个问题已完全解决. ** 更正和预防行动** 我们正在实施以下行动,以防止再次发生: *我们正在强化对交通线路部分的健康检查,以便立即隔离并自动重新启动任何在配置更新后未能正确验证的组件. 这使得退化的部件无法继续服务于交通,并造成客户间歇地无法进入。 * 我们正在改进我们的监测,使单个服务部分的能见度更高。 这有助于更快地发现局部问题,以免影响更多的客户。 我们为这个问题对你们行动的影响道歉。 我们致力于上述的改进,以防止类似的中断. 如有问题或关切,请与我们的[支助]小组联系(https://support.anaplan.com/).

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

1. 2026年8月15日 UTC 03:27investigating

   目前我们正在调查影响客户经营Cloudworks集成能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年8月15日 UTC 04:02investigating

   我们正在调查一个影响客户进入Anaplan平台能力的问题,这也影响到CloudWorks的一体化。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

3. 2026年8月15日 UTC 04:31investigating

   谢谢你耐心地继续调查这个问题。 目前,我们还没有时间解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

4. 2026年8月15日 UTC 05:03identified

   我们已查明了这一问题的可能原因,我们现在的重点是尽快恢复服务。 目前,我们还没有时间解决。 我们将在30分钟内或在决议通过后提供进一步的最新情况.

5. 2026年8月15日 UTC 05:33identified

   我们已同第三方提供者一起使这一问题升级,以缓解这一问题。 目前,我们还没有时间解决。 我们将在30分钟内或在决议通过后提供进一步的最新情况.

6. 2026年8月15日 UTC 06:13identified

   我们正在继续与我们的供应商密切合作,以解决影响欧盟二国区域的准入问题,这仍然是我们的最高优先事项。 通过我们的调查,我们确定与欧盟-加泰罗尼亚-1区域的联系问题是其根本原因。 从8月14日下午7点33分起, 我们的供应商开始发现, 受灾地点被确定为法兰克福的埃克尼克斯. 虽然取得了进展,但与该地点的连接仍然受到影响。 我们继续与我们的供应商优先采取解决步骤。 然而,预计全面恢复需要几个小时的时间。 在我们努力尽快恢复服务时,或者在获得更多信息时,我们将每60分钟提供一次最新情况.

7. 2026年8月15日 UTC 07:12identified

   我们正在继续与我们的供应商合作,解决影响eu2区域的准入问题,作为我们的最高优先事项。 我们还在探索多种途径,以尽快恢复服务。 正在与我们的供应商合作;但是,预计全面恢复需要几个小时。 当我们努力尽快恢复服务时,我们将每60分钟提供一次最新情况,如果获得更多信息,则将提前提供

8. 2026年8月15日 UTC 08:11identified

   我们已经完成了离开受影响地区的交通路线的调整,目前正处于监测阶段。 30分钟后将提供进一步的最新资料,如果有补充资料,则提前提供.

9. 2026年8月15日 UTC 08:37resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

10. 2026年8月25日 UTC 16:00postmortem

    2026年8月15日,从协调世界时03:16到协调世界时08:23,我们的eu2:数据中心的客户——德国地区经历了服务中断,使得无法进入Anaplan平台. 在此期间,当地基础设施的故障影响了该区域与外部服务连接的能力,导致平台可用性损失。 ** 循环原因** 中断的原因是我们供应商在德国法兰克福的第三方设施发生环境故障。 设施冷却系统出故障导致局部过热,引发了关键网络设备自动安全关闭. 逃出的水还损坏了设施内的局部电力分配系统,使网络设备失效. 这种综合电能和冷却故障使该系统无法解决外部地址问题并完成该区域的出行请求。 ** 恢复** 由于该设施的环境条件使该地区不安全进入,我们的供应商在评估和维修受影响设备方面被拖延。 因此,我们的工程组进行了紧急改变,通过另一个区域网络途径,绕过受损设施和区域,改变交通路线。 这成功恢复了完全的外部连接和名称分辨率,而平台接入在协调世界时08:23全面恢复. 随后几天,设施的运营商和我们的供应商继续进行恢复工作,到8月18日确认全面恢复。 在此期间,我们维持了紧急路线,以便在供应商完成修理时保持服务稳定。 ** 更正和预防行动** 我们正在执行以下措施,以加强复原力并减少发生类似破坏的风险: * 我们正在增加一层,在局部停电期间自动将交通转向其他地点,不需要人工干预。 * 我们正在允许缓存记录在无法找到外部解析器时继续服务流量,因此,外部服务的连通性损失不再妨碍发生区域事件时平台访问。 * 我们正在同我们的第三方设施和网络供应商合作,审查其关键电力和冷却系统标准,并确保建立更强有力的预防性保障措施。 我们为这个问题对你们行动的影响道歉。 我们致力于上述改进,以防止类似的干扰。 如果您有问题或问题,请联系支援小组.

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

1. 2026年7月29日 UTC 11:06investigating

   我们目前正在调查影响客户进入Anaplan平台能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年7月29日 UTC 11:36investigating

   我们目前正在调查影响客户进入Anaplan平台能力的问题。 谢谢你耐心地继续调查这个问题。 目前,我们还没有时间解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

3. 2026年7月29日 UTC 11:41monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

4. 2026年7月29日 UTC 12:51resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

5. 2026年8月7日 UTC 18:56postmortem

   On July 29, 2026, between 10:57 UTC and 11:53 UTC, customers in our us1: Data Center - US East, us2: Data Center - US West, eu1: Data Center - Netherlands, eu2: Data Center - Germany, eu4: Cloud - Europe, us5: Cloud - US East, us7: Cloud - US, and ap1: Cloud - Japan regions experienced degraded performance. This resulted in delayed model and workspace access, slow page load times, and slower logins across the platform, as well as delayed execution of CloudWorks™ integrations. All other regions were unaffected during this time.  **Root Cause**  The incident was triggered by an automated security software update deployed across our platform servers. This simultaneous update caused an unexpected, short-lived spike in storage activity that temporarily exceeded the storage systems' processing capacity. The resulting latency disrupted communication between internal metadata services and core system servers, causing the service connection pools to become unresponsive and preventing them from automatically recovering.  **Recovery**  Our engineering team identified the issue and took immediate action. We performed rolling restarts of the affected metadata services to clear the unresponsive connection pools and stabilize the systems. By 11:30 UTC, affected systems had recovered. Following this, the CloudWorks™ scheduler was restarted to process and clear the backlog of integration tasks. The issue was fully resolved by 11:53 UTC.  **Corrective & Preventative Actions**  We are implementing the following actions to prevent recurrence:  * We are implementing enhanced storage performance tiers and traffic-prioritization controls to isolate key platform workloads from other background system activities.  * We are updating our internal service connection frameworks to automatically detect and gracefully recover from unexpected system connection interruptions.  * We are refining our security software deployment processes to stagger rollouts and limit simultaneous resource utilization.  * We are enhancing our synthetic monitoring dashboards to improve visibility of regional service performance deviations.  * We are conducting rigorous connection-recovery and system testing in our lower environments to validate application resilience under loaded states.  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.  If you have further questions or concerns, please visit our [Support website](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F). We appreciate your patience during this incident and value the trust you place in Anaplan.

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

1. 2026年7月24日 UTC 20:35investigating

   我们目前正在调查一个导致一些客户无法装入模型的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年7月24日 UTC 23:01investigating

   谢谢你耐心地继续调查这个问题。 目前,我们还没有时间解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

3. 2026年7月24日 UTC 23:33investigating

   谢谢你耐心地继续调查这个问题。 我们的支助小组继续调查这一问题,但我们还没有时间加以解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

4. 2026年7月25日 UTC 00:07investigating

   谢谢你耐心地继续调查这个问题。 这个问题已升级到我们的高级工程和领导小组,他们正在积极调查局势并评估恢复全面行动的今后所有必要步骤。 虽然我们目前没有具体的技术细节可供分享,但请放心,解决这一事件是我们的最高优先事项。 我们为这次破坏表示诚挚的歉意并赞赏你的耐心。 我们将继续每30分钟提供最新情况,或者在出现新的细节时尽早提供最新情况,因为我们努力尽快解决这一问题.

5. 2026年7月25日 UTC 00:39investigating

   我们确定了可能的补救途径,目前正在积极开展减缓活动,以恢复服务稳定性。 虽然我们目前没有确切的估计恢复时间(ETA)可供分享,但请放心,我们的首要重点仍然是安全和迅速解决这一问题。 我们正在密切监测我们目前减缓措施的影响。 我们对目前的不便表示歉意。 我们的下一次更新将在30分钟后公布,或者在关键里程碑达到后尽早公布.

6. 2026年7月25日 UTC 01:08investigating

   我们理解这所造成的破坏,并想向你保证,尽快解决这一问题仍然是我们的首要任务。 我们的小组正在积极参与补救工作,所采取的措施正在朝着全面恢复服务的方向取得有意义的进展。 我们承认你在整个进程中的耐心,不认为这是理所当然的。 我们正在密切监测我们的系统,并将在30分钟内提供进一步的更新,或者如果有重大发展需要共享,则更早.

7. 2026年7月25日 UTC 01:42investigating

   我们正在继续执行和验证我们的补救计划。 随着复原努力的有步骤地向前推进,我们看到持续的进展。 为了确保安全彻底的恢复,我们正在认真取得进展,尚不能分享具体的技术里程碑。 请放心,我们的整个反应小组仍然全力解决这一事件。 谢谢你的耐心 我们的下一次更新将在30分钟后公布,或者在我们有进一步进展报告后尽快公布.

8. 2026年7月25日 UTC 02:18investigating

   我们目前正在加拿大地区进行紧急维修。 进入该平台暂时受到限制,而我们的团队则努力完成整治并验证全面恢复服务。 我们正在积极监测环境并取得进展。 我们赞赏你的耐心,并理解这对你工作的影响。 将每30分钟提供进一步的更新,如果有重大发展需要分享,则提前提供。 我们对不便表示歉意,并继续致力于尽快恢复服务.

9. 2026年7月25日 UTC 03:09investigating

   我们的小组仍然积极参与补救工作。 跨多个工作流程的工作正在取得进展,我们继续朝着全面恢复服务的方向前进。 我们将在30分钟内提供进一步的最新情况,如果有有意义的发展需要分享,则更早提供。 我们感谢你的耐心.

10. 2026年7月25日 UTC 03:47investigating

    我们目前正在加拿大地区进行紧急维修。 我们的小组正同我们的供应商协调,积极参与补救工作,这个问题已经得到控制。 在我们完成验证和恢复工作时,客户进入加拿大环境仍然暂时受到限制。 我们赞赏你的耐心,并将在一小时内提供进一步的最新情况,如果有重大发展需要分享,则更早提供.

11. 2026年7月25日 UTC 04:47investigating

    我们的小组继续与我们的供应商密切协调,在加拿大地区进行紧急维修。 这一问题已经得到遏制,恢复工作正在积极进行。 随着我们在恢复服务前完成必要的验证步骤,进入加拿大环境仍然暂时受到限制。 我们承认这对你工作的影响,并赞赏你持续的耐心。 我们的下一次更新将在1小时内提供,或者在出现重大事态发展时更早提供.

12. 2026年7月25日 UTC 06:05identified

    我们的小组继续与我们的供应商密切协调,在加拿大地区进行紧急维修。 然而,由于恢复进程的复杂性和范围,这一问题已经得到控制,我们期望恢复工作将是一项需要几个小时才能完成的扩大努力。 在恢复期间,进入加拿大环境仍将受到限制。 我们认识到这对你的工作有重大影响,并真诚赞赏你的耐心。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

13. 2026年7月25日 UTC 07:06identified

    我们的团队和供应商伙伴在紧急维护期间继续通过加拿大地区的复杂恢复进程取得进展。 我们在每个阶段都系统地执行回收规程和验证系统的完整性。 如前所述,由于这项努力的范围,这仍然是一个扩大的恢复进程,在我们努力安全和全面恢复服务时,进入加拿大环境将继续受到限制。 我们仍然充分认识到这种服务中断对你们业务的影响,并正在尽一切可能加快这些步骤。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

14. 2026年7月25日 UTC 08:07identified

    我们的工程和供应商小组继续积极执行紧急维修下的加拿大地区的恢复步骤。 目前没有新的技术细节或变化可供分享,因为我们的重点仍然是系统和安全地恢复服务。 在开展这些恢复活动的同时,进入加拿大环境仍然受到限制。 我们赞赏你在我们通过这一长期努力开展工作的过程中继续表现出耐心和伙伴关系。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

15. 2026年7月25日 UTC 09:06identified

    我们的工程小组和供应商伙伴继续通过紧急维修下的加拿大区域的恢复步骤取得进展。 我们正在取得积极的进展,并越来越接近使该区域重新成为大多数工作区。 在我们实施和完成这些关键的最后验证步骤以确保服务稳定性时,进入加拿大环境仍然暂时受到限制。 在我们进入恢复进程的最后阶段时,我们真诚赞赏你的耐心和伙伴关系。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

16. 2026年7月25日 UTC 10:07investigating

    我们正在继续系统地执行紧急维修下的加拿大地区的恢复步骤。 我们的工程小组和供应商伙伴仍然侧重于最后验证阶段,而且我们继续更接近于使该区域能够为大多数客户服务。 进入加拿大环境目前仍然受到限制,以确保我们在这些关键的最后步骤中保持系统稳定。 我们非常感谢你的耐心和伙伴关系。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

17. 2026年7月25日 UTC 11:14identified

    我们的工程小组和供应商伙伴在紧急维修下的加拿大地区最后审定阶段继续系统地取得进展。 我们仍然注重核查系统稳定,这使我们走上一条稳定的道路,使该区域能够为大多数客户服务。 进入加拿大环境目前仍然受到限制,以确保全面完成这些关键的安全和稳定检查。 我们极为感谢你在我们完成这项长期努力时继续表现出耐心和伙伴关系。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

18. 2026年7月25日 UTC 12:37identified

    我们的工程和供应商小组正在进入我们加拿大地区紧急维修恢复计划的最后准备阶段。 在我们准备恢复访问时,我们的计划是使该地区除带回自有密钥(BYOK)配置外的所有服务都能实现. 此外,少数工作空间在恢复一般服务后最初仍将被关闭。 对于这些具体的剩余工作空间,我们将执行一项高度控制、系统的恢复计划,以单独恢复每个环境,保证完全的稳定性和数据完整性。 目前进入加拿大环境仍然受到限制,同时我们完成了最后的认证前步骤。 我们认识到这对你的行动的持续影响,并真诚感谢你的持续耐心。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

19. 2026年7月25日 UTC 13:51identified

    我们正在恢复平台。 我们的工程和供应商小组正在积极努力,以尽快恢复服务。 作为我们恢复计划的一部分,我们将恢复该地区的所有服务,除了带回自有钥匙(BYOK)的配置. 此外,在初步恢复服务后,少数工作空间将暂时停用。 对于这些具体的工作空间,我们将实施一个高度控制、系统的恢复进程,以单独恢复每一种环境,并保证完全的稳定性和数据完整性。 目前进入加拿大环境仍然受到限制 我们认识到这对你的行动有重大影响,并真诚赞赏你的持续耐心。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

20. 2026年7月25日 UTC 16:22identified

    我们的工程队正在积极努力,通过仔细分阶段的恢复,恢复整个加拿大地区的平台稳定。 我们最初会恢复一般服务,除了带回自己的密钥(BYOK)配置. 为了保证一个稳定和安全的环境,少数工作空间在我们进行有控制的修复时可能会暂时被关闭. 随着我们完成这些关键的恢复措施,进入加拿大环境的总体条件仍然受到限制。 我们深切地认识到这种情况对你们的行动产生的重大影响,并真诚赞赏你们在我们通过这些安全措施的工作中继续表现出耐心。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

21. 2026年7月25日 UTC 17:24identified

    我们使一般客户能够进入加拿大地区。 区域内的所有服务现在都已上线,除了带回自有密钥(BYOK)配置. 此外,少数特定数量的客户工作空间将暂时停用。 对于这些剩余的工作空间,我们的工程小组正在执行一个高度控制、系统的恢复计划,以单独安全地恢复每个环境,确保完整的数据完整性。 我们真诚赞赏你在执行这些最后、准确的恢复步骤时不断表现出的耐心和伙伴关系。 我们的下一次更新将在一个小时内提供,或者在出现重大事态发展时提前提供.

22. 2026年7月25日 UTC 23:28identified

    我们对此造成的干扰表示诚挚的歉意并深切赞赏你的耐心。 加拿大地区的一般客户准入已经恢复,服务正在恢复。 将自己的密钥配置和少量工作空间暂时下线,同时完成细心,个性化的修复,确保数据完全完整. 我们将在一个小时内提供进一步的最新情况,如果有重大发展需要分享,则更早提供.

23. 2026年7月25日 UTC 23:52identified

    加拿大地区的一般客户准入已经恢复。 使用 Bring Your Onn Key( BYOK) 加密的工作空间将暂时关闭, 而我们将完成每个受影响的工作空间的个性化恢复。 我们将在协调世界时2026年7月26日9:00进一步提供BYOK恢复状态的最新情况. 我们为干扰道歉,并感谢你的耐心.

24. 2026年7月26日 UTC 08:59investigating

    我们正在写信,就协调世界时7月24日星期五20:35开始的影响到加拿大(CA1)区域接入的服务中断提供最新高级别信息。 通过我们工程小组和供应商伙伴的专注协调,于协调世界时7月25日星期六17:24成功重新启用了进入加拿大地区的通用通道。 我们的绝大多数客户现在可以正常地进入自己的工作空间和模型. 当前状况和下一步 虽然已经完全恢复了一般区域访问,但使用“带回自己的密钥”(BYOK)加密的工作空间仍然暂时关闭。 我们目前的主要重点是在受控制的环境中成功地再现技术干扰。 从这一复制阶段获得的见解至关重要,因为它们将直接影响和确定BYOK剩余工作空间最安全、最有效的恢复路径。 进行这一系统调查可以确保维持系统稳定和数据完整性的最高标准。 我们预计在协调世界时11点之前提供下一次关于BYOK工作空间恢复的有针对性的最新情况。 我们诚恳地为这次行动受到的干扰和影响而道歉。 我们的支助小组随时随时可以协助你处理任何问题或迫切需要.

25. 2026年7月26日 UTC 11:16investigating

    我们正在写信,就协调世界时7月24日星期五20:35开始的影响到加拿大(CA1)区域接入的服务中断提供最新高级别信息。 通过我们工程小组和供应商伙伴的专注协调,于协调世界时7月25日星期六17:24成功重新启用了进入加拿大地区的通用通道。 我们的绝大多数客户现在可以正常地进入自己的工作空间和模型. 当前状况和下一步 虽然已经完全恢复了一般区域访问,但使用“带回自己的密钥”(BYOK)加密的工作空间仍然暂时关闭。 我们目前的主要重点是在受控制的环境中成功地再现技术干扰。 从这一复制阶段获得的见解至关重要,因为它们将直接影响和确定BYOK剩余工作空间最安全、最有效的恢复路径。 进行这一系统调查可以确保维持系统稳定和数据完整性的最高标准。 我们期望在协调世界时下午1:00之前提供下一次关于恢复BYOK工作空间的有针对性的最新情况。 我们诚恳地为这次行动受到的干扰和影响而道歉。 我们的支助小组随时随时可以协助你处理任何问题或迫切需要.

26. 2026年7月26日 UTC 13:06investigating

    虽然自协调世界时7月25日星期六17:24起全面恢复了进入加拿大(CA1)地区的一般通道,但使用Bring your Own Key(BYOK)加密的工作空间仍然暂时下线。 我们的主要重点是在受控制的环境中复制这种干扰,目前我们与我们的供应商合作。 这是一个关键阶段,因为它将直接影响并确定BYOK剩余工作空间最安全、最有效的恢复路径,同时确保系统稳定性和数据完整性。 我们期望在协调世界时下午3:00之前提供下一次关于恢复BYOK工作空间的有针对性的最新情况。 我们诚恳地为这次行动受到的干扰和影响而道歉。 我们的支助小组随时随时可以协助你处理任何问题或迫切需要.

27. 2026年7月26日 UTC 15:20investigating

    大多数客户仍然完全恢复进入CA1地区。 使用“Bring your Onn Key(BYOK)加密”的工作空间仍然暂时关闭, 我们正与第三方加密伙伴积极合作,以了解原因和潜在的解决办法.

28. 2026年7月26日 UTC 17:53identified

    大多数客户继续全面恢复进入CA1地区。 使用 Bring your Onn Key( BYOK) 加密的办公空间仍然暂时关闭, 我们正与第三方加密伙伴积极合作,以了解原因和潜在的解决办法.

29. 2026年7月26日 UTC 18:49identified

    进入加拿大(CA1)地区的普遍通道仍然完全恢复. 然而,使用 Bring your Onn Key( BYOK) 加密的工作空间将暂时关闭。 将在协调世界时2026年7月27日10:00进一步提供BYOK恢复状态的最新情况. 我们为这种干扰道歉,并感谢你的持续耐心.

30. 2026年7月27日 UTC 10:03investigating

    我们写信提供最新资料,介绍目前为在加拿大(CA1)地区建立自有钥匙(BYOK)工作空间而开展的恢复工作。 为该区域提供的一般服务仍然全面恢复并正常运行。 目前调查情况 我们的工程和供应商小组正在继续深入调查最近服务中断的根本原因。 目前,我们正集中努力,在一个专注、非生产的环境中复制这一问题。 这种有控制的复制是一个关键步骤,因为技术调查结果将直接使我们能够确定和验证BYOK剩余工作空间最有效的恢复路径。 通过确保我们彻底了解系统在这些具体条件下首先在非生产条件下的行为,我们就可以保证你的数据在最后恢复阶段的绝对安全性,稳定性和完整性. 我们真诚赞赏你在执行这些仔细验证步骤时的耐心和伙伴关系。 我们的下一次更新将在两个小时内提供,或者在达到一个重要里程碑之前提前提供.

31. 2026年7月27日 UTC 12:30investigating

    我们正在继续积极调查和恢复规划,以便在加拿大(CA1)地区建立工作空间。 为该区域提供的一般服务仍然完全恢复,并继续正常运作。 我们的工程小组和供应商伙伴正继续集中努力,在不受控制的、非生产的环境中复制这种干扰。 在这些安全条件下复制情况仍然是我们的最高优先事项,因为这是关键步骤,将使我们能够确定和确认BYOK剩余工作空间最有效的恢复路径。 我们正在有条不紊地开展工作,以确保恢复进程一旦启动,将保持系统稳定性和数据完整性。 我们赞赏你在这种深入的技术鉴定工作继续进行的同时,继续耐心地合作。 我们的下一份最新情况将在两个小时内提供,或者如果我们有新的进展可以分享,就更早地提供.

32. 2026年7月27日 UTC 14:04investigating

    我们正在继续积极努力恢复加拿大(CA1)区域的工作空间。 整个区域的一般事务仍然完全恢复,并正常运行。 为了加快解决,我们的工程小组和供应商伙伴同时进行多行调查。 这种多面性的方法对于保证我们的修复计划得到充分验证,维护你们环境的完整性至关重要. 我们真诚赞赏你在我们同时开展这些工作时的耐心和伙伴关系。 我们的下一次更新将在两个小时之内提供,或者如果我们实现重大突破,就更早地提供.

33. 2026年7月27日 UTC 15:54identified

    我们正在继续积极努力恢复加拿大(CA1)区域的工作空间。 整个区域的一般事务仍然完全恢复,并正常运行。 我们的工程小组和供应商伙伴同时进行多行调查。 正在有意实施这一平行办法,以验证和最终确定其余BYOK工作空间最有效的恢复路径,确保我们安全、稳定地恢复服务。 我们赞赏你在我们的团队通过这些必要步骤开展工作时继续表现出耐心。 我们的下一次更新将在两个小时之内提供,或者如果我们实现重大突破,就更早地提供.

34. 2026年7月27日 UTC 17:37investigating

    虽然加拿大(CA1)地区的一般服务仍然完全恢复并正常运行,但我们继续专注于恢复 " 带回自己的钥匙 " 的工作空间。 我们的团队正在以多种平行的工作流程系统地向前推进。 同时执行这些努力使我们能够透彻地分析所有结果,确保我们验证和执行BYOK剩余工作空间最有效的恢复路径,确保我们安全地和在最稳定的情况下恢复服务。 我们赞赏你在执行这些关键的恢复步骤时不断提供合作和耐心。 我们将在协调世界时2026年7月28日9:00(10:00 BST)进一步提供BYOK恢复状态的最新情况.

35. 2026年7月28日 UTC 09:02identified

    加拿大(CA1)地区的总务仍然完全恢复并正常运行。 对于剩下的"Bring your Own Key"(BYOK)工作空间,我们的团队继续执行多个平行的工作流程. 正在有意采取这一并行办法,以验证BYOK剩余工作空间最有效的恢复路径,同时确保绝对系统稳定性。 我们赞赏你的耐心。 我们的下一次更新将在两个小时内提供,或者说,如果达到一个重要的里程碑,我们将更早地提供.

36. 2026年7月28日 UTC 11:01identified

    加拿大地区(CA1)的一般事务继续正常运作并保持完全稳定。 我们的工程团队和供应商团队正在继续通过多个并行的工作流程取得进展,以解决剩余的 " 带上自己的钥匙 " (BYOK)工作空间。 这一平行做法仍然是我们的积极重点,使我们能够系统地验证和执行安全程度最高的其余BYOK工作空间的最有效恢复路径。 我们赞赏你的耐心和支持。 我们的下一次更新将在两个小时内提供,或者说,如果达到一个重要的里程碑,我们将更早地提供.

37. 2026年7月28日 UTC 13:11identified

    加拿大境内(CA1)地区的总务仍然全面恢复,稳定,并继续正常运作. 我们的工程团队和供应商伙伴正在继续推进多个并行的工作流程,以解决剩余的 " 带上自己的钥匙 " 工作空间问题。 这一平行战略仍然是我们的积极重点,使我们能够系统地验证和执行BYOK剩余工作空间最有效的恢复路径。 我们真诚赞赏你在我们通过这些深思熟虑的步骤工作时的耐心。 我们的下一次更新将在两个小时内提供,或者说,如果达到一个重要的里程碑,我们将更早地提供.

38. 2026年7月28日 UTC 16:02identified

    加拿大境内(CA1)地区的总务仍然全面恢复,稳定,并继续正常运作. 我们的工程小组和供应商伙伴正通过多个平行的工作流程,积极保持对剩余 " 带来自己的钥匙 " 工作空间的关注。 我们赞赏你在完成这些关键验证阶段时的持续耐心和伙伴关系。 我们的下一次更新将在两个小时内提供,或者说,如果达到一个重要的里程碑,我们将更早地提供.

39. 2026年7月28日 UTC 19:51identified

    虽然加拿大(CA1)地区的一般服务仍然完全恢复并正常运行,但我们继续专注于恢复 " 带回自己的钥匙 " 的工作空间。 我们的团队正在以多种平行的工作流程系统地向前推进。 同时执行这些努力使我们能够透彻地分析所有结果,确保我们验证和执行BYOK剩余工作空间最有效的恢复路径,确保我们安全地和在最稳定的情况下恢复服务。 我们赞赏你在执行这些关键的恢复步骤时不断提供合作和耐心。 我们将在协调世界时2026年7月29日9:00(10:00 BST)进一步提供BYOK恢复状态的最新情况.

40. 2026年7月29日 UTC 09:04identified

    虽然加拿大(CA1)地区的一般服务仍然完全恢复并正常运行,但我们继续专注于恢复 " 带回自己的钥匙 " 的工作空间。 我们的团队正在继续通过多个平行的工作流程系统地取得进展。 同时执行这些努力使我们能够透彻地分析所有技术成果,确保验证和执行BYOK剩余工作空间最安全和最稳定的恢复路径。 我们赞赏你在执行这些关键的恢复步骤时不断提供合作和耐心。 我们的下一次更新将在两个小时内提供,或者说,如果达到一个重要的里程碑,我们将更早地提供.

41. 2026年7月29日 UTC 13:23investigating

    虽然加拿大(CA1)地区的一般服务仍然完全恢复并正常运行,但我们继续专注于恢复 " 带回自己的钥匙 " 的工作空间。 我们的团队仍在通过多个平行的工作流程继续系统地取得进展。 同时执行这些努力使我们能够透彻地分析所有技术成果,确保验证和执行BYOK剩余工作空间最安全和最稳定的恢复路径。 我们赞赏你在执行这些关键的恢复步骤时不断提供合作和耐心。 我们的下一次更新将在两个小时内提供,或者说,如果达到一个重要的里程碑,我们将更早地提供.

42. 2026年7月29日 UTC 15:21investigating

    加拿大(CA1)地区的总务仍然全面恢复,并继续正常运行。 我们的工程和运营团队继续专注于回收剩下的 " 带回自己的钥匙(BYOK) " 工作空间。 为确保尽可能安全地恢复,我们正在积极推进多个平行恢复工作流程。 同时开展这些努力,使我们能够在实时中严格分析技术成果,确保我们验证和执行BYOK剩余工作空间最稳定和最有保障的前进道路。 我们真诚感谢你在我们系统地执行这些关键的恢复步骤时不断表现出的耐心和伙伴关系。 我们的下一次更新将在两个小时内提供,或者说,如果达到一个重要的里程碑,我们将更早地提供.

43. 2026年7月29日 UTC 17:17investigating

    虽然加拿大(CA1)地区的一般服务仍然完全恢复并正常运行,但我们继续专注于恢复 " 带回自己的钥匙 " 的工作空间。 我们的团队正在以多种平行的工作流程系统地向前推进。 同时执行这些努力使我们能够透彻地分析所有结果,确保我们验证和执行BYOK剩余工作空间最有效的恢复路径,确保我们安全地和在最稳定的情况下恢复服务。 我们赞赏你在执行这些关键的恢复步骤时不断提供合作和耐心。 我们将在协调世界时2026年7月30日9:00(10:00 BST)进一步提供BYOK恢复状态的最新情况.

44. 2026年7月30日 UTC 08:59investigating

    尽管整个加拿大(CA1)地区的总务部门继续以完全稳定的方式正常运转,但我们的技术小组仍然专注于恢复剩余的 " 带回自己的钥匙 " 工作空间。 我们正在继续推进多个平行的工作流程,以验证和执行最安全的恢复路径。 同时开展这些努力,使我们能够透彻地分析所有技术成果,确保恢复所有杰出的BYOK工作空间的安全和稳定服务。 我们赞赏你在我们系统地通过这些关键的恢复步骤时继续表现出耐心和伙伴关系。 我们将在两小时后进一步介绍BYOK修复工作的最新进展.

45. 2026年7月30日 UTC 11:07investigating

    尽管整个加拿大(CA1)地区的总务部门继续以完全稳定的方式正常运转,但我们的技术小组仍然专注于恢复剩余的 " 带回自己的钥匙 " 工作空间。 我们正在继续推进多个平行的工作流程,以验证和执行最安全的恢复路径。 同时开展这些努力,使我们能够透彻地分析所有技术成果,确保恢复所有杰出的BYOK工作空间的安全和稳定服务。 我们赞赏你在我们系统地通过这些关键的恢复步骤时继续表现出耐心和伙伴关系。 我们将在协调世界时2026年7月31日9:00(10:00 BST),或者在达到一个重要里程碑的更早时间,进一步提供BYOK恢复状态的最新情况.

46. 2026年7月31日 UTC 09:04investigating

    尽管整个加拿大(CA1)地区的总务部门继续以完全稳定的方式正常运转,但我们的技术小组仍然专注于恢复剩余的 " 带回自己的钥匙 " 工作空间。 我们正在继续推进多个平行的工作流程,以验证和执行最安全的恢复路径。 同时开展这些努力,使我们能够透彻地分析所有技术成果,确保恢复所有杰出的BYOK工作空间的安全和稳定服务。 我们赞赏你在我们系统地通过这些关键的恢复步骤时继续表现出耐心和伙伴关系。 我们将在协调世界时2026年8月3日9:00(10:00 BST)进一步提供BYOK恢复状态的最新情况,或者在达到重要里程碑时更早.

47. 2026年7月31日 UTC 13:47resolved

    我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

48. 2026年8月11日 UTC 16:03postmortem

    **Summary**  On July 24, 2026, at 20:22 UTC, our engineering team began investigating an issue affecting customers in our ca1: Cloud — Canada region. Customers with affected workspaces were unable to open their models. As a precaution, while we validated the scope of the issue, we restricted access to the region behind a maintenance page at 02:18 UTC on July 25. General access to CA1 was restored at 17:24 UTC on July 25. Bring Your Own Key \(BYOK\) workspaces remained offline for additional safeguards, and were re-enabled progressively as those safeguards were validated. The incident was fully resolved on July 31, 2026, at 13:47 UTC.  **Root cause**  The disruption was caused by a defect in a third-party component used within our BYOK service. The defect only surfaced under a very specific combination of events occurring in a particular order on the same host. When a BYOK workspace was unloaded, the component failed tofully clear one of its local resources, leaving behind a stale reference. When a BYOK workspace was subsequently loaded onto the same host, the component attempted to clean up that stale reference before proceeding. During this step, it incorrectly executed a removal that extended beyond the stale reference and deleted files that were still in active use.   The affected files were captured in our regular backups. Once our engineering team identified the source of the activity, isolated it, and applied protective controls to stop any further impact, restoration became a controlled process of returning each affected file to its most recent backup.  **Recovery**  Our engineering team identified the issue and isolated it at its source, then worked systematically to restore the affected files. This allowed us to bring non-BYOK workspaces back online in a controlled sequence, and general access to CA1 was restored at 17:24 UTC on July 25.  We deliberately kept BYOK workspaces offline while our team worked with the third-party vendor to reproduce the trigger in a controlled, non-production environment. This reproduction gave us the diagnostic evidence the vendor needed to build a fix and to confirm the exact cause. It also allowed us to develop and validate our own temporary safeguards — targeted changes to how BYOK workspaces are scheduled — that eliminated the specific combination of conditions required to trigger the defect. These safeguards act as compensating controls to bring BYOK workspaces back online while the third party completes the permanent fix to the underlying component. We re-enabled BYOK workspaces once those safeguards were validated, ensuring the trigger conditions couldn't recur. The incident was fully resolved on July 31, 2026, at 13:47 UTC.  **Corrective and preventative actions**  Our corrective actions follow two complementary tracks. The first removes the specific combination of conditions required to trigger the defect, using controls we have developed and deployed ourselves as compensating safeguards. The second is the permanent fix to the underlying component itself, which the third party is delivering. Together, these tracks address both the trigger and the defect, so that neither can produce another incident of this kind. We are implementing the following actions to prevent recurrence:  * We have deployed changes that prevent the specific combination of conditions required to trigger the defect. This is a temporary but effective control that removes the trigger today, ahead of the permanent fix.  * We are working with the third party to deploy their validated fix. This removes the defect at its source and closes the underlying cause of this incident.  * We are strengthening how we validate BYOK third-party components in non-production before they reach production, including reproducing a wider range of workspace lifecycle scenarios and event sequences. This gives us stronger assurance to surface these types of issues in non-production and are addressed before they can affect customers.  * We have deployed dedicated alerting on the specific event pattern that triggered this incident and are actively reviewing additional file-level alerting. These alerts provide an additional safety net and earlier warning, enabling faster preventative action before customers are affected.  **Closing**  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.   If you have further questions or concerns, please visit our [Support](https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F) website. We appreciate your patience during this incident and value the trust you place in Anaplan.

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

1. 2026年7月21日 UTC 14:30investigating

   目前我们正在调查影响客户经营Cloudworks集成能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年7月21日 UTC 14:44monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

3. 2026年7月21日 UTC 14:54resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

4. 2026年7月30日 UTC 22:22postmortem

   2026年7月21日,从协调世界时14:15到协调世界时14:50,我们5:Cloud - US East区域经历了预定CloudWorksTM集成的中断. 在这个窗口中,无法启动自动工作流程,用户可能难以获得集成服务. ** 循环原因** 这个问题由系统回放后基础存储系统短暂中断而引发. 这导致集成调度系统内部失去连接,使得被安排的任务无法成功排队或被触发. ** 恢复** 我们的工程小组查明了问题,并立即采取行动。 随着基础服务自动恢复,我们核查了系统连接,我们进行了测试整合,以验证预定的工作流程。 这些验证检查证实,所有调度机制都安全地恢复了正常运行,而不需要系统重新启动。 至协调世界时14:50,该问题已完全解决. ** 更正和预防行动** * 我们正在对回滚行动中的系统性能进行深入调查,以确保在高负荷条件下的稳定。 * 我们正在对综合调度器实施强化的健康检查,以确保在回滚期间交通经过之前达到“准备状态”。 * 我们正在更新部署程序,包括在任何区域更新或回滚后立即自动验证任务队列深度。 * 我们正在用建议的请求/限制值更新我们为这项服务编制的资料数量,以确保有足够的部署和回滚能力。 我们为这个问题可能对你的企业业务造成任何影响而道歉。 我们正在加强我们的系统和程序,以避免干扰你的业务和用户。 如果您还有其他问题或问题, 请访问我们的[支持] (https://www.google.com/url?q=https%3A%2F%2Fsupport.anaplan.com%2F)网站 。 我们赞赏你在这起事件中的耐心,并珍视你对阿纳普兰的信任.

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

1. 2026年7月14日 UTC 20:04investigating

   目前我们正在调查影响客户经营Cloudworks集成能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年7月14日 UTC 21:00monitoring

   我们发现出事了 我们正在调查这个问题,不久将提供最新情况.

3. 2026年7月14日 UTC 21:04monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

4. 2026年7月14日 UTC 21:12resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

5. 2026年7月22日 UTC 18:15postmortem

   2026年7月14日 UTC凌晨19点55分,我们7:Cloud - US West地区客户在CloudWorksTM整合工作处理中遭遇了延误和失败. 计划在该区域开展的整合工作没有如预期的那样完成,导致积压的处理工作一旦全面恢复,就得到清理。 根源 一个支持CloudWorksTM服务的后端组件暂时耗尽了现有的内存,导致短暂的连接中断. 虽然数据库立即恢复,CloudWorksTM处理组件仍保留了不活跃的连接,无法自动重接. 这使得整合工作无法完成,并导致排队安排的任务被累积. 恢复 我们的工程小组查明了问题,并立即采取行动。 团队重启了CloudWorksTM处理组件,以清除所有已停用和闲置的连接. 为了迅速清理待处理的整合工作,我们暂时提高了各组成部分的处理能力。 在核实整合工作正常完成,积压工作得到全面处理后,我们恢复了该系统的原有能力。 至协调世界时21:14,该问题已完全解决. 纠正和预防行动 我们正在采取以下行动来防止再次发生: * 记忆分配增加额:** 我们正在增加后端部分的内存分配。 这降低了未来发生类似内存压力事件的可能性. * ** 背景过程优化:** 我们已经取消了某些背景度量收集程序,这些过程给后端组件带来了不必要的负荷. 这进一步降低了长期内存压力建设的风险. ***反应测试:** 我们的工程团队正在非生产环境中进行有控制的测试,以更好地理解CloudWorksTM服务在短暂的连接中断时的表现. 这项工作将帮助我们提高今后发生类似事件时服务自动恢复的能力,而不需要人工干预。 我们为这个问题对你们行动的影响道歉。 我们致力于上述改进,以防止类似的干扰。 如果您有问题或关切,请联系[支助](https://support.anaplan.com/).

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

1. 2026年7月2日 UTC 00:00investigating

   我们目前正在调查影响客户进入Anaplan平台能力的问题。 我们正在努力尽快地解决这一问题,并将每30分钟或在决议通过后提供最新情况.

2. 2026年7月2日 UTC 00:30investigating

   谢谢你耐心地继续调查这个问题。 目前,我们正面临严重的服务中断,造成受影响地区完全无法提供服务。 试图在这些区域获得服务的用户将遇到连接中断和无法加载资源的问题。 目前,我们还没有时间解决。 在我们努力尽快解决这一问题时,我们将继续每30分钟提供最新情况.

3. 2026年7月2日 UTC 00:59investigating

   我们正在调查一个影响我们ME1和EU5区域客户登录和平台接入的问题. 初步调查表明,这些区域的认证道路中断。 解决这个问题是我们的最高优先事项,我们的工程团队正在积极致力于恢复正常业务。 我们还没有埃塔。 我们将在30分钟内再提供一次更新,或者如果有重大的新信息就更早.

4. 2026年7月2日 UTC 01:29investigating

   我们正在调查影响ME1和欧盟5区域的登录和平台接入问题。 在我们努力查明并解决根源时,我们已经与我们的供应商进行了接触,寻求更多的支持。 解决这个问题仍然是我们的最高优先事项。 还没有ETA。 我们将在30分钟内提供下一次更新, 或如果我们有重大的新信息,更早.

5. 2026年7月2日 UTC 01:58investigating

   我们正在调查影响ME1和欧盟5区域的登录和平台接入问题。 我们的工程小组缩小了调查范围,并正在与我们的基础设施伙伴合作,积极开展若干调查。 恢复服务仍然是我们的最高优先事项。 还没有ETA。 我们将在30分钟内提供下一次更新, 或如果我们有重大的新信息,更早.

6. 2026年7月2日 UTC 02:27investigating

   我们正在调查影响我们ME1和欧盟5区域客户登录和平台接入的问题。 2026年7月1日协调世界时23:52左右开始发行. 我们与我们的基础设施伙伴协调,成功地缩小了潜在原因,目前正在把工程努力的重点放在孤立问题上,以启动有针对性的缓解行动。 我们的团队仍然全力以赴地尽快解决这一问题。 我们将在30分钟内提供下一次最新情况,或者在掌握重要新情况后尽早提供.

7. 2026年7月2日 UTC 02:55investigating

   我们正在继续调查影响我们ME1和欧盟5区域的客户登录和平台接入的问题。 我们已查明潜在原因,并正在积极推进减缓措施,以解决这一问题并恢复全面服务。 我们将继续提供补救进展的最新情况。 我们将在30分钟内提供下一次最新情况,或者在掌握重要新情况后尽早提供.

8. 2026年7月2日 UTC 03:21monitoring

   服务现已恢复;您现在应能恢复正常活动。 我们将继续监测该平台,以确保不出现其他问题。 如果你有任何问题、担心或继续遇到问题,请毫不犹豫地与Anaplan支助公司联系。 我们将在你认为局势完全得到解决时向你提供最后的最新情况.

9. 2026年7月2日 UTC 04:00resolved

   我们已经确认,这个问题现在已经得到解决。 我们对该问题可能产生的任何影响深表歉意。 我们赞赏你在处理这个问题时的耐心和伙伴关系。 我们将在7个工作日内进行详细的根源分析,并将在现状网页上公布。 如果您有任何问题或担心,请毫不犹豫地与我们在Anaplan支助公司联系.

10. 2026年7月10日 UTC 18:35postmortem

    2026年7月1日 UTC凌晨23点52分左右,我们的监测系统检测到有一次服务中断波及到 me1: Cloud – Middle East and Eu5: Cloud – Europe regions. 在此期间,受影响的客户无法登录到平台. 在协调世界时03:21恢复服务 ** 循环原因** 中断的原因是计划将网络配置改为内部名称解析基础设施。 作为造成根本路线冲突的变化的一部分,提出了错误的配置。 这导致内部名称查询的回路流量在例行的网络活动中走出不正确的路径. 因此,两个受影响地区的内部名称解决开始失败。 这阻碍了认证流程的完成,并阻止了客户登录。 ** 恢复** 在协调世界时23:52侦测时,我们的工程团队和基础设施合作伙伴开始平行调查. 由于内部解决名称问题可以以几种不同方式展现自己,因此该小组在孤立负责的具体路线冲突之前,通过多条调查线开展工作。 一旦确定后,我们撤回了最近的变化,以恢复先前已知的好路由配置。 随着回滚的推广,连通性逐渐恢复,到协调世界时03:21,两个受影响地区的认证工作已完全恢复。 ** 更正和预防行动** 我们正在采取以下行动来防止再次发生这种情况: * 我们正在增加更改前的验证,专门检测造成这一事件的路线冲突类别。 这在任何类似变化到达环境之前就结束了基本的配置问题。 *我们正在重新对受影响的路线设置进行存档,以防止再次引入这一类错位。 这消除了根源问题。 * 我们正在改进对云层环境之间内部名称解析路径的监测。 这缩短了发现和解决这一类问题的时间。 ** 结束** 我们为这次干扰对你们行动的影响道歉。 上述纠正行动的重点是防止今后再次发生任何类似问题。 如果您有问题或关切,请联系[支助](https://support.anaplan.com/).

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

1. 2026年6月22日 UTC 07:29investigating

   We are currently investigating an issue resulting in some customers not being able to load models. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026年6月22日 UTC 07:48investigating

   Thank you for your patience as we continue to investigate this issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026年6月22日 UTC 08:23investigating

   We are actively investigating a service disruption currently affecting customers' ability to open Models. This issue is also affecting CloudWorks Integrations. Our engineering teams are prioritizing this issue and evaluating immediate mitigation steps to restore full service as quickly and safely as possible. We do not yet have an estimated time to resolution, but will provide progress updates every 30 minutes or sooner.

4. 2026年6月22日 UTC 08:52identified

   We are progressing with active mitigation steps to resolve the disruption affecting Model opening and CloudWorks integrations. Initial reports indicate positive outcomes from these activities. Our engineering teams are closely monitoring system stability while we complete the remaining mitigation steps to ensure a full and durable recovery. We will continue to provide updates every 30 minutes as we work to bring all systems back to standard operations.

5. 2026年6月22日 UTC 09:25identified

   We are currently proceeding with the final remediation steps while continuing our investigation into the root cause. Customers should now be able to open models, though some may still encounter temporary delays; however, CloudWorks integrations are not yet completing. We are monitoring these recovery steps closely to ensure full system stability and will continue to provide updates every 30 minutes.

6. 2026年6月22日 UTC 09:36identified

   We are pleased to report that all issues affecting model loading have been fully resolved, and normal access has been restored. Additionally, CloudWorks integrations are running again, and our teams are currently processing the accumulated backlog of queued jobs. We are monitoring the queue progression closely to ensure all delayed integrations complete successfully. We will provide our next update in 30 minutes or once the backlog is fully cleared.

7. 2026年6月22日 UTC 10:05identified

   Our teams confirm that the CloudWorks integration backlog is actively processing and recovering. Access to opening models remains fully restored and stable. We are continuing to monitor the integration queues closely as jobs complete, and we will provide our next status update in 30 minutes.

8. 2026年6月22日 UTC 10:22monitoring

   Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

9. 2026年6月22日 UTC 10:52resolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

10. 2026年7月1日 UTC 19:34postmortem

    On June 22, 2026, at 07:20 UTC, we became aware of an issue affecting our us7: Cloud – US region. Customers experienced difficulties loading models, with impact beginning at approximately 05:12 UTC. CloudWorks™ integrations in the region were also unable to run during this period. Customers with active workspace sessions weren't affected. However, any workspace that was unloaded during this time couldn't be loaded until service was restored. Full service was restored at 10:21 UTC.  **Root cause**  A component that manages active workspace resources in the us7 region encountered an unexpected fault and restarted. On restart, the component entered a state where it appeared to be operating normally but couldn't process new workspace requests. Our systems normally recover automatically from this kind of state, but in this case the fault wasn't detected by our recovery processes. We intervened manually and performed a corrective restart of the component, which restored normal operation.  **Recovery**  We conducted a thorough investigation of the platform and identified the source of the issue. We performed a targeted reset of the resource scheduling services to clear the pending connections and restore normal communication. Once communication was re-established at 08:48 UTC, the platform began successfully assigning resources and loading models.  To handle the accumulated backlog of scheduled integrations, we scaled up the processing capacity for CloudWorks™. By 10:21 UTC, the backlog had finished processing, and the issue was fully resolved.  **Corrective and preventative actions**  We're implementing the following actions to prevent recurrence:  * We're deploying enhanced automated monitoring specifically designed to detect the condition seen in this incident, where a component appears operational but isn't processing requests. This closes the detection gap that extended the impact of this issue.  * We're developing automated self-healing for the resource scheduling component, so that a corrective restart can be performed automatically without engineering intervention. This directly addresses the failure mode that caused this incident.  * We're streamlining our scaling procedures for CloudWorks™, so that integration processing capacity can be expanded more rapidly during recovery. This shortens the time to clear integration backlogs following incidents like this one.  We apologize for any impact this issue may have had on your business operations. We are continuously strengthening our systems and procedures to ensure we avoid future disruptions to your business and users.  If you have further questions or concerns, please visit our [Support](https://support.anaplan.com/) website. We appreciate your patience during this incident and value the trust you place in Anaplan.

1. 2026年6月17日 UTC 07:02investigating

   We are currently investigating an issue resulting in some customers not being able to load models. We are working to resolve this issue as quickly as possible and will provide updates every 30 minutes or upon resolution.

2. 2026年6月17日 UTC 08:00investigating

   Thank you for your patience as we continue to investigate this issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

3. 2026年6月17日 UTC 08:31investigating

   Thank you for your patience as we continue to investigate this issue. Our technical teams are fully engaged, and restoring normal service operations as quickly and safely as possible is our absolute priority. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

4. 2026年6月17日 UTC 08:59investigating

   Thank you for your patience as we continue to investigate this issue. Our coordinated technical response has made progress in narrowing down the scope of our investigation. We have isolated the primary area of concern to our storage configuration layer and are evaluating mitigation steps to alleviate the issue. Currently, we do not yet have a time to resolution. We will continue to provide updates every 30 minutes as we work to resolve this issue as quickly as possible.

5. 2026年6月17日 UTC 09:22identified

   We have identified the likely cause of the issue, and we are focused right now on restoring service as quickly as possible. We have identified mitigation steps to alleviate the issue and initial reports indicate positive outcomes of these activities. Currently, we do not yet have a time to resolution. We will provide further updates in 30 minutes or upon resolution.

6. 2026年6月17日 UTC 09:50identified

   We are pleased to report a significant milestone in our resolution efforts. Our cross-functional engineering teams have successfully validated a targeted configuration adjustment to restore access to the affected workspaces. We have initiated a phased deployment of this mitigation across the region to safely and systematically restore full access to all affected workspaces. Currently, we do not yet have a time to resolution. We will provide further updates in 30 minutes or upon resolution.

7. 2026年6月17日 UTC 10:06monitoring

   Service has now been restored; you should now be able to resume normal activities. We will continue to monitor the platform to ensure no additional issues arise. If you have any questions, concerns, or continue to experience issues, please do not hesitate to contact Anaplan Support. We will provide a final update to you when we consider this situation fully resolved.

8. 2026年6月17日 UTC 10:23resolved

   We have confirmed that the issue is now resolved. We deeply apologize for any impact this issue may have caused. We appreciate your patience and partnership as we worked through this issue. We will follow up within 7 business days with a detailed root cause analysis (RCA) that will be shared on our Status Page. If you have any question or concerns, please do not hesitate to contact us at Anaplan Support.

9. 2026年6月26日 UTC 17:41postmortem

   On June 17, 2026, at 06:50 UTC, we became aware of an issue affecting a subset of workspaces in our eu4: Cloud - Europe region. Customers with affected workspaces were unable to load models, seeing persistent loading screens or errors when opening their work. CloudWorks™ integrations in the region also experienced a period of degradation, from approximately 05:20 UTC to 06:26 UTC, because of the same underlying issue. The impact was limited to a specific subset of workspaces — all other regions, and many workspaces in eu4: Cloud - Europe, continued to operate normally. Full service for the affected workspaces was restored at 10:00 UTC.   Root cause  The affected workspaces ran on a previous storage configuration in the eu4 region. Over time, a storage directory used by these workspaces accumulated a large number of small temporary files. The directory reached its operational limit and could no longer accept new file operations. This prevented models from loading for customers whose workspaces were running on this configuration.  Recovery  Our engineering team cleared the accumulated temporary files, which provided immediate relief. We then moved all affected workspaces from the old configuration to the new configuration through an automated process. We checked that model loading was restored through testing. By 10:00 UTC, the issue was fully resolved. On the same day, we implemented a change across the eu4 region to make sure no workspace can be directed to the old configuration.  Corrective and preventative actions  We've taken the following actions to address this incident and prevent it from happening again:  1. We've deployed an update across all regions that prevents any workspace from being directed to the older storage configuration. This eliminates the specific configuration condition that caused this incident.  2. We're decommissioning the older storage configuration. This permanently removes the configuration that caused this incident.  3. We’re strengthening our automated validation checks to confirm that workspaces are running on the correct configuration. This catches any configuration mismatch before it can cause customer impact.  4. We're implementing automated cleanup rules for the temporary files involved in this incident. This prevents storage directories from reaching operational limits and supports faster automatic recovery.  Closing  We apologize for the impact this issue has had on your operations. We're committed to the improvements outlined above to prevent similar disruptions. If you have questions or concerns, please contact [Support](https://support.anaplan.com/).