关于如何在经常使用的站点上进行维护的任何想法？

我为澳大利亚的大型游戏网站提供帮助。我们在当地时间每天早上7点到第二天凌晨1点之间进行比赛。自该网站发布以来，我们还没有跳过一天。自然，这使得维护变得极为困难，并且我们发现登台服务器在生产分支之前最多可以提交50次提交。通常，主要开发人员必须非常早地醒来以合并分支，并确保一切正常。

我们一直在尝试使登台站点与生产站点尽可能相似，但只能使其与生产站点相似。

我们的网站基于Laravel并带有Node.JS服务器，以实现实时。我们正在使用Laravel Forge。

是否有人对我们如何更频繁地推送更新有任何建议？我们对任何事物都开放。

您可以做很多事情来改善您的部署过程。其中一些是：

• 确保您的代码已经过测试。

  理想情况下，您应该具有100％的单元测试覆盖率，以及每种可能情况下的集成测试。

  如果还没有，您应该丢弃所有东西并妥善处理。

  研究行为驱动的开发。

  拥有完整的测试套件将使您能够...

• 运行持续集成。

  每当有人提交更改时，CI便可以在其上自动运行测试套件。如果测试套件通过，它可以立即进行部署（或安排部署）。对于不需要对数据库进行任何重大更改的更改，仅此一项就可以节省大量时间和头痛。

  如果出现问题，CI还可为您提供一键式回滚。

  CI是很多有用的更少，如果您的测试套件是不完整的，正确的，因为整个前提下休止符上能够验证您的代码以自动方式。

• 进行原子更新。

  理想情况下，您不应该只是在生产服务器上的旧文件上复制新文件。而是使用诸如capistrano之类的工具，该工具将每个文件复制到一个新位置，然后使用符号链接指向所需的部署。回滚是瞬时的，因为它涉及到简单地更改符号链接以指向先前的部署。（尽管这不一定涵盖您的数据库迁移。）

  还要研究诸如Docker之类的容器是否可以为您提供帮助。

• 进行更小，更频繁的更改。

  无论您有测试，配置项，还是什么都没有，仅此一项就可以极大地帮助您。每个更改都应具有自己的git分支，并且部署应包含尽可能少的更改。由于更改较小，因此在部署过程中出错的可能性很小。

  因此，请尽可能使更改更孤立。如果您对奥马哈游戏进行了更改，并且不影响德州扑克，5张牌梭哈或其他任何东西，那么这是唯一需要暂停进行维护的游戏。

• 分析任何长期运行的东西。

  您提到部署的某些部分需要很长时间。这可能是数据库架构更改。值得DBA查看您的数据库以及每个模式更改，以查看哪些性能更​​好。

  让主题专家查看部署中需要花费大量时间的任何其他部分。

• 零工上班。

  您可能已经在这样做，但是值得一提。开发人员（和系统管理员！）不应再工作“ 9 to 5”，尤其是对于24x7的操作。如果希望某人花一整夜的时间照顾部署，解决所有问题，然后保留白天的时间表，那么您的期望是不切实际的，并且您正在将该人设置为精疲力尽。

从您所说的看来，您每天都有一个凌晨1点至7点的维护时段，这不是时间而是便利。这是正常现象，许多人只是将其作为业务的一部分来处理。

您可能有2个（或更多后端）系统，其前端将流量定向到当前正在使用的任何系统。一旦您对发布即将开始感到满意，就告诉前端切换到新系统。这应该很容易在短时间内编写脚本。

现在，您可以选择保留旧系统，以便将其撤回或更新为最新版本，以便在构建/测试下一个更新之前，可以将其用作实时系统的备用。

修改其他答案：您应该遵循蓝绿色部署模型。当您要发布新版本时，可以将其部署到内部暂存网站。然后，您可以在下一个版本的生产站点上运行自动化测试。测试通过时，请指向负载均衡器以使用新网站。

这可以通过以下方式提供帮助：

1. 零停机通常会发现严重的问题。
2. 切换到新版本的停机时间完全为零，因为新版本已启动并已预热。
3. 您可以随时切换回旧版本，因为它仍在运行。

您和其他人提到的所有其他问题都可以在没有压力的情况下随时进行部署时变得不那么严重。蓝绿色部署模型是针对部署问题的非常完整的解决方案。

如果您的主数据中心不时出现故障（在所有数据中心中不时发生），您该怎么办？您可能会接受停机时间，可能会故障转移到另一个数据中心，可能一直在多个数据中心中以主动-主动模式运行，或者您可能有其他计划。无论是哪种版本，都在发布时执行，然后可以在发布期间关闭主数据中心。如果您准备在数据中心发生故障时发生停机，那么您就已经准备好发生停机，因此在发布期间应该不会有问题。

要添加到先前的答案中：

• 使用允许回滚和即时切换的部署策略，Capistrano或几乎任何其他部署系统都将对此提供帮助。您可以使用数据库快照和代码符号链接之类的东西来快速恢复到以前的状态。

• 使用完整的配置管理，请勿保留任何手动管理的内容。例如SaltStack，Ansible和Puppet之类的系统。它们也可以应用于Docker容器配置和无业游民的盒子。

• 使用HA确保在升级节点时可以移交请求。如果升级失败，则只需关闭该节点，然后将其回滚，将其恢复，您的HA解决方案将注意到并再次将请求推送到该节点。HAProxy是一个示例，但是nginx也可以正常工作。

• 确保应用程序可以处理并发实例，用于需要存储在磁盘上的非代码数据（例如缓存）的中央版本化数据存储库。这样，您将永远不会运行已升级的应用程序来缓存其他版本的文件。当然，这将在清除缓存和进行缓存预热的基础上完成。（缓存只是示例）

我通常会设置工作流，团队经理可以将合并请求批准到执行所有常规CI任务的特殊分支，但是作为最后一个附加步骤，也开始推送到生产节点。您基本上要做的是将手动CI部署到生产实例。如果该实例不会对数据产生无效的响应，中断或发生奇怪的事情，则可以使用所选的CI解决方案对所有节点进行大规模升级。这样，如果一个部署有效，您就会知道所有部署都将适用于特定的标记/提交。

现在，听起来好像您在一个具有一个部署过程，一个源和一个目标的单个节点上运行生产应用程序。实际上，这意味着工作流中的每个步骤都是一个故障点，它本身可能会破坏网站。确保这种事情不会发生是所有CI，HA和故障转移过程的基础。不要只运行一个节点，不要只运行一个HA进程，不要只运行一个IP地址，不要只运行一个CDN，等等。这听起来可能很昂贵，但是请复制已有的副本在具有自己连接的服务器机架上，在业务站点上的停机时间通常不到一小时。

我在全球范围内都同意Michael的所有观点（/server//a/739449/309477）。

我认为，您应该做的第一个改进就是使用部署工具（Capistrano）。

它可以让您和平部署，然后立即切换到新版本。如果出现任何问题，只需将当前符号链接更改为工作版本，即可立即切换回工作版本。

Capistrano的处理速度非常快（与开始使用测试和CI相比，这将花费更多的时间）。

其次，如果金钱不是您的主要问题，则应在生产环境中部署应用程序之前，先使用iso-prod开发服务器对其进行测试。使用工业解决方案（Ansible，Chef，Puppet）来管理VPS实例。