最近，我撰文探讨了技术谬误带来的危险，其中最令人沮丧的之一就是关于"最佳实践"的讨论。根据我的经验，这种思维模式会导致技术团队陷入过多无意义的讨论，随后进行无休止的概念验证工作，只为寻找那个并不存在的完美工具。事实上，大多数组织需要的不是最好的，而是"足够好"的解决方案，这样他们才能继续推进业务。

但这种错觉在云环境中会产生更严重的后果。当你仅基于"最佳实践"的要求选择工具时，可能会损害云架构的完整性。如果不考虑具体情境，你的选择可能会违反数据中心设计的一个神圣原则——最小化故障域的范围。

对许多人来说，云对底层网络的抽象降低了原本看似神秘知识的复杂性。这也让开发团队不再受制于看似反复无常的网络工程师带来的恐惧。然而，基础设施即服务（IaaS）的缺点在于，这种同样的模糊性使得那些没有传统数据中心设计背景的人容易在容错方面犯下关键错误。

我们都听说过那些恐怖故事：云应用程序因为只部署在单个可用区（AZ）或区域而失败。更糟糕的是，由于跨可用区或区域的应用程序依赖关系而发生的部分中断。虽然在物理数据中心中这种情况仍然可能发生，但那时更加明显，因为你可以看到系统在机架中的位置，而且当你没有构建容错能力并阻碍了网络工程师计划中的维护窗口时，他们会直接指出问题。

如今，组织通常使用各种软件即服务（SaaS）应用程序，却不知道正在使用哪些底层云提供商或这些服务是如何设计的。虽然这种简单性通常对业务有益，因为它提高了服务交付的速度，但也可能产生盲点，违反与IaaS相同的故障域原则。只有最执着的技术专家才能揭示这些应用程序的内部工作原理，以确定它们的部署方式是否与组织的基础设施设计保持一致。

不幸的是，业务部门并不总是理解这种细微差别，可能会陷入"最佳实践"的谬误，导致由于过大的故障域而形成脆弱的环境。通过用SaaS替代本地缓慢的系统，组织往往接受了与风险相关的另一组问题。

最终，在选择功能时，更好的建议是"与带你来的云共舞"。与其担心"最佳实践"，不如在可行的情况下利用云提供商的服务，选择更接近你基础设施的技术。这将为你的组织带来更好的技术架构，因为云提供商确保其托管服务具有低延迟、弹性和高可用性。虽然这并不总是可能，但在选择和实施解决方案时考虑故障域原则，你将能为组织实现更好的服务交付。