谷歌SRE自动化的应用案例
在运维行业中，自动化这个术语一般用来指代通过编写代码来解决各种各样的问题。尽管写这些代码的动机以及最终产生的解决方案本身往往区别很大。更广泛地说，在这一观点中，自动化是"元软件"，也就是操作其他软件的软件。正如我们之前暗示的，自动化有许多用例。下面是一个非详尽的例子列表∶
● 创建用户账户。● 某个服务在某个集群中的上线和下线过程。● 软件或硬件安装的准备和退役过程。● 新软件版本的发布。● 运行时配置的更改。● 一种特殊情况的运行时配置更改∶ 依赖关系的更改。
这个列表基本上可以无限扩展。
在 Google内部，上述所有使用案例都有，甚至更多。
然而，在Google SRE内部，我们主要负责运维基础设施，而不是管理那些穿过基础设施的数据的质量。这条分界线并不是完全清晰的——例如，我们会非常关注某个数据集在推送之后消失一半的情况，因此我们会针对这种粗粒度的差异报警。但对于SRE而言，具体修改系统中一些账户的某个子集的属性是相当罕见的。因此，自动化的情境通常是自动化管理系统的生命周期，而非系统内部的数据∶例如，部署新的群集服务。
即使如此，SRE的自动化努力也与其他组织所做的差距并不大。SRE使用不同的工具来管理自动化，同时关注的重点不同（我们接下来将会对此进行讨论）。
广泛使用的工具有 Puppet、Chef、cfengine，甚至 Perl都提供了自动化完成特定任务的方法，主要区别在于对帮助进行自动化的组件的抽象层次不同。Perl这种完整的语言提供了POSIX级别的接口，理论上在系统API层面上提供了一个基本上是无限的扩展范围。而Chef和Puppet则提供了一些"开箱即用"的抽象层，通过对这些抽象层的操作可以直接操作服务或者其他高级对象。这里的妥协十分经典∶高层次的抽象更容易管理和进行逻辑推理，但当你遇到一个"有漏洞的抽象"时，就会系统地、重复地甚至不一致地出现故障。例如，我们经常假设，将一个新的二进制文件发布到集群中是原子性的;该集群最终会全部变成新版本，或者全部维持旧版本。然而，现实中的行为很复杂∶集群网络中途可能会发生故障;物理机可能发生故障;与集群管理层的通信可能会失败，使系统进入不一致的状态;视具体情况不同，新的二进制文件可能安装了，但没有推送，或者推送了但是没有启动，或者启动了但是无法验证。没有几个抽象模型能够成功地模拟这些结果，大部分模型都会中止并要求人工干预。而那些真正糟糕的自动化系统甚至都不会这样做。
SRE在自动化领域有一系列设计哲学和产品，它们中的一些类似于一种不会特别详细地对高层次实体建模的通用部署工具，另外一些则类似于在非常抽象的层次上描述服务部署的语言。后者往往比前者更加通用，更符合通用平台。然而，我们生产环境的复杂性有时意味着前者是更容易采用的选择。
页:
[1]