《DevOps 精要:业务视角》- 读书笔记（二）

第2章 基础

2.1 精益生产

2.1.1 关键事实

正如1.2节提到的，DevOps非常依赖于精益生产的原则与实践。有些人甚至相信，在DevOps中大体上没有什么超出了精益范畴的。但这种观点并不正确。为了解释这一点，我们需要考虑精益生产的基本内涵。这有助于我们更好地理解什么是DevOps的基础。

简化起见，精益生产可以被缩小为识别与消除浪费。为了更好地理解这句话，有必要回顾一下精益起初试图解决的问题。

20世纪30年代，一家名为丰田自动织布厂（Toyoda Automatic Loom Works）的小公司（后来更名为Toyota）发现了汽车市场发展的机遇。一方面，那个时候“有效的需求”即人们愿意花在汽车的钱很少，这意味着产品应该尽可能便宜。另一方面，市场规模相当有限，这意味着不可能应用大规模生产和规模经济的原则。丰田公司决定寻找自己的道路，并在接下来的发展中证明自己的成功。年轻的工程师大野耐一（Taiichi Ohno，1912-1990）是丰田工厂和新产品技术创造与开发中心的职员。他想象了一幅理想的画面：只有在客户下了订单之后，生产过程才会开始，然后新车被立即交付给客户。为了实现这样的生产速度，就需要尽快并且只实施那些对创造产品有直接贡献的操作，并消除所有潜在的浪费。

在精益生产中，非常关注浪费的概念：对日常浪费的含义进行补充和扩展，使其成为不同领域工作中的管理目标。在最高层面，浪费被划分为Muri（超载）、Mura（不均衡）和Muda（浪费）。

• Muri可以被定义为价值存疑的工作，管理层基于非最优流程分配任务给员工执行；人员使用率持续超负荷，或者工作强度过高。
• Mura意味着不均衡或者不连贯，意思是不均衡的需求水平，这些需求分散着，波动着。
• Muda则指工作期间发生的浪费，它们的来源和性质都不是那么明显，因此需要额外进行分类。

下面给出不同浪费来源的列表，各个浪费在IT领域中的解释引自波朋迪克夫妇（Mary Poppendieck和Tom Poppendieck）所著的书。

从图2.1中可以看到，原始列表中来自于精益生产领域的几乎所有类型的浪费，都可以在信息技术领域找到对应关系。自从丰田生产系统的初始资料被发布以及其基本思想被理解之后，基于原始浪费列表的扩展就出现在许多跟随者的脑海中。不同的作者提议过增加以下各种类型的浪费：

• 管理成本（基本上是由管理者而非员工完成的任何事情）。
• 不满足客户期望或需求的产品或服务（与品质的经典定义一致）。
• 未发挥员工的潜在创造性和智力。
• 未能调动员工的资源来改进流程和技术。
• 不充足的员工培训。
• 使用不正确的度量，或根本没有使用度量。
• 对信息系统的低效使用（低质量的自动化及对信息技术的无效应用产生的浪费，如工作期间的游戏与社交聊天）。

当然了，带着一些想象，可以进一步扩展这个列表的类型，只要别忘记浪费的概念和基本原则并在实践中记住每种浪费类型对于管理决策的影响。谈及这些原则，这一条最流行：浪费是客户在能够有选择时不愿意为之付费的任何东西。但显然，这个陈述太过于宽泛，很难用于解决问题，如在判断一个具体工作是创造价值的抑或是浪费时，尤其在面对一些模棱两可的例子时。例如，预定义的IT系统架构规划是浪费吗？对多个源代码和模块进行集成测试是浪费吗？

在我看来，为便于实际应用，这个基本原则可以更精准地表述为“浪费是对于期望获得的成果非必需的且通过改变流程可以避免或最小化的动作。”
精益生产思想的实际应用，可以通过以下步骤顺序来描述。

• 1．使用专门工具来识别浪费。
• 2．应用其他的专门工具来消除或减少浪费。
• 3．重复步骤1。
• 4．……
• 5．利润！！！

精益生产使用了许多有趣的概念、实践和工具。DevOps借用了其中很多东西，例如价值流和价值流映射、快速的问题移除（安灯，Andon）、稳定与均衡的流动、一个单元时间处理单一任务、识别与消除瓶颈和约束、持续改进、拉动系统、工作可视化及其他，其中很多内容会在第3章与第4章中讨论。

2.1.2 挑战

虽然精益生产的思想很有吸引力，但组织尝试在工作中应用这些原则时，还是遇到了一些困难。就算不考虑精益在信息技术领域的应用，把眼光转向范围更广的生产组织的经验，我们也能看到精益生产有时无法达到预期的效果。主要的原因是，组织需要进行相当大的重构：不只是并且主要不是来自于实践和工具视角，而是更多地来自于原则的视角。这些变革需要不一样的公司文化，新的文化有别于当前大多数组织所构建的。员工必须拥有共同的价值观，这些价值观有别于“传统”公司当前所持有的。

我们来看一个例子，有个工人沿着工地行走，他发现在一台机器的边上，有些机器润滑油撒在地板上。在一个拥有精益生产精神的公司里，员工无法简单地就这样走过去，而是肯定会采取行动来消除这种无序，因为他/她们理解并共同认为这个油坑可能会导致（并且有很大概率会导致）生产出低品质的产品或拖慢生产速度。类似的情形如果出现在一个普通的公司中，员工可能就直接走了过去，因为他/她们确信这个工作不在其职责范围内，而且组织里应该有受过专门培训的人负责保持有序。我们可以看到，在所有员工中潜移默化地培养出一种不同的文化，是一件复杂、长期且费力的管理任务。很多资料显示，有些公司根本没有办法培育出这种文化。在很多案例里，这种文化的变革就算不用花好几十年的话，也得花好几年时间。

那些只是为了精益而精益、而不是为了解决实际问题的人，估计会遇到类似的困难。实践可以在很多地方找到，我们不会过多聚焦在这上面。我们想指出，如同其他的管理原则和工具，精益生产是一种达成目标的方式，目标需要提前定义，然后运用提供的手段来达成。

在信息技术领域中应用精益生产原则时，有一个挑战是，在常规的IT部门中找到某种类型的生产流水线并非易事。而精益中使用的实践，例如安灯（Andon）和准时制（Just-in-time），通常与流水线有关联。确实，如果我们视软件开发部门为一个分离的、独立的架构，那么我们可以识别出一个软件生命周期的流水线。但是，这个流水线并不结束于向最终消费者提供价值、因为它被限制为某个IT团队，因而是不完整的。在IT运维中，要找到一个流水线就更难了。也许这就是有些作者将IT服务交付以流水线的形式表述的原因，熟悉ITSM基础的人知道，流水线深层次的想法在运维的上下文中难以衡量。

通常来说，IT部门的工作是无形的，它无法被触及，甚至无法被看见或者被评估。对IT的工作产出，也完全一样：提供的IT系统功能或IT服务，取决于各个的表述。IT中库存、人工或产品的这种无形的特征，显著不同于制造工厂的产品。

有一个有趣并且被广为传颂的故事，讲的是在完全不同的环境下推广丰田实践的尝试，进行尝试的公司叫通用汽车。下面我们简要描述一下。在通用汽车的所有汽车制造工厂中，有一个工厂位于加利弗里蒙特。不管从产品品质上还是从管理上来看，这家工厂都是最差劲的，甚至差劲到员工当值时公开酗酒和赌博，管理者对此无能为力。1982年，这家工厂倒闭了。

差不多在同一时间，丰田尝试进入美国市场，它需要在当地进行生产。最好的解决方案看起来是在当地找一家汽车制造商作为合作伙伴，以便丰田可以快速打开当地市场，而合作伙伴也可以学到丰田的技术，包括管理方法。

1984年，这家弗里蒙特装配厂重新开张，改名为新联合汽车制造公司（New United Motor Manufacturing，Inc.，NUMMI）。有些员工，包括之前工会的负责人，留了下来。他/她们去日本接受培训，工厂管理则由带来价值的海外人员来施行。在很短时间内，NUMMI不管在产品品质还是生产文化上，都成为通用汽车下面最好的一家工厂。至少可以这么说，日本人创造了一个小小的奇迹。

理所当然的是，成功的故事应该被复制。通用汽车选择的下一个工厂是Van Nuys，与在弗里蒙特那个工厂有着类似的问题，然而，所有试图改变或改进任何东西的尝试，在Van Nuys都彻底失败了，尽管也有来自已经取得成功的NUMMI工厂的有经验人士参与其中。

“你可以看到很多东西不一样。但有一样没有看到，那就是支持NUMMI工厂运行的底层系统，”通用汽车的管理者后来回忆道，“那个时候，我并不认为有谁真正理解这个系统的关键本质。通用汽车有点像那种‘隔着墙扔东西’的组织。丰田则有一个围绕着它的哲学构建起来的包括组织文化、供应商关系、财务管理、HR及治理等在内的生态系统，只有这样，方能成功……”

通用汽车花了接下来15年时间来分析这种状况，并决定基于商业案例改变其文化与生产系统，然后又花了10年时间尝试实施这些变革。2009年，通用汽车走向破产，并被美国政府收购。2010年，NUMMI工厂关闭，但丰田在北美市场的汽车销量保持了15%的市场份额。

我们以一个美好的比喻来结束对精益应用的复杂性的讨论，这个比喻是前面提到的Mary & Tom Poppendieck（波朋迪克夫妇）提出的：如果拿一家餐馆来比喻，信息系统的创建更像是厨师设计的食谱，工厂里的生产比较接近于依据前面设计的食谱来烹饪菜肴。厨师的工作包括设想出一道最优雅、美味并满足需要的菜式，然后找到最优的方式来生产，对它们的测试通常会经过多轮的尝试和失败，并持续改进食谱。餐馆里的员工生产同样的菜式的过程，则接近于流水线，根据提供的食谱包括需要的食材列表及烹饪技术，来生产这个产品。

由此可见，直接应用精益生产的原则和想法，并不总是像我们预期的那么简单，尤其是当我们考虑到现代IT工作的特点时。

2.2 敏捷

2.2.1 关键事实

敏捷的起源、思想和原则，已经在1.1.1节中进行了总结。敏捷是DevOps的坚实基础、它的影响如此之大，以至于你甚至会时不时听到有些狂热人士提出一些武断的陈述，如DevOps没有任何敏捷没有的东西（可以回忆一下本章一开始提到的精益生产，也有类似声音）。如同精益，敏捷的故事也如出一辙，但这个陈述其实与事实相去甚远。

应该注意到，敏捷原先是一系列的原则和价值观。基于这些价值观，实际应用这些原则，并且由一些衍生物即不同的软件开发方法提供指引。目前至少有一打可用的相关方法，其中最有名的框架叫Scrum。

这里，我们不打算深入不同来源的知识点的细节，也不打算调查它们的起源，我们只是提炼出DevOps最常提及的那些敏捷相关想法和实践。

• 组建小的独立且自给的团队（最多10～12人），最好在一个地点工作，聚焦于有限的范围。
• 通过基于冲刺（Sprint）的迭代过程，创建并测试程序代码，每个迭代交付出一个可行的产品。
• 维护一个功能与非功能需求的列表（backlog），作为下个迭代计划的输入。
• 把大的任务分解为小的部分（故事），以约定的工作负载单位进行评估并排序。
• 客户代表积极参与到过程中。
• 团队定期召开短时间的站立会议，讨论任务计划、进展与当前困难。
• 进行定期的回顾，以帮助团队自主学习及改善工作方式。

部分内容将在第4章中展开讨论。

2.2.2 挑战

尽管当下对敏捷的宣传铺天盖地，但在很多案例中，敏捷方法在软件开发上的应用也面临着诸多困难。

• 首先，正如1.1.1节所示，敏捷仅覆盖到价值链的一部分，这也导致了总体效果的差强人意。
• 其次，敏捷开发方法并未考虑到信息技术运维工作的特点与复杂性，对运维而言迭代的方法的可应用性有所下降，至少如果只是简单直接应用的话。
• 再次，根据Scrum，假如团队每个迭代工作的最终产出仅仅是一些通过回归测试的新的代码，那么团队的工作就会被限定为固定重复的工作迭代，日复一日，周复一周，员工从工作中得到的精神满足感越来越少。确实，只有当开发的软件被遵循不同规则的另一个团队操作时，团队成员才能感受到被使用的程序算法的优雅。有些公司报告，员工在经过几十个迭代之后，感到精疲力竭。

注意，敏捷的历史还远远没有完结，这个领域还在持续发展中。值得留意的是，敏捷的关键人物已经意识到了当今的复杂性，在敏捷宣言发表十年之后，他们再次聚集在一起来讨论成就与问题。这个会议的产出之一是列出了这场运动的20个问题。不过，他们似乎并不真的打算公开讨论这些问题。

下面列出其中一部分问题：

• 许多检视失败的发起人处在直接的商业利益当中；
• 假装敏捷不是一项业务；
• 掩盖困难与负面案例；
• 没有说清楚有些实践可行或不可行的上下文，不断回归教条化、偏执化，声称放之四海而皆准；
• 价值主张模糊且未经证明；
• 想当然地进行规模化；
• 增加及累积技术债务。

所有这些都是应用实际知识与技能（practical know-how）的理由，并促进敏捷运动进一步演进到DevOps。

Philippe Kruchten（菲力浦·克鲁切顿）2011年在敏捷十周年会议上总结了敏捷想法在最初那些年的表现：“敏捷运动在有些方面有点像一个十几岁的青少年，比如有很强的自我意识，总爱照镜子观察自己的外表，不太愿意接受批评意见，只有兴趣和自己的玩伴在一起，拒绝过去的所有智慧只因为它们来自于过去，喜欢时髦并引入新的术语，有时候显得自大和傲慢。但我毫不怀疑，它会更加成熟，因为它对外部世界更加开放，有更多的反思，因而也更为有效。”