IT公司经验研发质量度量
2010-11-22 10:33:48 
阿炯
9 个研发质量度量指标
研发质量管理中的 MTTR、MTBF、MTTF、MTTD 都是什么？这里从生产事件的全生命周期出发，认识研发质量管理的 9 个度量指标 ——「MT 家族」。
1、Mean Time To ALL
「MT」是 Mean Time 的缩写，意为平均时间，「MT 家族」则是 LigaAI 对「MT」开头的一系列量化指标的戏称。
最常用于跟踪研发质量的两个 MT 指标分别是 MTTR 和 MTBF。近几年，随着精细化研发管理需求的攀升，行业也出现了 MTTD、MTTA、MTRS、MTTI 等细分管理指标，旨在帮助技术团队更好地了解生产事件发生的频率以及团队的恢复速度。
2、共识在前，度量在后
在使用「MT 家族」度量质量水平之前，研发团队需要先就两个基础问题达成共识。
如何计算系统的总服务时长？
如何定义系统的可用时间（Uptime）和不可用时间（Downtime）？
明确第一个问题有助于规范讨论对象。系统的服务周期是多长？系统维护升级或提前告知的主动停机等特殊事件应否计入服务时长？研发团队应就以上问题达成一致，才能辅助更准确的度量和管理。
讨论第二个问题的意义在于建立内部一致的判断标准。什么样的事件属于完全中断事件？在部分中断事件中，多大程度的阻碍或多大影响范围的故障可以被定义为「系统不可用」？可正常运行但不符合预期水平的系统是否处在可用状态？
如果能将事件的具体量值和标准讨论并确定下来，研发效能管理或许会有一个更加清晰的视图。
03「MT 家族」全员辨析
下面是单个生产事件从故障发生到修复完成的简要示意图，根据起止时间点的不同，将获得若干个 MT 指标。
温馨提示：研发效能管理下的「MT 指标」或与其他领域的定义有所不同。
1.Mean Time To Detect（MTTD）
平均故障检测时间（MTTD）是系统出现故障到问题首次被发现的平均时间，用来衡量问题在被发现前存在的平均时长，可以用一定周期内的事件总检测时间除以事件总个数计算得出。
系统出现故障后，生产事件可能会被监控工具或观测平台快速识别并自动提醒，也可能被用户率先发现。因此，对问题识别得越慢，MTTD 越大，用户可能遭受中断的时间也会越长。
2.Mean Time To Acknowledge（MTTA）
平均应答时间（MTTA）衡量了系统不可用被首次发现后，研发团队平均需要多久能够着手修复问题，反映了团队的响应能力和警报系统的效率。定期监控 MTTA 对减少警报噪音，提高工作效率也有显著作用，因为居高不下的 MTTA 可能说明研发团队正在被「警报疲劳」所困扰。
MTTA = 故障首次被发现到开始修复的总间隔时间/事件总数。
3.Mean Time To Repair（MTTR）
根据「R」的不同释义，MTTR 可以表示为平均修复时间、平均恢复时间、平均响应时间和平均解决时间。四者在含义上皆有不同，因此在日常工作和沟通中，要小心上下文缺失导致的「鸡同鸭讲」哦！
平均修复时间衡量了研发团队排除和修复故障的效率，是指开发团队从开始修复到系统恢复正常运行的平均时间，包含修复、测试、部署等多个环节。可以用一定周期内的系统总修复时长除以事件总个数得出。MTTR 越小，说明系统的可维护性越强，易恢复性越好。此外，由于系统复杂情况或故障严重程度各不相同，技术管理者在实际管理中也要避免掉入「数字管理陷阱」。
MTTR = 开始修复到恢复可用状态的总间隔时间/事件总数。
4.Mean Time To Recover（MTTR）
平均恢复时间也称平均服务恢复时长（Mean Time To Restore Service, 即 MTRS），也是 DORA 指标中的「服务恢复时间」。
它衡量了系统从不可用状态恢复到正常可用状态的平均耗时，在数值上与系统的平均不可用时长相等，包含研发团队监控、定位、识别和解决故障等多个过程。经验法则指出，优秀的研发团队每年的平均恢复时间一般不超过 5 个小时。
MTTR 或 MTRS = 系统总不可用时间/事件总数。
5.Mean TimeTo Respond（MTTR）
平均响应时间是指系统不可用状态从被发现到被解决的平均时间，反映了研发团队响应需求和变化的效率以及系统可维护性的高低。平均响应时间不考虑事件通知的延迟性，常在网络安全中用来衡量团队缓解系统攻击的效率。
MTTR = 故障被发现到系统恢复可用的总间隔时间/事件总数。
6.Mean Time To Resolve（MTTR）
平均解决时间衡量了故障出现到被彻底解决所花费的平均时间。「彻底解决」意味着该故障在未来的运行中不会再现，因此平均解决时间需要统计研发团队发现问题、检测故障、修复故障以及确保故障不会再发生等环节的总时间。
MTTR = 故障出现到彻底解决的总间隔时间/事件总数。
7.Mean Time Between Failure（MTBF）
平均无故障时间（MTBF）是衡量系统可靠性和可用性的关键指标之一，指可修复系统在运行期间从前一个故障（结束）到下一个故障（出现）所经历的平均时间，代表了系统的平均可用时间。
MTBF 越大，说明系统持续提供正确服务的时间越长，可靠性越强。通过计算一定周期内的 MTBF，研发团队还可以对未来故障的发生时间展开预测，以便更好地管理。
MTBF = 连续两次事件的总间隔时间/事件总数。
8. Mean Time To Failure（MTTF）
与 MTBF 相似，平均失效时间（MTTF）也是衡量系统可靠性的关键指标；二者的区别在于，MTTF 用于衡量不可修复的系统，而 MTBF 的管理对象是可修复的系统。
MTTF 是指不可修复的系统或产品从开始运行到发生故障而终止服务的平均时间，可以简单理解为平均使用寿命。相比软件研发行业，MTTF 更常用来描述硬件、组件或基础设施等等。
其管理价值在于通过对大量相同类型的系统或产品进行更长周期的观察和统计，团队可以了解该类型系统/产品的失效时间，并率先为淘汰和更换旧系统/产品做好准备。
小结
速率、质量和价值是研发效能管理的三驾马车。而相较速率而言，研发质量管理对团队共识的要求更高，因为我们需要通过集思广益，描绘一个线条干净、指标区隔清晰的质量评估视图，以进一步支持无歧义的指标量化管理；否则，研发效能管理最终又会回到让人头疼的「定义讨论会」。所提到的 9 个「MT 指标」可以从系统可靠性、可用性和可维护性等多个维度，衡量研发质量水平并辅助技术管理者展开更精确、更精准的研发质量监控和管理，进而有效提升组织效能，赋能业务增长。
高级开发人员要了解的高并发性能指标
QPS
QPS(Queries Per Second)即每秒查询率，是指一台服务器每秒钟能够支持的查询操作次数，为什么要定义这样一个标准呢？这个标准可以用来衡量服务器在规定的时间内的流量处理能力，而这里的流量其实就是指系统能够支持用户请求访问。在互联网环境下，QPS经常被用来定义域名服务器的机器性能，通俗来讲就是系统能够处理用户请求的能力。
TPS
TPS(Transaction Per Second)即每秒处理事务率，也就是每秒能够处理事务的个数。它是测试应用软件性能的标准之一。所谓的事务，其实就是指计算机所要完成的业务操作，例如转账、添加订单、扣减库存等等。也就是说当用户向服务器发送请求之后，服务器做出反应并且反馈到用户的整个过程，其实就可以被称为是一个事务操作。通过对TPS的统计可以有效的反映出业务系统处理事务的能力。
其实当我们的业务系统在处理用户请求的时候，QPS与TPS应该是相当的，也就是有多少个用户请求，就有多少个用户业务处理。但是有所不同的是，当用户点击了下单按钮之后，在用户看来只是单纯的下单也就是一个TPS操作，但是对于后台处理来说的话就有可能会调用订单系统、调用库存系统、调用其他一些业务判断系统例如减扣、优惠券等等。而这些处理就可以计入到QPS中。也就是说一个TPS中有可能会包含多个QPS。
RT
RT(Response Time)即响应时间，所谓的响应时间其实就是用户从发出一个请求到接受到请求响应的总时长。也就是说用户在浏览器中请求了一个商品详情信息，经历多少时间之后这个商品信息才渲染到用户页面上。这个指标主要用来反应系统的快慢，如果响应时间小的话，就说明系统反应较快，反之，则表示系统中存在了耗时操作，这个时候就需要对系统性能进行优化了。
并发数
并发数其实对大家来说是不是一个陌生的概念，并发数是指系统在同一时间能够处理多少个请求。侧面反映的就是系统的负载能力，举个简单的例子，很多人可能都经历过春运，我们知道在春运期间，火车站不但挤满了人，而且还挤满了火车，如果将火车站看做一个能够处理火车停靠的应用的话，并发数就相当于车站能够用来停靠火车的站台有多少，也就是说同时能够允许多少列火车停靠。这也就是这个车站最大的能够负载的能力。超过这个负载能力肯定火车是没地方停靠的。软件系统并发数的概念与之类似，如果超过了并发数，系统肯定会崩溃的。
吞吐量
系统的吞吐量是用来反映系统能够承载多少的用户请求压力。与用户请求、CPU处理能力、IO操作等等都有关系。简单的举个例子，在春运期间，一个车站的吞吐量就是指这个车站能够收发多少人员。如果我们将一个旅客看做一个用户请求的话，能够体现其吞吐量的因素应该有如下的几个：
1、能够处理请求的效率，也就是上面提到的QPS。
2、同时能够处理多少的请求，也就是上面提到的并发数。
3、就是系统的处理时间，也就是上面提到的响应时间。
这三个因素应该是共同影响这个系统的吞吐量的因素。如果是一个系统的QPS是100的话，也就是说它一秒之内能够处理100个请求。就可以理解为这个系统的并发数就是100。也就是说如果一个系统在一分钟之内处理了6000个请求，那么它一秒钟所处理的请求数就是100个。根据这个关系，我们就可以明确的感觉到系统吞吐量其实就是系统的整体性能的体现，包含了QPS、TPS、RT等一系列的参数。
PV
PV(Page Views)一般是指页面访问量，包含了用户对应用系统任意页面的访问量。例如当浏览了一个商品详情页的时候，就可以被记为一次PV。
线程数
线程数，也可以理解为并发数，也可以理解为QPS数，为什么这么说呢？了解Request请求原理，或者是了解过I/O模型的可能都清楚，我们的线程是不可能一直被无限创建的，并且一个系统所能创建的线程数是有限制的，超过限制就会导致系统异常。这里我们为什么说可以理解为QPS也可以理解为并发数呢？是因为当用户请求发送到服务器之后，会有一个线程来处理相应的请求。在多线程场景中，影响并发、影响QPS就是线程数的多少，在可控范围内一个系统所能创建的线程越多，就说明系统处理能力就越强。
简单的例子，当春运的时候我们的购票窗口往往都是排着长队的，那么这个时候，我们需要增加购票窗口，增加窗口之后，明显就感觉到买票的时间会缩短，并且窗口越多服务能力就越强。但凡事都有个限度，当我们超过了限度之后，就会适得其反。当然系统也是一样的。
有了上面的参数分析，我们可以得到如下的几个结论。
QPS/TPS = 并发数/RT
并发数=QPS*RT
QPS=PV/总时间
根据这些公式，结合上面的理论支持，就可以有效的进行计算机资源的分配，也可以根据上面的这些参数，来计算出系统的整体综合性能了。
稳定性建设工程之 SLA 浅述
在众多云服务提供商的套餐和支持方案中进行比较和选择；或是作为企业的采购负责人，评估外部供应商提供的服务系统是否满足企业业务需求和发展目标；亦或是公司内部服务平台的技术运维人员，需要评估系统的实际性能和边界条件，以判断其是否能够满足内部业务部门的要求并提供相应的保障承诺....... 所有这些场景都离不开一个关键概念：服务等级协议（SLA，Service-Level Agreement），而你打开任意一家云服务厂商的官网，你都能在产品页面中找到一份公示的 SLA。
在上述场景中，显然具备三个核心组成要素，即围绕 SLA 的上下游存在着两类角色，分别是服务提供方（SP，Service Provider）和服务客户（SC，Service Consumer），如下图所示：
图 1 SP -> SLA -> SC
形式上来说，SLA 是指系统服务提供者对客户的一个可量化服务承诺和协议，它是将服务质量评估从经验模型向量化模型转变的关键工具。SLA 通常明确列出了服务可用性、数据可靠性、响应时间等服务特性指标及其定义，服务提供方基于这些指标对客户做出量化承诺。此外，SLA 中还详细说明了服务提供方未满足承诺时的补偿操作（后果），例如提供额外支持、优惠折扣或钱款赔偿。通常，SLA 是在客户和外部服务提供商之间达成，但同一公司内的不同部门也可以相互签订 SLA，此时未满足 SLA 承诺的后果一般不涉及经济赔偿，而侧着于业务责任划分。
需要注意的是，SLA 的生命周期并不像图 1 所示的那样呈现单向、一次性或静态的特征。相反，它是一个双向、持续且动态的反馈和调整过程。在这个过程中，客户的需求可以通过 SLA 反向推动服务提供者进行系统设计和迭代决策。实际上，围绕 SLA 的生命周期，图 1 可以进一步优化为图 2 所示的形式：
图 2 SLA 生命周期
为了完全理解上图，我们需要了解一些 SLA 中的特别概念：
1. SLA 常见概念
SLI（Service Level Indicator）服务等级指标：SLI 指定了 SLA 中所提供服务某一维度的可量化指标，且必须具有清晰严谨的定义和计算方式。比如，对于某一网站的单实例服务器，一个简单的 SLI 定义是由客户端所发出合法的请求得到正常响应的百分比，合法的定义是请求参数和资源类型能够被服务端约定的协议解析成功，正常响应的定义是请求结果中不包含超出协议约定的错误或非预期数据。
SLO（Service Level Object）服务等级目标：SLO 明确了 SLA 中所提供服务某一维度的期望状态，是围绕 SLI 构建的目标。SLO 是客户感知和判断服务质量最为直观的方式，常见的说法如 “XX 可用性达到几个 9” 就是一种 SLO。规范来说，SLO 有指标范围和实现时间要求，这意味着在特定时间窗口内（通常是服务周期），涉及的 SLI 必须达到预定的指标标准，并且在该时间段内的实现比例应达到预期。如果未能达到 SLO，则应触发 SLA 中定义的后果，一般为对 SLA 中服务提供方的惩罚以及对客户的补偿方案。
例如，在单实例工作负载小于 10,000 TPS 的条件下，指定服务的平均请求响应时间应小于 85 毫秒，且响应有效率需超过 95%。承诺在一个月的服务周期内，这些指标的达成时间比例应超过 99.9%。若未满足上述服务等级目标，则将提供相当于服务费总额 20% 的代金券作为补偿。
因此，可以简单理解为：SLA = SLO + 后果 = SLI + 实现指标和时间占比要求 + 后果。可以看出，服务 SLA 是众多云厂商获取客户青睐和信任的有效竞争手段和必要承诺。通过明确服务质量的量化指标、期望目标以及未达成目标时的补偿措施，SLA 有助于建立客户与服务提供商之间的信任关系，并在竞争激烈的市场中提升服务商的竞争力。
此外，部分云厂商也提出了一些其他概念：
1).SLA 规则：是在 SLA 指标（SLI）的基础上，添加了判断条件，以触发告警或停止压测。这些规则可以帮助在服务性能偏离预期时及时识别问题，确保服务稳定性。
2).SLA 模板：是 SLA 规则的集合，可包含一个或多个 SLA 规则。SLA 模板通常与行业、业务类型绑定。通过使用 SLA 模板，组织可以快速应用符合其特定需求的服务等级协议规则集，从而提高管理效率和一致性。
3).SLA 拓扑，也称为 SLO 拓扑，指的是当服务足够复杂，链路中涉及多个子服务及其 SLO，评估和计算整体服务 SLA 所需的依赖路径关系。
2. SLA 基本要素组成
基于以上概念，当你作为某项服务系统的提供方起草一份规范的对外 SLA 时，通常需要包含但不限于以下内容：
协议概述：概述中应明确 SLA 的起始和结束日期、参与协议各方的详细信息，以及所涉及服务的简要说明。例如，协议可能会详细列出服务提供商和客户的联系信息和角色定义。
服务描述：这一部分应对 SLA 涵盖的所有服务进行详细描述，包括关键概念定义。例如，可以包括服务的周转时间、支持的技术和应用程序、计划的维护周期，以及相关流程和程序。
服务等级目标：明确协议中关于特定服务等级指标（SLI）的目标，例如服务可用性或平均响应时间。协议双方同意使用数据支持的关键服务指标来评估这些目标的达成，例如保证 99.9% 的服务可用性。
故障恢复流程：详细说明故障告警和恢复流程，概述供应商在发生服务故障时应遵循的机制和流程。这部分可能包括约定的响应时间（RTO）和恢复时间目标（RPO）。例如，故障报告后 1 小时内开始响应，4 小时内完成数据恢复。
安全标准：协议须明确约定双方采取的安全标准和措施，例如数据私密性、权限控制和安全审查流程，以确保服务的安全性。
排除条款：此部分描述双方商定的所有排除和豁免情形。例如不可抗力事件或第三方故障导致的中断不在服务承诺范围内。
惩罚与补偿：此部分明确规定未能履行 SLA 义务时的后果，例如给予客户相应的服务费退款或代金券作为补偿。
终止流程：双方可能会在某个时间点想要终止协议。除了任一方要求的通知期以外，SLA 还会清楚地规定允许终止或使协议失效的各种情形。
变更与审查流程：服务提供商能力、工作负载和客户要求会随着时间的推移而变化，因此需要定期审查服务商提供的 SLA 。有关服务商或客户要求的任何重大更改，需要被记录在协议当中，确保透明与合规，从而 SLA 能够整合服务提供商产品或服务的最新功能来满足当前的客户需求。
签名：该协议由双方授权的利益相关者审查文档中有关各事项后进行签署，在协议生效期间约束所有相关方遵守协议条款。
3. SLA 常见指标
3.1 服务可用性（Availability）
在各类系统服务的 SLA 中，服务可用性是最常见的指标之一。服务可用性指的是服务提供商在特定时间段内保持其服务可供使用的时长。这一指标通常以特定时段（称之为服务中周期）来衡量，并需要明确界定何为 "服务不可用"。例如，SLA 可能规定服务提供商的系统在每天内必须保持 99.5% 的可用性，这意味着每 24 小时，服务不可用的总时长不应超过 7.2 分钟。在计算服务可用性之前，先介绍如下几个定义：
1).平均故障间隔时间（MTBF）：是指服务相邻两次故障之间的平均时间
MTBF = 总运行时间 / 故障次数
2).平均故障修复时间（MTTR）：是指服务发生故障后，从故障发生到恢复完毕的平均时间。
MTTR = 故障恢复总时间 / 故障次数
3).平均正常运行时间（MTTF）：是指服务在无故障状态下能够持续运行的平均时间。该指标通常只用于不可修复的系统，也即代表了服务的期望寿命。
从而，可以计算得出服务可用性，给出了一个简单的例子：
Availability = MTTF /（MTBF + MTTR）
图 4 可用性计算简化案例
在大多数云产品的对外 SLA 中，一般以服务周期为评估单位，因此服务可用性采用了一种对客户更直观的表达方式来申明：
服务可用性 =（服务周期总时间 - 服务周期服务不可用时间）/ 服务周期总时间 * 100%
其中，服务不可用的具体定义取决于不同产品的 SLA 声明。基于以上计算原则，服务可用性 SLO 中服务周期选取与不可用时长的关系可由下表列出：
3.2 数据可靠性（Reliability）
通常针对存储系统设置，指的是数据在存储、传输和处理过程中保持准确性和完整性的能力。被视为可靠的数据将承诺不会丢失、损坏或被未经授权的修改。更细致的又可以分为数据持久性、数据一致性、数据可用（访问）性等等：
数据持久性：指的是数据在存储后能被长期保存的能力，不会因为断电或系统崩溃等问题而丢失。
数据一致性：指的是在数据存储和处理过程中，数据在多副本或多系统之间的状态保持一致的能力。
数据可用性：指的是用户能够访问和使用数据的能力，与服务可用性类似。高数据可用性意味着系统即使在系统发生部分故障或维护期间，在需要时也总是能够提供数据访问。
举个例子，某云服务厂商的对象存储服务承诺可提供 99.9999999999%（12 个 9）的数据持久性，这意味着，存储一万亿个对象大概只会有 1 个文件是不可读的。一般来说，数据可靠性可宽泛定义为数据在系统中确认存储成功后不丢失 / 不损坏的概率。影响数据存储的原因可分为三类：
硬件级故障：例如磁盘损坏、电源故障、内存故障以及网络设备失效等
软件级故障：例如消息队列中的实现 bug / 死锁可能导致数据未能正确传递或处理，在某些情况下，消息可能未实际写入内存或磁盘，但系统已经向客户端发送了成功确认（ACK）
人为故障：例如错误配置、数据误删除、运维误操作或执行脚本不当等
数据可靠性计算相对服务可用性计算复杂很多，需要依据专门的量化模型计算。如果仅考虑硬件级故障，可参考如下模型来量化一个存储系统的年度数据可靠性：
Reliability = Func(N，R，MTTR，CopySets，D，AFR)
其中，N 是存储系统磁盘的总数；R (Replications) 是单块磁盘配置的副本数；MTTR 为磁盘故障平均修复时间；CopySets（副本数据复制组）是分布式存储系统中对一份数据的所有存储副本的分组集合，这里取 CopySets 的模，例如一份数据写入到了 p1，p2，p3 盘，那么 {p1, p2, p3} 就是一个 CopySet，当该 CopySet 损坏，则这份数据丢失。CopySet 可以用于衡量数据副本存储的离散分布程度，且满足：
N/R <= |CopySets| <= C(N, R)
其中 C 是组合计算符，当数据存储分布越分散随机，那么同时损坏 R 个盘时会完全丢失某份数据的概率就越高，而 |CopySets| 越接近 N/R，那么发生损坏时丢失的数据量越高，恢复时间和成本也会攀升，因此 CopySet 的生成策略十分考验技巧；D (Distributions) 是预设的故障概率分布模型，常见有二项分布、泊松分布等；AFR（Annualized Failure Rate) 是磁盘的年故障率，其定义为：
AFR = 1 / (MTBF / (24 * 356)) * 100%
从模型组成因子的定义直观来看，AFR、MTTR 和 CopySets 的模与数据可靠性负相关，而磁盘总数和副本数与可靠性正相关。但实际情况并没有这么简单，每项因子对可靠性的贡献可能并不是线性或连续的，因子之间也并不完全独立，例如 AFR 与 MTBF 相关，而 MTTR 也受 Replications 和 CopySet 分布策略的影响。由于可靠性模型的具体推导计算过程超出本文篇幅，感兴趣的读者可以移步参考文献 [4][5]。
3.3 请求错误率 (Error Rate)/ 成功率 (Success Rate)/ 可用率 (Availability Rate)：
这三个指标在大多数服务中是客户使用感知最为明显的，通常关注的粒度为服务的接口级别，而服务可用性则是更多侧重评判服务整体的质量。一个常见的场景是，客户端定时监控某项服务请求的错误率，以此衡量服务的某项功能或者子集是否低于 SLA 中的预期目标。
以错误率计算方式为例：
错误率 = 1 - 成功率 = 时间片内导致系统产生错误的请求数 / 该时间片内的请求总数 * 100%
可用率：可用率在语义上不同于成功率，它要求服务请求的响应正确且有效，并且通常会排除非服务端导致的错误，例如客户端非法参数、权限拦截，服务外部前置链路的限流等等。
这三个指标通常以时间片进行周期计算，例如每 1 分钟错误率、每 5 分钟成功率等等
3.4 吞吐量 (Throughput)：
指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。吞吐量指标一般包括 QPS（Query Per Second，每秒处理请求数），TPS（Transaction Per Second ，每秒处理事务数）等。
QPS 指系统每秒能处理的请求（查询）数，通常用于衡量服务器能抗多少流量：
QPS = 时间片内请求总数 / 时间片秒数
TPS 指系统每秒能处理的事务数。这里事务是指一个完整的业务处理和响应过程，可能对系统发起多个 QPS 中定义的请求：
TPS = 时间片内事务总数 / 时间片秒数
以上计算通常针对网站或者业务系统，对于数据库（例如 MYSQL）等其他类型服务而言，除了有更区别细化的定义，还会关心 IOPS（Input/Output Per Second，磁盘每秒读写次数）等 SLI。
3.5 响应时间 / 延迟（Latency）：
指系统在收到用户的请求到响应这个请求之间的时间间隔，系统的延迟指标通常与服务的性能、吞吐量等指标相关。该指标通常会以时间片平均或者百分比的方式计算，并且与采点方式、点位选择强相关：
平均值：此方法通过计算所有请求的平均响应时间，判断是否低于设定阈值。但这只能作为一种较为宏观的评估方式，对于波动型的系统状态或者对半的响应时间分布情况，会掩盖许多问题。
百分比：我们也经常会在 SLA 中看见 p95 或者是 p99 这样的延迟声明，其中 p 指的是 percentile（百分位）。当系统的 p95 延迟为 1 秒，意味着 95% 的请求响应时间小于 1 秒，而剩余 5% 的请求则超过 1 秒。
3.6 其他
此外，SLA 中通常还会涉及如下指标：
故障频率和恢复：通常涉及服务可用性中提到的 MT 类型指标，例如代表故障平均恢复时长的 MTTR 等，部分 SLA 会单独针对这些指标做出承诺，以便故障发生时客户能有明确的修复耗时预期。
服务支持：通常包含服务提供商提供的技术支持、客户服务等方面的指标。例如，在运营云服务时，可要求服务提供商提供 24 小时客户服务、及时响应客户请求等。例如，某云服务商提供 8:00-24:00 的在线服务支持，并提供全天 24 小时的服务热线。
安全性：为了证明服务提供方会采取预防性措施来减少非安全操作和数据泄露，可量化、可控制的安全指标（如加密可靠性、防病毒更新和补丁等）是许多云服务厂商都必须面对的问题。
业务绩效目标：该指标通常关联服务提供方或者客户业务方的绩效标准。在公司内部的双方合作部门 SLA 签订中，常见的形式是服务周期内 xx 业务无 x 级以上故障。
其他特殊服务/中间件的定制指标
4. 制定 SLO 时需要考虑什么
4.1 制定并量化统计 SLI
在制定服务等级目标（SLO）时，准确统计和量化服务等级指标（SLI）是首先考虑的。如何有效采集和计算 SLI，将直接影响 SLO 的合理性和可达成性，一般需要考虑如下方面：
了解客户群体：明确服务的目标客户群体，在制定 SLI 时，需要提供简明、清晰且无歧义的定义，使客户能够快速理解并达成共识。我们不应追求 SLI 的数量和复杂度，而应重点关注客户真正关心的业务价值和服务使用体验。例如，对于电商平台，下单成功率就是一个关键 SLI。
反映系统性能和架构：SLI 指标应该反映系统的实际性能和可用性，同时采集和计算过程尽量减少对系统的侵入，对于通用型指标可以组装为 SLI 规则和模版。例如，选择可以通过现有监控工具轻松获取的响应时间或错误率指标。
计算和采集：优先选择可以简单采集且能够正确、准确量化的指标。SLI 的统计可以在用户端（Client-side）和服务提供方（Server-side）进行，常见的统计方式包括客户端埋点数据上报、服务端日志采集分析、探针巡检、时序数据库指标采集等。目前各大厂或云服务厂商都有成熟的中间件或产品方案，例如 ARMS；或是基于开源的 Prometheus、HertzBeat 等等二次开发搭建，进行在线或离线的指标采集和计算聚合。然而，无论采用何种方式，指标采集过程都应避免对服务性能和可用性产生负面影响。确保监控工具和策略设计规范，避免在采集数据时影响服务质量本身。
4.2 SLO 计算和聚合模型
SLO 的通用计算模型一般由 SLI、服务周期、服务拓扑链路组成。根据服务自身场景定义出不同维度的 SLI 并采集计算后，可以汇集出 SLO 的情况。SLO 的计算和聚合规则通常如下：
小周期评判：将服务周期（通常是自然月）拆分为多个小周期，以 “服务可用性 99.95%” 这一 SLO 为例来说，周期性地计算小周期中的服务可用时长是否达成 99.95% 占比，如果未达到，则标记此周期不可用。考虑到 SLI 的数据分析粒度和趋势平滑性，小周期的设定时长通常不高于 30s。
计算达成时间占比：计算整个服务周期 N 内，达标小周期时间的占比，从而得到服务的实际 SLO 水位：
SLO = ∑ SLI 达标小周期时长 / 服务周期总时长
SLO 拓扑聚合：如果服务涉及到多条链路，每条链路可拆分多个子服务，并对应有其 SLI、SLO，则需要聚合出服务的总 SLO
串联型：服务拓扑链路中，各服务是串型依赖关系，某一子服务出现不可用，将导致整个服务不可用。以服务可用性为例，串联服务可用性计算公式为：
串联服务可用性 = 子服务 1 可用率 * 子服务 2 可用率 * ....
并联型：服务拓扑链路中，不存在单点依赖，某一子服务不可用不影响整体服务可用性。以服务可用性为例，串联服务可用性计算公式为：
并联型服务可用性 = 1 - （子服务 1 不可用率 * 子服务 2 不可用率 * ...）
混合型：目前多数云产品都是以混合型的方式提供产品 SLA，服务链路中同时存在串联和并行拓扑。此时，服务可用性计算依赖具体的拓扑链路分析，如图 4 所示。可以看出，拓扑链路中横向增加单点依赖子服务会导致 SLA 降低，而纵向增加并行冗余服务，则会提高 SLA，同时冗余的维护成本也会相应增加。
图 5 SLA 拓扑类型举例
集群 SLO 计算：多数时候服务以集群形式对客户提供访问，假定集群中每个实例在流量路由和 SLO 链路上是完全独立的，则可分开计算每个集群的 SLO。对于单个集群，假设集群由 N 个实例节点组成，则可参照小周期的方式计算特定时间片内的集群 SLO：
集群 SLO = 1 - ∑ SLI 未达标实例数 / 集群总实例数
当然，以上只是一个简化的模型，真正的服务链路场景要复杂得多，因此需要因地制宜进行 SLO 的建模和计算。
4.3 设定 SLO 阈值和分级告警
在梳理出系统需要关注哪些 SLI 和量化 SLO 后，需要考虑一个现实的问题，SLO 的阈值应该如何设置？一般而言，SLO 阈值确定需要包括但不限于以下规则：
灵活应对变化：首先要认识到，阈值设置不存在银弹，并没有 “一劳永逸” 的解决方案。由于服务系统的状态和客户需求会随时间发生变化，SLO 阈值应是一个动态调整修正的过程。这意味着需要不断监测和修正，以确保其始终贴合实际情况。
基于实际性能分级设定阈值：确定 SLO 阈值时，应基于系统的当前实际性能水平。设定阈值时不能过于保守，以免低于系统能力，也不能过于激进，做出难以实现的承诺。在设定阈值前，应对系统进行充分的测试和验证，以了解其在长期和高压力条件下的表现。此外，应留有一定的安全空间，使内部的实际 SLO 略高于向外承诺的 SLO。一般来说，需要根据业务实际情况设定 warning，critical 和 urgent 三级告警，并配置相关触发动作。
结合客户场景进行优化：SLO 阈值的设定需考虑服务的实际客户业务场景、基数和业务价值，而不仅仅是基于系统当前性能和指标达成的小数点数位。例如，在电商交易场景中，如果系统支持单日 99.99% 的订单成功率，而这意味着 100w 订单中就有 100 笔失败订单，需要分析这些失败订单的发生原因、时段和用户影响，判断是否需要调整 SLO 并升级系统架构。同样，对于网站请求延时指标，若设定 p99 延时为 1 秒，而在 1 亿次请求中有 10 万次超过 1 秒，如果这些请求对应的是延时敏感的用户群，则尽管符合 SLA 的阈值设定，SLO 可能仍需优化。
4.4 错误预算
设定完 SLO 阈值，在系统开始提供服务之后，SRE 团队通常需要密切关注一个重要指标：错误预算（Error Budget ），它不仅反映了服务 SLO 的履行情况，还对团队的开发策略起着关键调节作用：
错误预算量化了在特定时间范围内可接受的服务失效或不符合服务水平目标（SLO）的程度，其计算方式依赖于 SLO：
计算方式：服务周期窗口总值 *（1 - SLO）
例如，对于服务可用性 99.99% 这一 SLO，则服务周期内错误预算为：服务周期总时间 * （1 - 99.99%）
协调与平衡：错误预算为团队提供了在服务维护和功能开发之间做出平衡的依据。若错误预算未被耗尽，团队可以在保证可靠性前提下进行更多的创新和功能开发，否则团队需避免任何可能突破 SLO 的功能升级或变更，以规避风险。
图 6 错误预算如何平衡服务的稳定性和迭代
监控与反馈：定期监控和评估错误预算的使用情况，确保团队能够及时应对服务质量的偏差，并及时做出相应的改进措施。例如，服务投入生产环境不足一周就消耗了 30% 的错误预算，那么开发团队需要及时对服务架构的合理性做出审视，至少要提前做好突破 SLO 的兜底应对链路，再寻求合适时机对服务进行敏捷的升级变更。
4.5 考虑成本和收益
当系统平稳持续运行一段时间后，客户业务诉求可能会（一定会）迎来变化。当判断决策需要为此调整 SLO 时，应当谨慎考虑投入成本和收益的比例关系。需要提高 SLO 阈值标准时，通常需要分析当前系统现状无法满足的原因：
历史技术债：系统当前架构设计存在既有缺陷
新的诉求和挑战：客户基于场景协商提出了更高要求
同时，系统地梳理成本投入项：
基础设施成本：评估主要系统和服务所需的硬件、软件和网络资源，包括云服务费用和维护成本。
人力资源成本：计算与服务交付相关的人员成本，包括运维团队的工资、培训费用以及人员流动带来的潜在成本。
运营成本：分析系统投入生产运行中的开销，如监控工具、备份兜底链路等。
过程中尽量遵循一个原则：增加维护资源和成本来提高服务质量带来的收益应大于将资源投入到其他地方带来的收益。例如，对于公司内部服务于业务的中台服务，服务可用性从 99.99% 提高到 99.999% 所需要的资源和带来的业务价值、服务业务数的增量之比，是决定该服务是否投入资源进行提升改造的核心判断准则。当效益比过低，则应当考虑其他达成业务目标的路径。当资源有限时，应当划分不同级别的业务，对重点业务倾斜资源进行高 SLA 保障。同时也要考虑不同客户 / 业务群体需求水位不一致、服务费存在差别（对外商业化时）的客观情况，提供分档位的 SLA。
研发质量管理中的 MTTR、MTBF、MTTF、MTTD 都是什么？这里从生产事件的全生命周期出发，认识研发质量管理的 9 个度量指标 ——「MT 家族」。
1、Mean Time To ALL
「MT」是 Mean Time 的缩写，意为平均时间，「MT 家族」则是 LigaAI 对「MT」开头的一系列量化指标的戏称。
最常用于跟踪研发质量的两个 MT 指标分别是 MTTR 和 MTBF。近几年，随着精细化研发管理需求的攀升，行业也出现了 MTTD、MTTA、MTRS、MTTI 等细分管理指标，旨在帮助技术团队更好地了解生产事件发生的频率以及团队的恢复速度。
2、共识在前，度量在后
在使用「MT 家族」度量质量水平之前，研发团队需要先就两个基础问题达成共识。
如何计算系统的总服务时长？
如何定义系统的可用时间（Uptime）和不可用时间（Downtime）？
明确第一个问题有助于规范讨论对象。系统的服务周期是多长？系统维护升级或提前告知的主动停机等特殊事件应否计入服务时长？研发团队应就以上问题达成一致，才能辅助更准确的度量和管理。
讨论第二个问题的意义在于建立内部一致的判断标准。什么样的事件属于完全中断事件？在部分中断事件中，多大程度的阻碍或多大影响范围的故障可以被定义为「系统不可用」？可正常运行但不符合预期水平的系统是否处在可用状态？
如果能将事件的具体量值和标准讨论并确定下来，研发效能管理或许会有一个更加清晰的视图。
03「MT 家族」全员辨析
下面是单个生产事件从故障发生到修复完成的简要示意图，根据起止时间点的不同，将获得若干个 MT 指标。
温馨提示：研发效能管理下的「MT 指标」或与其他领域的定义有所不同。
1.Mean Time To Detect（MTTD）
平均故障检测时间（MTTD）是系统出现故障到问题首次被发现的平均时间，用来衡量问题在被发现前存在的平均时长，可以用一定周期内的事件总检测时间除以事件总个数计算得出。
系统出现故障后，生产事件可能会被监控工具或观测平台快速识别并自动提醒，也可能被用户率先发现。因此，对问题识别得越慢，MTTD 越大，用户可能遭受中断的时间也会越长。
2.Mean Time To Acknowledge（MTTA）
平均应答时间（MTTA）衡量了系统不可用被首次发现后，研发团队平均需要多久能够着手修复问题，反映了团队的响应能力和警报系统的效率。定期监控 MTTA 对减少警报噪音，提高工作效率也有显著作用，因为居高不下的 MTTA 可能说明研发团队正在被「警报疲劳」所困扰。
MTTA = 故障首次被发现到开始修复的总间隔时间/事件总数。
3.Mean Time To Repair（MTTR）
根据「R」的不同释义，MTTR 可以表示为平均修复时间、平均恢复时间、平均响应时间和平均解决时间。四者在含义上皆有不同，因此在日常工作和沟通中，要小心上下文缺失导致的「鸡同鸭讲」哦！
平均修复时间衡量了研发团队排除和修复故障的效率，是指开发团队从开始修复到系统恢复正常运行的平均时间，包含修复、测试、部署等多个环节。可以用一定周期内的系统总修复时长除以事件总个数得出。MTTR 越小，说明系统的可维护性越强，易恢复性越好。此外，由于系统复杂情况或故障严重程度各不相同，技术管理者在实际管理中也要避免掉入「数字管理陷阱」。
MTTR = 开始修复到恢复可用状态的总间隔时间/事件总数。
4.Mean Time To Recover（MTTR）
平均恢复时间也称平均服务恢复时长（Mean Time To Restore Service, 即 MTRS），也是 DORA 指标中的「服务恢复时间」。
它衡量了系统从不可用状态恢复到正常可用状态的平均耗时，在数值上与系统的平均不可用时长相等，包含研发团队监控、定位、识别和解决故障等多个过程。经验法则指出，优秀的研发团队每年的平均恢复时间一般不超过 5 个小时。
MTTR 或 MTRS = 系统总不可用时间/事件总数。
5.Mean TimeTo Respond（MTTR）
平均响应时间是指系统不可用状态从被发现到被解决的平均时间，反映了研发团队响应需求和变化的效率以及系统可维护性的高低。平均响应时间不考虑事件通知的延迟性，常在网络安全中用来衡量团队缓解系统攻击的效率。
MTTR = 故障被发现到系统恢复可用的总间隔时间/事件总数。
6.Mean Time To Resolve（MTTR）
平均解决时间衡量了故障出现到被彻底解决所花费的平均时间。「彻底解决」意味着该故障在未来的运行中不会再现，因此平均解决时间需要统计研发团队发现问题、检测故障、修复故障以及确保故障不会再发生等环节的总时间。
MTTR = 故障出现到彻底解决的总间隔时间/事件总数。
7.Mean Time Between Failure（MTBF）
平均无故障时间（MTBF）是衡量系统可靠性和可用性的关键指标之一，指可修复系统在运行期间从前一个故障（结束）到下一个故障（出现）所经历的平均时间，代表了系统的平均可用时间。
MTBF 越大，说明系统持续提供正确服务的时间越长，可靠性越强。通过计算一定周期内的 MTBF，研发团队还可以对未来故障的发生时间展开预测，以便更好地管理。
MTBF = 连续两次事件的总间隔时间/事件总数。
8. Mean Time To Failure（MTTF）
与 MTBF 相似，平均失效时间（MTTF）也是衡量系统可靠性的关键指标；二者的区别在于，MTTF 用于衡量不可修复的系统，而 MTBF 的管理对象是可修复的系统。
MTTF 是指不可修复的系统或产品从开始运行到发生故障而终止服务的平均时间，可以简单理解为平均使用寿命。相比软件研发行业，MTTF 更常用来描述硬件、组件或基础设施等等。
其管理价值在于通过对大量相同类型的系统或产品进行更长周期的观察和统计，团队可以了解该类型系统/产品的失效时间，并率先为淘汰和更换旧系统/产品做好准备。
小结
速率、质量和价值是研发效能管理的三驾马车。而相较速率而言，研发质量管理对团队共识的要求更高，因为我们需要通过集思广益，描绘一个线条干净、指标区隔清晰的质量评估视图，以进一步支持无歧义的指标量化管理；否则，研发效能管理最终又会回到让人头疼的「定义讨论会」。所提到的 9 个「MT 指标」可以从系统可靠性、可用性和可维护性等多个维度，衡量研发质量水平并辅助技术管理者展开更精确、更精准的研发质量监控和管理，进而有效提升组织效能，赋能业务增长。
高级开发人员要了解的高并发性能指标
QPS
QPS(Queries Per Second)即每秒查询率，是指一台服务器每秒钟能够支持的查询操作次数，为什么要定义这样一个标准呢？这个标准可以用来衡量服务器在规定的时间内的流量处理能力，而这里的流量其实就是指系统能够支持用户请求访问。在互联网环境下，QPS经常被用来定义域名服务器的机器性能，通俗来讲就是系统能够处理用户请求的能力。
TPS
TPS(Transaction Per Second)即每秒处理事务率，也就是每秒能够处理事务的个数。它是测试应用软件性能的标准之一。所谓的事务，其实就是指计算机所要完成的业务操作，例如转账、添加订单、扣减库存等等。也就是说当用户向服务器发送请求之后，服务器做出反应并且反馈到用户的整个过程，其实就可以被称为是一个事务操作。通过对TPS的统计可以有效的反映出业务系统处理事务的能力。
其实当我们的业务系统在处理用户请求的时候，QPS与TPS应该是相当的，也就是有多少个用户请求，就有多少个用户业务处理。但是有所不同的是，当用户点击了下单按钮之后，在用户看来只是单纯的下单也就是一个TPS操作，但是对于后台处理来说的话就有可能会调用订单系统、调用库存系统、调用其他一些业务判断系统例如减扣、优惠券等等。而这些处理就可以计入到QPS中。也就是说一个TPS中有可能会包含多个QPS。
RT
RT(Response Time)即响应时间，所谓的响应时间其实就是用户从发出一个请求到接受到请求响应的总时长。也就是说用户在浏览器中请求了一个商品详情信息，经历多少时间之后这个商品信息才渲染到用户页面上。这个指标主要用来反应系统的快慢，如果响应时间小的话，就说明系统反应较快，反之，则表示系统中存在了耗时操作，这个时候就需要对系统性能进行优化了。
并发数
并发数其实对大家来说是不是一个陌生的概念，并发数是指系统在同一时间能够处理多少个请求。侧面反映的就是系统的负载能力，举个简单的例子，很多人可能都经历过春运，我们知道在春运期间，火车站不但挤满了人，而且还挤满了火车，如果将火车站看做一个能够处理火车停靠的应用的话，并发数就相当于车站能够用来停靠火车的站台有多少，也就是说同时能够允许多少列火车停靠。这也就是这个车站最大的能够负载的能力。超过这个负载能力肯定火车是没地方停靠的。软件系统并发数的概念与之类似，如果超过了并发数，系统肯定会崩溃的。
吞吐量
系统的吞吐量是用来反映系统能够承载多少的用户请求压力。与用户请求、CPU处理能力、IO操作等等都有关系。简单的举个例子，在春运期间，一个车站的吞吐量就是指这个车站能够收发多少人员。如果我们将一个旅客看做一个用户请求的话，能够体现其吞吐量的因素应该有如下的几个：
1、能够处理请求的效率，也就是上面提到的QPS。
2、同时能够处理多少的请求，也就是上面提到的并发数。
3、就是系统的处理时间，也就是上面提到的响应时间。
这三个因素应该是共同影响这个系统的吞吐量的因素。如果是一个系统的QPS是100的话，也就是说它一秒之内能够处理100个请求。就可以理解为这个系统的并发数就是100。也就是说如果一个系统在一分钟之内处理了6000个请求，那么它一秒钟所处理的请求数就是100个。根据这个关系，我们就可以明确的感觉到系统吞吐量其实就是系统的整体性能的体现，包含了QPS、TPS、RT等一系列的参数。
PV
PV(Page Views)一般是指页面访问量，包含了用户对应用系统任意页面的访问量。例如当浏览了一个商品详情页的时候，就可以被记为一次PV。
线程数
线程数，也可以理解为并发数，也可以理解为QPS数，为什么这么说呢？了解Request请求原理，或者是了解过I/O模型的可能都清楚，我们的线程是不可能一直被无限创建的，并且一个系统所能创建的线程数是有限制的，超过限制就会导致系统异常。这里我们为什么说可以理解为QPS也可以理解为并发数呢？是因为当用户请求发送到服务器之后，会有一个线程来处理相应的请求。在多线程场景中，影响并发、影响QPS就是线程数的多少，在可控范围内一个系统所能创建的线程越多，就说明系统处理能力就越强。
简单的例子，当春运的时候我们的购票窗口往往都是排着长队的，那么这个时候，我们需要增加购票窗口，增加窗口之后，明显就感觉到买票的时间会缩短，并且窗口越多服务能力就越强。但凡事都有个限度，当我们超过了限度之后，就会适得其反。当然系统也是一样的。
有了上面的参数分析，我们可以得到如下的几个结论。
QPS/TPS = 并发数/RT
并发数=QPS*RT
QPS=PV/总时间
根据这些公式，结合上面的理论支持，就可以有效的进行计算机资源的分配，也可以根据上面的这些参数，来计算出系统的整体综合性能了。
稳定性建设工程之 SLA 浅述
在众多云服务提供商的套餐和支持方案中进行比较和选择；或是作为企业的采购负责人，评估外部供应商提供的服务系统是否满足企业业务需求和发展目标；亦或是公司内部服务平台的技术运维人员，需要评估系统的实际性能和边界条件，以判断其是否能够满足内部业务部门的要求并提供相应的保障承诺....... 所有这些场景都离不开一个关键概念：服务等级协议（SLA，Service-Level Agreement），而你打开任意一家云服务厂商的官网，你都能在产品页面中找到一份公示的 SLA。
在上述场景中，显然具备三个核心组成要素，即围绕 SLA 的上下游存在着两类角色，分别是服务提供方（SP，Service Provider）和服务客户（SC，Service Consumer），如下图所示：
图 1 SP -> SLA -> SC
形式上来说，SLA 是指系统服务提供者对客户的一个可量化服务承诺和协议，它是将服务质量评估从经验模型向量化模型转变的关键工具。SLA 通常明确列出了服务可用性、数据可靠性、响应时间等服务特性指标及其定义，服务提供方基于这些指标对客户做出量化承诺。此外，SLA 中还详细说明了服务提供方未满足承诺时的补偿操作（后果），例如提供额外支持、优惠折扣或钱款赔偿。通常，SLA 是在客户和外部服务提供商之间达成，但同一公司内的不同部门也可以相互签订 SLA，此时未满足 SLA 承诺的后果一般不涉及经济赔偿，而侧着于业务责任划分。
需要注意的是，SLA 的生命周期并不像图 1 所示的那样呈现单向、一次性或静态的特征。相反，它是一个双向、持续且动态的反馈和调整过程。在这个过程中，客户的需求可以通过 SLA 反向推动服务提供者进行系统设计和迭代决策。实际上，围绕 SLA 的生命周期，图 1 可以进一步优化为图 2 所示的形式：
图 2 SLA 生命周期
为了完全理解上图，我们需要了解一些 SLA 中的特别概念：
1. SLA 常见概念
SLI（Service Level Indicator）服务等级指标：SLI 指定了 SLA 中所提供服务某一维度的可量化指标，且必须具有清晰严谨的定义和计算方式。比如，对于某一网站的单实例服务器，一个简单的 SLI 定义是由客户端所发出合法的请求得到正常响应的百分比，合法的定义是请求参数和资源类型能够被服务端约定的协议解析成功，正常响应的定义是请求结果中不包含超出协议约定的错误或非预期数据。
SLO（Service Level Object）服务等级目标：SLO 明确了 SLA 中所提供服务某一维度的期望状态，是围绕 SLI 构建的目标。SLO 是客户感知和判断服务质量最为直观的方式，常见的说法如 “XX 可用性达到几个 9” 就是一种 SLO。规范来说，SLO 有指标范围和实现时间要求，这意味着在特定时间窗口内（通常是服务周期），涉及的 SLI 必须达到预定的指标标准，并且在该时间段内的实现比例应达到预期。如果未能达到 SLO，则应触发 SLA 中定义的后果，一般为对 SLA 中服务提供方的惩罚以及对客户的补偿方案。
例如，在单实例工作负载小于 10,000 TPS 的条件下，指定服务的平均请求响应时间应小于 85 毫秒，且响应有效率需超过 95%。承诺在一个月的服务周期内，这些指标的达成时间比例应超过 99.9%。若未满足上述服务等级目标，则将提供相当于服务费总额 20% 的代金券作为补偿。
因此，可以简单理解为：SLA = SLO + 后果 = SLI + 实现指标和时间占比要求 + 后果。可以看出，服务 SLA 是众多云厂商获取客户青睐和信任的有效竞争手段和必要承诺。通过明确服务质量的量化指标、期望目标以及未达成目标时的补偿措施，SLA 有助于建立客户与服务提供商之间的信任关系，并在竞争激烈的市场中提升服务商的竞争力。
此外，部分云厂商也提出了一些其他概念：
1).SLA 规则：是在 SLA 指标（SLI）的基础上，添加了判断条件，以触发告警或停止压测。这些规则可以帮助在服务性能偏离预期时及时识别问题，确保服务稳定性。
2).SLA 模板：是 SLA 规则的集合，可包含一个或多个 SLA 规则。SLA 模板通常与行业、业务类型绑定。通过使用 SLA 模板，组织可以快速应用符合其特定需求的服务等级协议规则集，从而提高管理效率和一致性。
3).SLA 拓扑，也称为 SLO 拓扑，指的是当服务足够复杂，链路中涉及多个子服务及其 SLO，评估和计算整体服务 SLA 所需的依赖路径关系。
2. SLA 基本要素组成
基于以上概念，当你作为某项服务系统的提供方起草一份规范的对外 SLA 时，通常需要包含但不限于以下内容：
协议概述：概述中应明确 SLA 的起始和结束日期、参与协议各方的详细信息，以及所涉及服务的简要说明。例如，协议可能会详细列出服务提供商和客户的联系信息和角色定义。
服务描述：这一部分应对 SLA 涵盖的所有服务进行详细描述，包括关键概念定义。例如，可以包括服务的周转时间、支持的技术和应用程序、计划的维护周期，以及相关流程和程序。
服务等级目标：明确协议中关于特定服务等级指标（SLI）的目标，例如服务可用性或平均响应时间。协议双方同意使用数据支持的关键服务指标来评估这些目标的达成，例如保证 99.9% 的服务可用性。
故障恢复流程：详细说明故障告警和恢复流程，概述供应商在发生服务故障时应遵循的机制和流程。这部分可能包括约定的响应时间（RTO）和恢复时间目标（RPO）。例如，故障报告后 1 小时内开始响应，4 小时内完成数据恢复。
安全标准：协议须明确约定双方采取的安全标准和措施，例如数据私密性、权限控制和安全审查流程，以确保服务的安全性。
排除条款：此部分描述双方商定的所有排除和豁免情形。例如不可抗力事件或第三方故障导致的中断不在服务承诺范围内。
惩罚与补偿：此部分明确规定未能履行 SLA 义务时的后果，例如给予客户相应的服务费退款或代金券作为补偿。
终止流程：双方可能会在某个时间点想要终止协议。除了任一方要求的通知期以外，SLA 还会清楚地规定允许终止或使协议失效的各种情形。
变更与审查流程：服务提供商能力、工作负载和客户要求会随着时间的推移而变化，因此需要定期审查服务商提供的 SLA 。有关服务商或客户要求的任何重大更改，需要被记录在协议当中，确保透明与合规，从而 SLA 能够整合服务提供商产品或服务的最新功能来满足当前的客户需求。
签名：该协议由双方授权的利益相关者审查文档中有关各事项后进行签署，在协议生效期间约束所有相关方遵守协议条款。
3. SLA 常见指标
3.1 服务可用性（Availability）
在各类系统服务的 SLA 中，服务可用性是最常见的指标之一。服务可用性指的是服务提供商在特定时间段内保持其服务可供使用的时长。这一指标通常以特定时段（称之为服务中周期）来衡量，并需要明确界定何为 "服务不可用"。例如，SLA 可能规定服务提供商的系统在每天内必须保持 99.5% 的可用性，这意味着每 24 小时，服务不可用的总时长不应超过 7.2 分钟。在计算服务可用性之前，先介绍如下几个定义：
1).平均故障间隔时间（MTBF）：是指服务相邻两次故障之间的平均时间
MTBF = 总运行时间 / 故障次数
2).平均故障修复时间（MTTR）：是指服务发生故障后，从故障发生到恢复完毕的平均时间。
MTTR = 故障恢复总时间 / 故障次数
3).平均正常运行时间（MTTF）：是指服务在无故障状态下能够持续运行的平均时间。该指标通常只用于不可修复的系统，也即代表了服务的期望寿命。
从而，可以计算得出服务可用性，给出了一个简单的例子：
Availability = MTTF /（MTBF + MTTR）
图 4 可用性计算简化案例
在大多数云产品的对外 SLA 中，一般以服务周期为评估单位，因此服务可用性采用了一种对客户更直观的表达方式来申明：
服务可用性 =（服务周期总时间 - 服务周期服务不可用时间）/ 服务周期总时间 * 100%
其中，服务不可用的具体定义取决于不同产品的 SLA 声明。基于以上计算原则，服务可用性 SLO 中服务周期选取与不可用时长的关系可由下表列出：
可用性级别 | 可用时长百分比 | 不可用时长/年 | 不可用时长/月 | 不可用时长/周 |
1个九 | 90% | 36.5天 | 72小时 | 16.8小时 |
2个九 | 99% | 3.65天 | 7.2小时 | 100.8分钟 |
3个九 | 99.9% | 8.76小时 | 43.2分钟 | 10分钟 |
4个九 | 99.99% | 52.56分钟 | 4.32分钟 | 1分钟 |
5个九 | 99.999% | 5.25分钟 | 25.92秒 | 6秒 |
6个九 | 99.9999% | 31.5秒 | 2.5秒 | 0.6秒 |
3.2 数据可靠性（Reliability）
通常针对存储系统设置，指的是数据在存储、传输和处理过程中保持准确性和完整性的能力。被视为可靠的数据将承诺不会丢失、损坏或被未经授权的修改。更细致的又可以分为数据持久性、数据一致性、数据可用（访问）性等等：
数据持久性：指的是数据在存储后能被长期保存的能力，不会因为断电或系统崩溃等问题而丢失。
数据一致性：指的是在数据存储和处理过程中，数据在多副本或多系统之间的状态保持一致的能力。
数据可用性：指的是用户能够访问和使用数据的能力，与服务可用性类似。高数据可用性意味着系统即使在系统发生部分故障或维护期间，在需要时也总是能够提供数据访问。
举个例子，某云服务厂商的对象存储服务承诺可提供 99.9999999999%（12 个 9）的数据持久性，这意味着，存储一万亿个对象大概只会有 1 个文件是不可读的。一般来说，数据可靠性可宽泛定义为数据在系统中确认存储成功后不丢失 / 不损坏的概率。影响数据存储的原因可分为三类：
硬件级故障：例如磁盘损坏、电源故障、内存故障以及网络设备失效等
软件级故障：例如消息队列中的实现 bug / 死锁可能导致数据未能正确传递或处理，在某些情况下，消息可能未实际写入内存或磁盘，但系统已经向客户端发送了成功确认（ACK）
人为故障：例如错误配置、数据误删除、运维误操作或执行脚本不当等
数据可靠性计算相对服务可用性计算复杂很多，需要依据专门的量化模型计算。如果仅考虑硬件级故障，可参考如下模型来量化一个存储系统的年度数据可靠性：
Reliability = Func(N，R，MTTR，CopySets，D，AFR)
其中，N 是存储系统磁盘的总数；R (Replications) 是单块磁盘配置的副本数；MTTR 为磁盘故障平均修复时间；CopySets（副本数据复制组）是分布式存储系统中对一份数据的所有存储副本的分组集合，这里取 CopySets 的模，例如一份数据写入到了 p1，p2，p3 盘，那么 {p1, p2, p3} 就是一个 CopySet，当该 CopySet 损坏，则这份数据丢失。CopySet 可以用于衡量数据副本存储的离散分布程度，且满足：
N/R <= |CopySets| <= C(N, R)
其中 C 是组合计算符，当数据存储分布越分散随机，那么同时损坏 R 个盘时会完全丢失某份数据的概率就越高，而 |CopySets| 越接近 N/R，那么发生损坏时丢失的数据量越高，恢复时间和成本也会攀升，因此 CopySet 的生成策略十分考验技巧；D (Distributions) 是预设的故障概率分布模型，常见有二项分布、泊松分布等；AFR（Annualized Failure Rate) 是磁盘的年故障率，其定义为：
AFR = 1 / (MTBF / (24 * 356)) * 100%
从模型组成因子的定义直观来看，AFR、MTTR 和 CopySets 的模与数据可靠性负相关，而磁盘总数和副本数与可靠性正相关。但实际情况并没有这么简单，每项因子对可靠性的贡献可能并不是线性或连续的，因子之间也并不完全独立，例如 AFR 与 MTBF 相关，而 MTTR 也受 Replications 和 CopySet 分布策略的影响。由于可靠性模型的具体推导计算过程超出本文篇幅，感兴趣的读者可以移步参考文献 [4][5]。
3.3 请求错误率 (Error Rate)/ 成功率 (Success Rate)/ 可用率 (Availability Rate)：
这三个指标在大多数服务中是客户使用感知最为明显的，通常关注的粒度为服务的接口级别，而服务可用性则是更多侧重评判服务整体的质量。一个常见的场景是，客户端定时监控某项服务请求的错误率，以此衡量服务的某项功能或者子集是否低于 SLA 中的预期目标。
以错误率计算方式为例：
错误率 = 1 - 成功率 = 时间片内导致系统产生错误的请求数 / 该时间片内的请求总数 * 100%
可用率：可用率在语义上不同于成功率，它要求服务请求的响应正确且有效，并且通常会排除非服务端导致的错误，例如客户端非法参数、权限拦截，服务外部前置链路的限流等等。
这三个指标通常以时间片进行周期计算，例如每 1 分钟错误率、每 5 分钟成功率等等
3.4 吞吐量 (Throughput)：
指单位时间内系统能处理的请求数量，体现系统处理请求的能力，这是目前最常用的性能测试指标。吞吐量指标一般包括 QPS（Query Per Second，每秒处理请求数），TPS（Transaction Per Second ，每秒处理事务数）等。
QPS 指系统每秒能处理的请求（查询）数，通常用于衡量服务器能抗多少流量：
QPS = 时间片内请求总数 / 时间片秒数
TPS 指系统每秒能处理的事务数。这里事务是指一个完整的业务处理和响应过程，可能对系统发起多个 QPS 中定义的请求：
TPS = 时间片内事务总数 / 时间片秒数
以上计算通常针对网站或者业务系统，对于数据库（例如 MYSQL）等其他类型服务而言，除了有更区别细化的定义，还会关心 IOPS（Input/Output Per Second，磁盘每秒读写次数）等 SLI。
3.5 响应时间 / 延迟（Latency）：
指系统在收到用户的请求到响应这个请求之间的时间间隔，系统的延迟指标通常与服务的性能、吞吐量等指标相关。该指标通常会以时间片平均或者百分比的方式计算，并且与采点方式、点位选择强相关：
平均值：此方法通过计算所有请求的平均响应时间，判断是否低于设定阈值。但这只能作为一种较为宏观的评估方式，对于波动型的系统状态或者对半的响应时间分布情况，会掩盖许多问题。
百分比：我们也经常会在 SLA 中看见 p95 或者是 p99 这样的延迟声明，其中 p 指的是 percentile（百分位）。当系统的 p95 延迟为 1 秒，意味着 95% 的请求响应时间小于 1 秒，而剩余 5% 的请求则超过 1 秒。
3.6 其他
此外，SLA 中通常还会涉及如下指标：
故障频率和恢复：通常涉及服务可用性中提到的 MT 类型指标，例如代表故障平均恢复时长的 MTTR 等，部分 SLA 会单独针对这些指标做出承诺，以便故障发生时客户能有明确的修复耗时预期。
服务支持：通常包含服务提供商提供的技术支持、客户服务等方面的指标。例如，在运营云服务时，可要求服务提供商提供 24 小时客户服务、及时响应客户请求等。例如，某云服务商提供 8:00-24:00 的在线服务支持，并提供全天 24 小时的服务热线。
安全性：为了证明服务提供方会采取预防性措施来减少非安全操作和数据泄露，可量化、可控制的安全指标（如加密可靠性、防病毒更新和补丁等）是许多云服务厂商都必须面对的问题。
业务绩效目标：该指标通常关联服务提供方或者客户业务方的绩效标准。在公司内部的双方合作部门 SLA 签订中，常见的形式是服务周期内 xx 业务无 x 级以上故障。
其他特殊服务/中间件的定制指标
4. 制定 SLO 时需要考虑什么
4.1 制定并量化统计 SLI
在制定服务等级目标（SLO）时，准确统计和量化服务等级指标（SLI）是首先考虑的。如何有效采集和计算 SLI，将直接影响 SLO 的合理性和可达成性，一般需要考虑如下方面：
了解客户群体：明确服务的目标客户群体，在制定 SLI 时，需要提供简明、清晰且无歧义的定义，使客户能够快速理解并达成共识。我们不应追求 SLI 的数量和复杂度，而应重点关注客户真正关心的业务价值和服务使用体验。例如，对于电商平台，下单成功率就是一个关键 SLI。
反映系统性能和架构：SLI 指标应该反映系统的实际性能和可用性，同时采集和计算过程尽量减少对系统的侵入，对于通用型指标可以组装为 SLI 规则和模版。例如，选择可以通过现有监控工具轻松获取的响应时间或错误率指标。
计算和采集：优先选择可以简单采集且能够正确、准确量化的指标。SLI 的统计可以在用户端（Client-side）和服务提供方（Server-side）进行，常见的统计方式包括客户端埋点数据上报、服务端日志采集分析、探针巡检、时序数据库指标采集等。目前各大厂或云服务厂商都有成熟的中间件或产品方案，例如 ARMS；或是基于开源的 Prometheus、HertzBeat 等等二次开发搭建，进行在线或离线的指标采集和计算聚合。然而，无论采用何种方式，指标采集过程都应避免对服务性能和可用性产生负面影响。确保监控工具和策略设计规范，避免在采集数据时影响服务质量本身。
4.2 SLO 计算和聚合模型
SLO 的通用计算模型一般由 SLI、服务周期、服务拓扑链路组成。根据服务自身场景定义出不同维度的 SLI 并采集计算后，可以汇集出 SLO 的情况。SLO 的计算和聚合规则通常如下：
小周期评判：将服务周期（通常是自然月）拆分为多个小周期，以 “服务可用性 99.95%” 这一 SLO 为例来说，周期性地计算小周期中的服务可用时长是否达成 99.95% 占比，如果未达到，则标记此周期不可用。考虑到 SLI 的数据分析粒度和趋势平滑性，小周期的设定时长通常不高于 30s。
计算达成时间占比：计算整个服务周期 N 内，达标小周期时间的占比，从而得到服务的实际 SLO 水位：
SLO = ∑ SLI 达标小周期时长 / 服务周期总时长
SLO 拓扑聚合：如果服务涉及到多条链路，每条链路可拆分多个子服务，并对应有其 SLI、SLO，则需要聚合出服务的总 SLO
串联型：服务拓扑链路中，各服务是串型依赖关系，某一子服务出现不可用，将导致整个服务不可用。以服务可用性为例，串联服务可用性计算公式为：
串联服务可用性 = 子服务 1 可用率 * 子服务 2 可用率 * ....
并联型：服务拓扑链路中，不存在单点依赖，某一子服务不可用不影响整体服务可用性。以服务可用性为例，串联服务可用性计算公式为：
并联型服务可用性 = 1 - （子服务 1 不可用率 * 子服务 2 不可用率 * ...）
混合型：目前多数云产品都是以混合型的方式提供产品 SLA，服务链路中同时存在串联和并行拓扑。此时，服务可用性计算依赖具体的拓扑链路分析，如图 4 所示。可以看出，拓扑链路中横向增加单点依赖子服务会导致 SLA 降低，而纵向增加并行冗余服务，则会提高 SLA，同时冗余的维护成本也会相应增加。
图 5 SLA 拓扑类型举例
集群 SLO 计算：多数时候服务以集群形式对客户提供访问，假定集群中每个实例在流量路由和 SLO 链路上是完全独立的，则可分开计算每个集群的 SLO。对于单个集群，假设集群由 N 个实例节点组成，则可参照小周期的方式计算特定时间片内的集群 SLO：
集群 SLO = 1 - ∑ SLI 未达标实例数 / 集群总实例数
当然，以上只是一个简化的模型，真正的服务链路场景要复杂得多，因此需要因地制宜进行 SLO 的建模和计算。
4.3 设定 SLO 阈值和分级告警
在梳理出系统需要关注哪些 SLI 和量化 SLO 后，需要考虑一个现实的问题，SLO 的阈值应该如何设置？一般而言，SLO 阈值确定需要包括但不限于以下规则：
灵活应对变化：首先要认识到，阈值设置不存在银弹，并没有 “一劳永逸” 的解决方案。由于服务系统的状态和客户需求会随时间发生变化，SLO 阈值应是一个动态调整修正的过程。这意味着需要不断监测和修正，以确保其始终贴合实际情况。
基于实际性能分级设定阈值：确定 SLO 阈值时，应基于系统的当前实际性能水平。设定阈值时不能过于保守，以免低于系统能力，也不能过于激进，做出难以实现的承诺。在设定阈值前，应对系统进行充分的测试和验证，以了解其在长期和高压力条件下的表现。此外，应留有一定的安全空间，使内部的实际 SLO 略高于向外承诺的 SLO。一般来说，需要根据业务实际情况设定 warning，critical 和 urgent 三级告警，并配置相关触发动作。
结合客户场景进行优化：SLO 阈值的设定需考虑服务的实际客户业务场景、基数和业务价值，而不仅仅是基于系统当前性能和指标达成的小数点数位。例如，在电商交易场景中，如果系统支持单日 99.99% 的订单成功率，而这意味着 100w 订单中就有 100 笔失败订单，需要分析这些失败订单的发生原因、时段和用户影响，判断是否需要调整 SLO 并升级系统架构。同样，对于网站请求延时指标，若设定 p99 延时为 1 秒，而在 1 亿次请求中有 10 万次超过 1 秒，如果这些请求对应的是延时敏感的用户群，则尽管符合 SLA 的阈值设定，SLO 可能仍需优化。
4.4 错误预算
设定完 SLO 阈值，在系统开始提供服务之后，SRE 团队通常需要密切关注一个重要指标：错误预算（Error Budget ），它不仅反映了服务 SLO 的履行情况，还对团队的开发策略起着关键调节作用：
错误预算量化了在特定时间范围内可接受的服务失效或不符合服务水平目标（SLO）的程度，其计算方式依赖于 SLO：
计算方式：服务周期窗口总值 *（1 - SLO）
例如，对于服务可用性 99.99% 这一 SLO，则服务周期内错误预算为：服务周期总时间 * （1 - 99.99%）
协调与平衡：错误预算为团队提供了在服务维护和功能开发之间做出平衡的依据。若错误预算未被耗尽，团队可以在保证可靠性前提下进行更多的创新和功能开发，否则团队需避免任何可能突破 SLO 的功能升级或变更，以规避风险。
图 6 错误预算如何平衡服务的稳定性和迭代
监控与反馈：定期监控和评估错误预算的使用情况，确保团队能够及时应对服务质量的偏差，并及时做出相应的改进措施。例如，服务投入生产环境不足一周就消耗了 30% 的错误预算，那么开发团队需要及时对服务架构的合理性做出审视，至少要提前做好突破 SLO 的兜底应对链路，再寻求合适时机对服务进行敏捷的升级变更。
4.5 考虑成本和收益
当系统平稳持续运行一段时间后，客户业务诉求可能会（一定会）迎来变化。当判断决策需要为此调整 SLO 时，应当谨慎考虑投入成本和收益的比例关系。需要提高 SLO 阈值标准时，通常需要分析当前系统现状无法满足的原因：
历史技术债：系统当前架构设计存在既有缺陷
新的诉求和挑战：客户基于场景协商提出了更高要求
同时，系统地梳理成本投入项：
基础设施成本：评估主要系统和服务所需的硬件、软件和网络资源，包括云服务费用和维护成本。
人力资源成本：计算与服务交付相关的人员成本，包括运维团队的工资、培训费用以及人员流动带来的潜在成本。
运营成本：分析系统投入生产运行中的开销，如监控工具、备份兜底链路等。
过程中尽量遵循一个原则：增加维护资源和成本来提高服务质量带来的收益应大于将资源投入到其他地方带来的收益。例如，对于公司内部服务于业务的中台服务，服务可用性从 99.99% 提高到 99.999% 所需要的资源和带来的业务价值、服务业务数的增量之比，是决定该服务是否投入资源进行提升改造的核心判断准则。当效益比过低，则应当考虑其他达成业务目标的路径。当资源有限时，应当划分不同级别的业务，对重点业务倾斜资源进行高 SLA 保障。同时也要考虑不同客户 / 业务群体需求水位不一致、服务费存在差别（对外商业化时）的客观情况，提供分档位的 SLA。
该文章最后由 阿炯 于 2025-01-06 21:41:52 更新，目前是第 4 版。