谷歌SRE的7条原则

拥抱合理的风险

最大化系统的稳定性不仅毫无意义，而且会适得其反。不切实际的可靠性目标限制了新功能交付给用户的速度，而且用户通常不会注意到极端的可用性(比如99.99999%)，因为他们的体验是由最不稳定的组件决定的。

拥有100%的可用性需求严重限制了团队向系统交付更新和改进的能力。想要交付许多新特性的服务所有者应该选择不那么严格的SLOs，从而让他们在出现无关紧要的bug时可以继续交付。

服务所有者关注可靠性，因此他们可以选择更高的SLO。SRE准则将这种可接受的风险量化为“错误预算”。当错误预算耗尽时，重点就应该从新功能开发转移到提高可靠性。

服务水平目标SLO（Service Level Objectives）

站点可靠性工程(SRE)规程决定系统的可用性目标，并使用来自工程师、项目所有者和客户的输入来度量可用性。

如果没有一致的方式来描述系统的正常运行时间和可用性，团队间的交流和合作将会很有挑战性。运维团队不断地灭火，但是开发人员很少主动地修复错误。如果没有对正常运行时间的清晰度量，产品团队可能不同意可靠性是一个问题。

所以SLO是推动SRE学科发展的主要因素。SRE确保每个人都同意当可用性超出规范时应该做什么，以及如何度量可用性。这个过程包括所有项目相关的人员的领导。SREs与相关人员一起决定Service Level Indicators (SLIs) and Service Level Objectives (SLOs)。

SLIs是作为请求延迟的时间度量，即每秒请求的吞吐量。通常随着时间的推移而聚集，然后转化为一个速率，可以将与一个阈值比较。

SLOs是在相关人员一致同意的时间段内SLIs累积成功的目标。

SLIs、SLOs和SLAs更接近于“度量一切”的DevOps支柱，这也是我们说SRE实现DevOps的原因之一。

消除Toil

Toil不只是指自己不喜欢做的事。例如，下面的任务是费时的，但具体来说不是Toil: 提交费用报告，参加会议，回复电子邮件，通勤上班，等等。相反，Toil是与正式的prod环境服务的运行联系在一起的。这种工作往往是重复性的、手工的、可以自动化的、没有长期的价值。每当操作员需要操作系统时，例如响应页面、处理票据，就可能会出现Toil。

站点可靠性工程(SRE)学科的目标是通过关注SRE的“工程”部分来减少工作量。SRE的工作是设计一个解决方案，减少Toil，实现任务的自动化。

谷歌的目标是确保每个SRE至少有50%的时间花在工程项目上，这些SRE每个人都在季度调查中报告他们的Toil，以确定运营超负荷的团队。话虽如此，Toil并不总是坏事。重复性的和可预测的任务是让新成员加入的好方法，并且通常可以在低风险和低压力的情况下产生一种即时的满足感和成就感。

分布式系统的检测

监视一个复杂的应用程序是相当困难的。即使存在大量用于仪表、显示、收集和警报的现有基础设施，拥有10-12名成员的谷歌站点可靠性工程(SRE)团队通常也只有一到两名成员主要任务是为整个服务构建和维护监视系统。

随着SRE对公共监视基础设施进行泛化和集中，这个数字正在减少，但是每个SRE团队通常至少有一个“监视人员”。为人类生成警报的规则应该简单易懂，并代表明显的失败。

自动化

SRE的主要工作是实现自动化，从而改进系统。例如，集群可以增长，可以引入更多的特性，而不需要增加团队的规模。

发布自动化

发布工程师对源代码管理、构建配置语言、编译器、自动构建工具和安装程序有更好的理解。他们的技能包括对开发、配置管理、测试、系统管理和客户支持等多个领域的深入了解。

运行可靠的服务需要可靠的发布流程。站点可靠性工程师需要知道，他们所使用的配置是以一种可重复的、自动化的方式构建的，因此发布是可重复的，而不是一次性的。对发布过程的任何方面的更改都应该是有意的，而不应该是偶然的。SREs总是关心从源代码到部署的所有这些过程。

简单化

软件系统具有内在的动态性和不稳定性。一个系统只有存在于真空中才能完全稳定。如果我们停止改变代码库，我们就会停止引入新的错误。如果库永远不变，那么这两个组件都不会引入bug。如果我们冻结当前的用户群，我们就永远不需要扩展系统。

事实上，对SRE方法和管理系统的一个很好的总结是: 我们的工作是保持系统与敏捷性和稳定性的平衡