经济学人翻译社系统运维专家Comm & Contral

DevOps 漫谈:从作坊到工厂的寓言故事

2018-04-30  本文已影响25人  RiboseYim

转变主要不是基于自动化，相反，这种不可思议的改进来自于调整关于工作系统的策略和控制半成品的策略，确保有一个高效的跨职能团队，让所有事情都为约束点服务，以及管理好工作交接。——《凤凰项目 一个IT运维的传奇故事》

谈到 DevOps 概念，有几本书是绕不过去的，《凤凰项目：一个IT运维的传奇故事》（The Phoenix Project:a Novel About IT,DevOps,and Helping Your Business Win）就是其中之一。本书的主要特色之一是将 IT 运营和工厂生产对应起来，借鉴制造业的经验提升 IT 价值。

背景：《凤凰项目》的灵魂

《凤凰项目》的作者金(Gene Kim);贝尔(Kevin Behr);斯帕福德(George Spafford)，显然是高德拉特的拥趸。在整个故事中都贯穿了高德拉特的思想——约束理论(限制理论，Theory of Constraints，TOC)。

“不应该根据第一个工作站的效率来安排工作，而是根据瓶颈资源所能完成工作的速度来安排工作。”

埃利亚胡·高德拉特博士（Eliyahu M. Goldratt，1947－2011），以色列物理学家，同时是一位企业管理领域的大师。1984年，高德拉特博士发表了他的重要著作《目标：一种持续改进的流程》（The Goal: A Process of On going Improvement），书中以小说的形式提出了约束理论。他主张一个复杂的系统隐含着简单化，即使在任何时间，一个复杂的系统可能是由成千上万人和一系列设备所组成，但是只有非常少的变数或许只有一个，称为限制，它会限制（或阻碍）此系统达到更高的目标。在此基础上，他进一步提出了在制造业经营生产活动中定义和消除制约因素的一些规范化方法以支持连续改进（Continuous Improvement），例如约束理论之外还提出了关键链（Critical Chain Project Management，CCPM）项目规划和管理方法（与关键路径分析方法不同，它主要侧重于项目执行中所需的资源，关注资源依赖，强调监测项目的进展和缓冲的使用率，而不是规划个别任务的进展速度）。精益生产或者丰田生产系统在某种程度上也是以约束理论为基础的。

回到《凤凰项目》，它的体裁是按照时间线叙事的日记体：临危受命的主人公一直致力于改善各个约束点（瓶颈）对于整个组织能力的限制。起初是一个无可替代的工程师，接着是应用程序部署流程，安全审计，最后约束点移到了技术部门之外，甚至包括外部供应商。简单来说，小说的脉络遵循实践约束理论的基本步骤：

管理约束

“在瓶颈之外的任何地方作出的改进都是假象，在瓶颈之后作出任何改进都是徒劳的，而在瓶颈之前作出的任何改进则只会导致瓶颈处堆积更多的库存。” —— 艾利·高德拉特

最大的瓶颈是人

如果希望通过这本书获得一些解决方案和技术细节的人估计要失望了，《凤凰项目》本质上是一本探讨如何提高组织效率的书，或者说主要是讨论人、顺带谈了一些协同方法论。

我相信很多人看完《凤凰项目》之后都会把故事里面里面一堆人物名字搞混，但是有一个角色甚至比较主角还有意思 —— 布伦特。个人能力超强，工作超努力，对各类技术细节了如指掌，所有大小项目大家都喜欢找他合作，有了问题也会第一时间想到他，典型的超级员工、英雄人物。与此同时，布伦特实际上并不像人们认为的那样聪明绝顶。他每天需要处理大量计划外工作，即使布伦特天天加班都完不成堆积如山的任务，最终造成了大量的任务积压，战略工作不断延期，管理层疲于应付各种投诉。我相信大多数发展中组织里面都会有这么一个角色存在。

新上任的主人公（比尔）将布伦特识别为 IT 生产环境中的约束点，并采取了更改工作流转的方式来避免布伦特被计划外工作打扰：

可能他是故意让自己显得无可或缺，以免其他人抢了他的工作。... 是不是布伦特把他的知识看作一种权力。也许他身上的某些部分不愿意把那些知识交出来。这也确实让他成为了几乎难以取代的人。——《凤凰项目 一个IT运维的传奇故事》 第 107 页

值得注意的是，新的决策在开始阶段需要承受了很大的压力。领导人需要对抗的是长期形成的工作惯性，俗话说“病来如山倒、病去如抽丝”，想要改变也不是一朝一夕就可以实现的，更不要说组织内部微妙的人事关系，稍有不慎就可能踩到雷，顺畅的内部沟通、群众看得到的改进效果可以帮助解决一部分问题，但是现实中也有不可避免的碰撞。所以说，流程变更实质是是组织文化重塑的一种形式，领导者的信任与合作必不可少。这方面也是本书比较有趣的地方。

经过一段时间的坚持，布伦特的工作效率大大提升，顺利完成了凤凰项目，并在后来发起的独角兽和独角鲸项目取得了成功。

任务追踪

凤凰项目故事中，主人公面对的困境是：IT 团队因为大量工作积压而导致各种任务延期。

这个世界一定是哪里不对劲了，一半邮件都是紧急邮件。所有事情都那么重要，这可能吗？

经过一番梳理，IT 团队的各类工作内容大致可以分为以下四种类别：

计划外工作可不是免费的，恰恰相反，它非常昂贵。在故事的第一部分，计划外工作是最主要的困扰，它们包括突发严重故障、业务安全漏洞引发的舆论风波、部分领导人基于个人意愿追加的临时项目等等。如果要推动战略项目的进度，必须根除计划外工作的最大源头！

计划外工作会让你丧失开展计划内工作的能力，因此必须不惜一切代价去消灭计划外工作，墨菲法则确实存在，因此总会有计划外工作，但你必须高效地处理它们。

第一优先级是谁喊得最响，决定因素是谁能搬出最大的领导来。我见过很多员工总是优先为某个经理服务，因为他每月带他们出去吃一次午餐。

为了改变这一局面，主人公采用了一种“可视化工作区+任务追踪系统”的方式管理变更。

任务可视化

可视化的目的是为了做到充分的交流，就像风吹过树林，不分彼此的摇动每一片树叶。

可视化工作区

运营中心（NOC）：一个巨大的开放式办公区域，靠一面墙放着一排长桌，巨大的显示器上显示着所有IT服务的各种状态。1级和2级客服人员占据了工作站的三排位置。“这并不是阿波罗13号的太空飞行指挥中心，但我就是这样向亲戚们解释我的工作环境的。”

在 NOC 运作的具体支撑手段上，高度重视看板墙（Kanban）的作用。

看板(Kanban)是一种生产管理系统，起源于1940年代的丰田汽车公司。看板的核心理论是基于制造业中经常提到的概念：库存。与传统会计观念不同，丰田认为库存会带来成本以及浪费，而不是增加或储存价值，应鼓励逐步消除库存，以便削减生产流程中的成本，在管理中逐渐适应“零库存”的状态。1961 年 MIT（Sloan School of Management）教授 John Little 正式提出了利特尔法则（ Little’s Law ）：在一个稳定的系统 L中，长期的平均顾客人数，等于长期的有效抵达率，系统中的平均存货等于存货单位离开系统的比率（亦即平均需求率）与存货单位在系统中平均时间的乘积。

Cycle Time = Work in Progress / Throughput

根据利特尔法则，跟踪工作及进展的最重要的目标是：限制在制品（Work in process，WIP），例如尚未完成制造过程的商品，或是停留在库存仓库或是产线上，等待着进一步处理的商品。在 IT 语境中，半成品一般意味着积压的开发任务、等待启动的“重要不紧急”工作、“开发完成”但是未上线发布的新功能、等待执行的线上变更等等。

看板上的索引卡片是做成这件事最好的机制之一，因为每个人都能看到半成品。—— 《凤凰项目 一个IT运维的传奇故事》第 151 页

本书中关于看板（Kanban）实践的启示可以概括为以下几点：

控制半成品的能力不足，是造成长期性延误和质量问题的根源之一。 “完成”的真正定义 并非开发部完成了编码，而是只有在代码经过充分测试并按设计在生产中运行时，代码才算“完成”。

关于变更管理，还有一些具体的实践方法值得借鉴：

改进日常工作

改进日常工作比开展日常工作更重要。

预防性维护

技术债务。它来自于走捷径，那在短时间内也许行得通。但是就像金融债务一样，久而久之，利息成本会越滚越高。如果一个部门没有付清它的技术债务，公司的每一份努力都将以计划外工作的形式来偿还那些技术债务的利息。p186

如果你是一家跨国货运公司，你们用一百辆卡车组成的车队运送包裹，你们的一项公司目标就会是客户满意度和按时交货。一个影响按时交货的因素是车辆故障。车辆故障的一个关键起因是没有更换机油。那么，为了降低这个风险，你就要为车辆运营建立一个服务等级协议（SLA），每行驶五千英里就要更换一次机油。如果说按时交货是关键绩效指标（KPI），那么为了达到这个指标可以建立一个新的前瞻性KPI，比如说，已经按要求更换机油的车辆百分比。

对于 IT 组织来说，这一原则同样适用。

两个反常识的概念

系统里要经常出些故障

作者在书中提到一个观点：“系统里要经常出些故障，长此以往，再遇到困难就没有原来那么痛苦了。p216”

1960 年代，工业制造领域提出了弹性制造系统（Flexible Manufacturing System，FMS）的概念。FMS 的理想是制造系统能够富有弹性（能够因应预期或不可预期的变更），又兼有自动化设备规模生产的特性，以满足顾客对于产品要求多样化的趋势。制造系统的弹性通常被分为两类：

于 IT 生产而言，就有了弹性系统，即面对各种不确定场景时（如基础存储设施故障，恶意攻击，依赖服务故障，网络超时、中断等等）都能够存活并且具备一定的自愈能力的系统。弹性系统的出发点是承认在规模化服务的场景下，故障是常态的、不可预测的，既然不可避免，就需要在系统的生命周期去主动管理它，可以主动地给系统不断施加一些压力，从而不断强化习惯并加以改进。

Do not try to avoid failures ! Embrace them !

具体策略方面，可以将改进周期设定为小段时间，例如每次为期两周，每期都实施一个小型的改进项目，例如周期性的服务中断演练。每次日常改进都需要覆盖“设计—检测—恢复—预防”的各个环节，只有不断重复才能建立信任感和透明度，对需要团队合作的事情来说尤其如此。

建立起部落文化般的工作共识，这帮助我们比以往任何时候都能够更快地排除故障，而且，一旦真的需要把工作升级，也是可控而有序的。p263

人力资源使用率与效率成反比

每个人都需要空闲时间，或者说松弛时间。如果大家都没有松弛时间，半成品就会卡在系统里。或者更确切地说，卡在队列里，只是干等着。

[图片上传失败...(image-f3703c-1525084885540)]

图表说明：横坐标轴上是给定资源的忙碌百分比，纵坐标轴上是大致的等待时间（更确切地说是队列长度）。曲线的形状表明，当资源使用率超过80%时，等待时间就会直线上升。

等待时间取决于资源使用率。如果一个资源的忙碌时间是50%，那么它的空闲时间也是 50%。等待时间就是50%除以50%，也就是一个时间单位（可以简化理解为 1 个小时）。另一方面，如果一个资源 90% 的时间是忙碌的，等待时间=90% /10%，也就是说至少 9 个小时。换言之，任务排队等待的时间，将是资源有 50% 空闲时的 9 倍。

例如，小说中的技术大拿（布伦特），30分钟的简单变更需要耗费几个星期才能完成。原因很简单，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，每次交给他的工作都只能在队列里枯等，如果不进行加速或升级处置，就永远不会完成。

再进一步，如果简单任务实际需要 5 个以上交接步骤（分析、设计、程序、测试、发布、线上变更等），情况又会如何呢？假设所有工作中心都有 90% 的时间是忙碌的，由图上可知，在每一个工作中心的平均等待时间是 9 个小时。总共等待时间就是 5倍：45 个小时。高资源使用率带来的破坏性结果恐怕也就无需多言了。

因此，削减非必要人工环节、管理交接工作是提高资源周转率的关键。

扩展阅读：DevOps 漫谈系列

DevOps 实践的本质是文化

扩展阅读：凤凰项目作者推荐书单

《目标：一种持续改进的流程》

1984年，埃利亚胡·高德拉特博士撰写了他的重要著作《目标：一种持续改进的流程》（The Goal: A Process of On going Improvement）。这是一本苏格拉底式的小说，主人公是一位名叫亚历克斯·罗戈的工厂经理，他必须在90天内解决成本和按时交货的问题，否则他的工厂就要被关停。

高德拉特博士在他的后一本书 《绝不是靠运气》（It's Not Luck） 中，阐述了他称之为“思维过程”的内容。那是一套了不起的方法论（但是多少有些难以做到，且往往见效缓慢），主要是教公司如何识别长期的核心冲突、了解现状、描述理想的未来状况，以及多种提高成功可能性的策划技巧。

《丰田管理：为了获得改进、适应性和优异业绩而管理员工》

《团队领导的五大障碍：关于领导力的寓言》

团队达成目标的一个核心诱因是信任缺失。在他的模型中，五大障碍被描述为：

上一篇下一篇

猜你喜欢

热点阅读