SRE更多的代码，更少的辛劳

2003年，谷歌创建了网站可靠性工程师(SRE)职位。SRE团队已经遍布整个行业，根据LinkedIn的数据，现在有~25K个SRE。随着SRE角色的崛起，我们相信有机会建立支持SRE工作流程的大型企业。
开发人员几十年来一直与运营团队合作。在20世纪90年代和21世纪初，大多数运营团队被称为系统管理员，并与物理基础设施合作。传统上，开发人员将代码抛给负责系统配置、供应和管理的操作人员。虚拟化和云计算使基础设施变得可编程和远程。随着时间的推移，随着软件抽象出额外的操作能力和智能，操作开始编写更多的代码。Devops运动反映了作为代码趋势的基础设施。
与源于运营的Devops不同，SRE团队源于编程。根据谷歌工程副总裁兼谷歌SRE创始人本杰明·斯洛斯的说法，SRE是“当你要求软件工程师设计一个运营团队时所发生的事情。”斯洛斯指出，SRE团队“负责他们服务的可用性、延迟、性能、效率、变更管理、监控、紧急响应和容量规划。”SRE专注于编写软件来自动化流程和消除辛劳。

与Devops类似，SRE分解了开发人员和操作筒仓，因此组织可以以更高的速度交付应用程序和服务。SRE可以被视为Devops规范。
重要的是，SRE团队负责维护和建立服务水平指标、目标和协议。SLI是对所提供的服务水平的某些方面的定量度量，如请求延迟。SLO是由SLI测量的服务水平的目标值或值范围。例如，99.9999%的服务可用性。SLA是与用户的显式或隐式契约，其中包括丢失SLO的后果。SRE团队必须平衡维护某些SLO的成本和业务目标，如创新和快速部署。
有助于简化SRE工作的解决方案类别包括监视、警报/事故管理、票务、日志记录、故障排除、配置管理和可靠性测试。正如下面的展览所指出的那样，我们已经看到了帮助SRE更有效地工作的大企业的出现。

有助于减少平均分辨率时间(MTTR)和提高服务正常运行时间的解决方案对SRE具有最高价值。毕竟，谁想在凌晨2点随叫随到处理火灾？！单独防止失眠和通宵表明SRES愿意为让他们的生活更轻松的解决方案付费。我们仍然相信在这个领域有令人兴奋的机会，历史表明这些业务可以是巨大的。