问题描述
在进行DevOps转型的过程中，一位用户想说服团队和管理层采用“快速失败”（Fail Fast）原则。用户提到亚马逊有“秉持行动”和“很多时候是正确的”的两个原则，他认为这两个原则与Fail Fast有相似之处。然而，用户遇到了一个困境，特别是在采用新解决方案时。作为一家企业，他们倾向于先评估多种产品，然后进行多个概念验证，最后进行公开招标。这种方法浪费了时间和资源。用户认为应该基于技术和财务优势快速决定一个解决方案，并开始使用它。如果失败了，可以选择另一种技术。用户认为，对技术的决策并不是一个大问题，而DevOps不就是要灵活并快速获得反馈吗？用户希望了解您的意见。
解决方案
用户在追求快速失败（Fail Fast）原则时，需要权衡以下两个主要缺点：
技术债务： 尽管在架构和设计中应用“快速失败”的理念可能很诱人，但跳过或缩短设计阶段将是一个错误。快速失败应该与良好的设计实践结合使用，而不是代替它们。草率的决策通常会导致扩展性不足的解决方案。例如，当你处理100MB数据库生成报告时，使用MySQL似乎是一个不错的选择，但在处理数TB范围的归档报告时，它的扩展性会变得很差。在运行重叠DNS区域时使用DNSMasq可能在政治上是一个不错的决定，但几年后迁移到不重叠的上游区域将变成一场噩梦。
成本： 技术可能是昂贵的。购买一个解决方案，然后在不久之后将其丢弃并开发一个替代方案，会产生巨大的浪费性开支。但更昂贵的是人员的时间开销。薪水是每家公司最大的开销。浪费时间开发一个解决方案，然后将其丢弃并开发替代方案是极其低效的。
然而，这并不意味着决策瘫痪或分析瘫痪不是问题。它是！但“快速失败”并不是最好的方式来解决这个问题。有其他更为经过验证的方法可以解决这个问题，而不会牺牲良好的设计原则。
用户评论
用户提到了一些情况，让我们进一步探讨如何应用Fail Fast原则：
有限时间的概念验证： 用户认为有限时间的概念验证无法覆盖未来问题。在进行公开招标的过程中，选择最便宜的解决方案可能会导致技术债务。公开招标的过程可能会导致将需求降至最低公分母，而不是追求理想最佳解决方案。用户认为最佳做法是从上游开源版本开始，逐步适应并了解更多。初步的决策步骤不需要急于选择企业付费解决方案。
在合适的时机理解机会： 用户认为要在合适的方式中理解机会。如果你提出一个想法，独自进行一段时间的编码，然后将其发布给用户，你可能会失败，但并不是你所期望的方式。更好的方法是，提出一个想法，明确表述你为什么认为这是一个好主意的假设，然后与潜在客户验证这个想法，看看他们的看法。这将为你提供一个很好的机会，来澄清和完善想法，甚至可能在编写代码之前就将其否决。
无论如何，快速失败是一个灵活的方法，但在决策过程中，应该平衡好短期和长期的考虑，以及技术和经济的因素。在合适的场景中采用Fail Fast原则可以提高创新效率，但在某些情况下，需要更加深思熟虑。