失败率与延迟比原始计数更有诊断价值

[[业务功能指标能预示故障却不说明原因|业务动作计数]]（比如”用户登录次数”）同时混杂了成功和失败两种结果，如果负责登录的后端服务出问题，这个笼统的计数未必会明显下降——把它拆成登录失败数和登录延迟两个独立指标，诊断能力会显著提高：失败率直接反映功能是否在正常工作，延迟则往往是问题即将发生的早期预警信号，比等到彻底失败才发现问题更主动。把这套”业务KPI→细分为失败率+延迟”的模式套用到每个核心功能点（登录、发帖、投票、购买）上，就能在比笼统计数更细的粒度上持续回答”应用程序是否在正常工作”，而且这类指标不预设具体故障原因，只负责可靠地发出”可能有问题”的信号。