@umacloud/knowledge 1.0.1

package/development/02-playbooks/release-playbook.md

@@ -0,0 +1,469 @@
+---
+id: release-playbook
+title: 发布作战手册 (Release Playbook)
+domain: development
+category: 02-playbooks
+difficulty: intermediate
+tags: [2024-01-15, agent, checklist, development, playbook, release, 前置条件, 发布清单]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 发布作战手册 (Release Playbook)
+
+## 概述
+
+发布是将经过验证的代码安全地部署到生产环境的过程。本手册覆盖从发布准备、质量门禁、灰度放量、监控观测到回滚恢复的完整流程。适用于常规发布、紧急发布和大版本发布三种场景。
+
+## 前置条件
+
+### 必须满足
+
+- [ ] 所有功能开发已完成并通过 Code Review
+- [ ] CI 流水线全部通过（Lint、测试、安全扫描）
+- [ ] 测试报告已生成，测试通过率 >= 99%
+- [ ] 已确认无阻断级别的已知 Bug
+- [ ] 回滚方案已准备并经过验证
+- [ ] 发布窗口已预约（避免高峰时段）
+- [ ] On-call 值班人员已确认
+
+### 建议满足
+
+- [ ] 性能测试已通过
+- [ ] 安全扫描无高危漏洞
+- [ ] 数据库迁移脚本已在预发布环境验证
+- [ ] 变更通知已发送给相关方
+
+---
+
+## 步骤一：发布准备
+
+### 1.1 版本号管理
+
+```bash
+# 语义版本号规则
+# MAJOR.MINOR.PATCH
+# MAJOR: 不兼容的 API 变更
+# MINOR: 向后兼容的功能新增
+# PATCH: 向后兼容的 Bug 修复
+
+# 查看当前版本
+git describe --tags --abbrev=0
+
+# 创建发布分支
+git checkout develop
+git pull origin develop
+git checkout -b release/v1.2.0
+
+# 更新版本号
+# Python
+sed -i 's/version = ".*"/version = "1.2.0"/' pyproject.toml
+# Node.js
+npm version 1.2.0 --no-git-tag-version
+# 手动更新其他版本引用
+```
+
+### 1.2 Changelog 生成
+
+```bash
+# 基于 Conventional Commits 自动生成
+# 安装: pip install git-changelog
+git-changelog --output CHANGELOG.md --style conventional
+
+# 或手动整理
+cat >> CHANGELOG.md << 'EOF'
+
+## [1.2.0] - 2024-01-15
+
+### Added
+- 新增订单导出功能 (#123)
+- 新增批量操作接口 (#145)
+
+### Changed
+- 优化列表查询性能，P99 降低 40% (#156)
+- 升级 Redis 客户端到 v5.0 (#160)
+
+### Fixed
+- 修复并发场景下的库存扣减问题 (#167)
+- 修复分页查询的 off-by-one 错误 (#170)
+
+### Security
+- 升级依赖修复 CVE-2024-XXXX (#175)
+EOF
+```
+
+### 1.3 发布清单
+
+```markdown
+## 发布清单 v1.2.0
+
+### 代码
+- [ ] release 分支已从 develop 创建
+- [ ] 版本号已更新
+- [ ] CHANGELOG 已更新
+- [ ] 无未合并的 hotfix
+
+### 质量
+- [ ] 单元测试通过率 100%
+- [ ] 集成测试通过率 >= 99%
+- [ ] 代码覆盖率 >= 80%
+- [ ] 静态分析无新增告警
+- [ ] 安全扫描无高危/严重漏洞
+
+### 数据库
+- [ ] 迁移脚本已编写并测试
+- [ ] 迁移支持回滚
+- [ ] 预发布环境已验证迁移
+- [ ] 大表变更有预估执行时间
+
+### 基础设施
+- [ ] Docker 镜像构建成功
+- [ ] 配置变更已同步到各环境
+- [ ] 新增的环境变量/Secret 已配置
+- [ ] 资源配额已确认（CPU/内存/存储）
+
+### 监控
+- [ ] 核心指标告警已配置
+- [ ] 新功能的监控指标已添加
+- [ ] Dashboard 已更新
+
+### 通知
+- [ ] 发布计划已通知团队
+- [ ] 影响范围已通知下游
+- [ ] On-call 人员已确认
+```
+
+---
+
+## 步骤二：质量门禁
+
+### 2.1 自动化门禁
+
+```bash
+#!/bin/bash
+# release_gate_check.sh - 发布前自动检查
+
+set -e
+PASS=0
+FAIL=0
+
+check() {
+    local name=$1
+    local cmd=$2
+    echo -n "[$name] "
+    if eval "$cmd" > /dev/null 2>&1; then
+        echo "PASS"
+        ((PASS++))
+    else
+        echo "FAIL"
+        ((FAIL++))
+    fi
+}
+
+echo "=== 发布门禁检查 ==="
+
+check "Lint" "ruff check src/"
+check "Type Check" "mypy src/"
+check "Unit Tests" "pytest tests/unit/ -q"
+check "Integration Tests" "pytest tests/integration/ -q"
+check "Security Scan" "trivy image app:latest --severity HIGH,CRITICAL --exit-code 1"
+check "License Check" "pip-licenses --fail-on 'GPL;AGPL'"
+check "Docker Build" "docker build -t app:release-candidate ."
+
+echo ""
+echo "=== 结果: $PASS 通过, $FAIL 失败 ==="
+
+if [ $FAIL -gt 0 ]; then
+    echo "门禁未通过，不允许发布"
+    exit 1
+fi
+echo "门禁通过，可以发布"
+```
+
+### 2.2 手动检查项
+
+```markdown
+### 发布前人工检查
+
+- [ ] 在预发布环境完整走通核心用户旅程
+- [ ] 确认配置文件差异（staging vs production）
+- [ ] 确认第三方服务状态正常
+- [ ] 确认没有正在进行的大批量数据处理
+- [ ] 确认发布窗口没有冲突的其他变更
+```
+
+---
+
+## 步骤三：执行发布
+
+### 3.1 数据库迁移
+
+```bash
+# 先在生产环境执行数据库迁移
+# 原则：迁移必须向后兼容（旧代码能跑新 schema）
+
+# 备份当前数据库
+pg_dump -h db-host -U user -d production > backup_pre_release_v120.sql
+
+# 执行迁移
+python manage.py migrate --database production
+
+# 验证迁移
+python manage.py showmigrations --database production | grep -E "^\[X\]"
+
+# 如果迁移失败，回滚
+python manage.py migrate <app> <previous_migration> --database production
+```
+
+### 3.2 灰度发布
+
+```bash
+# Kubernetes 灰度部署
+
+# 阶段 1: 金丝雀 (5%)
+kubectl apply -f - << 'EOF'
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-canary
+  namespace: production
+spec:
+  replicas: 1  # 生产环境有 19 个副本，1 个金丝雀 = ~5%
+  selector:
+    matchLabels:
+      app: myapp
+      track: canary
+  template:
+    metadata:
+      labels:
+        app: myapp
+        track: canary
+    spec:
+      containers:
+      - name: app
+        image: app:v1.2.0
+        resources:
+          requests:
+            cpu: "500m"
+            memory: "512Mi"
+          limits:
+            cpu: "1000m"
+            memory: "1Gi"
+        readinessProbe:
+          httpGet:
+            path: /health
+            port: 8080
+          initialDelaySeconds: 10
+          periodSeconds: 5
+EOF
+
+echo "金丝雀已部署，观察 30 分钟..."
+```
+
+```bash
+# 阶段 2: 验证金丝雀
+# 持续监控金丝雀指标
+for i in $(seq 1 30); do
+    echo "=== 检查 $i/30 (每分钟一次) ==="
+
+    # 错误率
+    ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_errors_total{track='canary'}[5m])" | jq -r '.data.result[0].value[1] // "0"')
+    echo "金丝雀错误率: $ERROR_RATE"
+
+    # P99 延迟
+    P99=$(curl -s "http://prometheus:9090/api/v1/query?query=histogram_quantile(0.99,rate(http_duration_seconds_bucket{track='canary'}[5m]))" | jq -r '.data.result[0].value[1] // "0"')
+    echo "金丝雀 P99: ${P99}s"
+
+    sleep 60
+done
+```
+
+```bash
+# 阶段 3: 全量发布
+kubectl set image deployment/app app=app:v1.2.0 -n production
+kubectl rollout status deployment/app -n production
+
+# 删除金丝雀
+kubectl delete deployment app-canary -n production
+```
+
+### 3.3 发布类型矩阵
+
+| 类型 | 灰度策略 | 观察时间 | 回滚授权 |
+|------|----------|---------|---------|
+| 常规发布 | 5% -> 25% -> 50% -> 100% | 每阶段 30 分钟 | 发布负责人 |
+| 大版本发布 | 1% -> 5% -> 25% -> 50% -> 100% | 每阶段 2 小时 | 技术总监 |
+| 紧急发布 | 直接 100%（已验证的 hotfix） | 15 分钟 | On-call 负责人 |
+| 配置变更 | 特性开关渐进 | 即时 | 发布负责人 |
+
+---
+
+## 步骤四：发布后观测
+
+### 4.1 核心指标监控
+
+```bash
+#!/bin/bash
+# post_release_monitor.sh
+
+echo "=== 发布后监控 (每 5 分钟检查一次，持续 2 小时) ==="
+
+BASELINE_ERROR_RATE=0.001
+BASELINE_P99=0.2
+
+for i in $(seq 1 24); do
+    echo ""
+    echo "--- 检查 $i/24 ---"
+    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
+
+    # 错误率
+    ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_errors_total[5m])" | jq -r '.data.result[0].value[1] // "0"')
+
+    # P99
+    P99=$(curl -s "http://prometheus:9090/api/v1/query?query=histogram_quantile(0.99,rate(http_duration_seconds_bucket[5m]))" | jq -r '.data.result[0].value[1] // "0"')
+
+    # QPS
+    QPS=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total[5m])" | jq -r '.data.result[0].value[1] // "0"')
+
+    echo "[$TIMESTAMP] 错误率=$ERROR_RATE P99=${P99}s QPS=$QPS"
+
+    # 异常检测
+    if (( $(echo "$ERROR_RATE > $BASELINE_ERROR_RATE * 2" | bc -l) )); then
+        echo "!!! 警告: 错误率超过基线 2 倍 !!!"
+    fi
+
+    sleep 300
+done
+
+echo "=== 观察完成 ==="
+```
+
+### 4.2 业务指标确认
+
+```markdown
+### 发布后业务检查
+
+- [ ] 核心交易量正常（与上周同期对比偏差 < 10%）
+- [ ] 用户登录成功率正常
+- [ ] 支付成功率正常
+- [ ] 搜索结果正常
+- [ ] 无异常客服工单上升
+```
+
+### 4.3 发布确认
+
+```bash
+# 发布成功后的收尾
+# 1. 合并 release 分支
+git checkout main
+git merge --no-ff release/v1.2.0
+git tag -a v1.2.0 -m "Release v1.2.0"
+git push origin main --tags
+
+# 2. 同步到 develop
+git checkout develop
+git merge --no-ff release/v1.2.0
+git push origin develop
+
+# 3. 删除 release 分支
+git branch -d release/v1.2.0
+git push origin --delete release/v1.2.0
+
+# 4. 更新发布记录
+gh release create v1.2.0 --title "v1.2.0" --notes-file CHANGELOG.md
+```
+
+---
+
+## 步骤五：发布后清理
+
+### 5.1 资源清理
+
+```bash
+# 清理旧版本镜像（保留最近 5 个版本）
+docker images app --format "{{.Tag}}" | sort -V | head -n -5 | xargs -I {} docker rmi app:{}
+
+# 清理预发布环境
+kubectl delete deployment app-canary -n production 2>/dev/null || true
+```
+
+### 5.2 文档更新
+
+- [ ] API 文档已发布新版本
+- [ ] 用户文档/帮助中心已更新
+- [ ] 内部 Wiki 已更新
+- [ ] 发布邮件/通知已发送
+
+---
+
+## 回滚方案
+
+### 快速回滚
+
+```bash
+# Kubernetes 一键回滚
+kubectl rollout undo deployment/app -n production
+
+# 验证回滚
+kubectl rollout status deployment/app -n production
+
+# 确认服务恢复
+for endpoint in /health /api/v1/status; do
+    STATUS=$(curl -s -o /dev/null -w "%{http_code}" "http://api.example.com$endpoint")
+    echo "$endpoint: $STATUS"
+done
+```
+
+### 数据库回滚
+
+```bash
+# 回滚迁移
+python manage.py migrate <app> <previous_migration> --database production
+
+# 如果需要数据修复
+psql -h db-host -U user -d production < backup_pre_release_v120.sql
+```
+
+### 回滚决策矩阵
+
+| 信号 | 阈值 | 动作 | 决策者 |
+|------|------|------|--------|
+| 5xx 错误率 | > 1% | 立即回滚 | 自动 |
+| P99 延迟 | > 基线 3 倍 | 立即回滚 | 自动 |
+| 核心功能异常 | 任何 | 立即回滚 | On-call |
+| 非核心功能异常 | 影响 > 5% 用户 | 评估后回滚 | 发布负责人 |
+| 数据异常 | 任何数据不一致 | 立即回滚 + 数据修复 | 技术总监 |
+
+### 回滚后处理
+
+```bash
+# 1. 确认回滚成功
+kubectl get pods -n production -l app=myapp
+curl -s http://api.example.com/health | jq '.'
+
+# 2. 通知相关方
+echo "v1.2.0 已回滚至 v1.1.x，原因: [填写原因]"
+
+# 3. 创建故障报告
+# 参考 incident-hotfix-playbook.md
+
+# 4. 修复后重新走发布流程
+```
+
+---
+
+## Agent Checklist
+
+AI 编码 Agent 在协助发布时必须逐项确认：
+
+- [ ] **版本号正确**：符合语义版本规范，所有引用处已同步
+- [ ] **Changelog 完整**：所有变更已记录，格式规范
+- [ ] **质量门禁通过**：Lint、测试、安全扫描全部绿色
+- [ ] **迁移已验证**：数据库迁移在预发布环境成功执行
+- [ ] **回滚已准备**：回滚脚本存在且经过验证
+- [ ] **灰度配置就绪**：金丝雀部署配置正确
+- [ ] **监控已配置**：核心指标告警和 Dashboard 就绪
+- [ ] **发布窗口确认**：避开高峰时段，On-call 已确认
+- [ ] **观测进行中**：发布后持续监控至少 2 小时
+- [ ] **分支已合并**：release 分支已合并到 main 和 develop
+- [ ] **Tag 已创建**：Git tag 和 GitHub Release 已创建
+- [ ] **通知已发送**：发布结果已通知所有相关方

package/development/03-checklists/architecture-review-checklist.md

@@ -0,0 +1,168 @@
+---
+id: architecture-review-checklist
+title: 架构评审检查清单 (Architecture Review Checklist)
+domain: development
+category: 03-checklists
+difficulty: intermediate
+tags: [architecture, checklist, development, review, 参考, 可维护性与演进性, 可观测性, 成本与可行性]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 架构评审检查清单 (Architecture Review Checklist)
+
+> 适用场景：新系统设计评审、重大重构方案评审、技术选型决策、架构变更审批。
+> 通过标准：所有 MUST 项全部通过，SHOULD 项覆盖率 >= 80%，未通过项需记录风险接受决策。
+
+---
+
+## 1. 模块边界与职责
+
+- [ ] **系统边界已明确定义** — 系统上下文图（C4 Level 1）已绘制，外部系统 / 用户 / 数据源已标识。
+- [ ] **模块划分合理** — 每个模块有明确的单一职责，模块名称准确反映其业务能力。
+- [ ] **依赖方向单一** — 高层模块不依赖低层模块的实现细节，遵循依赖倒置原则。
+- [ ] **循环依赖已消除** — 模块间无循环依赖，依赖图为有向无环图（DAG）。
+- [ ] **接口契约已定义** — 模块间通过明确的接口（API / Event / Message）通信，非直接访问内部数据。
+- [ ] **领域模型已对齐** — 模块划分与业务领域（Bounded Context）对齐，无跨域混杂。
+
+---
+
+## 2. 非功能需求（NFR）
+
+### 2.1 性能
+
+- [ ] **性能目标已量化** — 关键接口的延迟目标（P50 / P95 / P99）和吞吐量目标（QPS / TPS）已定义。
+- [ ] **容量模型已建立** — 基于业务增长预测，1 年 / 3 年内的数据量、请求量、存储量已估算。
+- [ ] **热点路径已识别** — 高频访问的接口和数据已标识，有针对性的优化方案（缓存 / 异步 / 预计算）。
+- [ ] **性能测试方案已规划** — 压测场景、工具、目标指标、执行频率已确定。
+
+### 2.2 可用性
+
+- [ ] **可用性目标已定义** — SLA 等级已明确（如 99.9% / 99.95% / 99.99%），对应允许的停机时间已计算。
+- [ ] **RPO / RTO 已定义** — 数据恢复点目标和恢复时间目标已量化，与业务方达成一致。
+- [ ] **故障场景已枚举** — 各组件故障对系统整体影响已分析，故障传播路径已识别。
+
+### 2.3 可扩展性
+
+- [ ] **水平扩展路径已规划** — 系统可通过增加实例实现线性扩展，无全局锁或共享状态瓶颈。
+- [ ] **数据分片策略已定义**（如适用）— 分片键选择、数据分布、跨分片查询方案已设计。
+- [ ] **扩展成本可预估** — 从当前规模扩展 10x 的资源成本和架构改动范围已评估。
+
+### 2.4 安全性
+
+- [ ] **威胁模型已建立** — 使用 STRIDE / DREAD 等方法识别攻击面和潜在威胁。
+- [ ] **安全架构已设计** — 认证、授权、加密、审计的架构层面方案已定义。
+- [ ] **数据分级已完成** — 数据按敏感程度分级（公开 / 内部 / 机密 / 绝密），不同级别有对应保护措施。
+- [ ] **合规要求已纳入** — GDPR / 个人信息保护法 / 行业法规的技术要求已体现在架构设计中。
+
+---
+
+## 3. 可观测性
+
+- [ ] **监控方案已设计** — Metrics / Logging / Tracing 三大支柱的技术选型和集成方案已确定。
+- [ ] **关键指标已预定义** — 四大黄金指标（延迟、流量、错误率、饱和度）+ 业务指标的采集点已规划。
+- [ ] **告警策略已设计** — 告警分级、通知渠道、升级路径、抑制规则的方案已设计。
+- [ ] **Dashboard 已规划** — 系统全局视图、服务级视图、业务级视图的 Dashboard 布局已设计。
+- [ ] **日志规范已定义** — 日志格式、级别使用规范、敏感信息脱敏规则已制定。
+- [ ] **分布式追踪已设计** — traceId 传递机制、采样策略、存储方案已确定。
+
+---
+
+## 4. 数据架构
+
+### 4.1 数据存储
+
+- [ ] **存储选型有依据** — 每个数据存储（RDBMS / NoSQL / 对象存储 / 搜索引擎）的选型有明确理由。
+- [ ] **数据模型已设计** — ER 图或文档模型已定义，索引策略已规划。
+- [ ] **数据量级已评估** — 初始数据量和增长速度已估算，存储扩展方案已设计。
+- [ ] **数据备份策略已定义** — 全量 / 增量备份频率、保留策略、恢复演练计划已确定。
+
+### 4.2 数据一致性
+
+- [ ] **一致性模型已选择** — 强一致 / 最终一致 / 因果一致的选择有业务场景支撑。
+- [ ] **分布式事务方案已设计**（如适用）— Saga / TCC / 本地消息表等补偿方案已选定。
+- [ ] **对账机制已设计** — 关键业务数据有定期对账流程，不一致时有修复方案。
+- [ ] **幂等性设计已覆盖** — 所有写操作支持幂等重试，幂等键生成与存储方案已设计。
+
+### 4.3 数据流
+
+- [ ] **数据流向已可视化** — 数据从产生到消费的完整流转路径已绘制。
+- [ ] **消息队列选型合理** — Kafka / RabbitMQ / SQS 等选型匹配吞吐量、延迟、顺序性需求。
+- [ ] **消息可靠性已保证** — At-least-once / Exactly-once 语义已确认，消费失败有重试和死信队列。
+
+---
+
+## 5. 故障处理与韧性
+
+### 5.1 故障隔离
+
+- [ ] **服务间故障隔离** — 单个服务故障不级联影响其他服务，故障域已明确划分。
+- [ ] **资源隔离已实施** — 线程池 / 连接池 / 队列隔离，防止慢调用耗尽共享资源。
+- [ ] **租户隔离已设计**（如多租户）— 计算 / 存储 / 网络层面的租户隔离方案已确定。
+
+### 5.2 降级与熔断
+
+- [ ] **降级策略已定义** — 各非核心功能的降级方案已设计（缓存兜底 / 默认值 / 功能关闭）。
+- [ ] **熔断器已设计** — 下游服务调用的熔断阈值、半开探测、恢复策略已定义。
+- [ ] **限流策略已设计** — 全局限流 + 租户级限流 + 接口级限流的分层方案已确定。
+- [ ] **超时策略已设计** — 所有远程调用有超时配置，超时值基于上下游 SLA 设定。
+
+### 5.3 回滚与恢复
+
+- [ ] **回滚方案已设计** — 应用版本、数据库 Schema、配置变更均有可执行的回滚步骤。
+- [ ] **灰度发布已支持** — 新版本可按用户 / 流量比例分批发布，异常时快速回滚。
+- [ ] **灾难恢复方案已设计** — 主区域完全不可用时的恢复方案（热备 / 温备 / 冷备）已确定。
+
+---
+
+## 6. 可维护性与演进性
+
+- [ ] **技术栈统一且成熟** — 技术选型优先使用团队熟悉的成熟技术，新技术引入有 POC 验证。
+- [ ] **模块可独立部署** — 各模块可独立构建、测试、部署，无需全量发布。
+- [ ] **配置外部化** — 所有环境差异通过配置注入，无代码级别的环境判断。
+- [ ] **Feature Flag 机制已设计** — 支持功能开关，新功能可在线上安全地启停。
+- [ ] **版本兼容策略已定义** — 接口版本化规范、废弃流程、迁移窗口已确定。
+- [ ] **技术债务已评估** — 已识别的技术债务有清单和优先级排序，有计划的偿还节奏。
+
+---
+
+## 7. 成本与可行性
+
+- [ ] **资源成本已估算** — 计算 / 存储 / 网络 / 第三方服务的月度费用已估算。
+- [ ] **成本优化方案已考虑** — Reserved Instance / Spot / Serverless 等降本选项已评估。
+- [ ] **团队能力匹配** — 当前团队具备实施和维护该架构的技术能力，或有明确的招聘 / 培训计划。
+- [ ] **里程碑可达** — 架构实施分阶段，每阶段交付物和时间线现实可行。
+- [ ] **替代方案已对比** — 至少评估了 2 个替代方案，选型决策有 ADR 记录。
+
+---
+
+## 8. 文档交付物
+
+- [ ] **架构概览图** — C4 Level 1（系统上下文）和 Level 2（容器图）已绘制。
+- [ ] **技术选型文档** — 各组件的技术选型理由和对比分析已记录。
+- [ ] **数据模型文档** — ER 图 / Schema 定义 / 数据字典已完成。
+- [ ] **接口契约文档** — 各模块间 API 定义（OpenAPI / Protobuf / AsyncAPI）已发布。
+- [ ] **NFR 指标文档** — 非功能需求的具体量化指标已汇总。
+- [ ] **ADR 文档** — 重要架构决策已记录为 Architecture Decision Record。
+
+---
+
+## 参考
+
+- C4 Model — https://c4model.com/
+- AWS Well-Architected Framework — https://aws.amazon.com/architecture/well-architected/
+- Microsoft Azure Architecture Center — https://learn.microsoft.com/en-us/azure/architecture/
+- Martin Fowler: Patterns of Enterprise Application Architecture
+
+---
+
+## Agent Checklist
+
+供 AI Agent 在执行架构评审时使用的自检项：
+
+- [ ] 已审查架构图（系统上下文图 + 容器图），确认模块边界和依赖方向正确。
+- [ ] 已逐项核对非功能需求，每个 NFR 有量化的目标值。
+- [ ] 已验证数据一致性方案覆盖所有跨服务写操作场景。
+- [ ] 已评估单点故障风险，确认关键路径无 SPOF。
+- [ ] 已检查故障场景下的降级和恢复路径。
+- [ ] 已核对技术选型与团队能力的匹配度。
+- [ ] 架构评审结论已记录，包含通过项、风险项、和行动项清单。