两个晚上搭好系统，三周定不了一条规则

写代码只要两个晚上，但决定"什么算故障"花了三周——这不是技术债，是产品定义的隐形战场。

ingestion 很快，定义很慢

接到日志分析工具的需求时，你的本能反应一定是先搭数据流。建表、接接口、用 Postman 或 Curl 打一条测试数据，看着 Postgres 里出现新行——进度感满满。

TraceRoot 的作者就是这么开始的。两个晚上，ingestion 跑通。

接下来三周，他卡在了一个没想到的问题上：日志是事件，故障是有生命周期的状态对象。把 POST /logs 的流变成工程师愿意看的东西，才是没人写过的硬骨头。

这决定了你的工具是"有用的故障视图"，还是"加了慢查询的事件表"。

规则一：指纹——什么算同一个故障

日志进库后，第一个问题来得很快：哪些日志是同一个问题？

inventory-service 的两条 NullPointerException 明显相关。但 NullPointerException 和 TimeoutException 来自同一个端点呢？同一异常类型来自两个不同服务呢？共享 trace ID 但间隔十秒的两条日志呢？

每个场景都有合理答案，但系统必须选一个，对数百万条日志一视同仁。

TraceRoot 的解法是用四个字段拼指纹：服务名、日志级别、异常类型、端点。四字段全同即同一故障，变一个就是新故障。

选这四个不是拍脑袋。服务名区分"payment-service 和 inventory-service 的 NullPointerException 可能是同一根因，但修复责任不同"；日志级别区分严重程度；异常类型和端点定位代码位置。四者组合覆盖了"谁负责修、去哪修"的决策信息。

但代价是明确的：同一服务的内存泄漏可能分散成几十个 OOM 异常，因为端点不同。你得接受这种碎片化，或者再加规则——而每条新规则都是新的权衡。

规则二：阈值——多少次算故障

指纹解决了"是不是同一个"，阈值解决"算不算故障"。

单条 ERROR 日志就建单？服务Owner会被告警淹没。十分钟后，告警渠道变成白噪音，工程师开始批量忽略。

TraceRoot 的做法是滑动窗口计数：同一指纹在 N 分钟内出现 M 次，才触发故障创建。N 和 M 都是可配参数，但默认值的选择暴露了产品立场——偏敏感还是偏迟钝。

这里藏着个反直觉的点：阈值不是技术参数，是组织契约。定得太松，故障漏检；定得太紧，团队对工具失去信任。没有 universally right answer，只有"你们团队能接受的误报/漏报比例"。

作者没提具体数字，但强调了"wrong default that systems quietly inherit"——系统会默默继承错误的默认值，而使用者很久后才意识到。

规则三：重开窗口——什么时候算结束

故障关闭后，同类日志再次出现怎么办？新建还是重开？

TraceRoot 设了 reopen window：关闭后 X 分钟内出现的同指纹日志，重开原故障；超过 X 分钟，新建故障。

X 的选择同样痛苦。太短，间歇性问题变成故障刷屏；太长， genuinely new 的问题被埋进历史噪音。作者提到团队曾争论"30分钟 vs 4小时"，最后选了中间值——但承认这是 arbitrary，只是"系统必须选一个"。

这三个规则的共同点是：技术实现 trivial，产品决策 heavy。每条规则都是"opinions encoded as rules"，而每个 opinion 都有代价。

规则停在哪里

作者列了三个停下来的边界。

第一，不追根因。指纹只到端点级别，不解析堆栈找具体代码行。更深层的关联是人工判断的领域，自动化越界反而添乱。

第二，不做预测。基于历史频率的 anomaly detection 被明确排除——"我们做的是故障响应，不是运维水晶球"。

第三，不自动化修复。关闭故障、触发回滚、扩容——这些动作留给人工。工具只负责"让正确的人在正确的时间看到正确的信息"。

这三条边界划出了 TraceRoot 的产品定位：不是万能的运维大脑，是故障信息的可靠管道。定位清晰，才能拒绝功能蔓延。

检测才是硬骨头

文章最后把矛头指向了更上游的问题：上面三个规则都假设"日志已经 meaningful"，但现实中大部分 ERROR 日志是噪音。

第三方库的弃用警告、健康检查的偶发超时、非关键路径的降级处理——这些都会生成 ERROR 级别日志，但都不需要人介入。真正的信号藏在噪音里，而分离它们需要另一套规则：采样策略、白名单、动态阈值。

作者说这部分"deserves its own post"，但已经点出了核心洞察：ingestion 和 incident definition 是可见的工程问题，detection 是隐形的产品判断——什么值得人花时间看。

回到开头那个时间对比：两个晚上 vs 三周。差距不在代码复杂度，在"承认没有正确答案，但必须选一个"的决策负担。每个规则都是与不确定性的交易，而好的工具设计，是把交易条款摊开来给用户看。