价值流 (Value Stream)
价值流 = 从代码到生产的连续路径——跨项目通用的工程血脉。
一句话
价值流 = 持续集成 + 持续交付 + 持续部署——从代码到用户的连续血脉。
它在哲学里叫什么
Kant《纯粹理性批判》(1781) —— 时间序列的因果规律
第二类比（因果性）：
时间序列的必然规律——所有变化都遵循因果律。
价值流的 Kant 加深：
- 价值流 = 因果链——从代码 → 构建 → 测试 → 部署的因果序列
- 价值流 = 时间序列的必然性——每一步都是下一步的原因
海德格尔《存在与时间》(1927) —— §65 时间性
"时间性是此在的本源——将来-曾在-当前三种样式的统一到时。"
价值流的海德格尔加深：
- 价值流 = 此在的"到时"——代码的当前 → 构建的曾在 → 部署的将来
- 价值流 = 连续展开——不是孤立的步骤，是展开的过程
Wittgenstein《Tractatus》(1921) —— 时间中的命题
"The events of the future cannot be inferred from those of the present" (5.1361)
价值流的 Wittgenstein 加深：
- 价值流 = 因果推断——从当前推断未来
- 价值流 ≠ 完全可推断——5.1361 未来事件不能从当前推出
James《Pragmatism》(1907) —— 真理的实用主义
"Truth grows" / "We make truth"
价值流的 James 加深：
- 价值流 = 真理的生长——价值在流通过程中生长
- 价值流 = 实用主义的具体化——价值 = 实用后果
老子《道德经》—— 大邦处下
"大国者下流...大国以下小国，则取小国" (41 章)
价值流的老子加深：
- 价值流 = 大邦处下——价值流最大的瓶颈在下游（生产/用户）
- 价值流 = 处众人之所恶——价值流要服务于用户而非流程
它在控制论里叫什么
钱学森《论系统工程》(1978) —— §21 大系统 / §1.5 分析 vs 综合
综合（设计）的目的便是改造这种运动规律，使之满足我们的需要。
价值流的钱学森加深：
- 价值流 = 综合（设计）——把代码 → 部署的运动规律改造为满足用户需要的
- 价值流 = 大系统的多级控制——CI / CD / Production = 多级
- 价值流 = 互不影响原则——各阶段尽量解耦
INCOSE SE Handbook —— 生命周期 5 阶段
- Concept（概念）
- Development（开发）
- Production（生产）
- Operations（运营）
- Retirement（退役）
价值流的 INCOSE 加深：
- 价值流 = 生命周期 5 阶段——从概念到退役
- 价值流 = 跨阶段的连续性——不是孤立阶段
它在系统思维里叫什么
Marcus P. Dawson《Thinking in Systems》(2020) —— 系统映射 + 反馈环
系统映射：
"Systems mapping: A way to identify components of a system and see how they are connected."
价值流的 Dawson 加深：
- 价值流 = 系统映射——可视化每个环节
- 价值流 = 反馈环——每个环节的反馈
SE@G "SE = 编程 × 时间"
"The trick is to keep the quantity of feedback at a manageable level."
价值流的 SE@G 加深：
- 价值流 = 反馈量管理——保持反馈量可控
- 价值流 = 时间维度的工程——SE 解决时间维度问题
它在软件工程里叫什么
持续集成（CI）—— 通用模式
核心实践：
- 每次代码变更自动触发构建
- 自动化单元测试 + 集成测试
- 快速反馈（< 10 分钟）
- 主干开发 / 特性分支
- 提交频率高（每天多次）
工具生态（通用，不绑定特定技术栈）：
- CI 服务器（Jenkins / GitHub Actions / GitLab CI）
- 构建工具（Maven / Gradle / npm / Cargo）
- 测试框架（JUnit / pytest / Jest）
持续交付（CD）—— 通用模式
核心实践：
- 自动化部署到类生产环境
- 部署流水线（Build → Test → Stage → Production）
- 环境一致性（开发 / 测试 / 生产环境相同）
- 配置管理（基础设施即代码）
工具生态：
- 配置管理（Ansible / Chef / Puppet / Terraform）
- 容器化（Docker / Kubernetes）
- 制品仓库（Nexus / Artifactory）
持续部署（CD 2.0）—— 通用模式
核心实践：
- 自动化部署到生产环境
- 灰度发布 / 金丝雀发布 / 蓝绿部署
- 自动化回滚
- 监控告警
工具生态：
- 部署平台（Kubernetes / Spinnaker / ArgoCD）
- 流量管理（Service Mesh / API Gateway）
- 监控（Prometheus / Grafana / Datadog）
价值流的核心模式
| 模式 | 含义 | 通用实践 |
|---|---|---|
| 主干开发 | 所有开发者在主分支上工作 | GitHub Flow / GitLab Flow |
| 特性分支 | 每个特性独立分支 | Git Flow（不适合持续部署） |
| 拉取请求（PR） | 代码审查 + CI 集成 | GitHub PR / GitLab MR |
| 代码审查 | 团队对代码的反馈 | 同行审查 / 配对编程 |
| 自动化测试 | 单元 + 集成 + E2E | 测试金字塔 |
| 持续集成 | 每次提交自动构建 + 测试 | CI 服务器 |
| 持续交付 | 自动化部署到类生产 | CD 流水线 |
| 持续部署 | 自动化部署到生产 | 灰度发布 + 监控 |
| 基础设施即代码 | 环境配置版本化 | Terraform / Ansible |
| 不可变基础设施 | 服务器不修改，只替换 | 容器镜像 / AMI |
价值流的反模式
| 反模式 | 含义 | 后果 |
|---|---|---|
| 手动部署 | 人工 SSH 到服务器 | 不可重现 / 容易出错 |
| 长期分支 | 特性分支存活 > 1 周 | 合并冲突 / 集成风险 |
| 测试环境与生产不一致 | 开发用一套，生产用另一套 | "在我机器上能跑" |
| 跳过测试 | 注释掉失败的测试 | 技术债累积 |
| 大爆炸发布 | 一次性发布大量变更 | 风险集中 / 难回滚 |
| 手工配置 | 配置文件在服务器上手工改 | 配置漂移 |
看不见的地方
失效模式 1：价值流的瓶颈未识别
失效：价值流有瓶颈但未被识别 → 优化错位置。
失效模式 2：反馈环时间过长
失效：CI 流水线跑 1 小时以上 = 反馈不及时。
失效模式 3：构建不可重现
失效：构建依赖未版本化 = "我机器上能跑"。
失效模式 4：环境漂移
失效：开发 / 测试 / 生产环境不一致。
失效模式 5：手工部署的伪自动化
失效：自动化部署脚本中存在手工步骤。
失效模式 6：CI 服务器成为瓶颈
失效：CI 服务器资源不足 = 排队等待。
失效模式 7：测试覆盖率假象
失效：覆盖率 80% 但测试都是空跑。
失效模式 8：监控告警疲劳
失效：告警太多 = 真正的告警被淹没。
失效模式 9：部署窗口
失效：限制部署时间 = 风险集中。
失效模式 10：大爆炸发布
失效：半年发布一次 → 高风险 → 团队害怕部署。
失效模式 11：长期分支
失效：分支存活 > 1 周 → 集成风险。
失效模式 12：基础设施不可变被违反
失效：手动 SSH 到服务器修改。
失效模式 13：忽略 Kant 第二类比（因果性）
失效：价值流的因果链不清晰。
失效模式 14：忽略 Wittgenstein 5.1361
失效：以为可以从当前完全推断未来 → 失去对不可预测性的警觉。
失效模式 15：老子"大邦处下"的反向
失效：价值流优化错位置（如优化 CI 而忽略生产）。
相关节点
- 质量保障 (E2) — 价值流中质量如何保证
- 反馈机制 (E3) — 价值流中反馈如何流动
- 变更管理 (E4) — 价值流中变更如何控制
- 度量改进 (E5) — 价值流如何度量改进
哲学根基：Kant 第二类比因果律 / 海德格尔 §65 时间性 / Wittgenstein 5.1361 / James 真理生长 / 老子 41 章 元理论根基：钱学森 §21 大系统 / §1.5 综合（设计）/ INCOSE 生命周期 5 阶段 思维工具根基：Dawson 系统映射 / SE@G "编程 × 时间" 工程层投影：CI / CD / 持续部署 + 主干开发 + PR + 代码审查 + 自动化测试 + 基础设施即代码 + 不可变基础设施