题目重点：SD 加面题给 Email/API/Contact Form、多维 agent 查看和 claim，以及经理查询平均首响/关闭时间。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版 Ticket 状态 NEW→CLAIMED→IN_PROGRESS→CLOSED，可 reopen；首次响应是首次对提交者的可见人工/系统回复，机器人确认是否计入须问。
- 计算 elapsed wall-clock 时间，不自动排除周末/静默时段；结果按创建窗口选 ticket，未首响/未关闭的 ticket 在已完成平均值之外单列，避免生存偏差。
- agent 只能查看满足权限/语言/地域匹配的工单，规则字段可扩展；经理可看汇总但敏感内容受权限控制。
解题路线
- 为多入口建统一 ticketCreate 契约和 channelExternalId 幂等键，保存原始 payload 安全引用、规范化字段、createdAt 和来源。
- 索引 ticket 的 language/location/status/priority 与更新时间，agent 的候选列表由策略引擎过滤；claim 用条件更新 status=NEW 或 version CAS，确保多人同时点领取仅一人成功。
- 保存 append-only TicketEvent：created、claimed、firstResponded、closed、reopened，读模型计算当前状态；重复外部邮件/回调根据外部 ID 与内容指纹去重。
- 经理指标从事件时间线取 firstResponseAt−createdAt、closeAt−createdAt，按定义的时间窗和分群聚合；开放工单同时展示未完成比例/p90，避免只报完成工单平均值美化表现。
- 估算入口吞吐、附件存储与 agent 查询频率；监控投递失败、claim 冲突、长时间未响应、指标滞后及权限越界。
手动走一遍
训练例：email 与 API 重试携同 externalId=e7，系统只建一张 ticket；两个 agent 同时 claim，版本条件更新让仅一人成功。ticket 10:00 创建、10:05 首次回复、11:00 关闭，首响 5 分钟、关闭 60 分钟；若 11:30 reopen，需明确是否重算最终关闭时长。
规模与取舍
创建/claim 由唯一索引和条件写近似 O(log T) 数据库操作；agent 过滤查询成本取决于多列索引与候选规模；指标流式聚合随事件数线性，保留历史 O(事件数)。题目无规模。
易错点与追问
容易失分的边界
- 先查 NEW 再无条件写 owner，造成双领取。
- 各入口各造一套 Ticket schema，无法去重。
- 仅用当前行的状态/时间，reopen 后丢首响历史。
- 平均值只算已关闭而不展示未完成积压。
- 语言/地点规则没有权限边界。
继续深挖
- 跨时区/工作时间 SLA 如何算？
- reopen 是否重置首响/关闭时间？
- 复杂分配规则怎样版本化和解释？
- Email 重复转发怎么去重？
