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

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

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

自动化 与GoogleSRE 联系

---

自动化价值

1. 一致性

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

2. 平台性

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

3. 修复速度更快

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

4. 行动速度更快

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

5. 节省时间

操作与人解耦

---

自动化对Google SRE 的价值

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

---

自动化使用案例

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

---

Google自动化使用案例

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

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

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

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

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

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

Google 的自动化与实例

---

自动化演进遵循的路径

1. 没有自动化

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

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

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

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

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

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

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

5. 不需要任何的自动化系统

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

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

---

自动化数据库操作

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

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

---

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

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

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

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

变化导致自动化难以维护

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

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

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

Borg: 仓库规模计算机的诞生

1. 把集群管理变成可以发送API 的中央协调主题
2. 最终使得连续性，自动化的操作系统升级只需要很少的持续工作，这种工作不会根据生产部署的总规模而增加
3. 可靠性是最基本的功能

为了有效进行故障测试，自我检查中所依赖的内部运作细节也应该暴露给管理整体系统的操作员