07 - 部署与运营：从合并到用户可见

部署不是"开发者走完代码就下班"，是"上线后这个改动还活着、有反馈、有负责人"。部署后没人管 = 没部署。

一句话

CI/CD + 灰度发布 + 监控告警 + 事故复盘 = 完整部署闭环——任何一步缺失，部署就有"赌"的成分。

CI/CD 流水线

CI（持续集成）必跑的 5 个门

PR 提交 → CI 自动跑：
1. Lint         （5 秒）    代码风格
2. Build        （< 5 分钟）  编译
3. Unit Test    （< 5 分钟）  单元测试
4. Static Analysis（< 5 分钟） 静态检查
5. Security Scan（< 5 分钟） 漏洞扫描

全部通过 → PR 可合并

CD（持续部署/交付）的 4 种发布节奏

1. 持续部署（Continuous Deployment）
   PR 合并 → 自动生产部署
   适用：5-10 人小团队 + 强测试 + 灰度

2. 持续交付（Continuous Delivery）
   PR 合并 → 制品生产就绪 → 手动点击生产部署
   适用：10-30 人 + 业务风险中等

3. 定时发布（Daily / Weekly Release）
   定时窗口发布（如每天 10 点）
   适用：中等风险 + 运维要求控制时间

4. 紧急热修复（Hotfix）
   跳过部分流程，但必须经过 Review
   适用：生产事故 + 安全漏洞

流水线 YAML 示例（GitHub Actions）

yaml

name: Production Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm test --coverage
      - run: pnpm build
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/download-artifact@v4
      - run: ./deploy.sh staging
      - name: Smoke Test
        run: ./smoke-test.sh

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Manual Approval Gate
        uses: trstringer/manual-approval@v1
        with:
          secret_name: APPROVE_TOKEN
      - uses: actions/download-artifact@v4
      - run: ./deploy.sh production --canary 10%
      - run: ./deploy.sh production --full

4 种部署策略

策略 1：蓝绿部署（Blue-Green）

        负载均衡
          │
    ┌─────┴─────┐
    ▼           ▼
 ┌──────┐   ┌──────┐
 │ Blue │   │Green │ （一台旧，一台新）
 │ v1.0 │   │ v1.1 │
 └──────┘   └──────┘

切换：流量从 Blue 切到 Green
回滚：流量切回 Blue

优点：切换瞬间完成、回滚快缺点：双倍资源

策略 2：金丝雀部署（Canary）

        负载均衡
          │
   ┌──────┴───────┐
   ▼              ▼
 ┌──────┐      ┌──────┐
 │  v1  │      │  v2  │ （5-10% 流量到 v2）
 │ 90%  │      │ 10%  │
 └──────┘      └──────┘

观察 → 逐步加比例 → 100%

优点：小流量验证、风险可控缺点：需要监控支撑决策

策略 3：滚动部署（Rolling）

┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐
 │ v1   │  │ v1   │  │ v2   │  │ v1   │  (实例 3 已升级)
 │      │  │      │  │  🆕  │  │      │
 └──────┘  └──────┘  └──────┘  └──────┘

逐步替换 → 全部 v2

优点：资源不翻倍、流程简单缺点：回滚慢、新旧共存导致问题

策略 4：Feature Flag

代码已合并，但功能未启用
Feature Flag 控制开关：

if (feature_flag('new-payment', user)) {
  // 新代码
} else {
  // 老代码
}

优点：已部署 = 已验证（开关打开即发布）缺点：需要 FF 平台

SE@Google 与现代团队标配：蓝绿 + 金丝雀 + Feature Flag 组合。

监控的可观测性三件套

SE@Google 与业界共识：可观测性 = 指标 + 日志 + 追踪。

1. Metrics（指标）

最常用（RED 方法）：

Rate（请求速率）——QPS
Errors（错误数）——5xx / 4xx 比率
Duration（延迟）——P50 / P95 / P99

资源（USE 方法）：

Utilization（使用率）——CPU / 内存 / 磁盘
Saturation（饱和度）——队列长度
Errors（资源错误）

工具：Prometheus + Grafana / Datadog / 阿里云监控

2. Logs（日志）

结构化日志（JSON）：

json

{
  "timestamp": "2026-06-28T14:00:00Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc123",
  "user_id": "u_12345",
  "order_id": "o_67890",
  "message": "Failed to create order",
  "error": {
    "type": "DatabaseConnectionError",
    "stack": "..."
  }
}

关键字段：

service: 服务名
trace_id: 追踪 ID（与追踪系统关联）
level: 日志级别
context: 用户/订单 ID 等关键上下文

工具：ELK / Loki / 阿里云 SLS / Datadog Logs

3. Traces（追踪）

跨服务调用链：

Request → API Gateway → Order Service → Payment Service
            trace_id:  abc123              abc123
            span_id:   span_1              span_2
            parent_id:                     span_1

关键工具：Jaeger / Zipkin / Datadog APM / SkyWalking

OpenTelemetry 是行业标准——所有可观测性工具都支持。

告警体系

告警的三种类型

1. 严重（Page）——马上叫人

服务完全不可用
错误率 > 50%
P99 延迟 > 10s

2. 警告（Ticket）——下次处理

错误率上升 10%
资源使用率 > 80%
单个实例异常

3. 信息（Log）——只需查看

新版本发布
自动扩容

告警原则（减少"狼来了"）

告警必须有人认领——每个告警有明确的 Owner
可操作——告警必须含"如何修复"的提示
响应时间——严重告警 5 分钟响应，警告 1 小时
抑制规则——防止告警风暴（如网络故障导致所有下游告警）

告警疲劳修复

症状：凌晨 3 点被叫醒 10 次，9 次是误报。

根因：阈值设置不合理 / 监控指标选错。

修复：

区分"症状"和"原因"——症状（错误率）= 触发；原因（DB 慢）= 抑制
告警分级——严重才叫人，警告发邮件
每周告警评审——删除无效告警

事故响应（Incident Response）

角色分工（事故中）

IC（Incident Commander）:
   决策者。负责协调 + 决策 + 沟通。
   不是技术最强的人，是最冷静的人。
   任务：判定优先级 + 派任务 + 召集人。

Ops Lead（运维负责人）:
   执行者。负责调查 + 修复。
   是动手写代码 / 操作系统的。

Communications Lead（沟通负责人）:
   对外沟通。每 30 分钟一次更新。

Subject Matter Experts（SME）:
   领域专家。被 IC 调用。

关键：IC 不能动手写代码——要决策不要执行。

事故级别

SEV1：核心业务完全中断（不能下单） SEV2：核心业务部分受损（10% 错误率） SEV3：单个组件异常（监控不影响业务） SEV4：小问题（文案错误）

事故响应 6 步

1. 检测（监控告警）+
2. 通知（自动呼叫 On-call）+
3. 评估（IC 评定 SEV 级别）+
4. 修复（Ops Lead 执行）+ 沟通（每次重大进展更新）
5. 验证（确认问题不再出现）+
6. 关闭（SEV 降级 → 关闭）

事故复盘（Postmortem）

SE@Google Ch10 关键原则：

"Postmortems are blameless and focus on systemic improvements."

翻译：复盘不追责，找系统漏洞——避免下次同样事故。

Postmortem 模板：

markdown

# 事故 #P2026-XXX：[简短标题]

## 影响
- 时长：从 [HH:MM] 到 [HH:MM] = [X 小时 Y 分钟]
- 用户：[N 用户] 受影响
- 业务影响：[订单损失 / GMV 影响 / 退款额度]

## 时间线
| 时间 | 事件 |
|------|------|
| 14:00 | 监控告警：错误率 > 50% |
| 14:05 | On-call 同学 X 响应 |
| 14:10 | 确认问题：DB 连接池耗尽 |
| 14:20 | 应用新版本（含连接池扩大） |
| 14:25 | 错误率下降 |
| 14:30 | 全量恢复 |

## 根因
- **直接原因**：DB 连接池耗尽（HikariCP max=20 不够）
- **根本原因**：未做容量评估 + 流量是日常 3 倍

## 为什么没发现
- 上线前未做压测
- 监控阈值设置过高（连接池使用率 95% 才告警）
- 没有"扩缩容演练"

## 改进措施（Action Items）
| 改进项 | 负责人 | 截止日 | 优先级 |
|--------|--------|--------|--------|
| HikariCP max 调到 50 | 张三 | 7/5 | P1 |
| 加连接池使用率告警（70% 触发） | 李四 | 7/10 | P1 |
| 每月一次容量演练 | 王五 | 7/30 | P2 |
| 大版本上线前压测 | 全员 | 即时 | P0 |

反模式：复盘会议变成"追责会"——必须强调 blameless。

DORA 4 指标（行业标准）

1. Deployment Frequency（部署频率）

优秀：每天多次
良好：每周 1-7 次
一般：每月 1-4 次

2. Lead Time for Changes（变更前置时间）

优秀：< 1 小时
良好：< 1 天
一般：< 1 周

3. Change Failure Rate（变更失败率）

优秀：0-15%
良好：16-30%
一般：> 30%

4. MTTR（Mean Time To Recovery）

优秀：< 1 小时
良好：< 1 天
一般：> 1 天

这些指标用于自评，不用于"批评团队"——目标是把基建搞好让指标自然改善。

容量规划

容量 3 步法

1. 现状评估
   - 当前 QPS
   - 当前资源使用率
   - 当前峰值

2. 增长预测
   - 业务增长率
   - 季节性（双 11 / 春节）
   - 新功能影响

3. 资源规划
   - 计算新峰值
   - 预留 30-50% buffer
   - 提前压测验证

反模式："机器挂了再扩容"——扩容要 5 分钟，故障抢修要 30 分钟，差 25 分钟的事故量。

部署的反模式（10 种）

1. 部署恐惧症

症状：团队害怕发版，几次延迟合并后批量上线。

修复：用蓝绿 / 金丝雀 + 完善监控 → 让发版"无聊"。

2. 手动部署

修复：任何部署必须脚本化。手动 = 错误。

3. 不区分环境

修复：开发 / 测试 / 预发 / 生产 — 4 套环境。

4. 跳环境测试

修复：所有环境必须完整跑一遍。

5. 没有回滚计划

修复：每个发布必须有"1 键回滚"。

6. 部署时程序员不在

修复：On-call 必须覆盖发布时间。

7. 部署后不验证

修复：发布后 15 分钟必须有"业务指标看板" + "技术指标看板"双监控。

8. 监控只监控技术

修复：必须监控业务指标（订单数 / 转化率 / 错误率）。

9. 事故不复盘

修复：每次事故必须有 Postmortem + Action Items 落实。

10. 没有 On-call

修复：5 人以上团队必须有 On-call 轮值表。

发布 Runbook

每个服务必须有：

markdown

# 部署 Runbook：[服务名]

## 部署前
1. CI 是否通过：[链接]
2. 上一个版本是否稳定（错误率 < 0.1%）
3. 业务时段检查（避开业务高峰期）
4. 利益相关者通知（飞书机器人）

## 部署步骤
1. [手动点击 / 自动触发]
2. 观察指标 15 分钟
3. 完成部署

## 回滚步骤
1. [操作] 一键回滚到 v[Y]
2. 验证回滚成功
3. 发送通知

## 常见问题

### Q: 部署失败怎么办
A: 见 troubleshooting 章节

### Q: 数据库迁移怎么走
A: 见 migration-runbook

进入下一章

部署与运营完成后，下一步：

08 团队与流程——人员协作 + 知识沉淀 + 长期作战力

作者：基于 SE@Google Ch23-24 (CI/CD) + Ch25 (CaaS) + DORA 4 指标 + 事故复盘实践综合 最后更新：2026-06-28

07 - 部署与运营：从合并到用户可见 ​

一句话 ​

CI/CD 流水线 ​

CI（持续集成）必跑的 5 个门 ​

CD（持续部署/交付）的 4 种发布节奏 ​

流水线 YAML 示例（GitHub Actions） ​

4 种部署策略 ​

策略 1：蓝绿部署（Blue-Green） ​

策略 2：金丝雀部署（Canary） ​

策略 3：滚动部署（Rolling） ​

策略 4：Feature Flag ​

监控的可观测性三件套 ​

1. Metrics（指标） ​

2. Logs（日志） ​

3. Traces（追踪） ​

告警体系 ​

告警的三种类型 ​

告警原则（减少"狼来了"） ​

告警疲劳修复 ​

事故响应（Incident Response） ​

角色分工（事故中） ​

事故级别 ​

事故响应 6 步 ​

事故复盘（Postmortem） ​

DORA 4 指标（行业标准） ​

容量规划 ​

容量 3 步法 ​

部署的反模式（10 种） ​

1. 部署恐惧症 ​

2. 手动部署 ​

3. 不区分环境 ​

4. 跳环境测试 ​

5. 没有回滚计划 ​

6. 部署时程序员不在 ​

7. 部署后不验证 ​

8. 监控只监控技术 ​

9. 事故不复盘 ​

10. 没有 On-call ​

发布 Runbook ​

进入下一章 ​