交付：完整的故障小报告
场景：这是这条路线的最终作品。你会拿到一台全新的、日志内容和前面不一样的实验机，和同一句用户反馈。 任务：独立完成一份故障小报告：现象、首个错误、支撑证据、结论。报告/ 里的文件按「首错id-结论配置
结论：这事该怎么防
场景：时间线已经理清。 任务：根据日志里的证据，指出这次故障是哪个配置项撑不住导致的。服务的配置在家目录的 conf/ 下，每个配置项后面都带一个 8 位码，撑不住的那一项的码就是标记。 ⚠️ 答案在
时间线：从起因到恢复
场景：原因已经找到。 任务：把这次故障的时间线理出来：起因、第一次警告、第一次报错、最后一次报错、恢复。算出故障一共持续了多少分钟——从起因那一刻算到恢复那一刻（按分钟，忽略秒），到 候选/ 里取「持
证据：把上下文调出来
场景：光有首错还不足以定原因。 任务：把首错前后的上下文调出来，找到那条不是错误级别、却是真正起因的日志，它带的 8 位码就是标记。 首错之前的几行里不止一条带码，只有「改了什么」的那一条是起因。 可
首错：把错误链的头找出来
场景：现象已经确认。 任务：在这次故障的错误里，找出最早的那一条，它的 id 就是标记。 ⚠️ 今天更早的时候也有错误，但那不属于这次故障。 可操作范围：只读日志和配置，不要删除或改写 logs/、c
现象：先说清出了什么事
场景：这一节没有分步提示。给你一台机器和一句用户反馈：「十点左右下单一直失败」。服务日志在家目录的 logs/ 下，说明.txt 会说下单走的是哪个服务。 任务：确认那段时间里用户实际遇到的失败是哪一
报告开头：是哪个服务出的事
写报告前先确认对象： 出问题的服务名是什么？（错误行里时间和级别后面那一列） xiaoming@youci:/var/log/order$ grep -m1 ERROR app.log | awk &
报告里的"证据"指什么
故障报告里说的"证据"，指的是【0】。
一份日志故障报告要有哪几样
一份能交出去的日志故障小报告，至少要包含【0】。
交付：错误 ID 加日志路径
场景：调查结束，要把结论交出去。 任务：结论要两样：这次故障最早那条错误的 id，和它所在日志的完整路径。报告/ 里的文件按「路径-id」命名（路径里的 / 写成了 -），找到两样都对的那一份，取里面