共计 1399 个字符，预计需要花费 4 分钟才能阅读完成。
一、零碎不可能 100% 牢靠
零碎不可能 100% 牢靠，人都不可能 100% 衰弱，更何况咱们人类发明的零碎？所以，任何软件系统都不应该一味地谋求 100% 牢靠。事实证明，可靠性超过肯定值后，再进步可靠性对于一项服务来说，后果可能会更差而不是更好！极其的可靠性会带来老本的大幅晋升：比方过分谋求稳定性限度了新性能的开发速度和产品交付速度，并且很大水平地减少了投资老本和运维老本。
二、治理危险
不牢靠的零碎会影响产品的信用，尽管零碎不可能 100% 牢靠，但咱们也要缩小零碎出故障的几率。然而，教训表明，可靠性进一步晋升的老本并不是线性减少的：可靠性的下一个改良可能比之前的改良成本增加 100 倍。基于以上矛盾点，SRE 的做法是 治理危险 ，指标是： 咱们会努力提高一项服务的可靠性，但不会超过该服务须要的可靠性。治理危险旨在寻求疾速翻新和系统可靠性的均衡，而不是简略地将可靠性最大化。
三、度量危险
SRE 的做法是通过一个主观的指标来体现一个零碎的可靠性（或者是危险）。对于大多数服务而言，最间接的可能代表危险承受能力的指标就是对于计划外停机工夫的可承受程度。对于零碎而言，这个指标通常是基于零碎失常运行工夫比例的计算得出的。
可用性 = 零碎失常运行工夫 /（零碎失常运行工夫 + 停机工夫）应用这个公式，咱们能够计算出一年内可承受的停机工夫，从而能够使可用性达到预期指标。举例来说，一个可用性指标为 99.99% 的零碎最多在一年中停机 52.56 分钟，就能够达到预计的可用性指标。当然，并不是所有的零碎或者组件实用于这个公式，比方也能够通过申请成功率来定义服务可用性，具体如何度量还要结合实际状况灵便应答。
四、确定服务可靠性指标
如果 100% 不是一个正确的可靠性指标，那么多少才是呢? 这其实并不是一个技术问题而是一个产品问题。要答复这个问题，必须思考以下几个方面:
- 基于用户的应用习惯，服务可靠性要达到什么水平用户才会称心?
- 如果这项服务的牢靠水平不够，用户是否有其余的替代选择?
- 服务的牢靠水平是否会影响用户对这项服务的应用模式?
为了建设起一个正当的可靠性指标，SRE 必须与产品负责人一起致力，将一组商业指标转化为明确的能够实现的工程指标。在实践中，这种转化说起来容易做起来难，SAAS 层软件和 IAAS 层基础设施转化的形式又各不相同。
五、谬误估算
SRE 和产品负责人必须对每个零碎建设起一个正当的可靠性指标。一旦建设，“谬误估算”就是“1- 可靠性指标”。如果一个服务的可靠性指标是 99.99%, 那么谬误估算就是 0.01%，这意味着产品研发部门和 SRE 部门能够在这个范畴内将这个估算用于新性能上线或者产品的翻新等任何事件。
谬误估算能够用于什么领域呢? 研发团队须要用这个估算上线新性能，吸引新用户。现实状况下，咱们应该应用谬误估算来最大化新性能上线的速度，同时保障服务质量。这个根本模型建设起来之后，许多常见的战术策略，例如灰度公布、AB 测试等伎俩就全说得通了。这些战术性伎俩都是为了更正当地应用整个服务的谬误估算。
SRE 通过引进“谬误估算”的概念，解决了研发团队和 SRE 团队之间的组织架构抵触。SRE 团队的指标不再是“零事变运行”，SRE 团队和产品研发团队指标统一，都是在保障业务服务可靠性需要的同时尽可能地放慢性能上线速度。这个改变虽小，意义却很大。一次“生产事变”不再是一件好事，而仅仅是翻新流程中一个不可避免的环节，两个团队通过合作独特治理它。
