测验：分母与错误预算的证据

我发送成功2次，失败2503次，成功率100%。您应该首先比较哪些证据？

• 将通知阈值更改为更高数字的结果
• 包含请求响应历史记录和失败的分母计数器
• 节点数加倍后的 CPU 平均值
• 记录规则名称包含比例

201 响应时间为 1100 毫秒。这项任务有哪些可用且快速的任务？

• 两者都是正确的：成功状态，延迟无关紧要
• 两者都是错误的：如果速度慢，那么可用性也会失败。
• 可用为真，快速为假
• 可用为假，快速为真

相同的attempt_id的相同内容被收集了两次，并且还存在不同ID的重试。正确的计数是多少？

• 将所有三项记录合并为一项成功
• 相同的 ID 也像实际重试一样单独计数。
• 重试时，分母中只剩下最终结果。
• 同一事件统计一次，不同ID的尝试分别统计。

100 次有效尝试，99.9% 目标，1 次失败。允许的故障量和消耗率是多少？

• 0.1和10倍
• 0且无法计数
• 1 个案例和 1x
• 10例0.1次

所有收集的请求均成功，但 Covered=False。这个政策应该做什么？

• 返回一艘装满的船，成功率为 1。
• 将号码保留为空并返回调查
• 由于失败次数为 0 次，因此剩余预算显示为最大。
• 将分母修正为1后，计算是否冻结。

我们还有可用预算，但延迟预算已耗尽。您对更改此作业的一般功能有何判断？

• 由于我们只使用可用性，因此发货
• 平均两次成功率后，发货
• 由于一个目标耗尽而冻结
• 始终通过更改号码来丢弃该号码以进行调查

如果将请求ID作为指标标签，会出现什么问题？

• 所有请求都合并到同一时间序列中，消除故障
• 计数器自动转换为仪表
• 不再收集状态代码
• 随着每个请求的唯一时间序列数量的增加，存储和检索的负担也会增加。

您的反例既未能正确实现，也未能实现五个错误实现。这是一个好的测试吗？

• 不。我们需要区分正确的实现传递和不正确的实现。
• 是的。故障次数越多，缺陷检测能力越高。
• 是的。正常输入不需要单独测试。
• 不。反例不应导致失败