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…

翻译成中文就是：