历史回溯需支持定位到具体事件发生的时刻
别名: 事件定位回放 · event-centered trend
概念解释
以事件为中心的历史回溯（event-centered historical navigation），让操作者可以从一条报警记录、一次操作指令、一次模式切换或者一条日志条目直接跳转到它发生的那个具体时刻，并且查看这个时刻前后的完整上下文，而不需要在一条很长的时间轴上凭感觉盲目拖动去猜测事件大概发生在哪里。这个能力表面上看是个导航功能，实际上直接决定了事后复盘和故障调查能不能高效地把"发生了什么"和"什么时候发生的"对上号。
机制
故障复盘本质上要做一件事：把离散发生的事件——报警、操作、模式切换——和连续变化的过程变量对齐到同一条时间线上，判断谁先谁后、谁引发了谁。一个统一的时间游标，加上自动展开的事件前后窗口，能大幅减少人工在时间轴上搜索定位的工作量，也直接支持"哪个先发生"这类先后判断。但这套机制成立的前提是所有相关系统的时钟必须经过校正、彼此一致——如果不同子系统各自维护自己的时间、彼此之间存在没有被发现的偏差，那么"精确跳转到某个时刻"这个操作反而会制造出一种虚假的确定性：两个本来时间顺序就搞反了的事件，因为跳转显得"精确"，反而更容易被误判成正确的因果顺序，这是这套机制最隐蔽的失效方式。
边界
一个事件的"发生时刻"本身就有好几种可能的定义——是数据在源头产生的时刻，是数据被系统接收到的时刻，还是操作员事后手工补录的时刻——这几种时刻的精度完全不同，界面上如果不区分标注，回溯时会把不同精度的时间戳当成同等可信的证据来使用。通信中断期间丢失、之后又批量补传的数据，同样需要显式标注出来，因为它们在时间轴上出现的位置和它们实际发生的位置可能并不一致。默认展开的前后时间窗口也不应该变成一种限制——调查人员经常需要往更早的时间点去找触发这次事件链的真正源头，界面不能因为设了一个默认窗口就把这条路堵死。
怎么落地
关联多个来源不同、时钟基准也可能不同的系统数据时，界面应该主动显示彼此之间的时间差异，并且用视觉方式标出这个差异有多大程度的不确定性，而不是把本来就不确定的先后顺序硬生生压缩成一个看起来确定的时间线——后者看起来更整洁，但会把不确定性直接从证据里抹掉，交给使用者去承担一个他们并不知道自己在承担的风险。系统要为每一条事件记录保留它的时间来源信息，点击某个事件之后，让所有相关的趋势图同步跳转并默认展开前后一段上下文，同时允许操作者随时把这个窗口再往两边扩展。验证时专门使用包含断网补传数据、以及子系统之间存在已知时钟偏差的真实历史案例，检验排序结果和跳转定位是不是仍然准确。