原文地址：https://lukeshaughnessy.medium.com/infrastructure-as-code-is-not-the-answer-cfaf4882dcba
以下是译文
当然，你听过销售宣传。如果你在 DevOps、平台或 SRE 领域工作，那么你可能已经自己推销过它。基础设施即代码（Infrastructure as Code）！其好处多种多样且不言自明：
• 它是可复制的！
• 它是自文档化的！
• 它是可见的！
• 它可以防止错误发生！
• 它能降低成本！
• 它可以防止偏移（drift）发生！
• 它可以避免重复劳动，增加工作乐趣！
• 自助服务！
毫无疑问，所有这些事情都可能是真的可以实现的。在理想的世界里，所有这些好处都将显而易见，并且对于愿意投入前期资金将基础设施部署转换为代码和配置管理的任何组织都将大有裨益。而我们大多数人也确实如此。但是，那些不在理想世界中的事情呢？采用 IAC 存在哪些实际成本、风险和困难？在现实的光芒下，华丽销售宣传在哪里开始融化了呢？让我们看一下上面提到的一些优点，并检查其中的一些假设。
它是可复制的！
嗯，有点道理。我会说基础设施代码在一段时间内是非常可复制的 —— 但是随后...事情变得不稳定了。软件包过时了。功能被弃用并停止工作。代码语法发生了变化。镜像不再可用。Dockerhub 要你付费。某些用户账户已经建立，而他们已经不再在这里工作了。许多相互依存的依赖关系使得部署正常运行，但它们随时间改变。重点是部署代码具有一定的寿命，如果你不不断地更新它，当你突然需要它时，它将不起作用。
译注：意思是虽然基础设施的代码是被版本化的，是稳定的。但是它所依赖的东西却可能是不稳定的。
它是自文档化的！
同样，有点道理。然而，这个论点有几个缺陷。第一个问题与上面提到的问题有关。你的代码在一段时间后开始变得陈旧不堪。这意味着，第一次查看你的代码的工程师可能会开始追寻兔子洞，试图使一些旧模块在新的云环境中运行，在那里许多关于如何完成任务的假设已经不再适用。我有同事花了数天时间来追查失败的部署，并一步步调试，因为他们在代码中看到的内容与现实不符而感到完全困惑。事实上，如果他们重新开始编写新代码，可能会更快、更好。
译注：是代码就会有代码质量问题。作者所言的问是他使用的老模板的依赖发生了变化，导致老模板的失败。
第二个问题是，我认为代码真的不适合作为文档。我自己写过代码，六个月后回来看，我完全想不起我当时做了什么。在编写代码时，你可能会使用各种各样的技巧、半成品和明显错误的东西，因为很可能在做的时候还在学习相关知识。回头再看这些代码时，你会发现其中存在许多混乱和难以理解的部分。基础设施代码同样存在这些问题，它可能会包含各种不稳定的假设和方法。这些假设和方法可能会使其他工程师在查看时感到困惑或无法理解。
译注：只要是代码，都会遇到同样的问题。作者说的是代码的可读性问题。
它是可见的！
是的，它是可见的 —— 就像我在 CTO 的办公室角落用西里尔字母喷涂标语一样。这会很酷也很叛逆，但没有人知道它说了什么。问题在于代码，嗯，是 _代码_。这不是非工程师可以轻易阅读的内容，甚至对于不熟悉 Terraform 或其他技术的工程师来说也不容易阅读。理解其中的信息需要实践和培训，有时即使经验丰富的工程师也需要一些时间才能完全弄清楚所有信息的位置，特别是如果你有很多嵌套文件、依赖项和调用脚本的脚本。重点是，是的，你可以看到它，但这并不意味着你可以迅速或轻松地理解它。
译注：其实，这并不是什么问题，我们可以想办法根据代码生成基础设施的图。
它可以防止错误发生！
或者，它可以像氢弹核心周围的重氢外套一样放大它们。我曾经听过一个故事，说有个工程师在他的笔记本电脑上运行了“terraform destroy”命令——但是在错误的标签页上。他处于“Prod”目录下，并开始对生产环境进行摧毁。意识到自己的错误后，他按下了Control-C退出了命令，但为时已晚。很多东西已经消失了，除此之外，终止进程也让状态文件处于混乱状态。他们通过手动修复状态文件并重新运行terraform来恢复了它，并在几个小时内解决了这个问题。但这是一个非常容易犯的错误，任何人都可能会犯。
译注：作者说的案例是流程上问题。即使不使用基础设施即代码也会发生同样的问题。但是这个问题从侧面说明的是基础设施即代码需要配上一定的操作流程。
它能降低成本！
如果一切都完美地运作，从不发生变化，而且您一直做同样的事情，那当然可以。但根据我的经验，保持代码更新需要花费工程师大量时间和精力。工程师每天需要花费数小时进行调试、故障排除、学习和编写代码。如果你只是登录控制台并点击一些框，可能只需要几分钟就能完成的任务，可能需要数天的工作才能自动化完成。如果您经常使用自己的代码，那么它值得投资。但您需要认真考虑自己有多少次实际上会部署新的RDS实例或新的Cloudfront分发？其中许多任务只需完成一次，您可能永远不会再做了。你真的需要花费数天时间来自动化这个过程吗？
译注：作者说的是基础设施的规模问题。也就是我们在实践基础设施即代码时，需要考虑基础设施的规模。
它可以防止偏移（drift）发生！
只有当您创建代码以更改环境中的内容时，这才是正确的。一旦一个人拥有控制台的访问权限，你就可能会遇到“漂移”问题。那么这个神经病般的罪犯是谁，在控制台上不断进行变更呢？嗯，有时候就是你自己。因为出现了故障，你需要在负载均衡器中添加新的证书，或者因为你正在受到DDOS攻击，需要添加CloudFront分发来吸收传入请求。或者因为你需要将某些东西进行规模扩展以处理意外负载。现在显然，你可以事后回过头来重新编写你的代码，以反映你所做的更改。这看起来很愚蠢，但在我的经验中，这种情况在现实世界中经常发生。
译注：作者说的基础设施即代码中经常遇到的问题：界面操作先于代码操作。这种情况在实际情况会有发生，但是要看频繁程度和规模。如果经常发生，且界面上进行大量的操作，那么，这其实需要在流程上控制，且说明之前的基础设施的设计就存在问题。
它可以避免重复劳动，增加工作乐趣！
你想处理一些琐碎乏味的任务吗？比如将Terraform 0.10版本升级到1.3版本？这个过程中有相当多的语法变化，尽管一些自动化工具可以帮助处理。但是旧版本的Terraform需要很多奇怪的解决方法，而这些问题在新版本中已得到改进并增加了新功能。因此，仅仅使用自动化工具来重新处理语法是不够的，你需要全面重构整个代码库。我有同事已经进行了一年以上的Terraform迁移工作。这是一个需要投入许多工程师小时数才能更新的巨大工作。有时候很难说服老板这么做，特别是如果你已经消耗了所有的好感度以及花费几个月时间创建代码。
译注：这段文本谈到了如何将Terraform代码库从0.10版本升级到1.3版本，需要进行全面重构和大量工程师时间的投入。此外，这也涉及到旧版本的一些语法变化和解决方案，而新版本已经增加了新功能和改进。这种更新过程可能会被认为是琐碎乏味的任务，但它是必要的，因为它可以提高代码质量和可维护性。然而，向老板证明这种更新的必要性有时可能很难，尤其是当团队已经花费了大量时间创建代码并消耗了所有好感度时。
自助服务！
平台团队的终极目标是为整个公司打造一个自助PAAS（平台即服务）系统。所有基础设施和服务都经过了彻底的自动化，以至于非DevOps工程师可以拉取git存储库，编辑一些模板文件，然后将其推回，并且你的CI/CD系统会自动部署它们。所有的日志记录、警报、指标和安全策略都已经内置。我真的很喜欢这个想法，我正在努力让我的当前公司达到这个状态。但这又与现实相冲突。例如，我们曾经有一个非常复杂的自动化系统来管理Github中的用户账户。我们会编辑文件，将它们推送到CI中，然后用户和repo就会被填充。然而，我们意识到这是不必要的复杂性，显著减缓了新员工的入职进度，因为他们需要等待技术人员编辑自动化文件。直接确保团队经理经过审核并接受了安全策略的培训并获得直接访问Github，比起使用自动化管理用户账户更容易快速。我们相信他们会正确地点击来添加新账户并授予权限。
译注：作者举了一个Github用户授权管理的例子，想说明的是并不是基础设施并不一定要所有都通过“Code”来实现，有时通过界面点点可能效率更高。
总结
这是否意味着我们放弃IAC的整个想法而重新回到在控制台上点击操作呢？当然不是。我认为这是最好的答案。就像过去的好主意一样——比如敏捷开发、Scrum、DevOps、无服务器计算、微服务——它们都可以带来很大的价值。你不能固执地认为你必须全身心地致力于这个想法。IAC有其使用场景，但仅仅是一个使用场景而已。并非每种情况都相同，总存在一些魔鬼般的细节需要应对。一个好的工程师或工程经理会知道何时该放弃自动化完美的柏拉图式理念，允许人们在必要时灵活一些。
也许你想了解更多Everything as Code:
请关注我：