很多故障不是“突然发生”的。
它们前面往往有迹象：刚发布了一个版本，刚改了一条配置，刚扩容了一组节点，刚切换了一个支付通道，刚做了一次运营活动，Kubernetes 刚重建了一批 Pod，云厂商刚报了一个可用区事件，某个依赖服务刚开始连续告警。
这些信息如果都在同一个地方，故障定位会快很多。
但现实里，它们通常散在不同系统里：发布记录在 CI/CD 平台，配置变更在配置中心，Kubernetes 事件在集群里，云事件在云平台控制台，告警在告警系统，工单在 Jira，业务活动在运营日历，值班处理过程在 IM 群里。
指标曲线飘红以后，值班人要一边看监控，一边问群里：刚才有人发布吗？今天有没有活动？云上有没有异常？K8s 有没有重启？这个告警是不是已经有人处理？数据库团队有没有做过变更？
这不是排障能力的问题，而是故障现场缺少时间线的问题。
事件墙要解决的，就是把关键事件放回到同一个时间窗口里，让团队能把指标异常和事件变化对照起来，快速判断“这次异常可能是由什么触发的”。
指标告诉你异常，事件告诉你发生了什么变化
可观测性数据里，指标、日志、链路和事件各自回答不同问题。
指标回答：状态有没有变化。
日志回答：具体请求或程序执行里发生了什么。
链路回答：一次请求经过哪些服务，哪里慢了或错了。
事件回答：这个时间点系统环境发生了什么变化。
事故定位慢，很多时候不是缺指标，而是只有“异常结果”，没有“变化证据”。
一个接口错误率从 0.1% 升到 10%，你当然知道异常了。但下一步要问：异常开始前后发生过什么？如果 3 分钟前刚发布过新版本，它就是强嫌疑；如果 5 分钟前 K8s 开始驱逐 Pod，要看节点和调度；如果同一时间云平台出现负载均衡事件，要排查云侧影响；如果业务活动刚开始，流量翻倍，要判断容量是否不足。
事件不是替代指标，而是给指标异常补上下文。
没有事件时间线，排障就会变成口头考古
很多团队复盘时都会遇到一个尴尬问题：到底是哪次变更导致的？
事故发生时，大家觉得自己记得。过了两天，时间线就开始模糊：某个发布是 10:05 还是 10:15？配置是谁改的？云事件是在告警前还是告警后？Pod 重启是原因还是故障后的结果？业务活动流量峰值是在错误率上升前还是之后？
事故现场本来就混乱。研发看发布平台，SRE 看监控和 K8s，DBA 看慢查询，网络团队看云控制台，业务团队看订单和投诉，值班负责人在群里追问进展。如果没有统一事件视图，团队很难形成共同认知。
事件墙的价值，不只是“展示事件”。它是把故障现场里的关键动作、系统变化和告警信号整理成一条可对照的时间线，让排障从“谁记得什么”变成“时间窗口里实际发生了什么”。
事件墙应该收哪些事件
事件墙不应该只收告警。告警只是事件的一种。真正有价值的事件墙，至少应该覆盖五类信息。
第一，线上变更事件。包括应用发布、回滚、配置变更、灰度开关、限流策略、路由调整、数据库变更、缓存规则变更、域名解析和证书变更。大量线上事故都和变更有关。不是说变更一定有问题，而是变更天然会改变系统行为，指标异常一旦和变更时间重合，就应该优先验证。
第二，基础设施事件。包括 Kubernetes Pod 重启、节点 NotReady、Deployment 滚动更新、容器 OOM、调度失败、磁盘挂载异常、云主机重启、负载均衡异常、云数据库主备切换、云厂商 EventBridge 或 CloudWatch 事件。这类事件帮助判断异常是否由运行环境触发。
第三，告警事件。包括监控告警、业务告警、云平台告警、夜莺告警、Flashduty 事件、第三方监控事件。它的价值不是“重复通知一次”，而是帮助团队看到告警之间的先后关系：先是 Redis 连接数告警，再是订单接口超时，再是支付成功率下降，这个顺序本身就是线索。
第四，运营事件。包括大促开始、直播活动、渠道投放、批量推送、业务规则切换、门店活动、风控策略调整。很多技术异常不是系统“坏了”，而是业务流量或业务规则变化后，系统承载方式没有跟上。
第五，人工处理事件。包括故障确认、负责人接手、执行回滚、扩容、切流、屏蔽告警、恢复确认、复盘登记。它能帮助团队回答：发现用了多久，确认用了多久，恢复用了多久，哪一步卡住了。
事件不是越多越好
事件墙最容易踩的坑，是把所有东西都接进去。页面上密密麻麻，全是点，看起来完整，事故现场却更难用。
事件墙要有筛选和聚合。Flashcat 事件视图可以按事件源、事件类型、标签和时间窗口聚合展示。多个相近事件可以聚合成一个点，用户再展开看明细。
真实生产环境里，事件量可能很大。Kubernetes 一次滚动发布可能产生大量 Pod 事件，云平台一次资源异常可能产生多条事件，一个告警风暴可能触发成百上千条告警，一次大促可能带来大量业务动作。
设计事件视图时，可以先按几个维度做收敛：
按业务线筛选，避免看到全公司事件。
按环境筛选，生产、灰度、测试分开。
按集群或机房筛选，快速聚焦区域影响。
按事件类型筛选，故障定位优先看发布、配置、K8s、云事件和核心告警。
按标签聚合，K8s 按 deployment/namespace/cluster，告警按服务/级别/规则。
事件视图不是越全越好，它要服务于排障问题。你想在事故现场快速对照什么，就围绕什么配置视图。
事件墙要和北极星、灭火图一起用
事件墙单独看也有价值，但它真正发挥作用，是和北极星、灭火图、下钻路径放在一起。
北极星发现业务异常，比如订单量偏离预测区间、支付成功率跌破阈值、在线用户数突然下滑。灭火图定位异常对象，比如支付接口卡片飘红、订单服务卡片飘红、Redis 集群卡片飘红、某个机房网络链路卡片飘红。下钻路径进一步查看指标、日志、Trace 和仪表盘。
事件墙再回答一个问题：这些异常前后发生过什么？
订单量下降前 8 分钟，网关发布了一个版本。
支付成功率下降前 3 分钟，支付通道配置发生变更。
Redis 告警前 2 分钟，Kubernetes 调度了一批新 Pod。
某个机房接口 P99 上升时，云平台上报了负载均衡异常。
错误率上升同时，运营推送开始，入口流量翻倍。
这时排障路径才完整。不是只看到“哪个指标异常”，也不是只看到“哪个服务慢”，而是能把业务异常、技术对象异常和系统变化放到同一个时间线上。
这也是事件墙应该进入统一可观测平台，而不是留在外部系统里的原因。如果事件只能在发布平台、云控制台、K8s 命令行和告警系统里分别查看，它就很难参与故障现场。
一个支付故障的事件墙用法
假设某电商系统在 10:20 开始出现支付成功率下降。
北极星先发现异常：支付成功率从平时的 99.2% 降到 92%，连续几分钟低于预测区间。值班人进入灭火图后，看到支付接口卡片飘红，支付服务、MySQL、Redis 正常，第三方支付通道卡片飘红。从支付接口卡片下钻到日志，看到某个通道返回码明显上升；从 Trace 下钻，发现该通道请求耗时和失败率都升高。
到这里，团队已经知道问题集中在支付通道，但还不知道为什么。
这时打开事件墙，看 10:00 到 10:30 的时间线。
10:08，支付路由配置发布。
10:12，第三方支付通道健康检查出现告警。
10:18，运营活动开始。
10:20，支付成功率开始下降。
10:21，支付接口错误率告警。
10:23，Flashduty 升级通知到支付值班人。
10:25，执行支付通道切换。
10:27，支付成功率恢复。
如果只看日志和 Trace，团队可能会以为是第三方通道自身异常。但事件墙显示 10:08 有支付路由配置发布，10:18 又开始运营活动。排障就应该同时验证两件事：配置是否把更多流量切到了异常通道？活动流量是否放大了某个通道的容量问题？
事件墙不是替你给出唯一答案。它把关键候选原因放到同一个时间窗口里，让团队少走弯路。
事件接入的现实路径
很多企业已经有不少事件源，不需要从零建设。
Flashcat 事件墙支持按事件源接入事件，并通过事件视图聚合展示。常见来源包括 Flashduty、Kubernetes、Nightingale、Jenkins、Jira 以及其他系统。
公有云事件和各类告警事件，建议先进入 Flashduty，再同步到 Flashcat。这样可以先完成告警降噪、分派、升级和触达，再把处理后的事件纳入统一时间线。
Kubernetes 事件的接入方式略有不同，通常在数据集成里的 Kubernetes 入口处理，并通过白名单机制决定哪些事件进入事件墙。这个白名单机制很实用，因为 Kubernetes 事件量很大，不是所有事件都值得进入故障定位视图。正常调度、普通拉镜像、常规滚动更新不一定都要展示；OOM、重启、驱逐、调度失败、节点异常、探针失败，很值得进入。
建设事件墙时，可以按优先级逐步接入：
第一阶段，接入发布和配置变更。
第二阶段，接入 Kubernetes 和云平台事件。
第三阶段，接入告警事件和 Flashduty 处理事件。
第四阶段，接入运营事件和业务动作。
不要一开始就追求全量事件。先接那些事故现场一定会问的事件。
事件告警不是重复告警
事件进入事件墙以后，还可以做事件告警。这听起来可能有点重复：事件本来不就是一种告警吗？但两者不完全一样。
有些事件本身不一定会触发通知，但它们值得在特定条件下升级。比如 5 分钟内同一个产品的云事件超过一定数量，某个 Kubernetes namespace 连续出现 OOM，某个 deployment 反复重启，生产环境出现高危配置变更，核心业务线在大促期间发生发布事件，Jenkins 发布失败连续出现。
这些事件如果只在事件墙里展示，值班人可能不会及时看到。通过事件告警，可以把“关键事件模式”变成主动提醒。
Flashcat 的事件数据统一保存在依赖的数据库中，可以通过夜莺告警规则配置事件告警。比如基于 Doris 查询某个时间窗口内的事件数量，并按事件类型或标签过滤。
当然，事件告警要谨慎。如果把每个事件都告警，就会制造新的噪音。更适合告警的是那些具备明确风险含义的事件组合：核心服务 5 分钟内连续 OOM，生产支付服务在冻结期发布，核心地域负载均衡异常。
事件告警的目标不是多发消息，而是把关键变化提前暴露出来。
事件墙也能帮助 AI 根因分析
AI 做故障分析时，最怕缺上下文。只有一段日志或一条告警，AI 很容易给出泛泛建议。
如果同时有北极星业务异常、灭火图对象健康状态、指标曲线、日志、Trace 和事件时间线，AI 的分析质量会明显不同。
事件墙提供的是“变化上下文”：异常开始前有哪些发布，哪些配置发生变化，哪些云资源或 K8s 对象出现事件，告警之间的先后顺序是什么，处理动作从什么时候开始，恢复动作和指标恢复是否重合。
比如 AI 看到接口错误率上升，同时看到 5 分钟前发布了新版本，且事件墙里没有云侧或 K8s 异常，它会优先建议检查发布差异和回滚。如果错误率上升前没有发布，但同一时间 Kubernetes 节点 NotReady、Pod 重启和云网络事件集中出现，分析方向就应该转向基础设施。
事件墙不只是给人看的。它也是 AI-Ready 可观测性的一部分。灭火图提供系统对象和健康状态，下钻路径提供指标、日志、链路入口，事件墙提供时间线变化证据。这些信息放在一起，AI 才有机会从“猜原因”变成“基于上下文做判断”。
怎么判断事件墙有没有建好
事件墙不是接入成功就算建好。可以用几个问题检验。
第一，事故发生时，值班人能不能在一个视图里看到最近 30 分钟关键事件？如果还要去发布平台、云控制台、K8s、Jira、告警系统来回查，事件墙还没有成为故障入口。
第二，事件能不能按业务线、环境、集群和事件类型过滤？如果所有事件混在一起，事故现场很难聚焦。
第三，事件能不能按标签聚合？如果每个 Pod 事件、每条告警都铺开，页面很快会失控。
第四，事件和指标异常能不能对齐时间？事件墙最重要的是时间线。时间字段、时区、采集延迟如果不准，分析就会偏。
第五，复盘时能不能还原完整处理过程？不只是原因事件，还包括告警触发、人员接手、执行回滚、扩容、切流、恢复确认。
第六，关键事件模式能不能主动告警？比如核心服务连续重启、云资源异常集中、生产变更发生在冻结期，这些不应该只等人打开事件墙才看到。
如果这些问题都能回答，事件墙才真正进入稳定性保障体系。
结语：故障定位不是只看曲线，也要看时间线
很多团队排障慢，不是因为没有监控曲线，而是曲线之外的关键变化没有被组织起来。
指标告诉你什么时候异常。日志和 Trace 帮你看到请求和代码层面的细节。灭火图告诉你哪些系统对象不健康。北极星告诉你业务是否受到影响。事件墙则告诉你：异常前后，系统和业务环境发生过什么。
这几个信息合在一起，故障定位才完整。
所以事件墙不应该被理解成一个附属页面。它是统一可观测平台里的根因分析时间线。
如果你准备建设事件墙，不建议第一步就接入所有事件。先拿最近三次故障复盘，逐个列出事故现场反复追问的问题：刚才有没有发布？有没有配置变更？K8s 有没有重启或调度异常？云平台有没有事件？有没有业务活动或流量变化？告警和处理动作的先后顺序是什么？
这些问题对应的事件源，就是第一批最值得接入 Flashcat 事件墙的对象。
可以预约一次事件接入评估，带上现有发布平台、Kubernetes 集群、云平台事件、Flashduty / 夜莺告警和最近几次故障时间线，一起设计哪些事件先接入、如何按标签聚合、哪些事件模式需要主动告警。
