如何以最礼貌的方式更新一个活跃、繁忙的网站?

我倾向于在另一个环境(而不是现场环境!)中进行所有的测试。这使我能够将更新推送到实时网站,知道代码应该正常工作,我只是对实时数据进行健全性测试——确保我没有在某个地方忘记文件,或者出现了奇怪的问题。

因此,在测试或暂存环境中进行适当的测试,然后进行琐碎的健全性检查。无需停机。

已经有很多好的建议了。

正如人们所提到的,如果你没有涉及单点,那么通过一次升级应用服务器来逐步进行更改就很简单了。但这种情况很少发生,所以让我们忽略它,专注于困难的部分。

通常那里有一个db,这是其他所有东西都有的。这意味着整个系统的停机时间。 你如何尽量减少这种情况?

自动化 .编写整个部署过程的脚本。这(尤其)包括任何数据库模式更改。这(尤其)包括在模式版本之间所需的任何数据迁移。

质量控制 。确保有测试。自动化验收测试(用户从业务逻辑/体验角度看到和期望的内容)。考虑在生产系统中设置测试帐户,您可以编写脚本来测试只读活动。如果你不与其他外部系统交互,也可以考虑进行编写活动。您可能需要过滤掉系统某些部分的测试帐户活动,特别是如果它们涉及资金和会计。当豆子不匹配时,豆子计数器会很沮丧,这是有充分理由的。

排练 。在尽可能与生产环境相同的暂存环境中部署。对生产数据量和生产数据执行此操作。你需要感受一下换桌子需要多长时间。您需要检查alter表在结构上以及在实际数据中的所有外键上是否正常工作。

如果您有大量数据,模式更改将需要时间。也许比你能承受的时间还多。一种解决方案是使用 分阶段数据迁移 ,这样在停机期间,模式更改将填充“最近”或“当前”(比如一到三个月前)的数据,而剩余五年的数据可以在您再次联机后陆续输入。对于最终用户来说,一切看起来都很好,但有些功能在接下来的几个小时/几天/什么时候都无法访问。

在工作中,我们花了一段时间将代码冻结在测试环境中。然后,在几周的通知后,我们在周五午夜关闭了网站,彻夜部署和验证,并在周六上午晚些时候将其安装起来。交通统计数据显示,这是最好的时间框架。

如果你有一组负载平衡的服务器,你就可以单独离线并更新它。用户不会停机!

在我最后工作的地方,QA将在QA环境中进行测试。在推出之前,任何重大问题都将得到修复、测试和验证。

在构建通过QA认证后,生产支持团队将代码推送到Staging环境,客户在那里查看站点并验证一切是否符合预期。

实际的生产推出发生在非工作时间(如果是紧急夜间推送,则在晚上9点之后,如果是正常计划的推出,则在上午5点至8点之间)。

该网站托管在多个服务器上,这些服务器使用F5负载均衡器进行负载平衡:

• 从生产中删除了几台服务器,
• 代码已安装,并且
• 在将服务器放回池中之前,会对服务器进行粗略检查。

重复此操作,直到所有服务器都升级到最新代码,并允许站点始终保持运行状态。

这个过程是理想的,但有时也需要升级数据库。 如果是这样的话,那么有两种选择,具体取决于新数据库是否会破坏网站。

如果新数据库与现有前端不兼容,您别无选择,只能有一个站点关闭的时间窗口。

但是,如果新数据库与现有前端兼容,您仍然可以在没有任何实际停机时间的情况下推出代码,但这需要有两个生产数据库服务器。

• 所有流量都被路由到第二个DB,第一个DB服务器被拉取。
• 第一个数据库升级,验证完成后,重新投入生产。
• 所有流量都被路由到第一个DB,第二个DB被拉取。
• 第二个数据库升级,验证完成后,重新投入生产。
• 下一步是执行上述部分升级。

所以总结一下:

• 当您对实时网站进行更改时,如何检查实时系统是否正常工作? 在最好的情况下,这是逐步完成的。

• 你使用哪些工具? 使用任何自动化工具,手动检查以验证代码是否正确安装,以及一些基本的自动化测试。我们使用了Selenium IDE。

• 谁干的? DBA执行数据库升级,技术支持/系统管理员推送/拉取服务器并安装代码,QA或生产支持执行手动测试和/或运行自动测试。

• 在测试期间,您是否阻止访问该网站? 如果可能的话,应该不惜一切代价避免这种情况,特别是正如Gilles之前提到的,如果这是一个付费网站。

• 可接受的停机时间是多少? 停机时间应限制在用户最不可能使用网站的时间,并且应在3小时内完成。
  注: 3个小时很慷慨。经过练习和排练,就像jplindstrom提到的那样,团队将完成整个过程,有时可以在不到一个小时的时间内进出。

希望这能有所帮助!

有一个可爱、令人放松的图像和/或备份页面。一些网站实现了简单的javascript游戏,让你在等待更新时保持忙碌。

例如,失败的鲸鱼。

-亚当

其中一些取决于你是否也在更新数据库。过去,如果数据库正在更新,我们会在计划(和发布)的维护期内关闭该网站——通常是在影响最小的非工作时间。如果更新不涉及数据库,那么在负载平衡的环境中,我们将从混合中取出1个盒子,部署和维护数据库;测试。如果成功,则将其放入混合物中,并取出另一个盒子(假设为2个盒子)进行更新/测试。

注意:我们没有测试代码,只是部署进展顺利,因此停机时间很短。如前所述,代码应该已经在另一个环境中通过了测试。

依我之见,对于免费网站来说,长时间停机(小时)是可以接受的。如果你对用户进行了足够的教育,他们就会明白这是必要的。也许给他们一些东西玩,直到网站恢复(例如flash游戏、显示开发团队工作的网络摄像头实时馈送等)。对于一个人们付费访问的网站,如果你定期给他们提供停机时间,很多人会浪费你的时间来投诉。如果我运行的是向用户收费的服务,我会像瘟疫一样避免停机,并缓慢而谨慎地推出更新。

在我当前的设置中,我有一个辅助网站连接到与实时副本相同的数据库和缓存,以测试我的更改。

我还有几个在cron作业上运行的“页面监视器”脚本,它们使用正则表达式来检查网站是否正确呈现关键页面。

答案是“这取决于”。首先,关于你正在释放的环境类型。是共享主机上的“hello,world”类型的网站,还是拥有50万台服务器的google.com?通常每天有一个用户,还是更多,比如几百万?你是在发布HTML/CSS/JPG,还是有一个庞大的后端,包括SQL服务器、中间层服务器、分布式缓存等?

一般来说,如果你能负担得起为开发、QA、测试和生产提供单独的环境,那么就一定要有这些环境。如果你有资源——创建生态系统,这样你只需点击一下就可以构建完整的可安装包。并确保 该人 只需再次单击,即可在DEV/QA/STAGE/PROD中成功安装二进制安装。..关于这个主题有很多文章,你需要更具体地回答你的问题,才能得到合理的答案

在80以外的端口上运行主服务器。将一个轻量级服务器(例如nginx)放在端口80的前面。更新站点时,在新端口上启动另一个实例。测试。当你确信它已经正确部署时,编辑你的代理配置文件,然后重新启动它。在nginx的情况下,这会导致零停机或失败的请求,并且还可以提供比更典型的仅Apache托管选项更高的性能。

当然,这并不能替代一个合适的登台服务器,它只是一种在有限资源下执行切换的“礼貌”方式。

尽可能在a上测试一切 独立的开发站点上线前,我使用Selenium (网页测试人员)运行所有可导航的 部分现场,将虚拟值填写到表格中,检查 这些值因此出现在正确的位置等。

它足够强大,可以检查大量的javascript或 动态的东西也是。

然后再次快速使用Selenium 升级实时站点验证了更新 工作正常,没有缺失的链接或数据库错误。

通过捕捉细微的错误,它帮了我几次 我会错过手动浏览的机会。

此外,如果你把实时网站放在某种“反向代理”后面 或者负载均衡器(如果它很大),这使得切换变得容易 如果有问题,请返回到以前的版本。

使其对用户透明的唯一方法是将其置于负载平衡的代理之后。您在更新另一台服务器的同时关闭了一台服务器。然后,当你完成更新时,你把更新过的那个放到网上,把另一个拿下来。我们就是这样做的。

如果你有任何类型的“测试版”构建,不要在实时服务器上推出。如果你有一个“实时、繁忙的网站”,人们很可能会猛烈抨击它并破坏一些东西。

这是一个典型的高可用性设置,为了保持高可用性,您至少需要3台服务器。2个实时服务器和1个测试服务器。如果你想有一个专用的数据库或其他东西,再加上任何其他额外的服务器。

创建一个主机类,并在该主机类上部署您的实时站点。我所说的主机类是指一组设置了负载平衡并且易于在类中添加和删除主机的主机。

当你完成beta测试并准备投入生产时,不需要关闭你的网站,只需从生产主机类中删除一些主机,将它们添加到新的主机类中,并在那里部署你的最新代码并正确测试。一旦您确定一切正常,请将所有主机逐步移动到新主机,并将新主机类指定为生产主机类。或者,您可以使用最初使用的相同方法,此活动背后的整个想法是确保您在生产箱上测试您的部署,部署后您的站点将在生产箱中运行,因为部署问题很可怕,很难调试。