当您对实际网站进行更改时，如何检查 live 系统是否正常工作？你用哪些工具？谁做到了？您是否在测试期间阻止访问该网站？可以接受多少停机时间？
答案 0 :(得分：13)
我倾向于在另一个环境中进行所有测试（不是现场测试！）。这允许我将更新推送到实时站点，因为知道代码应该正常工作，我只是对实时数据进行健全性测试 - 确保我没有忘记某个地方的文件，或者有一些奇怪的错误。< / p>
在测试或登台环境中进行适当的测试，然后进行简单的健全性检查。无需停机。
答案 1 :(得分：6)
已经有很多好的建议。
正如人们所提到的，如果您没有涉及单点，只需通过一次升级应用服务器来分阶段进行更改即可。但这种情况很少发生，所以让我们忽略它并专注于困难的部分。
通常在那里有一个db，其他一切都是共同的。这意味着整个系统的停机时间。 你如何最小化？
<强>自动化即可。编写整个部署过程的脚本。这（特别是）包括任何数据库架构更改。这（特别）包括模式版本之间所需的任何数据迁移。
质量控制。确保有测试。自动验收测试（用户从业务逻辑/体验角度看到和期望的内容）。考虑在生产系统中拥有测试帐户，您可以编写脚本来测试只读活动。如果您不与其他外部系统交互，请考虑进行写入活动。您可能需要在系统的某些部分过滤掉测试帐户活动，尤其是在他们处理资金和会计时。当豆子不匹配时，Bean计数器会因为充分的原因而感到不安。
<强>排练即可。部署在与生产尽可能相同的临时环境中。使用生产数据量和生产数据执行此操作。您需要了解alter table需要多长时间。并且您需要检查alter table是否在结构上以及实际数据中的所有外键都能正常工作。
如果您有大量数据，架构更改将需要一些时间。也许还有更多的时间可以让你失望。一种解决方案是使用分阶段数据迁移，以便在停机期间使用“最近”或“当前”（假设一个或三个月）数据填充架构更改，并使用你再上网后剩下五年就可以流入。对于最终用户来说，事情看起来还不错，但有些功能无法再访问几个小时/天/无论如何。
答案 2 :(得分：4)
在工作中，我们花费一段时间将代码冻结在测试环境中。然后在几周的通知后，我们在星期五晚上的午夜将该网站关闭，整夜工作并进行验证，并在星期六上午晚些时候进行。流量统计数据显示，这是实现这一目标的最佳时间范围。
答案 3 :(得分：3)
如果您有一组负载平衡的服务器，您可以单独一个一个地离线并更新它。没有用户的停机时间！
答案 4 :(得分：2)
拥有可爱的，解除武装的图像和/或备份页面。有些网站实施简单的JavaScript游戏，让您在等待更新时保持忙碌。
例如，失败的鲸鱼。
- 亚当
答案 5 :(得分：2)
在我工作的最后一个地方，QA将在质量保证环境中进行测试。在推出之前，任何重大问题都将得到修复，测试和验证。
在构建经QA认证后，生产支持团队将代码推送到Staging环境，客户端在该环境中查看该站点并验证所有内容是否符合要求。
实际的生产推出发生在非工作时间（晚上9点以后，如果是紧急夜间推，或者从上午5点到早上8点，如果是正常计划的推出）。
该站点托管在多个服务器上，使用F5负载均衡器进行负载平衡：
重复此操作，直到所有服务器都升级到最新代码并允许网站保持最新状态。
此过程非常理想，但有时也需要升级数据库。 如果是这种情况，则有两个选项，具体取决于新数据库是否会破坏网站。
如果新数据库与现有前端不兼容，则您没有真正的选择，只能拥有网站停机的时间窗口。
但是如果新数据库与现有前端兼容，您仍然可以在没有任何实际停机的情况下推出代码，但这需要有两个生产数据库服务器。
总结一下：
当您对实际网站进行更改时，如何检查实时系统是否正常工作？在最好的情况下，这是逐步完成的。
您使用哪些工具？使用任何自动化工具手动检查以验证代码是否已正确安装以及一些基本的自动化测试。我们使用了Selenium IDE。
是谁做的？ DBA执行数据库升级，技术支持/系统管理员推/拉服务器并安装代码，QA或生产支持执行手动测试和/或运行自动化测试。
您是否在测试期间阻止访问该网站？如果可能的话，应该不惜一切代价避免这种情况，特别是如Gilles之前提到的，如果它是付费网站。
可接受的停机时间是多少？停机时间应限制在用户最不可能使用该网站的时间，并且应在不到3小时的时间内完成。
注意： 3小时非常慷慨。经过练习和排练，就像jplindstrom提到的那样，团队将完成整个过程，有时不到一个小时就可以进出。
希望这有帮助！
答案 6 :(得分：1)
其中一些取决于您是否也在更新数据库。在过去，如果数据库正在更新，我们会将网站用于计划（和已发布）的维护期 - 通常是在非常小的时间内，影响很小。如果更新不涉及数据库那么，在负载平衡环境中，我们将从混合中取出一个盒子，部署和放大。测试。如果那是成功的话，它会进入混音，而另一个盒子（假设有2个盒子）则被拿出并更新/测试。
注意：我们不测试代码，只是部署顺利进行，因此任何方式的停机时间都很短。如前所述，代码应该已经在另一个环境中通过了测试。
答案 7 :(得分：1)
IMHO长时间停机（小时）是免费网站可接受的。如果你足够了解你的用户，他们就会明白这是必要的。也许给他们一些东西可以玩，直到网站重新开始（例如，flash游戏，网络摄像头现场直播显示开发团队在工作中等）。对于人们付费访问的网站，如果您定期为他们提供停机时间，很多人会浪费您的时间进行投诉。如果我正在运行向用户收费的服务，我会像瘟疫一样避免停机，并且会非常缓慢而谨慎地推出更新。
在我目前的设置中，我有一个辅助网站连接到同一个数据库和缓存作为实时副本来测试我的更改。
我还在cron作业上运行了几个“页面监视器”脚本，这些脚本使用正则表达式检查网站是否正确呈现关键页面。
答案 8 :(得分：1)
答案是“它取决于”。首先，关于你正在释放的环境。它是某个共享主机上的“hello，world”类型的网站，还是拥有半个服务器的google.com？通常每天有一个用户，或者更像是几百万用户吗？您是在发布HTML / CSS / JPG，还是有一个带有SQL服务器，中间层服务器，分布式缓存等的大毛茸茸的后端？
一般情况下 - 如果你有能力为开发，质量保证，升级和生产提供单独的环境 - 确实有这些。如果您有资源 - 创建生态系统，以便您可以通过单击一次来构建完整的可安装程序包。并确保相同的二进制安装可以在DEV / QA / STAGE / PROD中成功安装，只需单击一下......这个主题上写了很多东西，你需要更加具体用你的问题来得到一个合理的答案
答案 9 :(得分：0)
在80以外的端口上运行主服务器。在端口80上粘贴一个轻量级服务器（例如nginx）。当您更新站点时，在新端口上启动另一个实例。测试。如果您对已正确部署它感到满意，请编辑代理配置文件，然后重新启动它。在nginx的情况下，这会导致零停机或请求失败，并且还可以提供相对于更典型的仅Apache托管选项的性能改进。
当然，这不能替代正确的登台服务器，它只是一种用有限资源执行切换的“礼貌”方式。
答案 10 :(得分：0)
尽可能地测试一切 在上线之前单独开发站点，我使用Selenium （一个网页测试器）来运行所有可导航的 站点的一部分，将虚拟值填入表单，检查 那些值出现在正确的位置，等等。
它足以检查大量的JavaScript或 动态的东西。
然后再次与Selenium快速连接 升级实时站点会验证更新 工作，没有丢失的链接或数据库错误。
通过捕捉微妙的错误，它为我节省了几次 我想错过只需手动轻弹。
另外，如果您将实时网站置于某种“反向代理”之后 或负载均衡器（如果它很大），这使它易于切换 如果有问题，请返回上一版本。
答案 11 :(得分：0)
使其对用户透明的唯一方法是将其置于负载平衡代理之后。更新另一台服务器时，您将关闭一台服务器。然后，当您完成更新后，将您在线更新的那个放下，另一个放下。我们就是这样做的。
如果您有任何类型的“测试版”版本，请不要在实时服务器上推出。如果您有一个“实时，繁忙的网站”，那么人们可能会对其进行攻击并破坏某些内容。
这是典型的高可用性设置，为了保持高可用性，您至少需要3台服务器。 2个实时和1个测试服务器。如果你想拥有专用的数据库或其他东西，还可以使用任何额外的服务器。
答案 12 :(得分：0)
创建主机类并在该主机类上部署您的实时站点。通过主机类我的意思是一组主机，其中设置了负载平衡，并且很容易在类中添加和删除主机。
完成beta测试并准备好生产后，无需关闭网站，只需从生产主机类中删除一些主机，将它们添加到新的主机类中，然后在那里部署最新代码并进行正确测试。一旦确定一切正常，将所有主机逐渐移动到新主机并将新主机类指定为生产主机类。或者您可以使用与最初使用的相同，此活动背后的全部想法是确保您在生产框上测试部署，部署后您的站点将在该生产框上运行，因为部署问题很可怕且难以调试。