发帖
雷达卡
毕竟，大多数专家都同意，要管理好某件事，就需要对其进行衡量。
数据工程师和 DataOps 团队还采用故障指标来衡量其数据和数据管道的可靠性，以及故障排除工作的有效性。
但是，当涉及到数据时，某些指标比其他指标更相关和有用，尤其是在当今云密集的环境中。
排名指标
这个博客对当今使用的十几个最常见的故障指标进行排名，按照对数据工程师的相关性和重要性排序，从最利基和最不相关的指标开始，最后是所有 DataOps 团队都应该跟踪的最重要的指标。之后，我将讨论像 Acceldata 这样的连续多维数据可观察性平台如何在帮助数据工程师和数据可靠性工程师优化这些指标方面发挥重要作用。
12. 平均无故障时间 (MTTF)
从历史上看，该术语衡量的是正常操作条件下不可修复的硬件或设备的平均寿命。MTTF 对于监督任务关键型数据中心和本地数据服务器的数据工程师可能很有用，他们希望围绕硬盘或固态驱动器的预测寿命规划硬件更新。其次，网络集线器、交换机和卡将数据从一个节点转移到另一个节点。
当然，此类硬件的责任通常主要由 IT 或网络管理员负责，从而降低了 MTTF 对数据工程师的重要性。随着许多组织将数据转移到托管提供商或云原生 Web 服务，MTTF 也变得越来越无关紧要。它通常也不如我稍后讨论的平均故障间隔时间 (MTBF) 有用。
11. 平均检测时间 (MTTD)
一种在网络安全界流行的指标，可以帮助衡量您的监控和可观察性平台以及自动警报的有效性。然而，过分强调 MTTD 可能适得其反。例如，针对最短 MTTD 进行调整的监控系统可能会变得过于迅速和过于频繁地发出警报。这可能会为小问题或彻底的误报创建一波警报潮。这会使数据工程师士气低落，并造成严重的警报疲劳问题。
此外，最好的连续可观察性平台使用机器学习或高级分析在故障和瓶颈发生之前预测它们。MTTD 没有捕捉到能够进行此类预测的数据可观察性系统的优越性。
10. 平均识别时间 (MTTI)
MTTI 与上述 MTTD 大部分可互换，具有相同的优点和缺点。
9. 平均验证时间 (MTTV)
这通常表示解决或恢复过程的最后一步。MTTV 跟踪从部署修复程序到证明修复程序已解决问题的时间。在当今复杂的数据管道和分布广泛的异构数据存储库中，手动减少 MTTV 实际上是一项重大挑战。可能对数据工程经理有用，但对其他人很少。
8.平均知道时间（MTTK）
测量发送警报与发现问题原因之间的差距。这可能是跟踪 DataOps 团队取证技能的好方法。否则，MTTK 是一个相当小众的指标。
7. 平均确认时间 (MTTA)
跟踪从检测到故障到开始解决问题的时间。与 MTTK（平均了解时间）一样，此细粒度指标可以帮助跟踪和提高待命 DataOps 团队的响应能力，还有助于确保及时通知内部客户和用户他们的问题正在得到处理。MTTA 与 MTTK 或 MTTR（平均响应时间）配合使用时效果最佳。这确保了随叫随到的数据工程师不会通过例如立即响应警报来玩弄系统，而是以更悠闲的节奏开始他们的实际工作。
6. 平均响应时间 (MTTR)
较小版本的 MTTR 衡量您的团队响应寻呼机警报或电子邮件所需的时间。该指标可用于跟踪和激励数据工程团队。但它是一个相当精细的指标，最好与众所周知的 MTTR（平均恢复/解决/修复时间）结合使用。这样，您可以跟踪 DataOps 团队需要多长时间来响应问题以及解决问题需要多长时间。
5. 服务事件之间的平均时间 (MTBSI)
这是通过将平均故障间隔时间 (MTBF) 和 MTRS/MTTR（平均恢复服务时间/平均恢复时间）相加来计算的。这是一个重要的战略指标，可以与您的内部客户共享，它可以捕捉您的基础架构的可靠性以及您的 DataOps 团队在正确诊断根本原因时的响应能力和技能。
4. 平均恢复服务时间 (MTRS)
对于专注于客户性能和正常运行时间的数据工程师来说，这是一个有用的以业务为中心的指标。它可以应用于本地数据服务器和在公共多租户服务上托管或运行的基础架构。在这些情况下，它与平均恢复/解决/修复时间 (MTTR) 同义。然而，它对数据质量问题的不适用性使其比 MTTR 下降了几个档次。
3. 平均故障间隔时间 (MTBF)
介词有什么不同。平均故障时间 (MTTF) 仅适用于无法修复的硬件，使其成为一个相当小众的指标。与此同时，平均故障间隔时间 (MTBF) 可以应用于可修复的硬件和软件，除非它已被彻底损坏，否则可以重新启动。例如，MTBF 将是跟踪数据应用程序和数据服务器崩溃的重要指标。这种灵活性使 MTBF 成为所有数据团队都应采用的关键指标，以提高团队绩效并改善与业务方客户的关系。
MTBF 不应包括修复硬件或恢复/恢复服务的时间。考虑到这一点，数据工程师将使用诸如 MTBSI（服务事件之间的平均时间）之类的 KPI，其中包括 MTBF 和 MTTR（平均恢复时间）或 MTRS（平均恢复服务时间）。
2. 平均恢复/解决/恢复/修复时间 (MTTR)
每个 R 词之间的差异是微妙的，但在数据上下文中是显着的。您是否正在跟踪将中断的数据管道重新上线需要多长时间？使用恢复或还原。或者您是否需要衡量定位和修复数据错误或其他数据质量问题需要多长时间？使用解决或恢复。
MTTR 包括诊断症状或一般问题、执行根本原因分析 (RCA) 以找到具体原因并修复它的时间。它几乎是 MTRS（平均恢复服务时间）的代名词。
MTTR 可能是 ITOps 和 DevOps 社区中最著名的失败指标。它可用于提高 DataOps 团队的绩效，也可与您的内部用户共享。
也许令人惊讶的是，我只是将它列为数据工程师和其他 DataOps 团队成员的第二重要指标。
1. 平均停机时间 (MDT)
最大限度地减少数据停机时间，无论是由瓶颈还是不可靠的数据引起的，都是最接近数据工程总体目标的事情。零停机时间是目标，尽管这显然实际上是无法实现的，尤其是当您同时包括计划内和计划外停机时间时。平均停机时间也可以反向表示为正常运行时间百分比，目标通常是 99.999% 的可用性或五个 9 的高可用性。
相关帖子DA内容精选
|
京公网安备 11010802022788号
