Atlassian依靠Apache Kafka、Kubernetes上的Apache Flink和OpenTelemetry，重建了为其自动事故创建系统提供数据的事故发现平台。根据运行18个月后公布的测量结果，事件到达指标的时间从超过40秒降至不到10秒；在使用50%采样率时，持续处理能力则从每天约5亿个事件提升至每天超过10亿个事件。
该项目并未将自己描述为一则完整的成功故事。在监控范围内发生的事故召回率从约60%上升至2026年6月的峰值86%，随后在8月降至64%。准确率也仍低于目标水平，这促使团队将检测器本身的质量，与已配置指标的产品和实验的覆盖范围区分开来。
围绕事件流构建的平台
Atlassian为数百万租户管理十多个云产品，这些产品每天会因用户交互产生数十亿个事件。事件包括任务开始及其结果，并包含租户、用户、实验和HTTP状态码等数据。平台利用这些数据快速回答三个问题：是否存在问题？影响规模有多大？应以何种严重程度通知哪个团队？
在新设计中，事件会在Apache Kafka总线处进行筛选，而不是在应用内部消耗完整数据流。约770行的YAML订阅过滤器被作为代码配置的一部分保存。随后，一个Apache Flink 1.20应用在Kubernetes上处理事件，为事件补充租户数据，通过OpenTelemetry发送指标，并以60秒为窗口汇总事故影响。
团队使用Apache Parquet存储聚合数据，并使用多区域键值存储；Impact API则提供受影响用户数和租户数的查询结果。AutoHOT引擎将告警转换为事故，应用严重程度矩阵，抑制瞬时告警，然后每分钟重新评估影响。
性能和成本收益
- 虚拟机数量从约90台，加上队列和缓存层，减少到4个Kubernetes容器。
- 月度运营成本从约2万美元降至约650美元，降幅接近97%。
- 处理停止后，可以通过在约20分钟内重放Kafka事件进行恢复，且不会丢失数据。
- 影响面板的查询时间从约10秒降至约1秒。
- 在持续两周的并行运行期间，与旧路径的匹配率达到99.9%。
该设计采用HyperLogLog计算受影响的唯一用户数，而不是保存用户标识符，误差约为1.5%。团队还使用幂等存储键，使Kafka重放能够在不重复生成行的情况下恢复。团队通过StatsD路径保留了旧指标名称，因此迁移时无需修改，SLO面板和现有检测器便可继续运行。
为什么性能数据仍然不够？
事故结果表明，加快数据管道并不一定意味着更好的覆盖率。在九个月期间，共发生263起重大事故，但只有117起事故，即44.5%，影响了已配置监控的实验。其中80起被发现，这意味着在该期间系统仅捕获了全部重大事故的30.4%。
准确率也因告警类型而异。在该财年，系统自动创建的Sev2事故准确率约为85%；风险较低的早期告警准确率则在70%至79%之间。抑制抖动使被拒绝的瞬时告警工单减少了约80%。另一方面，指标系统的延迟会使数据下降被视为零，从而产生一波误报；团队通过在数据量下降检测器上增加至少120秒的延迟解决了这一问题。
仍未解决的限制
最大的逻辑问题是，沉默可能会被视为健康状态。整个数据库停止运行可能会阻止页面加载，因此根本不会产生失败事件。事件管道本身停止也可能使检测器失明。因此，团队增加了数据量下降检测器和指标新鲜度检查，并计划纳入边缘5xx错误和合成探针等独立信号。
团队还发现，事故发现和影响测量是两个相互分离的问题。在其中一起事故中，工单被及早创建，但系统估计影响约为2,000名用户，而实际数量超过80,000人。此外，Impact API在约100个并发用户的压力下崩溃，因为它在读取时合并HyperLogLog图，而没有预先聚合或缓存。
最重要的弱点仍然是，事件网关、Kafka订阅和Flink作业都运行在单一区域，尽管决策引擎在两个区域采用主动-主动模式。这意味着区域性故障可能使计算保持正常，却会中断发现机制本身的数据源。
certi.news的编辑解读
Atlassian这次实践的核心价值不在于单独选择Flink或Kafka，而在于将架构决策与可审查的运营指标联系起来：在总线处进行筛选、使用幂等键、使用同一套OpenTelemetry工具监控平台，以及区分召回率和覆盖率。结果表明，提升效率可以明显降低成本和延迟，但不会自动解决测量盲点，或解决那些不会产生客户端信号的事故。
Atlassian计划将检测器迁移至通过OpenTelemetry供数的时间序列存储，将Flink管道扩展为跨区域主动-主动模式，并在Impact API前增加每日聚合和缓存。公司还将目标设定为：在已配置监控的范围内，召回率和准确率均超过90%，同时Sev3事故发现的P90时间低于90分钟。根据已发布材料，这些仍是未来目标，而不是已经实现的结果。