停止杀牛：服务器基础结构建议

最好将您的基础结构像牛一样对待，直到涉及到故障排除为止。

如果您在DevOps会议上花费了足够的时间，您会听到用来描述服务器基础结构的短语“宠物与牛”。这个概念背后的想法是，传统的基础设施是手工建造的，没有太多的自动化，因此，服务器被视为特殊的宠物-您将尽一切可能使宠物活着，而您的名字就知道了，因为您手工-设计其配置。结果，如果复制服务器出现故障，将需要大量的精力来创建它。相比之下，现代DevOps概念鼓励创建“牛”，这意味着您可以使用自动化工具来构建服务器，而不是使用独特的手工制作的服务器来构建服务器，从而使任何单独的服务器都不是特殊的（它们全都是农场动物），因此，如果一台特定的服务器死了，那没问题，

如果您希望您的基础架构和团队规模扩大，那么将服务器更像是牛而不是宠物是有很多智慧的。不幸的是，这种方法也有一个缺点。一些管理员，特别是初级的管理员，已经将一次性服务器的概念扩展到影响其故障排除过程的程度。由于服务器是一次性的，并且系统管理员可以如此轻松地产生替换项，因此在特定服务器或服务出现问题的第一个提示时，这些管理员销毁并替换了它，希望替换项不会出现问题。本质上，这是1990年代（和Linux管理员嘲笑）使用的IT团队仅应用于云的“重启Windows机器”方法。

这种方法并不危险，因为它无效。确实很危险，因为它经常起作用。如果您在使用计算机时遇到问题并重新启动它，或者在使用云服务器时又将其销毁并重新生成，则问题通常会消失。因为该方法似乎可行，并且比实际执行故障排除步骤容易得多，所以这种成功将重新启动和重新生成作为首要手段，而不是应采取的最后手段。

故障排除之前重生或重新启动的问题在于，由于这样做后问题通常会消失，因此您不再可以执行任何故障排除来查找根本原因。为了扩大牛的隐喻，这就像射击每头有点呆滞或表现出感冒迹象的母牛，因为它们可能患有疯牛病，而实际上并未对该病进行测试。如果您不小心的话，您会发现自己已经解决了一个问题，直到问题蔓延到其他人群。在不知道根本原因的情况下，您将来无法采取任何措施来防止这种情况的发生，尽管当前问题可能不会造成重大故障，但是无法知道您下次是否会如此轻松地下车发生。因此，尽管您可以通过不进行故障排除来节省时间，但这是 是您从获得故障排除经验中浪费的时间。最终，您需要发挥故障排除的力量，如果您没有锻炼过，可能会发现自己无法解决的问题。

简而言之，自动化非常好，对于现代基础架构来说，能够快速轻松地重生任何主机至关重要，但不要将基础架构最佳实践变成故障排除最坏的实践。