题目重点：工单既要关联同一用户的历史问题，也要追到所属系统并查询问题发生时的状态快照。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版 ticket 有 ticketId、tenantId、userId、systemId、openedAt、closedAt、主题和状态；字段为建议 schema，非题目给定。
- ‘该用户相关工单’先定义为同租户、同 userId 的工单，可按 systemId/时间/主题再筛；语义相似问题的自动聚类另作扩展。
- 系统状态来自带时间戳和版本的事件/监控快照，查询时间区间 [start,end)；当前最新状态不能代表过去故障时状态。
解题路线
- 主表 Ticket 以 ticketId 唯一，索引 (tenantId,userId,openedAt) 查用户历史、(tenantId,systemId,openedAt) 查系统相关工单；TicketRelation 表可存人工/规则确认的关联边及理由。
- SystemCatalog 维护 systemId、服务所有者和权限；TicketSystemLink 支持一张工单涉及多个系统，若训练版只许一个可简化为外键，但不要把系统名称字符串当唯一身份。
- 系统状态按 systemId、occurredAt、version 写不可变事件或周期快照，查询问题窗口时按时间范围取状态与变更；若只有快照需加上窗口前最近一条基线状态，再重放窗口内变更。
- 入口创建工单用请求幂等键、权限校验和异步富化；关联用户工单/状态的查询遵守租户边界，分页与时间范围限制防大用户或大系统扫全库。
- 写入与索引可异步分离，但 UI 要标水位/新鲜度；高并发按 tenant/system 分片，热门系统读可缓存短期状态，工单主记录与关联更新须有一致性边界。
- 审计谁查询过客户工单和敏感系统状态，提供保留/删除政策；监控 ticket 写入、索引延迟、关联准确率、状态查询覆盖率和热系统瓶颈。
手动走一遍
用户 U 在 10:00 报支付失败，ticket T 指向 payment system。查询 U 的历史先返回同租户的其他工单；系统状态查询取 09:55 的基线快照和 10:00–10:15 的状态变更，才能解释 T 的时间段。若只读当前 11:00 的 Healthy 状态，会掩盖 10:03 的故障。
规模与取舍
工单数 N、状态事件数 E：带复合索引的用户工单范围查询近 O(log N+K)，时间状态查询近 O(log E+M)，K/M 为返回数量；真实成本受热系统、跨度和保留期影响。关系图若要多跳相关工单，须限深/限量避免无界查询。
易错点与追问
容易失分的边界
- 把支持工单与电影票售票混成同题。
- 用系统当前状态回答过去故障时间窗。
- 只按 userId 查，不带租户边界造成串户。
- ‘相关’既无定义也无可审计关系来源。
- 高并发时不分页、无限制返回用户所有工单和系统历史。
继续深挖
- 一张工单涉及多个系统时怎样存与查？
- 状态事件迟到/修正时如何重建历史视图？
- 用户身份合并或更换账号时历史工单如何关联？
- 热点系统有千万级状态事件时如何分层存储？
