很多事故刚开始时，看起来都是指标问题。接口错误率升高，P99 延迟变大，订单量下降，Redis 连接数打满，Kubernetes Pod 重启，数据库慢查询增多。值班人沿着指标、日志、Trace 查下去，当然能看到很多异常证据，但真正推动根因判断的，经常不是"哪个指标异常"，而是"异常前后发生了什么变化"。
刚发布了一个版本，刚改了一条配置，刚切换了支付通道，刚扩容了一组节点，刚做了一次运营活动，Kubernetes 刚重建了一批 Pod，云平台刚上报可用区事件，某个依赖服务刚开始连续告警。如果这些信息散在 CI/CD、配置中心、Kubernetes、云控制台、告警系统、运营日历和 IM 群里，排障就会变成口头考古：刚才有人发布吗？今天有没有活动？云上有没有异常？这个 Pod 是什么时候重启的？
事件墙的价值，就是把这些关键事件放回同一个时间窗口里。它不是为了把页面做得更热闹，而是为了减少排障猜测。指标告诉你状态变了，事件告诉你环境发生了什么变化。根因定位经常需要的，就是把这两件事放在一起看。
指标是结果，事件是变化证据
指标、日志、链路和事件回答的问题不同。指标回答状态有没有变化，比如流量下降、错误率上升、P99 变慢、CPU 升高、连接数打满、队列堆积。日志回答程序或请求里发生了什么，比如错误码、异常栈、业务字段、TraceID 和用户请求上下文。Trace 回答一次请求经过哪些服务，哪个调用阶段慢了或错了。事件回答这个时间点系统环境发生了什么变化，比如发布、配置、扩缩容、重启、云资源异常、告警触发、工单处理和运营活动。
事故定位慢，很多时候不是缺指标，而是只有"异常结果"，没有"变化证据"。一个接口错误率从 0.1% 升到 10%，你当然知道异常了，但下一步要问的是异常开始前后发生过什么。如果 3 分钟前刚发布新版本，那发布是强嫌疑；如果 5 分钟前节点开始驱逐 Pod，就要看调度和资源；如果同一时间云平台出现负载均衡事件，就要排查云侧影响；如果运营活动刚开始导致流量翻倍，就要判断容量和限流策略；如果没有明显变更，再深入查依赖、数据和代码。
事件不是替代指标。事件是给指标异常补上下文。没有事件时间线，团队容易在指标和日志里反复验证结果，却迟迟找不到触发条件。
事件墙应该覆盖哪些事件
事件墙不应该只收告警。告警只是事件的一种，而且很多告警本身就是异常结果。真正有价值的事件墙，至少要覆盖四类事件。
第一类是变更事件，包括应用发布、回滚、配置变更、灰度开关、限流策略、路由调整、数据库变更、缓存规则变更、域名解析和证书变更。大量线上事故都和变更有关。不是说变更一定有问题，而是变更天然会改变系统行为。指标异常一旦和变更时间重合，就应该优先验证。
第二类是运行时事件，包括 Kubernetes Pod 重启、节点 NotReady、Deployment 滚动更新、容器 OOM、调度失败、磁盘挂载异常、云主机重启、负载均衡异常、云数据库主备切换、云厂商事件。应用日志里看到超时，不一定是代码问题，也可能是节点、网络、存储或云资源事件触发的连锁反应。
第三类是告警事件，包括监控告警、业务告警、云平台告警、夜莺告警、Flashduty 事件和第三方监控事件。告警事件的价值不是再通知一次，而是帮助团队看到告警之间的先后关系。比如先是 Redis 连接数告警，再是订单接口超时，再是支付成功率下降，这个顺序本身就是排障线索。
第四类是运营事件，包括大促开始、直播活动、渠道投放、批量推送、业务规则切换、门店活动、风控策略调整。很多技术异常并不是系统突然坏了，而是业务流量、用户行为或业务规则变化后，系统承载方式没有跟上。如果运营事件不进入故障时间线，技术团队很容易只在系统内部找原因。
重大故障里，还应该记录人工处理事件，比如故障确认、负责人接手、执行回滚、扩容、切流、屏蔽告警、恢复确认和复盘登记。这类事件对响应复盘很关键，它能帮助团队回答发现用了多久、判断用了多久、恢复用了多久、哪一步卡住了。
事件质量比事件数量更重要
事件墙最容易做坏的方式，是把所有东西都接进去。页面上密密麻麻全是点，看起来很完整，事故现场却更难用。事件墙要服务于排障，事件质量比事件数量重要。
第一，时间要准确。事件时间如果偏差很大，就会直接误导根因判断。发布完成时间、配置生效时间、Pod 重启时间、告警触发时间、运营活动开始时间要尽量使用系统真实时间，而不是人工补录时间。复盘时最怕的不是事件少，而是时间线不可信。
第二，对象要准确。事件必须能关联到服务、实例、Pod、集群、环境、业务线、通道或地域。一个只写"发布成功"的事件价值很低，一个写清楚 payment-service 在 prod 环境发布 v2.3.2 的事件才有排障价值。对象越准确，事件越容易和灭火图卡片、北极星指标、日志和 Trace 对上。
第三，负责人要准确。变更是谁发起的，哪个团队负责，哪个系统受影响，事故现场需要快速知道。否则事件墙只能告诉你"发生过变更"，不能帮助团队找到能解释和处理变更的人。
第四，来源要可追溯。事件来自 Jenkins、GitLab、配置中心、Kubernetes、云平台、Flashduty、运营系统还是人工录入，应该清楚。来源不清的事件很难被信任，也很难在复盘时追查细节。
第五，视图要能聚合和筛选。Kubernetes 一次滚动发布可能产生大量 Pod 事件，一个告警风暴可能带来上百条告警，云平台一次资源异常也可能产生多条事件。事件视图需要按事件源、事件类型、业务线、环境、集群、服务和标签聚合。一个支付系统故障，不应该默认看到全公司所有事件；事故现场要先聚焦相关业务和时间窗口。
如何用时间线缩小排查范围
事件墙的落地可以按一个简单流程推进。第一步，确定核心业务或系统的事件范围。比如支付链路，先接入支付服务发布、配置中心变更、支付通道切换、Kubernetes 事件、云数据库事件、核心业务告警和运营活动。不要一开始接全公司所有事件。
第二步，把事件和对象标签对齐。发布事件要带服务名、版本、环境、团队；Kubernetes 事件要带 cluster、namespace、pod、deployment；云事件要带实例、地域、产品类型；运营事件要带业务线、渠道、地域、时间窗口。只有标签对齐，事件才能和北极星、灭火图、日志和 Trace 关联。
第三步，定义事件视图。故障定位视图可以优先展示发布、配置、Kubernetes、云事件和核心告警；业务活动视图可以展示运营动作和流量变化；复盘视图可以加入人工处理动作、认领、回滚、恢复确认和工单。不同场景需要不同视图，不要把所有事件挤在同一张图上。
第四步，在事故中使用时间线。北极星发现业务异常后，先看异常开始时间；灭火图定位到异常对象后，围绕这个对象和时间窗口打开事件墙；如果异常前后有发布、配置、运行时或运营事件，优先验证它们和指标变化的关系；如果没有明显事件，再继续从日志、Trace 和依赖关系深入。这个顺序能减少盲查。
第五步，把复盘结论反向改进事件接入。每次事故后都问：这次定位时缺了哪些事件？哪个事件时间不准？哪个对象标签不清？哪个来源没有接入？如果复盘总是在群里追问"刚才谁改过什么"，说明事件墙建设还没到位。
Flashcat 事件墙应该和北极星、灭火图一起用
Flashcat 事件墙用于收集线上变更、重要告警、运营事件等关键事件，并支持将指标异常和相关事件进行对照分析。它单独看有价值，但真正发挥作用，是和北极星、灭火图、下钻路径放在一起。
北极星回答业务是否异常，比如订单量偏离预测区间、支付成功率跌破阈值、在线用户数突然下滑。灭火图回答哪些观测对象异常，比如支付接口卡片、订单服务卡片、Redis 集群卡片、某个机房网络链路卡片飘红。下钻规则进一步把异常对象带到日志、Trace、仪表盘和上下游对象。事件墙再回答：这些异常前后发生过什么。
一个完整的场景是：支付成功率下降，北极星先告警；进入灭火图后，支付接口和第三方支付通道卡片飘红；从支付接口下钻到日志，看到某个错误码集中；从 Trace 看到第三方通道耗时升高；再看事件墙，发现 10 分钟前该通道配置刚变更。此时排障路径就从"指标异常"变成了"业务异常、技术对象异常、错误证据、变更线索"连在一起。
C3 也涉及 Flashduty，但边界要说清楚。Flashcat 事件墙更适合承载观测侧事件时间线：变更、告警、运行时事件、运营活动与指标异常的对照。Flashduty 更适合承载事故响应时间线：谁认领、谁升级、谁处理、何时恢复、复盘行动项是什么。两者可以互补，但不要把事件墙写成 On-call 平台，也不要把事故响应系统写成全栈观测入口。
验收标准：事件能不能减少猜测
事件墙建设好不好，不看接了多少事件源，而看它能不能减少事故现场的猜测。可以用几个问题验收。
第一，核心业务异常发生时，事件墙能不能在同一时间窗口看到相关发布、配置、Kubernetes、云资源、告警和运营事件。第二，事件是否带有准确对象标签，能不能按服务、集群、环境、业务线和地域筛选。第三，事件时间是否可信，能不能用于判断先后关系。第四，事件来源和负责人是否清楚，能不能快速找到能解释变更的人。第五，事件视图是否有聚合和过滤，不会在事件风暴里制造新的噪声。第六，复盘时能不能直接引用事件时间线，而不是事后翻群聊和截图。
如果这些问题做不到，事件墙可能只是另一个展示页面。如果做到了，它会成为根因定位里很关键的一层：不替代指标、日志和 Trace，但帮助团队更快判断"刚才变了什么"。
总结：根因定位不是只查数据，也是查变化
很多事故的关键问题不是"哪个指标异常"，而是"为什么这个时间开始异常"。指标、日志和 Trace 能告诉你异常是什么样，事件墙能把发布、配置、运行时、告警、运营和处理动作放到同一个时间窗口里，帮助团队缩小排查范围。
下一步可以很小：选一个核心系统，预约一次事件接入评估。先接入最近三次事故中最常被追问的事件源，比如发布、配置、Kubernetes、云事件、核心告警和运营活动。跑通一个事件视图，再扩展事件类型。事件墙的目标不是让页面更热闹，而是让下一次事故少问几轮"刚才谁改了什么"。