自动化程序的不同体现在哪三个方面
自动化程序的不同体现在三个方面∶● 能力，即准确性。
● 延迟，开始执行后，执行所有步骤需要多久。
● 相关性，自动化所涵盖的实际流程比例。
最开始，我们的流程有如下特点∶能力强（由服务的所有者维护和运行）、高延迟（服务拥有者在他们的业余时间执行流程或者分配给新工程师来做），并且相关性高（服务拥有者知道现实世界已经改变并且能够修复自动化）。
为了减少集群上线的延迟，许多服务团队指导一个单独的"集群上线"团队来运行自动化。这个团队使用工单来启动每个阶段，这样我们就能够跟踪余下的任务，以及这些任务分配给了谁。如果关于自动化模块之间的人际互动发生在同一个房间里的人与人之间，集群上线就可以在更短的时间内发生。最后，我们的流程变成了能力强的、精确的，以及及时的自动化流程!
但是这个状态没有持续太久。现实世界是混乱的∶软件、配置、数据等都发生了变化，面这导致受影响的系统每天产生超过1000个独立变化。最受自动化Bug所影响的人不再是领域专家，因此自动化的相关性下降了（这意味着新的步骤被遗漏了），能力减弱了（新的功能开关可能导致自动化失败）。然而，这种质量的下降一段时间之后才会影响速度。
自动化代码和单元测试代码一样，当维护团队不再关心它与它所覆盖的代码仓库同步的时候就会逐渐死去。整个世界都在围绕代码改变∶DNS的团队增加了新的配置选项，存储团队改变了他们的包名，网络团队需要支持新的设备。
通过消除运维相关服务的团队维护和运行自动化代码的责任，我们创造了一个不合理的组织激励机制∶
● 某个最主要任务是加速现存的集群上线的团队是没有动力去减少服务运维团队在生产流程后期运维服务产生的技术负债的。
●一个不亲自运行自动化的团队是没有动力去建设一个能够很容易自动化的系统的。
● 一个产品经理的时间表如果不受低质量的自动化影响，他将永远优先新功能的开发，而不是简化和自动化。
最可用的工具通常是由那些每天使用它们的人写成的。类似的论点是，产品研发团队将会在保留一些生产运维知识的过程中受益。
集群上线流程再一次成为了高延迟的、不准确的、低能力的流程——最糟糕的结果。然而，一个不相关的安全方面的任务使我们摆脱了这个陷阱。当时，许多分布式自动化都依赖于SSH。从安全的角度来看，这是很笨拙的，因为人们必须拥有机器的root 权限才能运行大多数的命令。越来越多的人意识到，先进、持续的安全威胁迫使我们将 SRE的特权降到最低，仅仅满足完成其工作所需的最低的特权。我们不得不用一个支持认证、ACL驱动，以及基于RPC的本地管理进程来取代sshd，这被称为Admin服务器，它拥有本地执行更改权限。这样一来，没有人可以绕过审计跟踪来安装或是修改服务器。对Admin 服务器代码和Package仓库的修改通过代码评审来把关，这使得越权操作非常困难;赋予别人安装软件包的权限不会允许他们查看日志。Admin服务器会记录 RPC 请求者、全部参数，以及所有的RPC 的结果，以提高调试和安全审计功能。
页:
[1]