Stripo 中断历史

1. 2026年10月8日 UTC 23:32investigating

   开始时间:2026-10-08 UTC22:20 影响:客户无法使用插件——编辑器不加载/不响应. 我们收到了几个客户的报告。 发生的事:协调世界时22:13 Zabbix在插件 DB 主机(pg-plugins.stripo.email,172.31.13.64)上报告代理无法使用;在协调世界时22:40,活插的PostgreSQL显示器也失败了. 该插件在协调世界时~22:20停止为客户工作. DevOps正在调查 下一次更新在这里,一旦我们得到更多信息.

2. 2026年10月8日 UTC 23:33resolved

   插件再次全面运行 。 DevOps恢复了插件 DB 主机;我们正在监测,自协调世界时23:18起没有再看到出错. 正在准备一份有根本原因、时间表和行动项目的尸检,不久将公布.

3. 2026年10月9日 UTC 09:14postmortem

   页:1 2026年10月8日,协调世界时22:20至23:18之间,斯德罗插件无法使用:编辑器没有加载或响应. 断电持续了58分钟. 没有丢失客户数据,其他 " 外形 " 产品也没有受到影响。 发生了什么事? 插件后面的数据库服务器丢失了时间同步 。 两个时间同步服务同时运行在服务器上:标准守护进程,它逐渐地调整了时钟,以及一个遗留的排期任务,它突然步入了时钟. 错误的时间安排使得遗留的工作几乎每分每分每秒运行. 重复的时钟跳出使服务器不稳定,直到插件的数据库无法使用. ** TIMELINE\(UTC,2026年10月8日)** 21: 44 - 插件数据库服务器开始时钟不稳定. 22: 13 - 我们的监测提高了服务器的第一个警报. 22: 20 - 插件停止为客户装入. 22:40 - 监测报告插件数据库不存在. 23:00 - 收到第一次客户报告;值班工程师被叫来. 23:18 - 服务恢复. 插件已全面运作 。 ** 补偿** 我们的工程师确定了时间同步冲突并恢复了服务器. 该插件在协调世界时23:18恢复了正常运行,并一直受到延长监测。 我们在做什么 来证明这一点 * 移除遗留的时间同步任务, 这样此服务器和其他所有生产服务器都会使用单个的时间源 。 * 增加时钟漂移监测,以便在这种故障影响服务之前被抓住。 * 改变警戒升级。 我们的监控在停电前7分钟发出警报 但警报没有呼叫工程师 生产数据库服务器上的关键警报现在将立即与值班工程师通话。 我们为干扰道歉,并感谢你的耐心。 如果你有问题,请联系支援小组.

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

1. 2026年10月4日 UTC 17:03investigating

   在编辑器内上传客户图像时可能会有问题。 时间(UTC):2026-10-04T17:03:09

2. 2026年10月4日 UTC 17:04resolved

   这一事件已经得到解决.

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

1. 2026年10月4日 UTC 16:46investigating

   在编辑器内上传、更改或删除客户图像时可能会有问题。 时间(UTC):2026-10-04T16:46:22

2. 2026年10月4日 UTC 16:47resolved

   这一事件已经得到解决.

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

1. 2026年10月4日 UTC 16:43investigating

   在编辑器内部的模块库中查看、修改或创建新模块时可能存在问题。 时间(UTC):2026-10-04T16:43:49

2. 2026年10月4日 UTC 16:44resolved

   这一事件已经得到解决.

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

1. 2026年9月18日 UTC 14:19investigating

   目前,我们正面临一个影响一些外形插件功能的问题。 一些用户可能无法上传图像或文档或更新存储证书. 我们的小组正在调查这一问题并努力尽快恢复正常运作。 开始时间: UTC9月18日,13:41

2. 2026年9月18日 UTC 14:54identified

   这一问题已经确定,一个解决办法正在实施之中.

3. 2026年9月18日 UTC 14:56resolved

   这一事件已经得到解决.

4. 2026年9月18日 UTC 15:52postmortem

   ** 循环原因** 事件由主图像存储服务使用的访问密钥计划旋转过程中出问题而来. 新钥匙没有正确传播给负责处理储存业务的一个部门。 因此,该服务的请求无法通过存储进行认证,导致图像和文档上传操作失败. 我们还查明了与关键轮换程序有关的内部文件空白,这促成了这一事件。 ** 决议** 储存证书得到更正并成功分发给所有受影响的服务机构。 配置更新后,上传功能恢复正常. 我们还更新了相关的内部文件,以纳入先前缺失的配置步骤。 ** 预防行动** 我们正在审查证书轮换程序,以确保涵盖所有依赖性服务,并确保在轮换前后验证配置变化。 我们还正在改进内部文件和核查程序,以减少今后发生类似事件的风险。 我们为我们的团队努力解决问题时的中断表示歉意并感谢你的耐心.

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

1. 2026年9月16日 UTC 13:39investigating

   我们目前在斯德罗网络编辑器上的表现正在退化。 一些用户在打开电子邮件、无法使用的编辑器设置和编辑功能或“没有互联网连接”错误时可能会经历长时间的加载。 对于已经打开了电子邮件的用户,只要网页没有被重新装入,就应继续通过自动保存保存更改. 我们的小组正在积极调查这一问题并努力恢复正常运作。 开始时间: UTC9月16日13:25

2. 2026年9月16日 UTC 15:12resolved

   这一事件已经得到解决.

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

1. 2026年9月9日 UTC 15:18investigating

   在编辑器内部的模块库中查看、修改或创建新模块时可能存在问题。 时间(UTC):2026-09-09T15:18:49

2. 2026年9月9日 UTC 15:19resolved

   这一事件已经得到解决.

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

1. 2026年9月9日 UTC 15:13investigating

   在编辑器内部的模块库中查看、修改或创建新模块时可能存在问题。 时间(UTC):2026-09-09T15:13:49

2. 2026年9月9日 UTC 15:15resolved

   这一事件已经得到解决.

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

1. 2026年9月9日 UTC 15:11investigating

   在编辑器内部的模块库中查看、修改或创建新模块时可能存在问题。 时间(UTC):2026-09-09T15:10:49

2. 2026年9月9日 UTC 15:11resolved

   这一事件已经得到解决.

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

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

   进入客户账户可能有问题。 时间(UTC):2026-09-06T07:17:04

2. 2026年9月6日 UTC 07:19resolved

   这一事件已经得到解决.

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

1. 2026年8月5日 UTC 13:59investigating

   We are aware of an issue with the Stripo Plugin: the editor may fail to initialize and does not load for end users. Our team has identified the affected service and is working on a fix. We will post an update as soon as we have more information.

2. 2026年8月5日 UTC 14:00identified

   The issue has been identified and a fix is being implemented.

3. 2026年8月5日 UTC 14:49monitoring

   A fix has been implemented and we are monitoring the results.

4. 2026年8月5日 UTC 14:57resolved

   This incident has been resolved.

5. 2026年8月5日 UTC 16:03postmortem

   At 13:45 UTC the AWS host running the database and cache for our plugin environment failed. Auto-recovery restarted it by 14:00 UTC, but the cache service and several microservices required manual restarts. Full recovery: ~15:00 UTC. **Impact \(UTC\).** Autosave was unavailable 13:48–13:57, then severely slow \(~86 s per request vs. under 7 s normally\) until ~14:40. Some plugins using external AutoSave callbacks saw saves fail. Co-editing was degraded 14:16–15:00. Editor initialization also failed for some users early on. **Data.** No evidence of loss: crash recovery completed correctly, all patches that reached the database were persisted, and duplicate resubmissions were safely rejected. Contact us with a timestamp if you suspect otherwise. **Cause.** Hardware failure on the underlying AWS host. It escalated because autosave retries external callbacks synchronously inside the request, exhausting the database connection pool; the cache had no auto-start on reboot; and connection pools did not self-heal. No alarm covered host status or cache availability, so detection came from user reports. **Fixes.** Alerting on host status checks and cache availability; cache auto-start with a health check; connection pool recovery; moving external callbacks out of the request path; alerts on pool saturation, error rate and callback latency; a redundancy review for this environment. We apologize for the disruption. If the impact on your users differed from the above, please contact our support team.

1. 2026年7月31日 UTC 08:30investigating

   我们正在调查关于用户无法登录、看到团队成员失踪、或邮件加载缓慢的报告。 我们的团队正在努力找出原因.

2. 2026年7月31日 UTC 08:30identified

   我们找出了根源:一个内部缓存服务(Redis)耗尽了记忆,开始拒绝写作. 因此,权限检查绕过缓存,将过量的负载放入账户服务,导致回复缓慢,登录失败,账户数据缺失. 我们增加了缓存能力,并正在准备一项永久的固定方案.

3. 2026年7月31日 UTC 08:31monitoring

   缓存能力已经提高,该系统正在恢复。 反应时间随着缓存热化而恢复正常. 正在部署永久固定装置.

4. 2026年7月31日 UTC 08:49resolved

   永久固定装置已部署在所有生产集群,所有系统正常运行。 在事件期间(协调世界时7月30日,22:48 UTC – 7月31日~04:30 UTC,剩余慢到~08:49 UTC),一些用户经历了登录失败,团队成员数据缺失,邮件加载缓慢. 没有丢失数据 。 我们添加了内存使用提示,以检测这一类问题,以免影响用户。 我们为不方便而道歉.

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

1. 2026年7月28日 UTC 14:02resolved

   7月28日,大约在1:28 PM到1:58 PM(UTC)之间,斯德罗插件未能初始化为嵌入式集成. 造成这一问题的原因是内部统计服务绩效下降,使插件初始化请求放缓. 我们的团队重新启动了受影响的服务,并暂时禁用用于插件初始化的统计收集,以恢复正常运行. 该插件现在正在按预期装入 。 我们对此可能造成的不便表示歉意.

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

1. 2026年7月25日 UTC 09:18investigating

   在编辑器内上传、更改或删除客户图像时可能会有问题。 时间(UTC):2026-07-25T09:18:22

2. 2026年7月25日 UTC 09:20resolved

   这一事件已经得到解决.

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

1. 2026年7月24日 UTC 11:27resolved

   在协调世界时7月24日09:20至09:50之间,插件编辑器的实时同机编辑暂时无法使用. 在计划发布期间,数据库的更新计划花费了比预期更长的时间,并短暂地超载了数据库,这导致联合编辑服务重新开始. 我们的团队确定了事业,并在协调世界时09:50前全面恢复服务. 客户数据没有丢失,所有其他的斯地拉多功能在整个期间仍然可用。 我们从此在释放过程中增加了保障措施,以防止再次发生.

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

1. 2026年7月23日 UTC 09:39investigating

   进入客户账户可能有问题。 时间(UTC):2026-07-23T09:39:04

2. 2026年7月23日 UTC 09:49investigating

   [来自Opsgenie的评论] Dmitry Kudrenko承认提醒:"Fredo账户后端部分工作中的部分出局"

3. 2026年7月23日 UTC 10:02resolved

   这一事件已经得到解决.

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

1. 2026年7月20日 UTC 18:11investigating

   斯特拉多安全事件 事情是怎么开始的 我们收到两份客户报告,涉及与ESP账户有关的异常活动。 虽然个别报告可以合理地归因于各种原因,包括配置问题、遗留的整合或具体提供者的因素,但第二次报告涉及不同的ESP提供者,并显示出类似的特征。 届时,我们确定,所观察到的模式值得进行全面的安全审查并展开更广泛的调查。 目前情况 当我们用存储的ESP证书确定账户时,我们伸出援手,要求这些客户优先旋转钥匙. 这不是一个单一的,完整的通过: 在我们的调查继续进行时,我们发现了需要同样通知的更多账户,我们一直在联系他们,他们已经确认。 如果您有 ESP 证书与 Fredo 连接, 但尚未旋转 : 1. 在那里撤销旧密钥;生成新密钥不会自动使旧密钥失效. 2. 在您的ESP账户中生成新密钥。 3. 更新项目设置-集成下的Fredo新密钥。 4. 检查您的 ESP 或 CMM 账户最近的活性:登录历史,联系人列表更改,以及任何你不认识的运动或发送. 我们不会要求您通过电子邮件或支持聊天发送密钥、信使或密码。 正在进行的调查 我们的调查还在继续 如果我们发现任何对受影响客户重要的经证实的调查结果,我们将毫不迟延地予以通报.

2. 2026年7月20日 UTC 18:15investigating

   协调世界时7月20日,2026年 - 18:15 我们所修的 继我们初次通信之后,我们实施了若干额外的加强安保措施: 1. 信誉保护审计 我们审查了整个系统如何储存证书,并在酌情确定加强保护的情况下,对证书数据进行了额外的加密。 2. 实施额外的浏览器-侧保护,以解决已查明的与浏览器有关的曝光情况。 存储的证书在集成屏幕打开后不再发回浏览器. 再加上上述对储存的增强,大大减少了与证书处理有关的潜在接触风险。 3. 完成全面记录审计。 我们审查了我们的伐木系统端到端并更新了我们的伐木配置,以防止在应用程序日志中记录证书值。 4. 清理陈旧数据 我们删除了在停止使用后一直保存的旧的ESP连接,我们正在删除仍在文件中的旧的,未使用的密钥. 根据我们迄今的调查,我们没有发现任何对斯德洛插件影响的迹象。 Fredo不存储客户的财务或支付信息. 因此,根据我们迄今进行的调查,我们没有发现对Fredo所保存的财务或支付数据有任何影响。 根据目前掌握的资料,我们尚未发现对我们的初级生产系统有任何影响。 迄今确定的活动似乎与后备环境有关。 我们已经针对这种环境采取了额外的安全措施,并且正在继续评估在我们正在进行的调查中是否有任何更广泛的影响。 合规认证 我们维持一个独立审计的安全方案,包括SOC 2和ISO认证. 作为这项调查的一部分,我们查明了进一步加强与处理出口证书有关的某些技术管制的机会。 我们已针对我们在调查中查明的问题采取了额外的保障措施。 我们还将这次调查的结果纳入我们的安全方案、风险评估程序、技术控制和今后的审计活动。 这些结论为其他技术保障措施提供了依据,并将继续纳入我们的安全控制和审计方案。 安全认证证明,一个组织的安全方案已经按照公认的标准进行了独立评估. 与任何安全框架一样,随着新的风险和执行考虑的确定,它们支持不断改进。 正在进行的调查 我们的调查仍在进行中。 作为这项工作的一部分,我们继续审查与储存相关数据的数据库实例有关的访问活动。 如果我们确定对受影响客户具有重大意义的经证实的调查结果,我们将毫不拖延地予以通报.

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

   事件发生时间:2026年7月6日至18日 发布时间:2026年7月21日 最后事件报告——未经授权访问所储存的集成证书 内容提要 2026年7月6日至18日,一名未经授权的演员进入了一个内部非客户环境,该环境已读取了含有有限子集生产数据的有限只读复制品。 根据我们完成的调查,该行为者阅读了导致获得在该环境中储存的某些信息的查询,包括客户在斯特拉多为整合而储存的某些第三方ESP/出口证书以及某些账户记录。 确定活动后,我们将所涉环境隔离和退役,执行补救措施,并完成对事件的调查。 这起事件完全是通过客户要求报告的,不可能通过我们的标准监测来发现。 哪些数据受到影响 根据我们完成的调查,查明已查阅的信息包括客户保存的某些第三方ESP/出口证书,以便连接其合并,以及某些相关的账户记录。 账户认证数据 。 花旗口令是用散列和盐来储存的——从来不是纯正的文字,符合安全最佳做法,因此没有以可用的形式被曝光. 因为一个坚定的攻击者在理论上可以尝试在一段时间内破解被盐化的散列,所以我们没有冒险:我们主动地重置了每一个斯地拉多密码,尽管没有迹象表明散列可以实际恢复. 每个用户只需在下一个符号上设置一个新的密码。 我们所做的一切 1. 通过切断所涉内部环境并使其退役来遏制这一事件。 2. 对所有所储存的ESP/出口证书,包括那些尚未加密的证书(密钥被保存在管理的AWS KMS中)进行剩余加密。 3. 打开集成屏幕时停止向浏览器还原证书. 4. 审查了应用程序记录,并删除了可能显示这些记录的有限情景中的证明值。 虽然我们的调查没有找到证据表明应用日志是攻击路径的一部分,但作为我们更广泛的补救努力的一部分,我们还是实施了这项额外的保障措施。 5. 在不再使用后保留被没收的旧/无效证书。 6. 对Klavio、HubSpot、Zoho和AWeber来说,我们自动取消了所有授权标志。 7. 在我们的基础设施周边进行全面审查:审计了所有安保团体和进入系统节点的通道,轮调所有数据库的密码,将只读的复制品限制在内部仅取用,并审查了内部部门和工作人员持有的进入权,根据最低优先原则加以收紧。 8.主动重置所有用户口令并作废会话. 9. 在内部工具、外部数据库连接以及敏感表格的批量读取方面增加监测和提醒认证。 我们按照公认的安全和数据保护标准运作,包括我们的SOC 2方案。 作为我们正在进行的安全方案的一部分,我们继续根据这次调查的结果加强我们的技术和组织控制。 谁没有受到影响 仅向文件格式(HTML,AMP HTML,PDF,EML,图像等)输出的客户从未与我们保存过任何证书,也没有受到影响. 下列供应商也没有获得全权证书:CliverTap、Client.io、Colmbast Boss、Google Cloud、MallerLite、Mailtrap、Make、Mindbaz、n8n、Netcore、OneSignal、Optimove、Postup、Pubrio、Rapidmail、Reteno、Selzy、Sender.net、Ticketor、Unite、Inser、Voizee、WhatCounts、Yespo。 插件和自我托管的部署没有受到影响——所涉环境和复制品是斯德洛克云基础设施的一部分,而不是自托管产品或斯德洛插件。 长期不活动账户。 根据我们的数据保留政策,并根据我国的GDPR义务,不活跃的客户账户及其个人数据被例行删除,因此属于长期不活跃客户的信息在此环境中不存在,不可能被曝光。 付款数据 根据我们的调查,没有发现任何全额支付卡号码(PAN)或CVV代码被查取。 卡片支付由我们的支付提供商(Stripe和PayPal)处理,而Fredo不存储全额支付卡号码或CVV代码. 与我们的ESP伙伴合作 因为这些是第三方证书,我们本着伙伴关系的精神,主动与所涉ESP供应商联系,以保护我们的共同客户,这样受影响的证书就可以被取消,作为额外的保障。 我们推荐我们的顾客做什么 1. 如果您的提供者不在上文的 " 谁没有受到影响 " 一节中,而且您还没有: 旋转与您的 " Fredo " 账户相连的ESP 证书—— 取消您的提供者的旧密钥, 生成新的密钥, 并在 " Fredo " (项目设置 ) 中更新它。 对于基于OAuth的整合,取消Fredo在您的提供者的授权并重新连接. 2. 从7月初开始,审查你的ESP/CRM活动——签注、联系人名单更改以及任何你不认识的运动、发送或出口。 旋转密钥会停止未来的使用, 但不会取消已经发生的活动 。 3. 您的外形密码已经重新设置—— 在您的下个标志上设置新的密码 。 闭幕 我们对此事件深感遗憾。 我们直接联系了受影响的客户 随时可以回答后续问题 联系人: [email protected].

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

1. 2026年7月7日 UTC 15:26investigating

   在编辑器内上传、更改或删除客户图像时可能会有问题。 时间(UTC):2026-07-07T15:26:22

2. 2026年7月7日 UTC 15:27resolved

   这一事件已经得到解决.

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

1. 2026年7月1日 UTC 03:53investigating

   可能有一个问题涉及从编辑器中导出电子邮件模板作为PDF文件. 时间(UTC):2026-07-01T03:52:37

2. 2026年7月1日 UTC 03:53resolved

   这一事件已经得到解决.

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

1. 2026年6月18日 UTC 13:43investigating

   可能有一个问题涉及向特定电子邮件地址发送测试信息,和/或与用酸性电子邮件测试电子邮件模板有关。 时间(UTC):2026-06-18T13:43:15

2. 2026年6月18日 UTC 13:44resolved

   这一事件已经得到解决.

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