凤凰项目读后感

学到了什么

• 更广的业务理解与技术视野能更好的帮助我们完成工作
• 约束点的重要性，保护约束点不被预定任务之外的事情干扰（对于小公司来说，避免未经确认的需求直接对接开发人员，保证他们手上的开发工作正常有序进行）
• 看到过去开发与运维之间的关系和难点，开发运维技术的变化，理解了目前自动化运维与持续部署的意义与效益（明白了它好在哪，不再觉得这本该如此）
• 区分工作类型，分清主次，避免次要任务干扰工作流程进度

重要概念

1. 三步工作法
 - 第一步：是关于从开发到IT运维再到客户的整个自左向右的工作流。（开发阶段）（强调工作拆分，流程安排，减少返工，环境保障）
 - 第二步：是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。（上线后阶段）（从结果中获取反馈（正或负），改进自身，这个结果很泛，书中提到资金快速回流也是第二步工作法体现的一种，也就是说包括市场反馈、用户反馈亦或者内部反馈等等）
 - 第三步：是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。（环境的创造，其实就是构建一种问题处理习惯，比如我很希望我的团队成员都能自己确认和讨论需求，使用自己认为合适的技术，这很有利于他们成长，而他们只在必要时向我提问）

2. 约束点
 - 在整个工作流程中重要的节点，所有流程都受限于他们的处理速度（小公司不太存在这种情况，又或者说哪里都可能有这种情况，就我而言，开发人员都是约束点，应该保护他们不受计划外工作的干扰）

3. 工作类型
 - 业务项目（主项目）
 - IT内部项目（零散项目或运维类工作）
 - 变更（由前两种引起的调整）
 - 计划外工作或救火工作（上述三种操作引发的问题事故）

4. 等待时间
 - 人或资源利用率拉太满，反而会产生巨大等待、排队、阻塞
 - 等待时间=忙碌时间百分比/空闲时间百分比
 - 50%/50%=1, 90%/10%=9 这同样适用于服务，所以为让服务器的cpu长时间处于80%以上
 - 底层逻辑：不要追求把人和机器榨满，留冗余缓冲，才能保证整体流程顺畅。

原文节选

简介

我谨代表本书的合著者，万分感谢你阅读本书。

本书阐释了开发部和IT运维部之间长期的核心冲突为何会导致整个IT组织及其所服务企业的失败。如果不加以抑制，冲突会拖延开发部的上线时间，并在功能发布期间导致时间更长、问题更多的部署，增加1级严重级别服务中断的数量，而IT运维部则要做越来越多的计划外工作，难以清偿技术债务。

我们现在知道，开发部和IT运维部之间的这种冲突是可以化解的。证据是，诸如亚马逊、谷歌、Twitter、Etsy* 和网飞等高绩效公司，正在采用一套我们称之为“开发运维”的技术，他们每天都要部署成百上千个产品变更，同时保持着世界一流的可靠性、稳定性及安全性。通过构建一套文化规范、流程与做法，这些表现突出的企业取得了惊人的业绩。

* 一家手工艺品交易网站。——译者注

他们能够快速完成更新，将代码部署交付周期缩短为几分钟或几小时，并能够凭借更高的产品质量和更好的客户服务，在市场中不断创新突破、脱颖而出。

代码部署交付周期是指从开发部“将变更提交至版本控制”到“在生产中成功运行”所需的时间。

为什么需要开发运维

开发运维这种能力能创造巨大的竞争优势，使产品功能更快地进入市场，并提升客户满意度、市场份额、员工生产力以及工作幸福感，同时让企业在市场上百战百胜。为什么？因为技术已成为首要的价值创造过程，并已成为绝大多数公司获得客户的越来越重要的（而且常常是基础性的）一种手段。

相比之下，需要几周乃至几个月的时间来部署软件的公司，在市场上处于非常不利的位置。

| 公司 | 部署频率 | 部署交付期 | 可靠性 | 客户响应 |

| —- | ——– | ———- | —— | ——– |

| 亚马逊 | 23 000次/天 | 分钟 | 高 | 高 |

| 谷歌 | 5500次/天 | 分钟 | 高 | 高 |

| 网飞 | 500次/天 | 分钟 | 高 | 高 |

| Facebook | 1次/天 | 小时 | 高 | 高 |

| Twitter | 3次/周 | 小时 | 高 | 高 |

| 普通企业 | 9个月1次 | 月或季度 | 低/中 | 低/中 |

各领域的佼佼者都有一个特点，那就是他们永远“鹤立鸡群”。也就是说，最出色的人总是能独占鳌头。

这种持续而不间断的性能改善也适用于开发运维领域。2009年，一天10个部署就算很快了，而现在则只能算是平均水准。2012年，亚马逊公司宣布，他们平均每天能开展23 000个部署。

采用开发运维的商业价值

在玩偶实验室2012年的“开发运维报告说明”中，为了更好地理解企业在采用开发运维各阶段的情况和习惯，我们用基准问题测试了4039家IT企业。

第一点出人意料的是，在敏捷性指标（agility metric）方面，运用开发运维的高绩效公司远胜过表现平平的同行：

• 代码部署频率快30倍
• 代码部署交付期快8000倍

还有可靠性指标：

• 变更成功率高2倍
• MTTR（Mean Time To Repair，平均修复时间）快12倍

换言之，他们更为敏捷。他们部署代码的频率快30倍，从“代码提交”到“成功投产运行”的速度快8000倍。表现突出企业的交付期以分钟或小时计算，而表现较差企业的交付期则以周、月乃至季度计算。

这些企业不仅做了更多的工作，他们取得的成效也好得多：表现突出的企业成功部署变更和代码（即未导致生产服务中断或者服务故障）的可能性是其他公司的2倍，并且一旦变更失败引发事故，处理事故的速度要快12倍。

这一研究结果特别令人兴奋，因为它表明，长期的核心冲突可以化解：表现突出企业正在更快地部署功能，同时提供世界上最高的可靠性、稳定性及安全性，从而在市场上胜过竞争对手。一个更为惊人的事实是：更强的产品可靠性需要更高频率的变更！

我们在2014年的研究中还发现，这些表现突出的企业不仅有着更好的IT业绩，其公司总体业绩也明显更佳。他们在盈利能力、市场份额及生产目标方面胜出的可能性要高出2倍，而且有迹象显示，他们在资本市场上的表现也好得多（就像最后一章里，埃瑞克想要创建对冲基金时所预测的那样）。

置身于开发运维世界的感觉如何

想象你置身于开发运维的世界，在这里，产品所有者、开发部、QA、IT运维部以及信息安全部共同不懈地工作，帮助彼此及整个企业取得胜利。他们能够快速地完成工作计划（比如，每天完成几十个、几百个乃至几千个代码部署），同时保持着世界一流水准的稳定性、可靠性、可用性及安全性。

上游的开发团队不再给下游的工作中心（比如QA、IT运维部以及信息安全部）造成麻烦，开发部将20%的时间用于帮助确保工作顺利地通过整个价值流，加快自动化测试，改进部署基础架构，并确保所有应用程序创建有用的产品遥测（production telemetry）。

为什么？因为每个人都需要快速反馈回路，以防止问题代码进入生产环节，并且让代码能够迅速部署投产，从而迅速发现并修复任何产品问题。

价值流中的每个人都共享一种文化，这种文化不仅重视彼此的时间和贡献，而且为了实现整体的学习和改进，不断向工作系统中注入压力。大家都能把吸取到的教训运用到实践之中，偿还技术上的欠债。每个人都像重视功能性要求一样重视非功能性要求（比如质量、可扩展性、可管理性、安全性、可操作性等）。

为什么？因为非功能性要求对于实现业务目标同样重要。

我们拥有一种高度信任、合作共事的文化，每个人都对其工作的质量负责。与低信任度、高控制度和以审批服从流程为特点的管理文化相反，我们依靠同事评议来确保每个人都对其代码质量充满信心。

此外，还有一种假设驱动的文化，要求每个人都成为科研工作者，不会理所当然地作出任何假设，也不会在未经测算的情况下草率行事。为什么？因为我们知道时间宝贵。我们不会花费几年时间来构建客户实际不想要的功能，部署没用的代码，或是费力维修那些并没有出问题的地方。所有这些都使我们能够推出令人兴奋的新功能，既让顾客满意，又让公司获利。

矛盾的是，执行代码部署正变得无聊而平常。开展部署不再是在压力之下、混乱之中于深夜或周末进行，而是在工作日进行，大部分人甚至都不会察觉。而且由于代码部署发生在下午而非周末，几十年来，IT运维人员终于和其他人一样，在正常上班时间开展工作。

代码部署究竟是怎么变得平常的？因为开发人员在工作中不断获得迅速的反馈：在他们编写代码时，自动单元、验收和集成测试一直在类生产环境中运行，让我们不断确认，代码和环境将会按照预先设定的运行，而且我们总是处于可部署状态。代码部署后，普遍性生产指标显示部署成功，而且客户也获得了价值。

甚至连风险最高的功能发布（feature release）也变得稀松平常了。怎么做到的？因为在产品上线时，交付新功能的代码就已经投产了。在上线之前几个月，开发部就已经把代码部署为产品，这对客户是不可见的，但内部员工可以运行并测试功能。

在功能启用的最后一刻，不再有新代码投入生产。相反，我们只要改变一个功能开关或者参数设置即可。

新功能开始慢慢地对一小部分客户可见，如果发生故障，就自动回滚。

只有在确定功能已经按照设定运行时，我们才会将它向另一部分客户公开，以一种可控、可预测、可逆而且压力很小的方式推出。我们不断重复，直到每个人都使用了这一功能。

这样，我们不仅大幅降低了部署风险，而且也提高了达到预期业务成果的可能性。因为可以迅速开展部署，我们才得以在生产中进行试验，对构建的每一项功能的业务假设进行测试。我们可以反复测试，并且使用几个月乃至几年来的客户反馈，在生产中改进各项功能。

难怪我们超越了竞争对手，赢得了市场。

通过开发运维，就可以实现上述一切。开发运维是一种新方法，是指开发、测试、IT运维以及IT价值流中的其他各方共同工作。

开发运维是我们时代的生产革命

开发运维工作模式的原理与改变生产制造的原理相同。开发运维并非优化在制造工厂里将原材料转化为成品的方式，而是展示如何优化IT价值流，以及如何把业务需求转换为向客户提供价值的能力与服务。

20世纪80年代，制造业领域有过一次非常著名的长期核心冲突：

• 保护销售承诺
• 控制制造成本

为了保护销售承诺，产品销售人员希望拥有很多库存，让客户在需要时总能拿到产品。然而，为了降低成本，厂长则希望降低库存水平和半成品数量。

由于无法在工厂内同时提高和降低库存水平，销售经理和厂长在一场长期的冲突中僵持着。

通过采用精益理论，他们化解了冲突。精益理论包括降低批量规模、减少半成品以及缩短并增强反馈回路。结果，工厂生产力、产品质量和客户满意度急剧提升。

20世纪80年代，平均订单交付期是六个星期，按时发货的订单不到70%。到了2005年，平均产品交付期已经缩短到三个星期以内，按时发货的订单超过95%。无法实现这些绩效突破的企业，即使尚未倒闭，也已丧失了市场份额。

开发运维从何而来

100年后，历史学家回顾这十年，会唏嘘这一时期的变化：开发和IT运维的工作方式彻底改变了……我预测，历史学家会把这十年称为“IT界的寒武纪大爆发”，一个充满革新和分化的惊人时代。在计算机技术诞生50年后，我们终于明白了技术能够用于何处。

——约翰·威利斯，“开发运维咖啡馆”播客节目主持人之一

“开发运维”这个词最初是在2008年由帕特里克·德布瓦和安德鲁·谢弗提出的，并于2009年因为约翰·阿尔斯帕瓦和保罗·哈蒙德那场著名的“每天超过10次部署：Flickr的开发与运维合作”演讲，在Velocity技术大会广为流传。

在本书中，我们认为开发运维是在IT价值流中应用精益理论的结果。这些原理是以一个多世纪以来的正确管理实践为基础的。然而，我们运用这些原理来提高流经生产管理、开发、测试、IT运维以及信息安全等部门的工作流的速度，而不是应用于实体产品的转化。

开发运维从“敏捷社区”开展的工作中获益良多，这些工作表明，信任度高的小团队，加上小的批量规模以及更小、更频繁的软件发布，能够极大地提高开发部门的生产能力。事实上，开发运维历史上的很多关键时刻都发生在敏捷会议以及热闹的DevOpsDays活动上。首次DevOpsDays活动于2009年举行，此后这一活动在世界各地开展。

当然，开发运维脱胎于马克·伯吉斯博士发起的“基础设施即代码”的实践以及持续集成和持续部署（由杰兹·亨伯尔和戴维·法利发起），这是实现快速部署流的前提。

开发运维同样受益于新型管理思潮的惊人融合，比如精益创业、创新文化、丰田套路、加固型计算以及Velocity社区。它们相互促进，产生强大的聚合力，加快开发运维的采纳应用。

对三步工作法的解释

在本书中，我们阐述了这一基础原理，即所有开发运维模式都来自三步工作法，它旨在阐明指导开发运维的流程与实践的价值观与理念。

第一工作法

是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。

必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。

第二工作法

是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。

必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；日复一日地持续改进日常工作；创建快速的自动化测试套装软件，确保代码总是处于可部署的状态；在开发和IT运维之间创建共同的目标和共同解决问题的机制；创建普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定运行，以及是否达到了客户的目标。

第三工作法

是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。

尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。

必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。

对开发运维的主要误解

一如各种变革性、颠覆性的运动，开发运维也会被误解或曲解。以下是对开发运维的一些主要误解。

开发运维取代了敏捷开发

开发运维与敏捷开发完全兼容。事实上，开发运维是始于2001年的敏捷开发的逻辑延伸，因为我们现在知道，“完成”的真正定义并非开发部完成了编码，而是只有在代码经过充分测试并按设计在生产中运行时，代码才算“完成”。（注意，敏捷开发并非采用开发运维的前提条件。）

开发运维取代了ITIL

尽管有些人可能会把开发运维看作ITIL（信息技术基础架构库）或ITSM（信息技术服务管理）的对立面，但是开发运维与ITIL也是可兼容的。ITIL和ITSM仍然是支撑IT运维流程的最佳编码法则，而且它们描述了为了支撑开发运维协同工作的流程，IT运维部所需要具备的很多能力。

为了适应与开发运维相关的更短的交付周期和更高的部署频率，ITIL流程的许多方面都需要自动化，特别是变更、配置和发布流程等方面。

因为在发生服务事故时，我们同样需要快速检测和修复，所以关于服务设计以及事故问题管理的ITIL准则仍然和以前一样有意义。

开发运维意味着无需运维

有时候，“开发运维”被错误地理解为“无需运维”（例如，IT运维部被整体取消了）。然而，更准确地说，开发运维经常会让开发部承担更多开展代码部署和维持服务水平的责任。这只不过意味着开发部接管了许多IT运维部和运维工程的职责。

为了支持快速交付并让开发人员提高工作效率，IT运维确实要求把许多IT运维任务转变为自助服务。也就是说，不再是开发部开出一张派工单，等着IT运维部完成工作。许多这一类的活动将会自动化，让开发人员自己就能做这些事（例如，构建一个类生产的开发环境，为产品远程添加一个功能指标）。

开发运维只适用于开源软件

尽管开发运维的很多成功案例都来自使用LAMP栈等软件的公司，但各组织通过Microsoft .NET、SAP，甚至COBOL应用程序，将开发运维的模式植入到大型机和惠普激光打印固件上。

开发运维的原理是通用的，它们在很大程度上独立于所采用的底层技术。一些开发运维模式有特定的技术要求（例如，可支持自动测试，可公开能够在版本控制中核查的配置），这在开源软件中更为普遍。

开发运维只是“作为代码的基础架构”或自动化

尽管本书展示的许多开发运维模式需要自动化，但开发运维也需要IT价值流自始至终拥有共同的目标并共同解决问题。这远非自动化所能涵盖的。

开发运维只适用于创业公司和“独角兽”公司

“独角兽”公司即超过10亿美元估值的创业公司，估值低于此的则称为“马驹公司”。

开发运维适用于任何一家亟需提高开发部门计划内工作流，同时为客户保持质量、可靠性及安全性的企业。

事实上，我们认为开发运维对于“马驹公司”的重要性更甚于“独角兽”公司。毕竟，如理乍得·福斯特所言：“1955年的财富500强公司中，有87%业已消失。1958年，财富500强公司的平均寿命为61年，而现在只有18年。”

“马驹公司”最主要的一个反对意见是，所有的“独角兽公司”（例如谷歌、亚马逊、Twitter、Etsy）都是生来如此的。也就是说，“独角兽公司”从一开始就在做开发运维。

实际上，几乎每一家开发运维“独角兽公司”都曾是“马驹公司”，都曾有过“马驹公司”所面临的全部问题。

亚马逊在2001年之前一直运行OBIDOS内容交付系统，这个系统后来变得问题重重、难以为继，于是亚马逊公司CTO沃纳·威格尔把整个组织和代码都改换成了以服务为导向的架构体系。

2009年，Twitter千方百计想对其前端单片机Ruby on Rails系统扩大规模能级，为了逐步重构并替代这个系统，启动了一个耗时多年的项目。

LinkedIn在2011年成功实施IPO之后六个月，在问题部署上吃尽苦头，于是发起了“逆向操作”行动——为期两个月的功能冻结，并因此得以彻底检修其计算环境、部署和架构体系。

2009年的Etsy，用迈克尔·伦巴西的话说，“正深陷自身工程问题的泥沼，必须认真着手应对”，处理问题软件部署和技术债务。于是他们开始进行公司文化转型。

2009年，Facebook的基础架构运维将近崩溃，无法跟上用户的增长，代码部署变得日益危险，员不停地到处救火。杰伊·帕里克和佩德罗·甘纳胡帝展开了改革，让代码再次能够安全地进行部署。

简而言之，所有的“独角兽公司”都曾经是“马驹公司”。如果一匹马驹想变成独角兽，那么就该好好学学开发运维。事实上，采用开发运维的企业还在不断增加。

金融服务：纽约梅隆银行（BNY Mellon）、美洲银行（Bank of America）、世界银行（World Bank）、沛齐公司（Paychex）以及美国全国保险公司（Nationwide Insurance）。

零售业：盖普（GAP）、诺德斯特姆（Nordstrom）、REI、梅西百货（Macy’s）、游戏驿站（GameStop）以及塔吉特百货（Target）。

高等教育：斯腾山大学、堪萨斯州立大学和英属哥伦比亚大学。

四种工作类型

由于布置工作的途径比以往更多（例如电子邮件、电话、关于业务应用程序的中途会谈、短信、报修系统、会议等），我们希望直观地看到现有任务。

埃瑞克告诉比尔，IT从事着四种类型的工作。

1. 业务项目

这是多数开发项目所包含的业务举措，通常隶属于项目管理办公室。项目管理办公室跟踪管理公司内的所有正式项目。

2. IT内部项目

包括可能由业务项目衍生出的基础架构或IT运维项目，以及内部生成的改进项目（例如创建新环境和部署自动化）。这些项目经常并非集中跟踪，而是属于预算所有者（例如数据库经理、存储管理经理和分布式系统经理）。

当IT运维成为瓶颈时，这会导致问题，因为不能轻易查明已经在内部项目中投放了多少生产能力。

3. 变更

经常由上述两种类型的工作引起，往往在报修系统中被跟踪（例如IT运维补救、JIRA或者用于开发的敏捷计划工具）。事实上，在价值流的两个不同部分中存在两个工作跟踪系统，这会引起问题，尤其是在交接工作的时候。

偶然情况下，在一些兼具功能开发和服务交付职责的专门团队中，所有工作都处在同一个系统之中。这样做有一些好处，操作层面的故障会和功能缺陷以及新的特性功能一起，在存量工作和现行工作过程中显现。

4. 计划外工作或救火工作

包括操作事故和操作问题，通常由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。

为什么需要使IT工作可视化并控制半成品

本书中我最喜欢的（也是唯一的）一张图表显示，等待时间是工作中心中某个资源忙碌程度的函数。埃瑞克用这张图表来说明为什么布伦特的30分钟的简单变更要耗费几个星期才能完成。原因显然是，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，我们每次交给他的工作都只能在队列里等待，如果不进行加速或升级处置，就永远不会完成。

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

本书中，比尔及其团队意识到，他们对项目管理办公室承诺的交付期会带来怎样的灾难性后果。

我告诉他们，埃瑞克在MRP-8对我说过，等待时间取决于资源使用率。

“等待时间是‘忙碌时间百分比’除以‘空闲时间百分比’。也就是说，如果一个资源的忙碌时间是50%，那么它的空闲时间也是50%。等待时间就是50%除以50%，也就是一个时间单位。就说是一个小时吧。所以平均来说，一个任务在处理前的排队等待时间为一个小时。”

“另一方面，如果一个资源90%的时间是忙碌的，等待时间就是‘90%除以10%’，也就是9个小时。换言之，我们的任务排队等待的时间，将是资源有50%空闲时的9倍。”

我得出结论：“因此，对这个凤凰任务来说，假设我们有7个交接步骤，而且每一个资源都有90%的时间是忙碌的，那么任务排队等待的总时间就是9小时乘以7个步骤……”

“什么？只是排队等待的时间就要63个小时？”韦斯充满疑惑地说。

帕蒂似笑非笑地说：“哦，当然了。因为输入字符只需要30秒，对不对？”

比尔及其团队意识到，他们那个30分钟的简单任务实际上需要7个交接步骤（也就是服务器团队、网络维护团队、数据库团队、虚拟化团队，当然还有布伦特、布伦特、布伦特）。假设所有工作中心都有90%的时间是忙碌的，那么这张图表告诉我们，在每一个工作中心的平均等待时间是9个小时。由于工作必须经过7个工作中心，总共等待时间就是7倍：63个小时。

也就是说，总的“有效时间”（有时候也称为“加工时间”）只有总交付周期的0.16%（30分钟除以63小时）。

那就意味着，在总交付周期99.8%的时间里，工作只不过在排着队等待被执行（例如，在报修系统里等和在电子邮件里等）。

我的合著者乔治·斯帕福德和我同在华盛顿州立大学参加詹姆斯·霍尔特博士的EM 526约束管理课程时，我们首次见到了这张图，它如此出色地显示出，高资源使用率所导致的长时间排队的破坏性本质。

遗憾的是，我不知道这幅图的确切来历。有人和我一样相信，这幅图是立特尔法则的简化版本。根据这个法则，我们假定的是只有一个工作中心、均匀的工作队列（例如，所有任务需要的完成时间都相同）、工作之间没有延迟等。

在这幅图中，我相信“等待时间”其实代表着“队列长度”。也就是说，由于它不是所用时间，因此没有时间单位（也就是说，既不是分钟，也不是小时、天）。

关于此书派生出来的最棒的讨论（及其合理性/不合理性）都可以在Linkedin网站上本书的页面看到。

这些讨论尽管有时略显尖刻，但确实充满智慧。

肖恩·H.，“等待时间=（忙碌百分比）/（空闲百分比）”，《凤凰项目》讨论组，领英网站，2013年3月29日，https://www.linkedin.com/groups/Wait-time-busy-idle-4865747.S.227406165?trk=groups_most_popular-0-b-ttl&qid=ab4853b8-10a5-4adf-a666-038c0a65471e&goback=.gmp_4865747 。

我的看法是，科学的目标是用最少的原理来解释最多的现象，并揭示惊人的内涵。我认为这张图很能说明问题。它有效阐释了过度压榨IT工作者的灾难性后果，以及在IT运维部门使用传统项目管理方式的错误。