SRE Google运维解密——第7章 Google的自动化系统的演进

第7章 Google的自动化系统的演进

==================================================================

自动化与GoogleSRE 联系

自动化价值

一致性

可以准确执行重复可能出错的命令或者行为

平台性

可以搭建一个可扩展的平台，解放运维

修复速度更快

对于出错的处理更好的指定修复

行动速度更快

自动操作人来操作重复无意义的事情

节省时间

操作与人解耦

自动化对Google SRE 的价值

每一个组件自动化不合适
基本系统由快速原型开始
谷歌一般不会购买特定任务的软件，会选择自己去实现，因为自己所实现的接口有长期价值

自动化使用案例

创建用户账户
某个服务在某个集群中的上线与下线过程
软件或者硬件安装的准备和退役过程
新软件版本的发布
运行时配置的更改
一种特殊情况下的运行时配置更改：依赖关系的更改
…

Google自动化使用案例

从抽象层次的角度上来描述Google SRE 自动化使用

不会特别详细对高层实体建模的通用部署工具

生产环境复杂，容易被采用
类比于Perl 提供的POSIX 级别的接口

在非常抽象层次上描述服务部署语言

更加通用，更符合通用平台
类比于Chef ,Puppet

==================================================================

Google 的自动化与实例

自动化演进遵循的路径

没有自动化

如手动将数据库著进行在多个位置之间转移

外部维护的特定系统的自动化系统

如在某一主目录中保存一份通用故障转移脚本

外部维护的通用自动化系统

如将数据库支持添加到每个人都在使用的通用故障转移脚本

内部维护的系统特定的自动化

如数据库自己发布故障转移脚本

不需要任何的自动化系统

数据库注意到问题发生，在无需人工干预的情况下进行故障转移

手动操作不可避免
相对于特定系统相关配置上变更的自动化，另外一种自动化是面向整个生产领域的变更

自动化数据库操作

让自己脱离工作，自动化所有东西。形成一个良性的循环

将标准副本替换流程的常规工作最糟糕的部分自动化掉，但没有全部自动化
将mysql 迁移到Google集群调度系统Brog 之下，部署了一个原型实例，但需要手动故障转移，满足不了需求
完成自动故障切换后台程序，“决策者”。快速进行数据库故障转移流程。
在应用程序中增加许多错误处理逻辑

将自动化应用到集群上线中

使用Prodtest检测不一致情况
幂等的解决不一致情况

单元测试指出哪个测试失败，在失败的地方增加修复程序解决问题

对问题进行幂等修复
在测试，修复，再测试之间的延迟引入了不稳定测试，时好时坏。并不是所有的修复程序都具有等幂性，一个不稳定的测试可能造成系统处于不一致的状态
3. 专业化倾向
自动化程序的不同体现在三个方面
1 能力
2 延迟
3 相关性

变化导致自动化难以维护

安全认证一定程度上摆脱了自动程序三个方面的不佳

Admin 服务器 , 支持认证，ACL驱动，以及基于RPC本地管理进行。拥有本地执行更改权限，所有人必须经过审计跟踪来安装或者修改服务器其。对Admin服务器和Package 仓库的修改通过代码评审来把关。Admin 服务器会记录RPC 请求者，全部参数，以及所有RPC的结果，以提高调试和安全审计功能。

服务为导向的的集群上线流程
找到一种以服务为导向的架构（SOA）来解决集群上线问题的方法：服务拥有者将负责创建一个Admin服务器，处理系统在集群就绪后发出的上线/下线RPC。反过来，每个团队按照合同提供自动上线所需要的自动化，然而可以随意改变底层实现细节。随着一个集群进入“网络就绪”，自动化系统将给每个负责上线的Admin的服务器发送RPC。