TT Lab
开始
学习 学习路径 课程

集成与部署

写一份故障报告

在 TT Lab 中继续学习

目标

以本环境提供的合成原始日志为依据,写出一份非工程人员也能读懂的故障报告。

为什么重要

FDE 的故障响应不是在系统里结束,而是在报告里结束。即使技术上修得完美,只要汇报迟了或含糊,客户的记忆里留下的就只有不安。

本实验强制要求的四点,都是现场的规则。先写影响,后写原因——读者最先需要知道的,是现在谁无法做什么。用数字来写——形容词因人而异,这种差异日后会变成纠纷。不指名个人——如果在客户公司的报告中点了负责人的名,下次故障时那个人就会隐瞒信息,而代价会以下一次检测延迟的形式回来。约定下次汇报时间——在原因未明的阶段承诺解决时间是赌博,但下次汇报时间,应由负责人按当前已确认的情况定下他能遵守的时间。

评分会检查必需章节、部分数值、长度和技术术语,但不会判定整段文字是否符合事实,也不会判定对客户行动的指引是否安全。是否写了原始资料中没有的事实,必须对照下面的依据范围自行检查。

访问日志中的错误响应,并不能证明每笔订单的处理失败或扣费失败。这份资料里没有订单账本或扣费核对结果,所以不要断言没有重复扣费,也不要指引客户立即重新支付。请区分已确认的服务症状、正在确认的逐笔订单结果,以及客户应先核对的明细。恢复后错误减少的观测,与过去订单的处理结果,也是不同的问题。

六个必需章节——## 영향、## 현재 상태、## 잠정 원인、## 타임라인、## 다음 단계、## 고객 안내(韩文,依次意为“影响”“当前状态”“暂定原因”“时间线”“后续步骤”“客户通知”)

步骤

  1. 创建 /root/incident.md。
  2. 把上面的六个章节全部写进去,并让 ## 영향 排在 ## 잠정 원인 之前。
  3. 在 ## 영향 一节中,写入出问题的路径(/api/pay)和从原始资料中统计出的准确错误响应数量,并带上计数单位(韩文中表示“件数”的量词)。
  4. 在 ## 잠정 원인 一节中,写入出问题的部署版本(2.7.0)和变慢的表(payments)。
  5. 在 ## 타임라인 一节中,写入 03:19、03:27、03:31、03:36、03:39 这五个时刻。
  6. 整个文档中不要写日志中的负责人账号名,也不要使用追究责任的措辞(失误、错误、过失、归咎之类,指韩文中的对应词)。
  7. 写一行以 다음 보고:(韩文,意为“下次汇报:”)开头的内容,并写上时刻或周期。
  8. 把 ## 고객 안내(韩文,意为“客户通知”)一节写到至少 30 个字符(不含空白),但不要使用 타임아웃·쿼리(韩文,依次意为“超时”“查询”)、500、payments、2.7.0,而要用 결제(韩文,意为“支付”)这个词来说明发生了什么。

参考

创建报告文件

创建 /root/incident.md。

创建 /root/incident.md。只有骨架也可以,但必须有内容。

备齐必需章节

把上面的六个章节全部写进去,并让 ## 영향 排在 ## 잠정 원인 之前。

需要六个章节,并且影响必须出现在暂定原因之前。

用数字写影响

在 ## 영향 一节中,写入出问题的路径(/api/pay)和从原始资料中统计出的准确错误响应数量,并带上计数单位(韩文中表示“件数”的量词)。

影响一节中必须写明哪条路径出了问题以及错误数量。要用数字,而不是形容词。

写出根本原因的值

在 ## 잠정 원인 一节中,写入出问题的部署版本(2.7.0)和变慢的表(payments)。

暂定原因一节中必须写明出问题的部署版本和变慢的表名。

填写时间线一节

在 ## 타임라인 一节中,写入 03:19、03:27、03:31、03:36、03:39 这五个时刻。

五个时刻必须全部出现在时间线一节之内。这些是在前面的课程中求出的值。

用无责的措辞来写

整个文档中不要写日志中的负责人账号名,也不要使用追究责任的措辞(失误、错误、过失、归咎之类,指韩文中的对应词)。

不要抄写日志里 actor 的值,也不要使用追究责任的措辞。

约定下次汇报的时间

写一行以 다음 보고:(韩文,意为“下次汇报:”)开头的内容,并写上时刻或周期。

在以上面任务中给出的那个韩文固定短语(意为“下次汇报:”)开头的那一行里,写上时刻或周期。

翻译成客户的语言

把 ## 고객 안내(韩文,意为“客户通知”)一节写到至少 30 个字符(不含空白),但不要使用 타임아웃·쿼리(韩文,依次意为“超时”“查询”)、500、payments、2.7.0,而要用 결제(韩文,意为“支付”)这个词来说明发生了什么。

客户通知一节中不能出现技术术语。请用日常用语写出哪项业务受到了影响。