自托管Adobe Commerce灾难恢复想法
本文的灾难恢复包括失败的部署。 虽然整个过程可能不同，但适用类似的原则。 灾难可能是由于生产部署失败、服务器变得无响应、发现利用漏洞以及许多其他情况所致。 如果失败部署的恢复过程可能只需要两个简单的步骤，则从利用漏洞进行恢复可能更具挑战性。 由于环境的复杂性、托管变体以及其他复杂性，本文提供了一些想法和概念，但您需要自行继续调查。 这样，您就可以确保设计一种符合业务需求的策略。
经常练习恢复过程
练习，练习，练习。 实践首先出现在灾难恢复列表是有原因的。 制定恢复计划却从不执行，这要容易得多。 如果您没有进行足够的练习，则很容易出错，可能会错过一些步骤，而且可能会使实际恢复花费更长的时间。 恢复实践的节奏取决于您和您的业务合作伙伴。 让恢复过程成为年度活动或许就够了，但与公司决策者的深入对话应该包括几个关键主题。 这些主题有助于他们了解为什么练习很重要，并且应该被期待。 下面是一些有助于开始对话的主题：
- 练习可减少实际发生事件时的实际停机时间。 如果练习练习每年中断您的网站一小时，它可能会将实际事件的实际停机时间减少几个小时。 恢复站点需要8小时或更长时间，这种情况并不少见。 通过经常练习此事件，您可以减少每个阶段所花费的时间，并且可以更快地恢复。
- 这些练习运行的计划停机时间可能与服务器修补程序、清单调整或应定期执行的任何其他操作一致。
- 练习不同的场景而不是相同的场景。 为了从以前的日期进行完全恢复，请偶尔花一些时间。 这包括查找和使用数据库的归档副本、回滚代码以匹配日期等内容。 一种更简单的方法是从失败的部署中恢复，在这种部署中，您只需回滚到上一次提交。
- 验证恢复过程是否真的有效，有时存档的数据库可能会损坏。 通过这样做，它可确保一切都可以恢复并且正常运行。 查找并恢复旧数据库需要时间，应知道此过程可能需要多长时间。
- 验证是否记录了配置中的所有更改。 这可确保从旧数据库进行的任何恢复操作如有任何新的配置更改，都必须正常运行。 例如，如果您的API密钥在过去几天更改为您的支付处理者。 通过良好的变更管理流程，查找这些关键更新即可使流程按计划进行。
数据库备份
数据库备份应该相当正常。 具有每小时、每天、每周和每月快照的情况并不少见。 备份最终应移至长期存储。 当业务或技术团队认为已经过了足够的时间以至于可能不再需要快速恢复时，这种长期存储就会发生。 从长期存储中恢复会增加恢复过程所需的时间，因此应谨慎确定何时进行恢复。 数据库备份应是自动化的，而不是依赖于人工交互。 这可以确保您有足够的存储空间来提供安全且可预测的恢复过程。 这也有助于任何法医活动，如果这种活动是必要的，是可行和可靠的。 在检测到利用漏洞后，或者在尝试诊断信用卡欺诈活动发生时，甚至是某人加入您的网站时，您可能会发现需要进行法证研究。 这些备份的使用方式没有限制，但在您实际需要时，拥有良好的备份节奏是您省钱的好选择。
以下是数据保留策略的示例：
- 每八小时。 备份应易于访问。
- 过去七天的每日备份，应易于访问。 这些文件的副本可以作为迁移离场的候选文件。
- 过去四周的每周备份考虑迁移异地备份。
- 过去三个月的每月备份已转移到异地。
- 较旧的备份被转移到长期异地存储。
将基础架构作为代码
此方法意味着您拥有工具和代码来为项目重建部件或整个基础架构。 当服务器遇到问题时可能需要此操作，并且必须停止使用。 能够快速使新服务器联机、部署代码、进行任何PHP、Nginx或Apache配置以及其他任何配置，自动意味着停机时间更短。 即使是在运行手册中记录完整的步骤，也更容易设置，执行这些步骤所需的时间要长得多。 此外，请考虑在压力下使无响应网站重新联机时可能发生的人为错误。
辅助数据库
使用辅助数据库可能很有用，原因如下：
- 如果主驱动器出现故障，则为热备用
- 允许来自应用程序的就绪请求
- 允许发生mysqldump并允许在不锁定数据库的情况下发生正常事务
- 允许从外部数据源访问数据，而不会降低网站处理客户请求信息的能力。
辅助数据库可以作为warm standby使用。 当您考虑如何从主数据库故障中恢复时，这可能会起作用。 将辅助数据库升级为主数据库的复杂性低于将数据库重建和恢复到新创建的Mysql实例的复杂性。 这减少了恢复操作期间的实际停机时间。
可以将一些请求转移到辅助数据库。 如果使用此方法，建议将辅助数据库设为只读。 通过允许Adobe Commerce应用程序使用此辅助数据库进行读取操作，可以接受一些读取请求并允许辅助数据库做出响应，从而有所帮助。 但是，此更改仅占所有请求的30-50%，但您可以从主数据库中消除的任何负载都是一种胜利。
创建包含回滚的部署计划
每个部署都应包含一个回滚计划。 是的，每次部署。 如果你做好了计划，你永远不会感到惊讶，并且会为糟糕的事件做好准备。 有时候，最简单的代码更新可能会由于任何原因而灾难性失败。
假设一个团队提交了一个小的简单拉取请求以在数据库中执行模式更改，那么这个真实故事就是这样的。 随着部署从1分钟增加到5分钟，再增加到10分钟，团队变得更加担心。 到目前为止，他们未能验证和考虑的就是与暂存数据库相比，生产数据库存在任何差异。 他们有一个通用做法，在使用生产副本刷新暂存环境时删除所有客户数据。 这意味着，在此之前的所有测试和QA都反映了部署应只需几分钟即可完成。 实际上，他们拥有超过2000万客户，并且这种小型架构更改需要非常长的时间才能完成。 因为他们不知道这实际需要多长时间，所以他们被迫终止mysql进程并回退部署。
准备部署的回滚过程只需要几分钟，因为整个过程将会很相似。 但是，您应该花一些时间来准确地记录将将Git存储库的HEAD重置回的提交。 您应该准确地记录要使用的数据库快照或查找当前快照的位置（如果它始终位于同一位置）。 定义了必须讨论部署状态以及自动生效的时间。 例如，如果任何部署需要超过15分钟，请询问项目经理和其他利益相关者是否应该继续。 但是，如果回滚过程需要45分钟，则自动执行回滚过程并通知所有利益相关者，无论项目经理和架构师是否对项目犹豫不决。
确保有几个人参与整个流程和每个阶段。 让中层开发人员审查部署过程、回滚过程和文件的位置，是让他们参与进来的好方法。 他们最终会执行这些步骤，因此让他们了解整个过程对于长期成功至关重要。 确保每个人都有权取消部署。 给予您的团队这么多的发言权是赋权且有回报的。 如果初级开发商真的感到缺少某样东西，他们应该感到必须大声疾呼，让他们的谨慎得到倾听。 让架构师和项目经理确认或缓解他们的恐惧。 有一个强大的团队来寻找项目并保持完美部署的跟踪记录非常重要。
验证对域名管理、DMS、SSL、WAF的访问权限
由于域名过期，可能会意外修改DNS记录，SSL证书可能过期，等等；请确保能够登录并验证是否经常发生连接。 每季度都进行这种简单的检查，可让您确信自己知道东西的确切位置，尤其是在紧急情况下。 请不要认为您的DNS是在注册机构中进行管理的，而只是为了确定您是否已在Amazon中进行管理。 这些记录并不经常使用，因此遗忘它们的位置概率很高。 不要只信任用户名和密码的书面文档。 登录每个配置文件，并验证您要查找的配置是否实际受管理。 在管理层变动或公司收购期间，事情经常会发生变化，而且只有一个人知道发生了什么，因为他们是进行更新的。 他们不知道您依赖共享的Word文档的位置、用户名和密码。 找到一个对您和您的组织有意义的检查过程，但每三到六个月执行一次此检查是一个很好的起点。