后备窗口要求

不同业务的回滚要求非常不同。要确定如何设置自己的特定回退要求，至少从扩展角度提问的问题是，何时获得足够的性能信息以确定是否需要撤消最近的更改。许多公共资源的最低条件是确保分析结果中每周的峰值使用率不异常。此最小条件足以修改现有功能，但是当添加新功能时，这种情况可能还不够。

不同业务的回滚要求非常不同。要确定如何设置自己的特定回退要求，至少从扩展角度提问的问题是，何时获得足够的性能信息以确定是否需要撤消最近的更改。许多公共资源的最低条件是确保分析结果中每周的峰值使用率不异常。此最小条件足以修改现有功能，但是当添加新功能时，这种情况可能还不够。新功能通常有曲线。对于此功能，要获得足够的流量来确定其对系统性能的影响，时间是不够的。对于任何新功能，随着时间的推移收集的数据量也会对性能产生负面影响，从而影响您的可伸缩性。让我们来看看AllScale的Johnny，Ficks和HRM应用程序。 Johnny的团队正忙于为HRM系统的简历跟踪部分实施“分离”功能。这个功能的想法是让系统找出公司中知道候选人或知道候选人的一些员工，以便通过个人关系理解候选人的背景。此功能的输家是当前员工所服务的所有公司以及候选人所服务的公司的列表。 Johnny的团队最初认为可以使用线性搜索，因为可选公司列表和重合公司列表可能不会很大。发布新功能后，在接下来的几周内，将计算关系图。一开始，一切都很好，Johnny的团队对应用程序的结果和运行时非常满意。但随着候选人名单的增加，候选人所做的公地名单也在增加。此外，随着AllSeale的发展，其员工人数也有所增加，因此关系树也在增长。很快，许多依赖于分离过程的过程开始耗尽时间，客户逐渐生气。于是开始进入危机管理过程，约翰尼的团队很快发现罪魁祸首就是分离功能。 Johnny与整个团队合作，并认为团队可以在一天内修改功能，使用更有效的搜索算法，然后测试并在30小时内将修改后的版本发布到该点。首席执行官克里斯蒂娜担心如果问题在几个小时内没有得到解决，就会导致大量客户流失。如果Johnny Gona有我们的建议，请确保回到最后发布的版本，然后回滚代码，然后在问题解决后释放它，很容易设置他的回退过程。他退休了E日之前发布的代码。虽然这可能会引起用户的混淆，但提示相应的消息将有助于控制混淆，以及在两天内发布新代码，以便此功能正常工作，而不会影响当前的可伸缩性。如果您没有使用我们的建议，或者退回流程只允许在发布后的六个小时内退役，那么我们怀疑Johnny的概念会发生变化，并确保有一个满足其需求的回滚流程。对于后备窗口的大小，最后一个考虑因素是您的发布频率以及您需要能够回滚的已发布版本的数量。也许您的发布流程允许您在几周内在网站上发布多个新功能。在这种情况下，如果任何新的使用率延长到下一个发布周期以稳定，那么您可能需要一次回滚多个已发布的版本。如果是这种情况，那么您的流程需要更严格，因为您不仅要考虑一个版本，还需要考虑多个更改和多个版本。后备窗口要求备注若要确定执行回滚所需的时间，应考虑以下几点。●版本发布后的第一个流量高峰期有多长？现有功能是否已修改？发布新功能？ ●如果是新功能，其采用曲线是什么？ ●根据发布频率，我应该考虑网站建设回滚多少次？我们称这是对回滚版本数量的需求。 您的后备窗口应该允许您在大量采用新功能（例如，采用率大于50％）之后以及在第一个高峰使用期之后或期间回滚。