缩短生产崩溃与修复之间的时间

Source: Dev.to

问题

你发布代码，一切正常——但随后生产环境出现崩溃。

即使在仪表化完善的系统中，调查过程通常也会是这样：

• 查看监控警报
• 翻阅日志
• 搜索代码库
• 尝试复现问题
• 编写修复代码
• 提交 Pull Request

在许多团队，这个过程很容易耗时数小时。

引入 Crashloom

在多年从事复杂应用和关键数据工作流的开发后，我开始思考是否可以将这部分调查过程自动化。

我们能否缩短 崩溃检测到验证修复 的周期？

这促使我开始构建 Crashloom。

Crashloom 是一个实验项目，利用 AI 代理来调查崩溃、识别潜在根因并提出可在创建 Pull Request 前验证的修复方案。

其目标是通过在调查工作流中提供帮助，减少生产崩溃到安全修复之间的时间。

工作原理

crash → investigation → sandbox validation → pull request

征求反馈

项目仍处于早期阶段，我想了解其他团队目前是如何处理生产事故的。

在你的团队中，从检测到崩溃 → 合并修复，通常需要多长时间？