DevOps的思想来源

以你之姓@ 2022-05-20 22:58 226阅读 0赞

*  DevOps的思想来源
    
     *  DevOps概念介绍
     *  精益生产方式 ／ 丰田生产系统
     *  约束理论
     *  敏捷
     *  小结
     *  扩展阅读

# DevOps的思想来源 #

## DevOps概念介绍 ##

在DevOps入门篇的开始，我们首先来了解一下DevOps这个概念。从字面上看，DevOps就是Dev + Ops。Dev可以理解为Development，也就是开发；也可以理解为Developer，也就是开发人员。Ops可以理解为Operation，也就是运维；也可以理解为Operator，也就是运维人员。所以从字面上来看，DevOps就是如何开发软件，如何交付软件，如何运维软件，以及在这些过程中的协调。

但是说完上面这句话，和没有说是一样的。我们要从思想上、源头上和哲学上来梳理DevOps这个概念的来龙去脉。

DevOps的思想来源是非常广泛的，主要的来源有几个方面：第一个方面是来源自精益生产模式（Lean) 或者说是丰田生产系统（TPS)；第二个方面是来自于约束理论（ToC）；第三个方面是来自于敏捷（Agile）。

本来想严格地按照时间线来梳理DevOps的思想来源，但是考虑到这是一篇技术博客，而不是考古文章，所以就换用思想来源加实际案例来讲解。

## 精益生产方式 ／ 丰田生产系统 ##

DevOps经典图书《DevOps实践指南》阐述了DevOps的思想来源，该书对DevOps思想来源之一的精益生产方式特别推崇，提出DevOps基础原则（三步法）：流动、反馈和持续学习与经验。这三步和精益生产方式是完全契合的，并且该书的目录结构也是基于这三步法。

精益方式（lean production）／丰田生产系统（TPS) 是来自生产制造企业的思想。

在二战后，美国凭借其强大的工业实力，一跃成为世界最强大的国家，其中美国制造业成了品质保障的标志。

然而，不久日本制造就大量进入美国市场，包括汽车和电子产品等。一时间，比较日本制造和美国制造的优劣成了工业界的热门话题。

相比美国制造，日本制造的主要优点是：物美价廉、品种多样、交货期短。

物美价廉意味着日本制造可以花更低的成本制造出同等优良品质的产品。对制造业来说，控制成本至关重要。

品种多样意味着日本制造企业可以快速地响应市场需求，能够定制化地满足各类需求。对传统制造企业来说，大批量才能降低单位成本，但是大批量就意味着不能同时做到品种多样和满足个性化需求。

交货期短意味着日本制造业可以给销售商更靠谱的承诺。因为通常只有越临近销售日期，比如节假日，销售商才能够更正确地估计销售额。因此销售商总是希望制造商的交货期越短越好。

那么日本制造是如何做到这几点的呢？

美国学者研究了美国制造企业和日本制造企业，得出了一个重要结论就是日本制造普遍使用了精益生产方式。精益生产方式来源自日本丰田公司（就是丰田汽车的丰田）发明的丰田生产系统。美国学者把丰田生产系统重新命名为一个更通用的名字——精益生产方式。

从此，生产制造企业开始了学习精益生产方式的热潮，至今方兴未艾。

关于精益生产方式或丰田生产系统的系统学习，请参考《精益思想》和《丰田生产方式》。

下面结合IT实践来简单讲解精益生产方式的几个概念和技术：

**价值流**

精益生产方式强调要加快价值流的流动，即尽量缩短前置时间（交货期），尽量减少生产过程的浪费。

以软件交付为例，价值流就是将用户需求转变成可以工作的软件，并提供给用户使用。用户提出一个新需求，多久可以上线？竞争对手的App出了个大受欢迎的新功能，多久你的App也可以实现类似功能？

精益生产方式中列出了很多种浪费的情形，其中因为质量问题而导致返工和等待是其中两种最容易被忽视却非常值得关注的浪费。

以软件交付为例，如果不做好测试，系统上线有缺陷而导致紧急修复缺陷，不仅会导致声誉受损、客户流失，同时也是一种浪费。另外，在开发过程中，因为编译构建太慢，开发人员不得不等待编译构建完成才能继续工作，也是一种浪费。或者，测试人员在开发人员手工打版之前，不得不等待，也是一种浪费。

**小批量生产**

精益生产方式强调采用和流水线适应的小批量生产，而不是无节制的大规模批量生产。以生产汽车为例，一条汽车生产线上，从进入生产线开始，到离开生产线，一辆汽车的总装完成只需要1～2分钟。也就是说，每条汽车生产线都是以生产出一台可以正常行驶的汽车为目标的，而不是为了生产出组装汽车的各类零配件。小批量生产的好处主要有：短时间内就可以生产出第一个可交付的产品；发现问题快，一旦发现问题，修复成本低；避免库存积压风险。

以软件集成为例，开发人员每次提交代码后，就触发集成过程，并运行自动代码质量分析和自动化单元测试。这个过程也叫持续集成，可以帮助我们快速地发现代码质量问题，并尽早解决问题。如果不做持续集成，而是等到软件要上线前一个星期才开始集成，代码的冲突、测试失败、集成后启动失败会是一个噩梦。也就是说，我们应该关注的是我们交付了多少可以工作的软件，而不是我们写了多少代码。

**及时生产（JIT)**

精益生产方式中及时生产就是指生产下游环境真正需要的制品，也就是由下游环节拉动，而不是上游环节推动。比如，超市货架上位置有限，摆放不了几篇牛奶，这个时候就应该根据牛奶销售情况，及时补充货架上的牛奶，而不是把牛奶堆满整个超市。事实上，大野耐一就是从超市货架的灵感发明了及时生产的理论。

以软件项目管理为例，在使用看板后，如果WIP一列任务过多，就需要考虑是否同时开始了多个任务，并且这些任务都没法短期完成。这个时候就需要重新排优先级来将一部分任务从WIP中挪回TODO。

**现场管理**

精益生产方式强调现场管理，也就是管理者要现场实地实物考察，才能做出决策。以丰田汽车为例，丰田汽车的办公室和汽车制造车间是挨在一起的。丰田汽车的经理们平时也都是穿着工装，这样他们就可以随时进入工厂现场管理。

对软件团队来说，最理想的工作环境就是大家坐在一起办公，有问题当面讨论。如果是分布式团队，也可以借助视频会议的方式让团队可以”面对面“沟通。

**看板**

精益生产方式非常强调看板这种可视化工具。看板可以真的是一块白板，上面标出了一些任务状态，也可以是任何可视化地表达了一定含义的东西。比如，堆积如山的零配件是一种看板，因为它意味着生产线的下一个环节出了问题，不能消化掉这些零配件。比如，散落一地的工具是一种看板，因为它意味着没有对工具进行分类存放，会导致寻找工具过程的浪费。比如，聚集在一起闲聊的工人是一种看板，因为它意味着这个岗位安排的值班人数太多，或上一个生产环节太慢。

以软件项目管理为例，可以用看板来可视化团队的工作情况、任务进展、项目目标、风险列表等。又比如持续集成失败时的红色警告标志或系统自动发送的通知邮件也是一种看板。

**大部屋**

丰田汽车在研发新款汽车时，会组建跨职能团队在一个大房间里集中办公。这个大房间在日语中叫大部屋。

在软件项目管理中，对一些重点项目的开发，也会采取这种跨职能团队集中办公，并和一般办公区域隔离起来的做法。通常这种集中办公区域叫做作战室（War Room）。

## 约束理论 ##

DevOps的另一本经典图书《凤凰项目》则是以小说的形式讲述了主人公被任命为运维经理后，如何在导师的帮助下，理清楚复杂局面下问题的瓶颈，并通过消除瓶颈，实现了全局优化，并最终让部门的运维工作走入正轨。

在《凤凰项目》书中，作者多次表达了对高德拉特的《目标》和约束理论（ToC）的敬意。其实，《凤凰项目》该书的写作手法也是模仿自高德拉特的《目标》。

下面以高德拉特博士的墓志铭上的话来高度概括约束理论（ToC)的精髓：

*  One, people are good.
 *  Two, every conflict can be removed.
 *  Three, every situation, no matter how complex it initially looks, is exceedingly simple.
 *  Four, every situation can be substantially improved; even the sky is not the limit.
 *  Five, every person can reach a full life.
 *  Six, there is always a win-win solution…

翻译成中文就是：

*  一，人都是好的。
 *  二，所有冲突都是可以被解决的。
 *  三，无论情况最初看起来多么复杂，其实都是非常简单的。
 *  四，问题总是可以被大幅度改善的，即使天空也不是极限。
 *  五，每个人都可以拥有完整人生。
 *  六，总是可以找到双赢的解决办法。

![高德拉特墓志铭][70]

## 敏捷 ##

如果说上面的精益生产方式和约束理论都是来源自生产制造行业，敏捷思想则是IT行业多年实践的反思。

没有什么能比“敏捷宣言”更能代表敏捷的精髓。

英文原版：

[Manifesto for Agile Software Development][]

中文版：

[敏捷软件开发宣言][Link 1]

![敏捷软件开发宣言][70 1]

再次回顾精益生产方式和约束理论时，就会发现敏捷价值观的思想和精益生产方式和约束理论也是契合的。

在软件开发敏捷管理中，常见的实践包括：

*  组建跨职能团队
 *  集中办公
 *  项目看板
 *  每日站会
 *  迭代计划会议
 *  迭代回顾会议
 *  Show Case
 *  燃尽图
 *  编写用户故事
 *  用Story Point来评估
 *  同行评审

DevOps概念的提出不是为了代替敏捷（Agile），而是对敏捷概念的延伸和实践的落地。敏捷是方法论，是管理办法；DevOps在此基础上提出了具体实践，比如持续集成、持续交付，并发展出了相对完备的DevOps工具链用于DevOps实践的落地。

## 小结 ##

在这一篇中我们介绍了DevOps的概念，并阐述了DevOps的主要思想来源：精益生产方式／丰田生产系统，约束理论和敏捷。最后阐述了DevOps和Agile的关系。

## 扩展阅读 ##

John Willis 在2018年DevOps国际峰会(DOIS)上演讲的“DevOps：Almost 10 Years - What A Strange Long Trip It’s Been” 用一幅超长手绘画卷讲述了DevOps的历史，生动有趣。

PPT下载：

> 链接：[https://pan.baidu.com/s/17WZI0of2Wjylh\_1tuK2z2A][https_pan.baidu.com_s_17WZI0of2Wjylh_1tuK2z2A] 密码：og6e

[⇐ 回到目录][Link 2]

[70]: /images/20220521/d7e58feb839a4c959d4e2290a7127eb4.png
[Manifesto for Agile Software Development]: http://agilemanifesto.org/
[Link 1]: http://agilemanifesto.org/iso/zhchs/manifesto.html
[70 1]: /images/20220521/e4b21010686b4e849ad1f27ade4dbbc9.png
[https_pan.baidu.com_s_17WZI0of2Wjylh_1tuK2z2A]: https://pan.baidu.com/s/17WZI0of2Wjylh_1tuK2z2A
[Link 2]: https://blog.csdn.net/nklinsirui/article/details/80685563