# DevOps 漫谈:从作坊到工厂的寓言故事 ## 摘要 * 背景：《凤凰项目》的灵魂 * 管理约束：最大的瓶颈是人 * 任务追踪：可视化工作区和看板实践 * 改进日常工作：预防性维护 * 反常识：系统里要经常出些故障、人力资源使用率与效率成反比 * 安全与审计 * IT 价值流：像电力一样无处不在 > 转变主要不是基于自动化，相反，这种不可思议的改进来自于调整关于工作系统的策略和控制半成品的策略，确保有一个高效的跨职能团队，让所有事情都为约束点服务，以及管理好工作交接。——《凤凰项目 一个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 生产环境中的约束点，并采取了更改工作流转的方式来避免布伦特被计划外工作打扰： * 与 CEO 达成共识，调整布伦特的工作职责：允许他拒绝除凤凰项目（战略级）以外的任何工作； * 设置资源防火墙，任何人需要“征用”他都必须经过其部门领导评估优先级，所有资源请求通过层层过滤才能达到布伦特； * 围绕布伦特组建了一个二线梯队，负责学习他的工作经验、编写文档、甚至实现部分自动化，逐步替代布伦特处理任务，将布伦特从各种繁琐的事情中解放出来 > 可能他是故意让自己显得无可或缺，以免其他人抢了他的工作。... 是不是布伦特把他的知识看作一种权力。也许他身上的某些部分不愿意把那些知识交出来。这也确实让他成为了几乎难以取代的人。——《凤凰项目 一个IT运维的传奇故事》 第 107 页 值得注意的是，新的决策在开始阶段需要承受了很大的压力。领导人需要对抗的是长期形成的工作惯性，俗话说“病来如山倒、病去如抽丝”，想要改变也不是一朝一夕就可以实现的，更不要说组织内部微妙的人事关系，稍有不慎就可能踩到雷，顺畅的内部沟通、群众看得到的改进效果可以帮助解决一部分问题，但是现实中也有不可避免的碰撞。所以说，流程变更实质是是组织文化重塑的一种形式，领导者的信任与合作必不可少。这方面也是本书比较有趣的地方。 经过一段时间的坚持，布伦特的工作效率大大提升，顺利完成了凤凰项目，并在后来发起的独角兽和独角鲸项目取得了成功。 ## 任务追踪 凤凰项目故事中，主人公面对的困境是：IT 团队因为大量工作积压而导致各种任务延期。 > 这个世界一定是哪里不对劲了，一半邮件都是紧急邮件。所有事情都那么重要，这可能吗？ 经过一番梳理，IT 团队的各类工作内容大致可以分为以下四种类别： * 第一类：业务项目，由 PMO 跟踪的正式项目； * 第二类：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）实践的启示可以概括为以下几点： * 目标导向：相对于强化审批流程，更重要的是通过任务卡片的梳理识别半成品积压在哪个环节，通过建立一条反馈环路能够一直往回通向产品定义、设计及开发的最初环节。 * 简洁性：例如一张变更索引卡片只要求填写必需的三条信息：变更计划的制定者、将要实施变更的系统以及一条一句话的概述，避免设置过多的必填字段和无效选项。繁琐而缺乏人性考量的工具难以发挥作用，最终将变成 "大家为了完成自己的工作，一直在胡乱对付这套系统”，再也没有比阻止人们去做他们理应做的事更能毁掉大家的热情和支持了。 * 灵活性：针对需要特别关注的问题可以采取灵活方式，不拘泥于死板格式。例如在第一部分首席工程师（布伦特）是一个阶段性瓶颈，各部门在提交卡片的时候就将“是否需要布伦特支援”作为必填信息，或者使用单独一种颜色的卡片。 **控制半成品的能力不足，是造成长期性延误和质量问题的根源之一。** **“完成”的真正定义** 并非开发部完成了编码，而是只有在代码经过充分测试并按设计在生产中运行时，代码才算“完成”。 关于变更管理，还有一些具体的实践方法值得借鉴： * 分级授权：可以把一部分变更审核委派给代理人 * 脆弱变更：列出了十大最脆弱的服务、应用程序和基础架构列表，可能会影响到其中任何一个的变更申请都将立刻标上记号，由 CAB 详细审查 * 标准变更（ITIL 名称）：对于之前已多次成功实施的变更，我们只需要提前批准就行。它们仍然需要提交，但可以不经过我们批准就安排操作日程。” * 外部影响变更：对于‘复杂的中等变更’ 变更提交者有责任向可能受到影响的人员进行咨询并得到其认可，做完这些之后才可以将变更卡片送入审核流程。 * 禁止条款（透明化）：禁止未经授权的变更，禁止在服务中断期间出现未经公开的变更。 ## 改进日常工作 > 改进日常工作比开展日常工作更重要。 ### 预防性维护 > 技术债务。它来自于走捷径，那在短时间内也许行得通。但是就像金融债务一样，久而久之，利息成本会越滚越高。如果一个部门没有付清它的技术债务，公司的每一份努力都将以计划外工作的形式来偿还那些技术债务的利息。p186 如果你是一家跨国货运公司，你们用一百辆卡车组成的车队运送包裹，你们的一项公司目标就会是客户满意度和按时交货。一个影响按时交货的因素是车辆故障。车辆故障的一个关键起因是没有更换机油。那么，为了降低这个风险，你就要为车辆运营建立一个服务等级协议（SLA），每行驶五千英里就要更换一次机油。如果说按时交货是关键绩效指标（KPI），那么为了达到这个指标可以建立一个新的前瞻性KPI，比如说，已经按要求更换机油的车辆百分比。 对于 IT 组织来说，这一原则同样适用。 ## 两个反常识的概念 ### 系统里要经常出些故障 作者在书中提到一个观点：“系统里要经常出些故障，长此以往，再遇到困难就没有原来那么痛苦了。p216” 1960 年代，工业制造领域提出了弹性制造系统（Flexible Manufacturing System，FMS）的概念。FMS 的理想是制造系统能够富有弹性（能够因应预期或不可预期的变更），又兼有自动化设备规模生产的特性，以满足顾客对于产品要求多样化的趋势。制造系统的弹性通常被分为两类： * “机器弹性”：涵盖了系统制造新产品的应变能力和零件工序改变的应变能力； * “用途弹性”：同一组件可以使用不同机器设备而运行相同的工序之。 于 IT 生产而言，就有了弹性系统，即面对各种不确定场景时（如基础存储设施故障，恶意攻击，依赖服务故障，网络超时、中断等等）都能够存活并且具备一定的自愈能力的系统。弹性系统的出发点是承认在规模化服务的场景下，故障是常态的、不可预测的，既然不可避免，就需要在系统的生命周期去主动管理它，可以主动地给系统不断施加一些压力，从而不断强化习惯并加以改进。 **Do not try to avoid failures ! Embrace them !** 具体策略方面，可以将改进周期设定为小段时间，例如每次为期两周，每期都实施一个小型的改进项目，例如周期性的服务中断演练。每次日常改进都需要覆盖“设计—检测—恢复—预防”的各个环节，只有不断重复才能建立信任感和透明度，对需要团队合作的事情来说尤其如此。 > 建立起部落文化般的工作共识，这帮助我们比以往任何时候都能够更快地排除故障，而且，一旦真的需要把工作升级，也是可控而有序的。p263 ### 人力资源使用率与效率成反比 每个人都需要空闲时间，或者说松弛时间。如果大家都没有松弛时间，半成品就会卡在系统里。或者更确切地说，卡在队列里，只是干等着。 ![资源忙碌百分比](http://riboseyim-qiniu.riboseyim.com/DevOps-资源忙碌百分比.png) 图表说明：横坐标轴上是给定资源的忙碌百分比，纵坐标轴上是大致的等待时间（更确切地说是队列长度）。曲线的形状表明，当资源使用率超过80%时，等待时间就会直线上升。 **等待时间取决于资源使用率**。如果一个资源的忙碌时间是50%，那么它的空闲时间也是 50%。等待时间就是50%除以50%，也就是一个时间单位（可以简化理解为 1 个小时）。另一方面，如果一个资源 90% 的时间是忙碌的，等待时间=90% /10%，也就是说至少 9 个小时。换言之，任务排队等待的时间，将是资源有 50% 空闲时的 9 倍。 例如，小说中的技术大拿（布伦特），30分钟的简单变更需要耗费几个星期才能完成。原因很简单，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，每次交给他的工作都只能在队列里枯等，如果不进行加速或升级处置，就永远不会完成。 再进一步，如果简单任务实际需要 5 个以上交接步骤（分析、设计、程序、测试、发布、线上变更等），情况又会如何呢？假设所有工作中心都有 90% 的时间是忙碌的，由图上可知，在每一个工作中心的平均等待时间是 9 个小时。总共等待时间就是 5倍：45 个小时。高资源使用率带来的破坏性结果恐怕也就无需多言了。 因此，削减非必要人工环节、管理交接工作是提高资源周转率的关键。 ## 扩展阅读：凤凰项目作者推荐书单 * 《The DevOps Cookbook》(开发运维指导书) * [《持续交付：发布可靠软件的系统方法》](https://book.douban.com/subject/6862062/) ### 《目标：一种持续改进的流程》 1984年，埃利亚胡·高德拉特博士撰写了他的重要著作《目标：一种持续改进的流程》（The Goal: A Process of On going Improvement）。这是一本苏格拉底式的小说，主人公是一位名叫亚历克斯·罗戈的工厂经理，他必须在90天内解决成本和按时交货的问题，否则他的工厂就要被关停。 高德拉特博士在他的后一本书 **《绝不是靠运气》（It's Not Luck）** 中，阐述了他称之为“思维过程”的内容。那是一套了不起的方法论（但是多少有些难以做到，且往往见效缓慢），主要是教公司如何识别长期的核心冲突、了解现状、描述理想的未来状况，以及多种提高成功可能性的策划技巧。 * 华盛顿州立大学网站“EM526 约束管理”（课程）， * 学习“思维过程”的教科书《逻辑化思维过程》，作者H.威廉·德特曼博士。 ### 《丰田管理：为了获得改进、适应性和优异业绩而管理员工》 * Toyota Kata : Managing People for Improvement , Adaptive nessand SuperiorResults ### 《团队领导的五大障碍：关于领导力的寓言》 * The Five Dysfunction sofa Team : A Leader ship Fable * 作者：帕特里克·兰西奥尼 团队达成目标的一个核心诱因是信任缺失。在他的模型中，五大障碍被描述为： * 信任缺失——不愿在团队中显示弱点； * 惧怕冲突——在充满激情的建设性辩论中寻求和谐的假象； * 缺乏诚意——假意与团队的决策达成一致，形成模棱两可的公司氛围； * 回避问责——面对员工的失职行为，逃避追责，降低了工作标准； * 忽视结果——对个人成就、地位和自我价值的关注超过了对团队成功的关注。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://riboseyim.gitbook.io/perf/devops-phoenix.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.