发布、迁移、回滚与部署故障诊断
Docker、Nginx 与 Python 项目部署#Python全栈#第十九阶段#Docker、Nginx 与 Python 项目部署#发布、迁移、回滚与部署故障诊断约 804 字 · 2 分钟阅读
追问显示点击任意追问卡片可收起 / 展开
一次发布应怎样安排构建、迁移、启动、代理接入与验证顺序？
追问 哪些步骤可提前准备，哪些步骤失败后必须停止？镜像、配置、数据结构和静态产物怎样建立对应关系？
怎样让发布版本可追踪，而不是依靠一个不断变化的 latest 标签？
追问 提交标识、镜像摘要、配置版本和迁移记录怎样关联？用户报错时，如何确认处理请求的是哪个实际版本？
单机替换与同时运行新旧实例各有什么发布约束？
追问 容器重建会不会产生短暂中断？额外容量、就绪检查、代理切换和旧请求排空怎样影响结果，为什么不能仅凭双实例就承诺零中断？
数据库迁移为什么需要考虑新旧应用同时运行与回滚？
追问 新增字段、删除字段和改变约束分别怎样影响旧版本？怎样先保持兼容再收缩结构，为什么回滚镜像不等于数据结构也自动恢复？
怎样执行发布后的最小业务冒烟验证？
追问 登录、查询、提交、报告状态与文件访问应选哪些样本？怎样同时确认新版本、正确数据源、权限范围和实际持久化结果？
配置改变、秘密更新与服务重建后，怎样验证没有环境串用？
追问 数据库、缓存、消息 Broker 和文件目录分别怎样识别？诊断输出怎样展示必要配置，同时不暴露凭据？
上线后出现大量 502 或连接失败，怎样按链路逐层定位？
追问 DNS、公网入口、Nginx、容器网络、应用监听和进程状态如何依次核对？哪些证据能区分网络问题与代码启动问题？
接口越来越慢、容器重启、磁盘空间下降，怎样关联原因？
追问 CPU、内存、数据库连接、日志增长和临时文件怎样观察？怎样先控制持续影响，再在测试环境验证修复，而不是盲目扩大超时？
怎样制定一个可以实际执行的回滚方案？
追问 旧镜像、配置、静态资源与数据库兼容条件怎样保存？切回旧版本后，怎样确认代理目标、业务功能和已发生的数据修改？
部署说明与故障记录应包含哪些可复用信息？
追问 拓扑、版本、启动命令、配置位置、数据卷、迁移和验证步骤怎样交付？为什么只写“重启试试”不足以让下一位同事恢复服务？