我被要求调查如何减少我们网站升级的停机时间。
我们维护一个 DNN 网站，其中包含面向公众的页面和仅限会员的页面。仅限会员的页面直接链接到我们的核心应用程序数据库，而面向公众的页面则不链接。
我们目前的流程是在升级过程开始后立即重定向网站用户，其中包括
- Prod DB 的备份
- 更新产品数据库
- 更新可执行文件（应用程序）
- 升级网站应用程序（如果需要更新）
- 安装依赖项
- 升级通信引擎、支付代理等子系统
- 更新各种配置文件
- 执行系统测试
- 重启所有服务
- 允许访问网站
此过程可能需要 2 到 8 个小时，具体取决于所需的升级、要运行的脚本、数据库的大小以及门户的数量。
我最初的想法是限制用户只能阅读页面，并且任何更新页面都不可用。
有人能针对我认为常见的问题提供最佳实践建议吗，以便我们可以减少停机时间，如果我们需要改变基础设施，我可以把这个问题提交给我们的技术部门。
答案1
您是否实践过任何敏捷部署方法？我的第一个建议是衡量部署的哪些部分花费的时间比预期的要长，并对其进行优化。尝试将数据库部署与代码部署计划分开。
由于您每晚都会备份数据库（对吗？），因此如果需要，应该不会有太多数据需要回滚。虽然我不是数据库专家，但我确信您可以简单地使用脚本更新需要更新的数据库架构，而无需花费太多时间。
您可以通过脚本轻松地将 dll 和资源部署到站点，而无需中断现有会话。
在部署到生产环境之前，您应该在临时服务器上进行大部分测试。因此，一旦部署完成，您就不需要在生产环境中进行太多测试。
我鼓励你研究持续集成或持续部署（http://continuousdelivery.com/）。
答案2
我会建议：
a) 设置站点 RO
b) 进行数据库备份//应该很快。如果不是，请使用 redgate 或其他东西来加快速度
c) db update:// 应该很快。如果不是，则说明您经常进行太大的更改。
d) 所有代码都应该在准备阶段进行预测试。您应该能够启动网站，然后在网站上线时进行测试（因为您非常有信心测试会通过）
我们有一个非常大的.net 应用程序，位于 500gb sql 服务器数据库之上，我们的步骤与您的相同，但我们只有几分钟的停机时间来进行升级（我们每周进行几次）。