不同业务的回退需求有很大不同。要确定如何建立你自己特定的回退需求，那么至少从扩展的角度应该问的问题是，何时你才能得到足够的性能信息以确定你是否需要撤销近来的变更。许多公同的最低条件是保证每周工作日的峰值用量在分析结果中没有异常。对于修改现有的功能来说，这个最低条件已经足够了，但当要添加新功能时，这个条件可能就不够了。
不同业务的回退需求有很大不同。要确定如何建立你自己特定的回退需求，那么至少从扩展的角度应该问的问题是，何时你才能得到足够的性能信息以确定你是否需要撤销近来的变更。许多公同的最低条件是保证每周工作日的峰值用量在分析结果中没有异常。对于修改现有的功能来说，这个最低条件已经足够了，但当要添加新功能时，这个条件可能就不够了。新功能通常都有一个采用曲线，对于该功能，要获得足够的流量以确定它对系统性能的影响，天的时间是不够的。 对于任何 新功能，一段时间内收集的数据量也可能对性能产生 负面影响，从而影响你的可扩展性。
让我们再来看看AllScale公司的约翰尼，菲克斯和HRM应用。约翰尼的团队在忙于给HRM系统的简历跟踪部分实现一个“分隔度”的功能。这个功能的思路是让系统找出公司内的一-些员工，这些员工是与候选人认识的，或者是认识与候选人相熟的人，这样就可以通过个人关系了解候选人的背景。这个功能的输人是当前员工曾经工作过的所有公司以及候选人曾经工作过的公司列表。约翰尼的团队最初认为采用线性检索就可以了，因为可选的公司列表以及得到的重合的公司列表可能都不大。
新功能被发布后，在接下来的几周中，开始计算关系映射表。开始时，一切正常，约翰尼的团队对应用的结果和运行时间都很满意。但随着候选人列表增大，候选人曾经工作过的公同的列表也随之增大。此外，随者AllSeale公司发展，它的员工数量也增加了，于是关系树也随着打大。很快，许多依赖于分隔度功他的进程开始运行超时，客户逐渐变得愤怒了。
于是开始进人危机管理流程，约翰尼的团队迅速发现了罪魁祸首是分隔度功能。约翰尼和整个团队一起工作，认为这个团队可以在一天内修改这个功能，采用更有效的检索算法，然后测试它，在30个小时之内把修改过的版本发布到姑点上。而CEO克里斯蒂娜关心的是如果不在几个小时内修复这个问题，会造成重大的客户流失。
如果约翰尼果纳了我们)的建议，确保可以回退到上个发布的版本，那么只是回退代码，然后当问题修就后再发布它就可以了，这里很设他的回退流程允许他回退E天前发布的代码。虽然这样可能会给用户造成些困惑，但提示相应的消息就有助于控制混乱，而且约榆尼可以在两天内发布新的代码，使这个功能正常运行，无损于当前的可扩展性。如果约愉尼不采用我们的建议，或者约輸尼的回退流程只允许在发布之后的六个小时内进行回退，那么我们猜约翰尼的观念一定会有所转变，转为要确保一直具备能够满足他需求的回退流程了。
对于回退窗口的大小，最后个要 考虑的因索是你发布的频率以及你需要能够回退多少个发布的版本。也许你的发布流程允许你-周之内在站点上，发布多个新功能。对于这种情况，如果任何新功他的采用率都要延伸到下一个发布周期才能稳定，那么你可能就需要一次回退多个发布的版本了。如果是这种情况，那么你的流程需要更加严谨一此，因为你要考虑的不是只有一个发布的版本，而是多个变更和多次发布。
回退窗口需求备忘录要确定执行回退必需的时间安排，应该考虑以下几点:
●你发布一个版本后，距离产品的第一个流量高峰期有多长时间?O是修改现有的功能还是发布新功能?
●如果是个新功能，它的采用曲线是怎样的?
●根据发布频率，我应该考虑回退多少次发布?我们称这为关于回退版本个数的需求。你的回退窗口应该允许你在新功能被大量采用(如采用率大于50%)后以及第一次使用高峰期之后或之中，还能够回退。
可能您还想看