resolved
**1. 总结**
2026年10月5日,从15:55开始,我们美国平台上的客户看到反应缓慢,间歇出错,拉出请求检查和CLI扫描出现延误. 一些需要Cycode拉取请求检查的客户在恢复扫描前无法合并.
问题开始于我们原始数据库中一个背景维护进程落后并停止完成,数据库停止保存新数据。 恢复服务需要几个小时,因为备用数据库首先需要处理大量积压的更改。
数据库恢复了,平台在19:43之前再次开放。 被拖延的处理随后被赶上,事件于23:24IDT得到解决. 检查了事故中错过的请求。
**2. 关键时间线(IDT)**
• ** 2026年10月5日,12:55 IDT**: 一个例行的数据库维护程序开始比正常运行慢得多. 还没有影响客户
• ** 2026年10月5日,14:53 IDT**: 下个维护周期开始,没有完成.
• ** 2026年10月5日,15:55 IDT**: 数据库停止保存新数据,平台性能下降.
• ** 2026年10月5日,16:03 IDT**: 数据库达到了连接极限. 顾客开始看到错误。
• ** 2026年10月5日,16:21 IDT**: 事件宣布,反应小组开始行动。
• ** 2026年10月5日,16:24 IDT**: 第一次更新发布在状态页面上.
• ** 2026年10月5日,16:49 IDT**: 切换到备用数据库已启动 。
• ** 2026年10月5日,17:00 IDT**: 我们的云基础设施供应商开案了
• ** 2026年10月5日,18:24 IDT**: 替代恢复路径平行开始。 为客户公布的工作周刊 被要求的拉取请求检查封锁。
• ** 2026年10月5日,19:43 IDT**: 数据库再次可用,Cycode API和Cycode平台可以访问.
• ** 2026年10月5日,19:54,IDT**: 拉请求扫描恢复。
• ** 2026年10月5日,20:20 IDT**: 处理能力得到提高,以清理所拖延的事件。
• ** 2026年10月5日,20:45 IDT**: 大量工作量被暂停,以减少数据库负荷。
• ** 2026年10月5日,21:56 IDT**: 查清并扫描了事故发生时错过的请求
• ** 2026年10月5日,23:09 IDT**: 所有服务全面投入使用.
• ** 2026年10月5日,23:24 IDT**: 事情解决了
**3. 根源**
我们的数据库运行一个常规的背景过程,经常将最近的变化保存到永久存储中. 有两个条件导致这一进程放缓:
• ** 大量短寿命数据操作:** 我们的一些处理工作量不断创造和去除大量短寿命数据结构。
• ** 延迟背景同步:** 数据同步进程远远落后于此,使数据库无法自行清理。
维护过程放缓并最终停止了完成. 之后数据库无法再保存新数据,请求开始排队. 我们的服务重新研究了这些请求,并打开了许多新的连接,从而利用了数据库的连接能力。 客户认为这是错误和反应缓慢。
我们转到了备用数据库 在它能为交通服务之前,它必须处理自上一个完成的维护周期以来所作的所有改变,大约四个小时的活动. 这延长了停电时间。
**4. 采取的行动**
• 通过暂时减少非必要处理,减少数据库的负荷。
• 开始改用备用数据库。
• 与我们的云基础设施供应商开了一个支助案例,并在升级的基础上与他们合作。
· 平行制定其他恢复途径。
• 为因需要的拉力请求检查而受阻的客户共享临时工作。
• 数据库恢复后,清理延迟事件的处理能力得到提高。
• 减少造成大量短期数据操作的工作量,以减少数据库负荷,同时推迟清理事件。
• 扫描了事件中错过的拉力请求。
**4b. 行动项目**
· 改变大批次的数据的写法,以减少数据库负荷。
• 将我们工作量最高的工作转移到自己的专用数据库,因此,一个问题不能影响其他平台。
• 为数据库连接的使用和数据库的健康增加警报并进行更深入的监测。
• 向每项服务提供自己的专用数据库证书。
• 更有效地处理即将到来的事件,以在中断后加快恢复。
• 改进对处理延误和内部事件警报的监测。
• 审查数据库的能力和业绩设置,以增加主室.
