将你的基础设施视为“牲畜”是很棒的——直到需要进行故障排除时。

如果你在 DevOps 会议上待过足够的时间，你一定听过用“宠物与牲畜”来描述服务器基础设施的说法。这个概念背后的想法是，传统的基础设施是手工构建的，没有太多的自动化，因此，服务器更像是特殊的宠物——你会尽一切努力来保持你的宠物活着，并且你通过名字认识它，因为你手工制作了它的配置。因此，如果服务器宕机，创建重复的服务器将需要大量的努力。相比之下，现代 DevOps 概念鼓励创建“牲畜”，这意味着你不使用独特的手工制作的服务器，而是使用自动化工具来构建你的服务器，这样就没有哪个单独的服务器是特殊的——它们都只是农场动物——因此，如果某个特定的服务器死了，也没关系，因为你可以使用你的自动化工具在短时间内重新生成一个完全相同的副本。

如果你希望你的基础设施和你的团队能够扩展，那么将服务器更多地视为牲畜而不是宠物是有很多智慧的。不幸的是，这种方法也有缺点。一些管理员，特别是那些级别较低的管理员，已经将可丢弃服务器的概念扩展到影响了他们的故障排除过程的地步。由于服务器是可丢弃的，并且系统管理员可以很容易地生成替代品，因此一旦某个特定的服务器或服务出现问题的迹象，这些管理员就会销毁并替换它，希望替换的服务器不会出现问题。本质上，这就是 20 世纪 90 年代 IT 团队使用的“重启 Windows 机器”的方法（Linux 管理员对此嗤之以鼻），只是应用于云环境。

这种方法之所以危险，不是因为它无效。它之所以危险，恰恰是因为它通常有效。如果你有一台机器出现问题并重启它，或者如果你有一个云服务器出现问题并销毁并重新生成它，通常问题确实会消失。因为这种方法看起来有效，而且比实际执行故障排除步骤更容易，所以这种成功反过来又强化了重启和重新生成作为首选方法，而不是它应该成为的最后手段。

在故障排除之前重新生成或重启的问题在于，由于问题在这样做之后通常会消失，你将无法再进行任何故障排除来追踪根本原因。为了扩展牲畜的比喻，这就像射杀每一头有点迟钝或出现感冒迹象的奶牛，因为它们可能患有疯牛病，而实际上并没有对奶牛进行疾病检测。如果你不小心，你会发现你让一个问题得不到治疗，直到它蔓延到你的其余牛群。在不了解根本原因的情况下，你无法采取任何步骤来防止它在未来发生，而且尽管当前的问题可能没有造成重大中断，但无法知道下次发生时你是否会如此轻松地摆脱困境。因此，尽管你可能通过不进行故障排除来节省时间，但那是你从获得故障排除经验中损失的时间。最终，你将需要锻炼你的故障排除能力，如果你没有锻炼它，你可能会发现自己遇到了一个无法解决的问题。

简而言之，自动化很棒，并且在现代基础设施中能够快速轻松地重新生成任何主机都非常重要——只是不要将这种基础设施最佳实践变成故障排除的最差实践。