问题描述
需要指导团队为其正在设计的服务制定服务级别目标 (Service Level Objectives, SLOs)。他们想知道对于尚不存在的服务，是否有制定SLOs的标准？或者是否最佳做法是在服务启动后，基于初始性能制定SLO，并朝着目标逐步发展？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
在为新服务制定SLOs时，应该基于业务需求和客户信息。SLO应该是绝大多数用户对服务满意度的反映。
以下是制定SLOs的最佳实践步骤：
1. 将服务的行为分解为关键操作。
关键操作是服务提供的离散功能，而且是客户关心的功能。它通常从客户的角度定义，并独立于实现方式（例如，“客户成功将商品添加到购物车”，“客户查看高分榜”）。
2. 对于所选的关键操作，确定每个操作的正确服务级别指标（Service Level Indicator, SLI）规范：操作成功或失败，是否需要可用性SLI；操作是否需要一定的完成时间，需要延迟SLI；操作是否生成数据以供以后使用，需要新鲜度或正确性SLI？等等（例如，将商品添加到购物车需要可用性和延迟SLI；查看高分榜还需要新鲜度SLI，以及可能的正确性SLI）。
3. 考虑不可靠性对用户的影响：每隔几天发生一次故障是否会让用户不满意？每小时一次故障呢？故障是否被客户端重试遮盖？点击按钮后100ms的延迟会让用户感到烦恼吗？那1000ms或10秒呢？
4. 基于上述信息开始制定SLOs，并思考如何实现SLI规范：在保证可观察性的前提下，进行准确性、成本和复杂性之间的权衡。在服务尚处于设计阶段时，可以充分利用这一点，确保服务的设计考虑到可观测性。例如：
– 将服务拆分为微服务，使得这些微服务可以与不同的SLIs和关键操作相对应。
– 确保应将应计入不同SLIs的任何HTTP请求在负载均衡器中可以被明确区分（例如，不要让所有请求都成为对/handler的POST请求）。
– 从一开始就在设计中包含日志和指标（例如，通过OpenCensus），并考虑它们对应用程序的可扩展性和可靠性的影响。
– 如果计划使用合成探测，请确保能够执行此操作（考虑网页的多少逻辑在客户端脚本中，而不是服务器端，以及如何监控此逻辑）。
– 是否可以包含客户端端的仪器，以及如何收集结果？
5. 最重要的是，在为新服务制定SLO时，计划进行迭代：即使一开始不知道什么服务水平才能使用户满意，也应该有一些指标来确定这一点（满意度分数、工单级别、随机调查等），并根据需要调整当前的SLO。
不要将服务的SLO设置得比客户所需的更难以维护，但确保SLO足够使他们满意。