题干与适用场景
请设计一个面向多团队的事件指挥平台：它要接收告警、创建事件、分配响应角色、同步内部与外部沟通，并在恢复后保留可审计的时间线。请说明一致性、权限、通知风暴和恢复目标。
这道题适合系统设计、SRE、平台工程和后端岗位。它考察在故障压力下如何把检测、指挥、协作和复盘连成可恢复系统。事件指挥平台的核心不是聊天工具，而是一个有明确责任人、状态转换、证据时间线和降级路径的控制平面。面试中的容量可按“每分钟告警量、同时进行事件数、参与者数、通知渠道和保留期限”澄清。
面试官考察点
- 是否把事件管理与原始监控、聊天和工单系统分层。
- 是否定义事件状态、幂等键、单一事实源和并发编辑规则。
- 是否将 incident manager、tech lead、通信负责人和记录员职责分离。
- 是否处理告警去重、相关事件合并、通知风暴和权限边界。
- 是否提供降级、跨区域故障恢复、审计完整性和数据保留策略。
- 是否用 MTTA、MTTR、告警噪声和沟通延迟验证设计结果。
30 秒回答框架
“我会把平台分为告警接入、事件编排、实时协作、通知和复盘存储。接入层按来源和时间窗口去重，编排层以事件为单一事实源，使用版本号保证状态与角色变更可审计。事件经理负责指挥，技术负责人处理诊断，通信负责人对外同步，记录员维护时间线。消息先写入持久事件日志，再通过可重放流推送；通知按优先级和订阅限流。跨区域故障时允许只读或人工降级，恢复后用时间线生成复盘。”
分步骤深入解答
第一步：明确边界和非功能目标
告警来源可以是指标、日志、合成监控、客服升级或人工创建。平台负责把信号组织成事件和响应流程，不替代监控计算、聊天内容存储或部署系统。先确认 SLO：事件创建延迟、关键通知送达率、时间线写入持久性、跨区域恢复时间和审计保留期。
容量问题要区分平时和大规模故障：例如每分钟数万条告警、数百个并发事件、每个事件数百名参与者，以及同时发送短信、邮件、移动推送和 Webhook。极端峰值需要背压和优先级，不能让低优先级通知阻塞事件经理的控制操作。
第二步：接收、去重和关联告警
接入端为每条信号保留来源、规则版本、时间戳、指纹和原始载荷。客户端重试和网络重放要求 API 支持幂等键；服务端用租约或唯一约束避免同一指纹重复创建事件。去重窗口不能永久吞掉新故障，应该按服务、环境和时间动态配置。
关联逻辑可以先按服务拓扑、部署版本、区域和共同标签聚合，再允许事件经理手动拆分或合并。自动关联必须记录依据和版本，不能静默改变已有事件的范围。原始告警不可覆盖，后续聚合结果作为派生状态保存。
第三步：设计事件状态机和角色
事件至少包含 detected、triaged、mitigating、monitoring、resolved 和 closed 等状态，并定义允许的转移、操作者和必填证据。状态不是单个布尔值；它应与影响范围、当前假设、下一步动作和更新时间一起记录。
响应角色要与身份分离：incident manager 负责优先级和决策，tech lead 负责技术调查，communications lead 负责内部与外部更新，scribe 维护时间线。角色变更要追加审计事件，旧负责人不能无声消失。重大操作采用租约和版本号，避免两个值班人员同时提交互相覆盖的指令。
第四步：构建实时协作和单一事实源
所有状态、角色、行动项和沟通摘要先写入事件日志或事务数据库，再通过消息总线推送到 WebSocket、SSE、邮件和移动渠道。客户端可以乐观展示，但收到版本冲突时必须重新读取服务端状态；不能把浏览器内存当作最终事实。
时间线应保存操作者、服务器时间、事件版本、动作类型、摘要和关联告警。长文本聊天可以外接存储，但关键决策和恢复证据要进入结构化时间线。读模型可以按事件生成当前视图，重放日志后仍能还原状态。
第五步：处理通知风暴与权限
通知策略按事件优先级、用户值班表、渠道可靠性和已确认状态限流。低优先级告警进入摘要，高优先级通知使用指数退避、渠道升级和确认超时；同一事件不应让一名值班人员收到数百条重复消息。通知队列要和控制平面隔离，避免短信供应商故障阻塞状态更新。
权限至少区分观察者、响应者、事件经理、通信负责人和管理员，并按租户、服务和环境限制访问。外部状态页只读投影经过脱敏的影响和进展，不直接暴露内部假设、客户数据或凭证。所有读取和导出都应记录审计事件，紧急破窗操作需要原因和事后复核。
第六步：设计降级、恢复和复盘
平台本身故障时，必须保留电话桥、静态运行手册或备用事件表等人工路径。控制平面优先保证创建事件、认领角色和写入时间线；非关键分析、搜索和历史报表可以暂时不可用。跨区域部署采用主写与异步复制或分片写入，需明确冲突合并和故障转移后的租约重新获取。
恢复后生成复盘草稿：检测、确认、缓解、恢复和关闭各阶段的时间，关键决策、告警质量、沟通对象和后续行动。复盘记录不能篡改原始时间线；修订应追加版本。指标包括 MTTA、MTTM、MTTR、重复告警比例、角色认领延迟、通知送达率和行动项按期完成率。
信息增益与边界
事件指挥平台的增益来自责任、状态和证据的结构化，而非把所有聊天搬到一个页面。它不能保证根因正确，也不能替代监控质量和人员训练。设计必须承认通知渠道、身份服务、区域网络和平台自身都可能同时故障，因此要有最小可用控制面和人工回退。
高质量示范回答
“我会先定义平台边界和目标：它组织告警与响应，不替代监控、部署或普通聊天；关键目标是创建延迟、通知送达、时间线持久性、跨区域恢复和审计保留。接入端保留原始告警，使用来源指纹和幂等键去重，按服务、区域、版本和拓扑关联，但所有自动聚合都可解释、可拆分。
事件编排层以版本化状态机为核心，状态和角色变更追加到持久日志。事件经理负责优先级和决策，技术负责人负责诊断，通信负责人负责更新，记录员维护时间线。客户端通过可重放流获得状态，版本冲突时重新读取，浏览器缓存不作为事实源。关键通知与控制操作使用分离队列，按优先级、值班表和确认状态限流。
权限按租户、服务和环境隔离，外部投影只暴露脱敏影响。跨区域故障时优先保留创建、认领和写时间线，搜索与报表可以降级到只读或离线。恢复后从不可篡改的时间线生成复盘，计算 MTTA、MTTR、告警噪声和行动项完成率。如果平台不可用，电话桥和静态运行手册仍能让团队继续指挥。”
常见错误
- 把平台当聊天工具 → 关键状态埋在消息中且无法审计 → 结构化状态机和事件时间线。
- 告警全部实时广播 → 通知风暴阻塞真正的控制动作 → 去重、优先级、确认和限流。
- 角色只存在于前端 → 多人操作会互相覆盖且责任不清 → 服务端租约、版本和追加审计。
- 自动合并不可解释 → 事件范围错误时无法回溯 → 保留原始告警和聚合依据。
- 只设计正常区域 → 平台故障时团队失去指挥渠道 → 最小控制面与人工回退。
- 复盘覆盖原始记录 → 无法验证时间和决策 → 原始日志不可变，修订追加版本。
追问及应对
两名事件经理同时接管怎么办？
使用带过期时间的接管租约和单调版本号，服务端只接受当前租约持有者的控制写入。接管失败的一方读取最新状态并显示当前负责人；紧急破窗需要权限、原因和审计记录。
通知供应商宕机会不会影响事件状态？
不会让通知队列成为状态写入的前置条件。先持久化事件和待发送通知，再由独立 worker 重试、切换渠道或进入人工电话流程；控制平面仍可读取和更新。
如何避免自动关联漏掉真正的新事件？
关联只产生候选关系并保留原始信号，使用时间、服务、区域和拓扑等多个证据。高影响或低置信度信号进入人工确认；规则版本和拆分操作都写入时间线。
外部状态页应该实时显示什么？
只投影经过权限和隐私过滤的影响范围、当前阶段、下一次更新时间和恢复进展。内部假设、客户标识、凭证、未确认根因和详细日志留在受控内部视图。