|
虽然所有这些自动化步骤都是有价值的，同时自动化平台本身也是很有价值的。在一个理想的世界里，我们不需要任何平台之外的自动化进程。事实上，构建一个完全不需要胶合逻辑的系统要比有一个依赖外部的胶合逻辑的系统更好，不仅仅是因为内部化效率更高（尽管这样的效率提升很有价值），而是因为设计中将胶合逻辑排除在外了。这样做需要将胶合逻辑的具体用例——一般来说是对系统的直接操作，例如添加账户或执行系统集群上线——-用某种方法在应用程序中直接处理。
这里提供了一个更详细的例子，Google的集群上线系统自动化经常出现问题，因为这些最终是在核心系统之外维护的，因此经常受到"代码腐烂"（bitrot）的影响。也就是说，当基本系统变化的时候，上线自动化系统没有随之改变。尝试将两者（集群上线自动化系统和核心系统）更紧密地连接起来的努力常常会由于两个团队不一致的优先级定义而失败。产品的研发人员会——不能说不合理的——抵制对每一次改动都进行一次测试部署的要求。其次，关键性的，但是不经常执行的，以至于很难测试的自动化系统尤其脆弱，因为反馈的周期很长。集群故障转移自动化是一个经典例子∶故障转移可能每隔几个月甚至更长时间才发生一次，导致每次执行都不一致。自动化的演进遵循以下路径∶
1）没有自动化 手动将数据库主进程在多个位置之间转移。
2）外部维护的系统特定的自动化系统 SRE 在他或她的主目录中保存了一份故障转移脚本。
3）外部维护的通用的自动化系统 SRE 将数据库支持添加到了每个人都在使用的"通用故障转移"脚本中。
4）内部维护的系统特定的自动化 数据库自己发布故障转移脚本。
5）不需要任何自动化的系统 数据库注意到问题发生，在无须人工干预的情况下进行故障转移。
SRE讨厌手动操作，所以我们尽力创造不需要他们的系统。然而，有时手动操作是不可避免的。 同时，相对于在特定系统相关配置上变更的自动化，另外一种自动化是面向整个生产领域的变更。在 Google 这种高度集中的专有生产环境下，有大量的跨特定服务范围的变更存在——比如，对上游的Ch y服务器的变更，使访问更可靠的一个Bigtable客户端库的功能开关的变更等——这些变更也需要安全地管理，在必要的情况下进行回退。当变更数量超过一定量之后，这种全生产范围内的变更就不可能手动完成了，即使在这之前，对一个变更很小或者通过基本的重启＋检查就可以完成的流程进行人工监督是毫无意义的。
下面让我们使用内部案例研究来详细描述上文提到的这些要点。第一个案例研究的是如何利用有远见的工作来成功地实现了SRE 自我标榜的涅槃∶通过自动化将SRE 从整个流程中消除。
| 
转播
分享
淘帖
()