如果你已经想到设计和实现回退保险策略是需要成本的，那么你完全正确。对于某些发布来说，这种成本还可能很高，会给发布成本增加10%或20%。但在大多数情况下，对于大多数发布，我们认为你都能够用低于发布成本或时间的1%的成本，实现有效的回退策略，因为通常你只是涉及在数据库或其他存储系统中以不同方法存储数据而已。保险不是免费的，但它的存在是有理由的。

如果你已经想到设计和实现回退保险策略是需要成本的，那么你完全正确。对于某些发布来说，这种成本还可能很高，会给发布成本增加10%或20%。但在大多数情况下，对于大多数发布，我们认为你都能够用低于发布成本或时间的1%的成本，实现有效的回退策略，因为通常你只是涉及在数据库或其他存储系统中以不同方法存储数据而已。保险不是免费的，但它的存在是有理由的。



我们的许多客户实施的流程没有遵循设计为能够回退的架构设计原则，不过所幸他们还有其他几个降低风险的步骤或流程。我们通常建议，CEO或相应产品或服务的总经理在同意违背可回退的架构设计原则之前，要签署书面风险协议，并且审查降低风险的计划(请参阅第16章)。理想的场景是，考虑到发布版本的规模和影响，当要具备回退能力所需的成本超过了回退带来的价值时，以小型、低风险的发布的方式违背可回退的架构设计原则。但遗憾的是，通常发生的情况是，为了赶上上市时机，往往会以大型、复杂的发布的方式违背可回退的架构设计原则。这种方式的问题在于，这些复杂的大型发布常常又是最需要具备回退能力的。

每当你的团队表明为某次发布实施回退策略的成本很高或者实现起来很困难时，你要要求他们想办法解决。通常都有简单的解决方法可以减少实施回退策略的成本，提高实现的可能性，例如实行短期的数据APP开发转移脚本。有时，相比确保一个发布可回退来说，减少复杂功能的复杂度更能大大降低该发布的风险。根据我们在AKF Patrers的咨询经验，许多团队成员开始时都说“我们不可能回退”，但在接受回退是可能的这一事实后，几乎对于任何难题，他们都能够提出建设性的解决方案。