1.2 站点可靠性工程如何提供帮助

在SRE团队中，目标是用实际的软件来替换这样的脚本，这些软件有正确的版本、成熟的发布策略、持续的集成和交付过程，并且在专用的机器上运行最新的发布版本，例如，OpenShift集群。

OpenShift SRE团队将OpenShift集群的操作（从设置到拆除）视为一个软件问题。通过将软件工程领域的最佳实践应用于集群操作，可以解决前面提到的许多问题。可以对软件进行单元测试，以确保新的更改不会破坏现有的行为。此外，一组集成测试可以确保即使在环境发生变化（例如发布新版本的OpenShift）时也能按预期工作。

随着服务采用的增长，SRE团队无须主动响应越来越多的客户请求，而是提供自服务流程，客户可以使用该流程来提供和配置集群。这也降低了雪花的风险，因为SRE团队需要更少的手动交互。什么可以配置，什么不可以配置，应该是提供给客户的用户接口（User Interface，UI）的一部分，因此将单个集群与所有其他集群区别对待的请求应该转化为对自动化或UI的特性请求。这样，它最终将成为一个受支持的状态，而不是手动配置更新。

为了确保警报策略可以扩展，SRE团队通常从基于原因的警报策略转换为基于症状的警报策略，以确保只有可能影响用户体验的问题才会触发告警。不需要立即解决的小问题可以在时间允许的情况下转移到ticket队列中处理。

向SRE文化的转变意味着允许人们监控自己的软件，一步一步地从团队中卸下操作负担。虽然这是一个需要时间的转变，但这是一个有益的过程。它将把一个运行别人编写的软件的团队变成一个编写和运行自己的软件的团队，其目标是在他们的控制下自动化软件的生命周期和操作。SRE文化通过真正的自动化和对客户体验的观察而不是内部状态来实现服务的增长。