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