"一周内上线"是一个很恐怖的任务。我们目前有十几个团队编写出的几万行的shell脚本。虽然我们能够快速分析任何一个集群的问题所在，但是修复它意味着十几个团队不得不提交数百个Bug，接着我们就只能希望这些Bug 能被及时地解决。

我们意识到，从"Python 单元测试发现错误配置"到"Python代码修复错误配置"的演进能够使我们更快解决这些问题。

单元测试已经能够指出被检查的集群中哪个测试失败，我们就给每个测试增加了一个修复程序。如果每一个修复程序都具有幂等性，并且假设所有的依赖关系都得到满足，那么修复问题就是简单而安全的。强调修复程序的幂等性意味着团队可以每 15分钟运行一次他们自己的"修复脚本"，而不用担心对集群配置造成损害。如果DNS团队的测试在等待机器数据库团队对新集群的配置，只要该集群出现在数据库中，DNS 团队的测试和修补程序就会立刻开始工作。

以图7-2 展示的测试为例。如果TestDNSMonitoringConfigExists失败，我们可以调用FixDNSMonitoringCreateConfig，这样会从一个数据库中将配置去掉，然后将一个骨架配置文件提交到版本控制系统中。接下来重试TestDNSMonitoringConfigExists成功，然后就可以进行TestDNSMonitoringConfigPushed测试。如果测试失败，就运行FixDNSMonitoringPushConfig。如果一个修复程序失败多次，自动化系统假设这个修补程序失败、并且会停止进行，通知用户修复。

图7-2∶DNS 服务的ProdTest，体现了-个失败测试的后果仅仅是多运行-个修复程序，左侧是测试，右侧是对应的修复程序。

有了这些脚本后，一小组工程师可以保证我们能够在一个或两个星期内从"网络就绪以及机器在数据库中存在"发展到"服务网络搜索和广告流量的1%流量"。在当时，这似乎达到了自动化技术的巅峰。

然而，现在回头来看，这种方式本身是存在严重缺陷的;在测试、修复、再测试之间的延迟引入了"不稳定"的测试，时好时坏。并不是所有的修复程序都具有幂等性，所以一个"不稳定"的测试引起的一次修复可能造成系统处于不一致的状态。

"一周内上线"是一个很恐怖的任务。我们目前有十几个团队编写出的几万行的shell脚本。虽然我们能够快速分析任何一个集群的问题所在，但是修复它意味着十几个团队不得不提交数百个Bug，接着我们就只能希望这些Bug 能被及时地解决。

我们意识到，从"Python 单元测试发现错误配置"到"Python代码修复错误配置"的演进能够使我们更快解决这些问题。

单元测试已经能够指出被检查的集群中哪个测试失败，我们就给每个测试增加了一个修复程序。如果每一个修复程序都具有幂等性，并且假设所有的依赖关系都得到满足，那么修复问题就是简单而安全的。强调修复程序的幂等性意味着团队可以每 15分钟运行一次他们自己的"修复脚本"，而不用担心对集群配置造成损害。如果DNS团队的测试在等待机器数据库团队对新集群的配置，只要该集群出现在数据库中，DNS 团队的测试和修补程序就会立刻开始工作。

以图7-2 展示的测试为例。如果TestDNSMonitoringConfigExists失败，我们可以调用FixDNSMonitoringCreateConfig，这样会从一个数据库中将配置去掉，然后将一个骨架配置文件提交到版本控制系统中。接下来重试TestDNSMonitoringConfigExists成功，然后就可以进行TestDNSMonitoringConfigPushed测试。如果测试失败，就运行FixDNSMonitoringPushConfig。如果一个修复程序失败多次，自动化系统假设这个修补程序失败、并且会停止进行，通知用户修复。

图7-2∶DNS 服务的ProdTest，体现了-个失败测试的后果仅仅是多运行-个修复程序，左侧是测试，右侧是对应的修复程序。

有了这些脚本后，一小组工程师可以保证我们能够在一个或两个星期内从"网络就绪以及机器在数据库中存在"发展到"服务网络搜索和广告流量的1%流量"。在当时，这似乎达到了自动化技术的巅峰。

然而，现在回头来看，这种方式本身是存在严重缺陷的;在测试、修复、再测试之间的延迟引入了"不稳定"的测试，时好时坏。并不是所有的修复程序都具有幂等性，所以一个"不稳定"的测试引起的一次修复可能造成系统处于不一致的状态。