很长一段时间以来，Google的广告产品将数据存储于一个MySQL 数据库中。因为广告数据显然需要很高的可靠性，一个SRE 团队负责管理那些基础设施。从2005 年到 2008 年，我们认为广告数据库基本是在一种成熟的和可管理的状态下运行的。例如，我们已经将标准副本替换流程的常规工作中最糟糕的部分自动化掉了，但是没有将全部工作自动化。我们认为广告数据库已经管理得很好了，已经摘到了优化和规模方面的大部分的"低挂的果实"。然而，随着日常工作变得越来越容易，SRE 团队成员开始考虑下一级的系统研发∶将MySQL 迁移到 Google 的集群调度系统 Borg 之下。

我们希望这种迁移会带来两点主要益处∶

● 彻底消除对物理机/数据库副本的维护∶Borg 会自动安装新任务，或者重启出问题的任务。

●将多个MySQL实例安装在同一台物理机上∶利用容器化可以更好地利用计算机资源。

2008年年底，我们成功地在 Borg 上部署了一个原型实例。然而不幸的是，这带来了一个严重的新增困难。Borg的一个核心操作特点就是它的任务可以自动地移动∶Borg内部运行的任务，通常的移动频率达到了每周一次或两次。这样的频率对数据库的副本来说是可以接受的，对于主实例则不可接受。

当时，主实例故障转移过程每次需要30~90 分钟。由于我们在共享的机器上运行，同时需要进行内核升级而重启，我们每周都需要在正常的物理机故障率之外进行一些无关的故障转移。这一因素，加上系统中分片数量庞大的因素，意味着∶

●手动故障转移将消耗大量的人力时间，并且在最好条件下也只能给我们99%的可用性，这样比产品的实际业务需要低很多。

● 为了满足错误预算，每个故障转移的停机时间要小于30s。优化依赖人为操作的流程达到这一目标是不可能的。

因此，我们唯一的选择是自动进行故障转移。实际上，我们不仅仅需要自动化故障转移流程。

2009 年，广告SRE完成了自动故障切换后台程序，称为"决策者"。决策者程序可以在95%的时间内用小于30s的时间完成计划内和计划外的 MySQL数据库故障转移流程。随着决策者的诞生，MySQL On Borg（MOB）最终变成了现实。我们从不断优化基础设施以避免进行故障转移的模式转化为拥抱失败，承认故障是不可避免的，并因此通过自动化进行快速恢复的模式。

虽然通过自动化，我们可以在一个每周强制两次重启的世界里仍然保证 MySQL的高可用，但是这也带来了它自己的一套成本，所有的应用程序都必须增加很多错误处理逻辑。由于MySQL 开发世界中的常态是假设 MySQL实例是整个技术栈中最稳定的成分，这种改变意味着我们要定制类似JDBC这样的软件，以便对我们的故障环境更加宽容。然而，与决策者一起迁移到MoB上的益处对这些成本来说是很值得的。迁移到MoB之后，我们的团队在无聊的运维任务上花费的时间下降了95%。整个故障转移过程是自动化的，所以单个数据库任务中断不再给任何人发出紧急报警。

这一新的自动化的主要好处是，我们有更多的空闲时间花在改进基础设施的其他部分上。这些改进有一个连锁效应∶节省的时间越多，优化和自动化其他烦琐工作的时间就越多。最终，我们能够将数据库结构的变更也自动化了，这导致广告数据库的总运维成本下降了近95%。有人可能会说，我们已经成功地自动将自己从这项工作中自动化出来了。同时，在硬件资源方面也有了改进。迁移到 MoB的过程中释放了大量的资源，因为我们可以在同样的机器上运行多个MySQL实例，从而提高了硬件利用率。总的看来，我们最终解放了近 60% 的硬件资源，团队的硬件资源和工程资源都非常充足。

该例子描述了通过额外努力构建一个平台，而不是仅仅取代现有的手动流程的好处。下一个例子来自于集群基础设施组，描述了一些进行全自动化时可能遇到的更困难的权衡。

很长一段时间以来，Google的广告产品将数据存储于一个MySQL 数据库中。因为广告数据显然需要很高的可靠性，一个SRE 团队负责管理那些基础设施。从2005 年到 2008 年，我们认为广告数据库基本是在一种成熟的和可管理的状态下运行的。例如，我们已经将标准副本替换流程的常规工作中最糟糕的部分自动化掉了，但是没有将全部工作自动化。我们认为广告数据库已经管理得很好了，已经摘到了优化和规模方面的大部分的"低挂的果实"。然而，随着日常工作变得越来越容易，SRE 团队成员开始考虑下一级的系统研发∶将MySQL 迁移到 Google 的集群调度系统 Borg 之下。

我们希望这种迁移会带来两点主要益处∶

● 彻底消除对物理机/数据库副本的维护∶Borg 会自动安装新任务，或者重启出问题的任务。

●将多个MySQL实例安装在同一台物理机上∶利用容器化可以更好地利用计算机资源。

2008年年底，我们成功地在 Borg 上部署了一个原型实例。然而不幸的是，这带来了一个严重的新增困难。Borg的一个核心操作特点就是它的任务可以自动地移动∶Borg内部运行的任务，通常的移动频率达到了每周一次或两次。这样的频率对数据库的副本来说是可以接受的，对于主实例则不可接受。

当时，主实例故障转移过程每次需要30~90 分钟。由于我们在共享的机器上运行，同时需要进行内核升级而重启，我们每周都需要在正常的物理机故障率之外进行一些无关的故障转移。这一因素，加上系统中分片数量庞大的因素，意味着∶

●手动故障转移将消耗大量的人力时间，并且在最好条件下也只能给我们99%的可用性，这样比产品的实际业务需要低很多。

● 为了满足错误预算，每个故障转移的停机时间要小于30s。优化依赖人为操作的流程达到这一目标是不可能的。

因此，我们唯一的选择是自动进行故障转移。实际上，我们不仅仅需要自动化故障转移流程。

2009 年，广告SRE完成了自动故障切换后台程序，称为"决策者"。决策者程序可以在95%的时间内用小于30s的时间完成计划内和计划外的 MySQL数据库故障转移流程。随着决策者的诞生，MySQL On Borg（MOB）最终变成了现实。我们从不断优化基础设施以避免进行故障转移的模式转化为拥抱失败，承认故障是不可避免的，并因此通过自动化进行快速恢复的模式。

虽然通过自动化，我们可以在一个每周强制两次重启的世界里仍然保证 MySQL的高可用，但是这也带来了它自己的一套成本，所有的应用程序都必须增加很多错误处理逻辑。由于MySQL 开发世界中的常态是假设 MySQL实例是整个技术栈中最稳定的成分，这种改变意味着我们要定制类似JDBC这样的软件，以便对我们的故障环境更加宽容。然而，与决策者一起迁移到MoB上的益处对这些成本来说是很值得的。迁移到MoB之后，我们的团队在无聊的运维任务上花费的时间下降了95%。整个故障转移过程是自动化的，所以单个数据库任务中断不再给任何人发出紧急报警。

这一新的自动化的主要好处是，我们有更多的空闲时间花在改进基础设施的其他部分上。这些改进有一个连锁效应∶节省的时间越多，优化和自动化其他烦琐工作的时间就越多。最终，我们能够将数据库结构的变更也自动化了，这导致广告数据库的总运维成本下降了近95%。有人可能会说，我们已经成功地自动将自己从这项工作中自动化出来了。同时，在硬件资源方面也有了改进。迁移到 MoB的过程中释放了大量的资源，因为我们可以在同样的机器上运行多个MySQL实例，从而提高了硬件利用率。总的看来，我们最终解放了近 60% 的硬件资源，团队的硬件资源和工程资源都非常充足。

该例子描述了通过额外努力构建一个平台，而不是仅仅取代现有的手动流程的好处。下一个例子来自于集群基础设施组，描述了一些进行全自动化时可能遇到的更困难的权衡。