当我们将更改发布到实时网站时，如何检查实时系统是否正常运行？我们使用哪些工具？是谁啊在测试期间，我们是否阻止访问该网站？可接受多少停机时间？

解决方案

回答

我倾向于在其他环境(而不是现场环境)中进行所有测试。这使我知道代码应该可以正常工作，从而将更新推送到实时站点，并且我只对实时数据进行了完整性测试，以确保我不会忘记某个地方的文件，或者发生了一些奇怪的错误。

因此，在测试或者过渡环境中进行适当的测试，然后进行琐碎的检查即可。无需停机。

回答

如果我们有一组负载平衡的服务器，则可以分别使一个脱机并对其进行更新。用户无停机时间！

回答

其中一些取决于我们是否还要更新数据库。过去，如果要更新数据库，我们会在计划的(并已发布的)维护期间关闭站点，通常会在数小时之内关闭，而影响最小。如果更新不涉及数据库，则在负载平衡的环境中，我们将从混合，部署和测试中取出1个框。如果成功，则将其加入混合，并取出另一个盒子(假设有2个盒子)并进行更新/测试。

注意：我们不是在测试代码，只是为了使部署顺利进行，因此停机时间最少。如前所述，该代码应该已经在另一个环境中通过了测试。

回答

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

当然，这不能替代适当的登台服务器，仅是在有限资源下执行切换的"礼貌"方式。

回答

在工作中，我们花了一段时间将代码冻结在测试环境中。然后，在几周的通知后，我们在星期五晚上午夜将站点关闭，整个晚上进行部署和验证，并在星期六深夜将其设置。流量统计数据显示这是执行此操作的最佳时间范围。

回答

拥有可爱的撤防图像和/或者备份页面。一些网站实施了简单的JavaScript游戏，以使我们在等待更新时保持忙碌状态。

例如，让鲸鱼失败。

-亚当

回答

免费网站可以接受恕我直言的长时间停机(小时)。如果我们对用户进行了足够的教育，他们会明白这是必要的。也许要给他们一些玩玩的机会，直到网站恢复正常(例如Flash游戏，显示开发团队正在工作的网络摄像头实时供稿等)。对于人们付费访问的网站，如果我们定期给他们停机，那么很多人会浪费时间来抱怨。如果我运行的是一项向用户收费的服务，我会避免像瘟疫这样的停机时间，并真的要缓慢而谨慎地推出更新。

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

我还在cron作业上运行了几个"页面监视程序"脚本，这些脚本使用正则表达式来检查网站是否正确呈现了关键页面。

回答

答案是"取决于"。首先，关于要释放到的环境。是某个地方的共享主机上的" hello，world"类型的网站，还是拥有半数服务器的google.com？通常每天有一个用户，或者几百万个吗？我们要发布HTML / CSS / JPG，还是SQL Server，中间层服务器，分布式缓存等庞大的后端？

通常，如果我们有能力为开发，质量检查，登台和生产提供单独的环境，则一定要有这些环境。如果我们有足够的资源，请创建生态系统，以便我们可以通过单击一(一)次来构建完整的可安装软件包。并确保再次单击即可在DEV / QA / STAGE / PROD中成功安装相同的二进制安装程序。关于此主题，有成千上万的东西要写，而且我们需要更具体地回答问题才能得出合理的结论。回答

回答

为了尽可能地测试所有内容
单独的开发站点上线之前，我使用Selenium
(网页测试器)来运行所有可导航的
网站的一部分，将虚拟值填写到表单中，检查
结果这些值会出现在正确的位置，依此类推。

它足够强大，可以检查很多javascript或者
充满活力的东西。

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

通过捕获细微的错误为我节省了很多时间
我会错过只是手动滑动。

另外，如果我们将实时网站放在某种"反向代理"后面
或者负载均衡器(如果很大)，则可以轻松切换
如果有问题，请返回以前的版本。

回答

使它对用户透明的唯一方法是将其置于负载平衡代理之后。我们在更新另一台服务器时关闭了一台服务器。然后，当我们完成更新时，将其中一个在线更新，然后将另一个更新下来。我们就是这样做的。

如果我们有任何"测试版"构建，请不要在实时服务器上发布；如果我们有一个"实时，繁忙的站点"，人们很有可能会对其进行破坏。

这是典型的高可用性设置，要维持高可用性，我们最少需要3台服务器。 2个在线服务器和1个测试服务器。如果我们想要一个专用的数据库或者其他东西，再加上任何其他额外的服务器。

回答

已经有很多好的建议。

就像人们已经提到的那样，如果我们没有涉及任何一点，那么通过一次升级应用服务器来逐步引入变更很简单。但是，这种情况很少见，所以让我们忽略这一点，而将注意力集中在困难的部分上。

通常那里有一个db，这是其他所有东西都共有的。因此，这意味着整个系统都将停机。我们如何将其最小化？

自动化。编写整个部署过程的脚本。这(尤其是)包括任何数据库架构更改。 (特别是)这包括我们需要在模式的各个版本之间进行的所有数据迁移。

质量控制。确保有测试。自动化的验收测试(用户从业务逻辑/体验角度看到和期望的结果)。考虑在生产系统中拥有测试帐户，我们可以编写脚本来测试只读活动。如果我们不与其他外部系统交互，请考虑也进行写活动。我们可能需要过滤掉系统中某些部分中的测试帐户活动，尤其是当它们处理金钱和会计时。由于种种原因，当Bean不匹配时，Bean计数器会感到不安。

排练。在与生产环境尽可能相同的暂存环境中进行部署。使用生产数据量和生产数据执行此操作。我们需要感觉一下alter table需要多长时间。而且，我们需要检查alter table在结构上以及实际数据中的所有外键是否都起作用。

如果我们有大量数据，架构更改将需要时间。也许时间比我们承受不起的时间还多。一种解决方案是使用分阶段的数据迁移，以便在停机期间用"最新"或者"当前"(假设有一个或者三个月的时间)数据填充架构更改，而剩余五年的数据可以在之后迁移我们再次在线。对于最终用户来说，一切看起来还不错，但是某些功能在接下来的几个小时/天/天都无法访问。