“我们这个服务很稳定。”
听到这句话，客户可能觉得报告每天都能准时收到。开发者想表达的，却只是网页很少打不开。同一句好话，在两个人脑子里对应着不同画面。
所以，稳定需要拆成能说清楚的东西。软件工程里通常会区分三个层次。
一个层次是实际表现：任务成功了多少次，报告平均等了多久。这叫服务指标。
再一个层次是希望达到的标准：在明确的一段时间内，表现应该到哪里。这叫服务目标。
如果双方还约定了达不到标准会有什么后果，那又进入了服务协议的范围。Google 的相关章节对这些概念作了区分。资料：Google
不记英文缩写，也不影响理解。实际成绩、目标成绩，以及没达标时的约定，本来就不是同一样东西。
举个假设例子，一款工具每天给门店生成补货建议。店长八点就开始采购，报告九点才出来，即使当天后来一直能访问，也已经错过了有用的时刻。只统计页面可用率，就可能把这次失败藏起来。
数据新不新也一样。报告准时生成，用的却是前天库存，形式上交了作业，业务上未必能用。指标要贴近客户想办的事，才不会把一张正常运行的页面误认成正常服务。
还有一种错觉来自平均数。大多数人几秒拿到结果，少数人却每次等很久，整体平均仍可能很好看。用户体验分布不均时，一个数字就会遮住特定人群的困难。
分母同样会影响结论。超时后退出的任务算不算失败？一天按自然日统计，还是按营业时段统计？不同口径算出来的比例不一定能比较。如果标准到事后才解释，双方很容易各挑一套有利数字。
我觉得，服务目标的价值不是多出几个专业词，而是让“有多好”有共同含义。尤其在问题发生时，团队知道它是否已经偏离承诺，客户也知道自己买到的保障是什么。
目标不能为了让报表好看，临时往后挪。它可以随业务变化重新约定，却需要让相关的人知道变化。
对那位八点采购的店长而言，最有意义的稳定，仍然是那个具体时刻：他打开工具时，手里有一份足够新、足够可信、能用于当天工作的建议。