把症状用数字钉住

在 20 分钟内将“偶尔无法使用”的问题反馈转化为测量值和可证伪的假设。

客户提供的不是缺陷报告，而是痛苦报告。将其转化为可测量的问题完全是我们的工作，第一个工具就是复现命令。一旦用数字固定失败率，就会得到两样东西：第一，你能与客户看到同一个事实；第二，之后有了判断“已经修复”的尺度。没有尺度的修复，无法知道是否真的修复。

下一步是提出假设，其中有一条规则：如果没有事先规定假设错误时会看到什么，它就不是假设。 “可能是网络问题”无论出现什么结果都不会被否定，因此无法减少候选原因。只有可能被推翻的陈述才能缩小调查范围。而且如果不记录已排除的候选项，30 分钟后你会重新检查自己已经排除过的原因。

创建 /root/hypothesis 目录。
运行 /opt/app/flaky.py，使其在 127.0.0.1:8001 上响应。
连续 20 次调用 /quote，将非 200 响应的数量写入 /root/hypothesis/baseline.txt。
将该失败率以整数百分比写入 /root/hypothesis/rate.txt，只写数字，不带符号。
将失败响应的正文字符串保存到 /root/hypothesis/reason.txt。
在 /root/hypothesis/h1.md 中写一个包含 가설:、맞다면:、틀리면: 三行的假设。
在 /root/hypothesis/ruled_out.txt 中写下已排除的层级。每行以 network、auth、app、data 之一开头，并附上依据。至少两行。
连续 40 次调用 /quote，将失败次数写入 /root/hypothesis/confirm.txt。

使用 python3 /opt/app/flaky.py & 启动，并通过 curl -s http://127.0.0.1:8001/health 确认。
for i in $(seq 1 20); do curl -s -o /dev/null -w '%{http_code}\n' URL; done | sort | uniq -c
常见错误 1：将 20 次调用拆开，并在其间混入其他请求。必须是连续 20 次。
常见错误 2：第 5 步只保存状态码。需要的是响应正文。

创建假设工作目录

创建 /root/hypothesis 目录。

将排除列表和假设文档集中放在一处。日后它们会构成报告的一半。

启动报价 API

运行 /opt/app/flaky.py，使其在 127.0.0.1:8001 上响应。

使用 python3 运行 /opt/app/flaky.py 后，它会在 127.0.0.1:8001 上监听。请在命令末尾添加 &，避免占用当前 shell。

调用 20 次并统计失败数量

连续 20 次调用 /quote，将非 200 响应的数量写入 /root/hypothesis/baseline.txt。

组合使用 curl 的 -o /dev/null 和 -w '%{http_code}'，即可只输出状态码。使用 seq 循环 20 次，统计非 200 响应。

以百分比记录失败率

将该失败率以整数百分比写入 /root/hypothesis/rate.txt，只写数字，不带符号。

这是将形容词转化为数字的步骤。把 20 次中失败的次数换算为整数百分比，不带符号写入。

获取失败响应正文

将失败响应的正文字符串保存到 /root/hypothesis/reason.txt。

仅查看状态码无法知道失败原因。去掉 -o /dev/null，原样接收响应正文。

编写可证伪的假设

在 /root/hypothesis/h1.md 中写一个包含 가설:、맞다면:、틀리면: 三行的假设。

需要“假设”“如果正确”“如果错误”三行。如果第三行写不出来，这还不是假设，只是一种感觉。

记录已排除的层级

在 /root/hypothesis/ruled_out.txt 中写下已排除的层级。每行以 network、auth、app、data 之一开头，并附上依据。至少两行。

从 network / auth / app / data 中，至少写出两个截至目前已确认排除的层级，并分别说明排除原因。

使用相同尺度重新测量

连续 40 次调用 /quote，将失败次数写入 /root/hypothesis/confirm.txt。

扩大样本后即可区分随机现象和规律。重新测量 40 次，确认比例是否保持不变。