第2章：第一步：流动原则（The First Way: Flow）
一、导读
1.1 本章学习目标
流动原则是 DevOps 三大原则之首，目标是让工作快速、顺畅地从开发流向生产环境。
本章的核心学习目标包括：
- 使工作可视化：看板、信息辐射器。
- 限制在制品（WIP Limit）：减少多任务切换。
- 减少批量大小：小批量快速反馈。
- 识别和消除约束：约束理论（TOC）。
- 建立持续交付流水线：从代码到生产的自动化。
1.2 为什么本章如此重要
流动是 DevOps 的基础。如果工作无法快速流动，反馈就慢、学习就慢、改进就慢。本章借鉴精益制造的流动优化方法，将其应用到软件交付中。
1.3 核心问题引导
为什么多任务切换会降低效率？
小批量为什么比大批量更好？
如何识别价值流中的约束？
持续交付流水线的核心是什么？
二、核心概念详解
2.1 使工作可视化
2.1.1 看板（Kanban）
| Backlog | Development | Code Review | Testing | Staging | Production |
| 10 | 3/5 | 2/3 | 4/4 | 1/2 | - |
数字格式：当前数量/WIP限制
当 Testing 列满了（4/4），Development 不能再推送新工作看板的作用：
- 可视化工作流
- 识别瓶颈
- 限制在制品
- 促进协作
2.1.2 信息辐射器
- 团队看板
- 构建状态灯（绿/红）
- 部署频率图表
- 生产环境指标大屏
2.2 限制在制品（WIP Limit）
多任务切换的代价：
- 上下文切换成本（重新进入状态需要时间）
- 增加等待时间
- 降低质量
没有 WIP 限制：
开发者 A 同时进行 5 个任务，每个任务都进展缓慢
所有任务都需要 2 周才能完成
有 WIP 限制（每人最多 2 个任务）：
开发者 A 专注完成 2 个任务，再开始新的
每个任务 3 天完成，吞吐量更高2.3 减少批量大小
大批量的问题：
- 风险高（大量变更一次性上线）
- 反馈慢（几周后才知道问题）
- 回滚难（变更太多难以定位问题）
小批量的优势：
- 风险低（每次只变更一小部分）
- 反馈快（几分钟就知道结果）
- 回滚容易（只回滚一小部分）
大批量：每2周发布一次，每次100个变更
- 出问题后难以定位是哪个变更导致的
- 回滚会丢失2周的所有功能
小批量：每天发布多次，每次1-3个变更
- 出问题后立即可知是哪个变更
- 只回滚有问题的变更2.4 识别和消除约束
约束理论（TOC）的五步聚焦法：
识别约束：找到价值流中最慢的环节
利用约束：确保约束环节不被浪费
迁就约束：其他环节配合约束环节
提升约束：增加约束环节的能力
重复：约束转移后，回到第1步
示例：
价值流：开发(3天) → 代码审查(1天) → 测试(5天) → 部署(0.5天)
约束：测试（最慢，5天）
利用约束：确保测试环境随时可用，不被其他工作占用
迁就约束：开发完成后立即进入测试，不等待
提升约束：增加测试人员、自动化测试
重复：测试加速后，约束可能转移到代码审查2.5 持续交付流水线
commit → build → unit test → integration test → security scan
→ staging deploy → smoke test → production deploy → canary流水线的要求：
- 快速：整个流程在10分钟内完成
- 可靠：每次运行结果一致
- 自修复：失败后自动重试或通知
- 可观测：每个阶段的状态清晰可见
三、实战案例
3.1 Jenkins Pipeline
groovy
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean package'
}
}
stage('Unit Test') {
steps {
sh 'mvn test'
}
}
stage('Integration Test') {
steps {
sh 'mvn verify -Pintegration'
}
}
stage('Security Scan') {
steps {
sh './security-scan.sh'
}
}
stage('Deploy Staging') {
steps {
sh './deploy.sh staging'
}
}
stage('Deploy Production') {
when {
branch 'main'
}
steps {
sh './deploy.sh production'
}
}
}
}3.2 GitHub Actions
yaml
name: CI/CD Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Test
run: npm test
- name: Lint
run: npm run lint
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Deploy
run: ./deploy.sh四、本章小结
使工作可视化：看板让工作流透明。
限制在制品：专注完成，减少切换。
减少批量：小批量快速反馈。
识别约束：找到并消除瓶颈。
持续交付：自动化从代码到生产的流程。
五、思考与练习
思考题
为什么限制在制品能提高吞吐量？
小批量部署的风险一定比大批量低吗？
如何识别你团队的价值流约束？
练习题
为你的团队画一个看板，识别瓶颈。
设计一条持续交付流水线。
计算你的价值流的流动效率。