1.1 传统运维团队

为Toil（这里指需要重复手动操作的工作）工作设定上限的目标是避免回到一个人们将大部分时间花在减少Toil上的运维团队，这些Toil会随着服务规模和软件的发展而累积。

在服务采用不断增长的过程中，部分累积的To i l是，如果警报策略还没有准备好进行扩展，那么运维团队会收到大量警报。如果你正在维护的软件每天为每个租户创建一个警报，让一个工程师忙于运行10个租户，那么你将需要根据团队运维的租户数量线性扩展on-call的工程师数量。这意味着为了将租户数量增加一倍，你需要将专门响应警报的工程师数量增加一倍。这些工程师将无法在减少To i l并调查问题的同时有效地减少警报带来的Toil。

在传统的运维团队中，OpenShift是作为公司其他部门的开发平台来运维的，接入新租户通常是一项手工任务。它可能由请求团队发起，创建一个ticket来请求新OpenShift集群。运维团队中的某个人收到这个ticket，开始创建所需的资源，启动安装程序，配置集群，以便需求团队获得访问权限，等等。当不再需要集群时，可以设置一个类似的过程来销毁集群。管理OpenShift集群的生命周期可能是一个巨大的Toil来源，只要这个过程以手动为主，Toil就会随着服务的采用而增加。

手工生命周期和配置管理除了是费力的工作之外，还容易出错。当工程师在一周内多次运行相同的操作时，正如团队管理的Wiki中所记录的那样，他们很可能会错过重要的步骤或将错误的参数传递给任何脚本，从而导致可能无法立即发现的破坏状态。

在管理多个OpenShift集群时，由于创建或配置过程中的错误，甚至由于客户请求，其中一个集群与其他集群会略有不同，这是危险的，并且通常会产生更多的Toil。

随着时间的推移，团队生成的自动化可能不会针对单个集群的具体情况进行定制。运行自动化可能是不可行的，这会给运维团队带来更多的Toil。在最坏的情况下，它甚至可能导致集群不可用。

传统运维团队的自动化通常可以在一个中央存储库中找到，这个存储库可以在工程师设备上检出，这样他们就可以运行需要的脚本，作为处理文档化流程的一部分。这会带来很多问题，不仅因为它仍然需要手动交互，从而不能很好地扩展，还因为工程师的设备通常配置不同。这些设备可能使用不同的操作系统，增加了在工具中支持不同供应商的需求，例如，通过提供标准化环境（如容器环境）来运行自动化。

但即便如此，要运行的脚本版本也可能因工程师而异，或者要运行的脚本在其应该更新时没有得到更新，因为OpenShift的新版本已经发布了。自动化测试很少用于操作脚本，而这些操作脚本可以快速地摆脱一些Toil。所有这些都使得在开发人员机器上运行的脚本自动化变得脆弱。