SRE基础——概述

SRE 的目标是构建可扩展和高可用的软件系统，通过软件工程的方法解决基础设施和操作相关的问题。

SRE管理体系包含：服务质量目标（SLO）、on-call轮值、变更和事故管理、故障复盘、应急响应机制等一系列的管理手段。

SRE有这样一些观点：

1. 运维是软件问题

 做好运维是一个软件问题，应该使用软件工程方法来解决该问题。SRE实际上支持软件工程，但也可以改变体系结构，安全性，治理和合规性。当我们利用SRE专注于提供服务平台时，所有其他这些注意事项都将得到一流的重视，但是这种情况发生的地点和方式可能完全不同。就像SRE(并希望DevOps)将越来越多的负担转移到软件工程上一样，现代体系结构和安全性实践也从幻灯片，检查表开始发展，并希望通过运行代码实现正确的行为。

2. 服务有具体的质量目标

 不会尝试为所有内容提供100％的可用性。产品团队和SRE团队为服务及其用户群选择适当的可用性目标，然后将服务管理到该SLO。度量是SRE如何工作的绝对关键。对于SRE，SLO在确定为改善服务而采取的措施中占主导地位，没有度量标准就不可能有SLO(以及跨团队辩论-理想情况是产品，基础架构/ SRE和业务之间)。

3. 减少手动的结构强制性的操作任务

 任何手动的，结构强制性的操作任务都是令人讨厌的。如果机器可以执行所需的操作，则通常应该由机器去做。“琐事”不能算是“工作”，花在运维任务上的任何时间都意味着是没有花在项目正常工作上的时间，而项目工作就是使服务更可靠和可扩展。

4. 自动化

 对于团队成员可以花多少时间在“琐事“上有一个硬性限制，相对于工程方案维持在50％——一种明确的声明和启用机制，对于采用基于工程的方法来解决问题，而不是一遍又一遍地解决问题，要有用得多。

5. 通过降低失败成本来快速行动

 减少常见故障的平均维修时间(MTTR)可以提高产品开发人员的速度，因为工程师不必浪费时间并集中精力解决这些问题。

6. 与开发者共享所有权
 
 倾向于将重点放在生产问题上，而不是业务逻辑问题上。通常，S服务的可用性，延迟，性能，效率，变更管理，监控，紧急响应和容量规划方面具有特殊的专业知识。那些特定的(通常是定义明确的)能力是SRE为产品以及相关产品开发团队所做的工作的基础。理想情况下，产品开发和SRE团队都应该对以下方面有整体了解堆栈-前端，后端，库，存储，内核和物理机。

7. 无论功能或职称如何，都使用相同的工具

 没有一种好的方法来管理一项具有一个针对SRE的工具以及一个针对产品开发人员不同的工具的服务，并且在不同情况下的行为不同。