选择目标SLO 不是一个纯粹的技术活动，因为这里还涉及产品和业务层面的决策，SLI和SLO（甚至 SLA）的选择都应该直接反映该决策。同样的，有时候可能可以牺牲某些产品特性，以便满足人员、上线时间（time to market）、硬件可用性，以及资金的限制。SRE 应该积极参与这类讨论，提供有关可行性和风险性的建议，下面列出了一些有用的讨论。

不要仅以目前的状态为基础选择目标       
了解系统的各项指标和限制非常重要，但是仅仅按照当前系统的标准制定目标，而不从全局出发，可能会导致团队被迫长期运维一个过时的系统，没有时间去推动架构重构等任务。

保持简单
SLI中过于复杂的汇总模式可能会掩盖某种系统性能的变化，同时也更难以理解。

避免绝对值
虽然要求系统可以在没有任何延迟增长的情况下无限扩张，或者"永远"可用是很诱人的，但是这样的要求是不切实际的。就算有一个系统能够做到这一点，它也需要花很长时间来设计和构建，同时运维也很复杂——最关键的是，这可能比用户可以接受的（甚至是很开心地接受的）标准要高太多。

SLO越少越好
应该仅仅选择足够的SLO来覆盖系统属性，一定要确保每一个SLO都是必不可少的∶如果我们无法针对某个SLO达标问题说服开发团队，那么可能这个SLO就是不必要的准。然而，不是所有的产品属性都能用SLO表达，用户的"满意度"就很难。

不要追求完美
我们可以随着时间流逝了解系统行为之后优化SLO的定义。刚开始可以以一个松散的目标开始，逐渐收紧。这比一开始制定一个困难的目标，在出现问题时放松要好画得多。

SLO可以成为——也应该成为——SRE和产品团队划分工作优先级的重要参考，因为SLO代表了用户体验的程度。好的 SLO是对开发团队有效的、可行的激励机制。但是一个没有经过精心调校的SLO会导致浪费，某团队可能需要付出很大代价来维护一个过于激进的SLO，而如果SLO过于松散，则会导致产品效果很差。SLO是一个很重要的杠杆∶要小心使用。

选择目标SLO 不是一个纯粹的技术活动，因为这里还涉及产品和业务层面的决策，SLI和SLO（甚至 SLA）的选择都应该直接反映该决策。同样的，有时候可能可以牺牲某些产品特性，以便满足人员、上线时间（time to market）、硬件可用性，以及资金的限制。SRE 应该积极参与这类讨论，提供有关可行性和风险性的建议，下面列出了一些有用的讨论。

不要仅以目前的状态为基础选择目标       
了解系统的各项指标和限制非常重要，但是仅仅按照当前系统的标准制定目标，而不从全局出发，可能会导致团队被迫长期运维一个过时的系统，没有时间去推动架构重构等任务。

保持简单
SLI中过于复杂的汇总模式可能会掩盖某种系统性能的变化，同时也更难以理解。

避免绝对值
虽然要求系统可以在没有任何延迟增长的情况下无限扩张，或者"永远"可用是很诱人的，但是这样的要求是不切实际的。就算有一个系统能够做到这一点，它也需要花很长时间来设计和构建，同时运维也很复杂——最关键的是，这可能比用户可以接受的（甚至是很开心地接受的）标准要高太多。

SLO越少越好
应该仅仅选择足够的SLO来覆盖系统属性，一定要确保每一个SLO都是必不可少的∶如果我们无法针对某个SLO达标问题说服开发团队，那么可能这个SLO就是不必要的准。然而，不是所有的产品属性都能用SLO表达，用户的"满意度"就很难。

不要追求完美
我们可以随着时间流逝了解系统行为之后优化SLO的定义。刚开始可以以一个松散的目标开始，逐渐收紧。这比一开始制定一个困难的目标，在出现问题时放松要好画得多。

SLO可以成为——也应该成为——SRE和产品团队划分工作优先级的重要参考，因为SLO代表了用户体验的程度。好的 SLO是对开发团队有效的、可行的激励机制。但是一个没有经过精心调校的SLO会导致浪费，某团队可能需要付出很大代价来维护一个过于激进的SLO，而如果SLO过于松散，则会导致产品效果很差。SLO是一个很重要的杠杆∶要小心使用。