CoderPath

部署、观测与 5.2 → 6.0 升级 ​

本站纵览 ｜ 练习答案

生产配置骨架 ​

python
# config/settings_prod.py（示意；值由环境提供）
import os
from .settings import *

DEBUG = False
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]
ALLOWED_HOSTS = os.environ["DJANGO_ALLOWED_HOSTS"].split(",")
CSRF_TRUSTED_ORIGINS = [
    value
    for value in os.environ.get("DJANGO_CSRF_TRUSTED_ORIGINS", "").split(",")
    if value
]
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

不要把这段当完整模板：是否信任代理 HTTPS Header、HSTS 周期、静态文件服务和数据库连接都依赖部署拓扑。

发布顺序 ​

text
备份/恢复点 → 兼容 schema 迁移 → 新应用灰度 → 健康与业务验证
→ 全量切换 → 回填/异步任务 → 观察窗口 → 后续版本清理旧字段

WSGI 适合成熟同步栈；ASGI 适合完整异步请求栈和长连接需求。两者都需要生产服务器、反向代理、超时、优雅停机和容量测试。

结构化日志 ​

python
LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {"console": {"class": "logging.StreamHandler"}},
    "root": {"handlers": ["console"], "level": "INFO"},
    "loggers": {"django.request": {"level": "WARNING", "propagate": True}},
}

实际 JSON 格式化器可由组织平台提供；关键合同是稳定字段和脱敏，不是某个日志包。

5.2 → 6.0 升级路径 ​

  1. 把 5.2 更新到最新补丁并锁定依赖。
  2. 在 5.2 上运行 python -Wd manage.py test，清零自己代码和受控依赖的弃用告警。
  3. 确认 Python 升至 3.12+；检查数据库、驱动和第三方应用兼容矩阵。
  4. 阅读 6.0 发布说明中的不兼容变更，单独验证邮件 API、CSP、Tasks 和数据库行为。
  5. 在预发布执行迁移、静态资源、任务、异步与回滚演练，再分批发布。

深水边界 ​

  • check --deploy 不知道代理和云权限是否正确。
  • worker 数 × 每 worker 连接池可能超过数据库上限。
  • collectstatic 产物要和应用版本对应；CDN 缓存需要内容哈希与回滚策略。
  • 日志、指标、trace 和发布事件用请求 ID、服务、环境和版本关联。
  • 备份成功不等于可恢复；按 RPO/RTO 在隔离环境恢复并校验业务数据。

验收 ​

发布使用已验证制品；迁移计划、健康检查和回滚步骤可复现；日志能按请求 ID 与版本定位失败；备份完成过恢复演练。

练习（先独立完成） ​

  1. 为项目写 WSGI/ASGI 选择 ADR。
  2. 计算 4 worker、每个最大 10 数据库连接时的总连接预算，并预留管理连接。
  3. 写出 schema 已扩展、新应用失败时的回滚步骤。

完成后核对答案。

深度加餐：部署顺序是系统的一部分 ​

代码、迁移、静态资源和 worker 必须按兼容顺序发布；否则每一层都可能看到半套系统。

先做一个可观察实验 ​

python
# config/settings_prod.py
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 60 * 60
SECURE_HSTS_INCLUDE_SUBDOMAINS = True

# 发布检查
# python manage.py check --deploy
# python manage.py migrate --plan

预期：部署检查能在上线前暴露安全默认值与待执行迁移；HTTPS、cookie 和 HSTS 只在代理转发配置正确时启用。

原理下潜与工程边界 ​

发布常见顺序是向后兼容代码 → schema 扩展 → 数据回填 → 切换读写 → 清理旧字段。Django 5.2 LTS 到 6.0 要先看弃用项、第三方兼容和迁移锁表时间。

HSTS 一旦发出会影响回滚；ALLOWED_HOSTS、SECURE_PROXY_SSL_HEADER 与反向代理必须配套；滚动发布期间旧 worker 可能读取新列或相反。

反例排错路线 ​

保留版本 SHA、迁移计划、健康探针和回滚命令；错误率、延迟、数据库连接、队列积压一起看，避免只盯应用日志。

练习加码（仍不提供答案） ​

加码：写一份 5.2→6.0 升级彩排清单，包含影子库迁移、双版本 worker、回滚和数据兼容验证。

验收时请补充：正常路径、权限或失败路径、以及一条能证明事务/资源/配置边界没有被绕过的测试。

继续查阅：Django 官方文档（外部资料已收录于证据账本） · Django 安全清单（外部资料已收录于证据账本）

课程合同：部署、观测与升级 ​

学习目标 ​

学完本篇，读者应能把「5.2 LTS 到 6.0 在兼容矩阵、告警和回滚约束下发布」拆成输入、可信边界、Django 机制和可复查证据；同时能说明 Django 6.0 与 5.2 LTS 的差异不会改变业务不变量。

心智模型 ​

请求/数据输入 → 边界检查 → Django 核心机制 → 可观察输出 → 恢复动作。配置、数据库提交和外部副作用分别拥有自己的生命周期；没有证据的“应该可以”不算完成。

本地机制图 ​

部署、观测与升级机制图

图中的“输入”是不可信的 HTTP、表单、任务或配置；“边界”负责身份、格式、权限、大小、超时与版本；“机制”才是 URL、View、ORM、事务、缓存、Tasks 或 ASGI；“证据”是测试、响应、日志、查询计划和发布记录。

最小实验 ​

在全新虚拟环境中运行：

bash
python -m django --version
python manage.py check
python manage.py test

实验只验证一个机制：输入一条有效值，再输入一条空值、重复值或无权限值。每次实验都记录 Django 版本、数据库、命令和退出码。

完整场景 ​

把实验接到 tickets 工单流：请求携带用户身份和工单 ID，经过当前专题负责的边界，完成一次读或写，并留下响应状态、数据库变化、日志字段和清理动作。完整场景必须能第二次执行，或明确说明幂等键、事务回滚、缓存失效和任务重试策略。

运行输出 ​

成功路径应出现：

text
Django 6.0.x
System check identified no issues (0 silenced).
OK

失败路径要保留真实信号，例如 400（输入无效）、403（权限/CSRF）、404（资源不存在）、405（方法不允许）或数据库约束异常；不要把失败改写成含糊的 200。

失败边界 ​

至少验证：空输入、重复提交、匿名用户、越权对象、并发写入、下游不可用、超时和版本不兼容。记录“谁拒绝、何时拒绝、状态是否回滚、重试是否安全”。开发模式的 traceback 不得进入生产响应，缓存不得跨用户复用敏感结果。

原理与排错 ​

先确认版本和 settings，再用 manage.py check 定位启动问题；接着确认 URL/任务入口、输入解析和权限；最后检查 SQL、事务提交、响应和副作用。若结果异常，用最小复现打开 SQL/请求 ID/任务 ID 观测，沿「复现 → 缩小 → 观测 → 修复 → 回归」闭环，不靠重装依赖猜测。

练习（正文不泄答案） ​

  1. 为上述完整场景补一条正常路径和两条失败路径测试，并记录完整输出。
  2. 画出本篇机制图，标出身份 owner、数据提交点、缓存/任务副作用和恢复动作。
  3. 故意制造一次重复、越权或超时，说明应返回的状态、日志字段和是否可重试。
  4. 写一条 Django 5.2 LTS 兼容验收标准，再说明 Django 6.0 的新能力是否需要条件分支。

验收标准：命令可重复、输出可复查、正文没有练习答案；完成后再打开本阶段答案册。

答案册 ​

本阶段答案册提供参考实现、关键推理、失败边界和替代方案；先独立完成练习再对照。

下一篇 ​

下一篇是10-deployment-observability/02-static-health-release-evidence，继续沿同一条输入—边界—机制—证据链前进。

用心记录每一步成长

Copyright © 2026-present Twiink