一、系统不可能100%可靠
二、管理风险
不可靠的系统会影响产品的信誉，虽然系统不可能100%可靠，但我们也要减少系统出故障的几率。然而，经验表明，可靠性进一步提升的成本并不是线性增加的：可靠性的下一个改进可能比之前的改进成本增加100倍。基于以上矛盾点，SRE的做法是管理风险，目标是：我们会努力提高一项服务的可靠性，但不会超过该服务需要的可靠性。管理风险旨在寻求快速创新和系统可靠性的平衡，而不是简单地将可靠性最大化。
三、度量风险
可用性=系统正常运行时间/（系统正常运行时间+停机时间）
使用这个公式，我们可以计算出一年内可接受的停机时间，从而可以使可用性达到预期目标。举例来说，一个可用性目标为99.99%的系统最多在一年中停机52.56分钟，就可以达到预计的可用性目标。当然，并不是所有的系统或者组件适用于这个公式，比如也可以通过请求成功率来定义服务可用性，具体如何度量还要结合实际情况灵活应对。
四、确定服务可靠性目标
- 基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意?
- 如果这项服务的可靠程度不够，用户是否有其他的替代选择?
- 服务的可靠程度是否会影响用户对这项服务的使用模式?
为了建立起一个合理的可靠性目标，SRE必须与产品负责人一起努力，将一组商业目标转化为明确的可以实现的工程目标。在实践中，这种转化说起来容易做起来难，SAAS层软件和IAAS层基础设施转化的方式又各不相同。
五、错误预算
“错误预算”就是“1-可靠性目标”。如果一个服务的可靠性目标是99.99%,那么错误预算就是0.01%，这意味着产品研发部门和SRE部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。
SRE通过引进“错误预算”的概念，解决了研发团队和 SRE 团队之间的组织架构冲突。SRE 团队的目标不再是“零事故运行”，SRE团队和产品研发团队目标一致，都是在保障业务服务可靠性需求的同时尽可能地加快功能上线速度。这个改动虽小，意义却很大。一次“生产事故”不再是一件坏事，而仅仅是创新流程中一个不可避免的环节，两个团队通过协作共同管理它。