32 KiB
| doc_type | bookId | author | cover | reviewCount | noteCount | title | description | keywords | tags | date | readingStatus | progress | totalReadDay | readingTime | readingDate | finishedDate | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| weread-highlights-reviews | 27337404 | 仲平 | https://cdn.weread.qq.com/weread/cover/74/YueWen_27337404/t7_YueWen_27337404.jpg | 2 | 117 | 凤凰项目：一个IT运维的传奇故事（修订版） | 本书讲述了一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处，让读者不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。 |
|
|
<% tp.date.now("YYYY-MM-DD") %> | 读完 | 100% | 16 | 6小时40分钟 | 2022-11-28 | 2023-12-13 |
简介
- 书名：《凤凰项目：一个IT运维的传奇故事（修订版）》
- 作者： 吉恩·金 凯文·贝尔 乔治·斯帕福德
- 分类： 文学-散文杂著
- ISBN：9787115516763
- 出版社：人民邮电出版社
概述
本书讲述了一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处，让读者不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。
划线
在当年我还想着成为IT人的学生时代，阅读各种IT类书籍是一件苦差，需要在月明风清的晚上备好香茶点心，沐浴更衣，鼓足勇气才能翻开书本，而且预想的彻夜苦读经常以一夜好梦而告终——书还翻在一开始的几页，似乎字里行间都散发着不可思议的催眠魔力。
信息技术与核心业务的“黏性”正成为公司竞争力至关重要的构成因素。
所以，如果你的老板还觉得IT运维部就是“修电脑的”，那么，给他/她这本书，或者趁早换一个老板。
过去十年间，CIO每两年肯定会轮换一次，就像钟表一样有规律。他们在位的时间仅够理解各种首字母缩写的含义，知道卫生间在哪里，推行一堆计划和倡议，然后梦想破灭，再然后走人。
你以为我们会把那样的奖励随便颁给什么人吗？”他认真地说，“那是一个重要的项目。为了做成那个并购，我们必须做好那个项目。你和你的团队干得好极了
“这我相信，”史蒂夫笑起来，“我也在军队里待过八年，比我的义务服役期略长一点。不过我不介意。我只有参加预备役军官训练营才能付得起大学学费，而且他们待我不错。”
绝地武士控心术”
我很难从他们提出的那些不依不饶、歇斯底里、自以为是的要求中，找出与切实提高环境防御有什么关联。
导致周二的SAN事故和工资核算故障之类的事件了。一开始只是个中等规模的工资核算故障，最后像滚雪球一样演变为非常严重的乌龙SAN事故。
但是现在大家显然都知道，不应该根据第一个工作站的效率来安排工作，而是根据瓶颈资源所能完成工作的速度来安排工作。”
作为IT运维部的副总裁，你的工作是确保形成一条迅速、可预测、持续不断的计划内工作流，从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏，那样你才能提供稳定的、可预期的、安全的IT服务。
第一步帮助我们理解在工作从开发部移向IT运维部时该如何建立快速工作流，因为那就是业务部门与客户之间的衔接。第二步告诉我们如何缩短及放大反馈环路，从而在源头上解决质量问题，避免返工。第三步告诉我们如何建立一种文化，既能鼓励探索、从失败中吸取教训，又能理解反复实践是精通工作的先决条件。
在白板上可以清楚地看到，将近一半变更都安排在周五，剩下的变更又有一半安排在周四，其他的零零散散地排在上半周。
“我不是说周五碰巧有173个变更不好，我担心的是变更冲突以及可用资源矛盾。周五也是部署凤凰的日子。”
“好极了。”帕蒂说，“每解决一个问题，我们的知识库里就会多一篇关于如何解决某个疑难杂症的文章，而且能够实施修复的人会越来越多。”
我担任CEO以来，一直都听到这样的投诉。IT拖累了每一项重要举措。与此同时，竞争对手们却把我们远远甩在身后，让我们备受羞辱。该死的，我们做屁大点事儿都有IT的人在那里碍手碍脚
上周参加了一个会议，那个项目已经积压了很多待处理功能，产品经理们却还在讨论三年后哪个功能会更有用！我们连有效制定一年计划都做不到，更别说三年了！都有什么用？
尽管无法请出一整天的假，我还是带佩奇出去吃了早餐。在我每天两眼一睁就投入工作的那段时间里，是她独自一人撑起了这个家。
海军陆战队里的一个同僚曾经告诉我，他对自己的定位是：养家者，家长，伴侣，然后是突发事件的应变者。以此为序。
：“高德拉特教育我们，在大多数工厂里，总有那么一小部分资源，不论是人、机器还是原材料，决定了整个系统的产出。我们称之为约束点或者瓶颈。任何一项团队工作都是如此。
在你建立起一个可信赖的系统用以管理通向约束点的工作流之前，约束点经常是被闲置的，也就是说，约束点可能在很大程度上未被充分利用。”“那就意味着，你没有向业务部门交付全部的可用资源。也可能意味着，你没有还清技术债务，因此随着时间的推移，你遇到的问题和计划外工作量会不断增加。”他说。
你现在听上去和吉米一样，对你无法控制的事情怨天尤人。”他叹了口气，“当然是凤凰导致了所有的问题。在其位，谋其政
我用以前训练出来的方法应付这么气急败坏的人。我冷静地重申了之前所说的话：“如我所言，我今天早些时候和迪克谈过了。他已经把所有利害关系都强调得很清楚了。我们已经启动了新的事故处理流程，而且我们正在有条不紊地调查可能造成故障的原因。他们正在做我要求他们做的事，因为面对这么多不确定因素，妄下结论实在太容易把事情弄得更糟了。”
“好吧，你走后我们彻底搞砸了。”韦斯说，听上去十分窘迫，这证实了我最担心的事情，“史蒂夫坚持要我们把所有工程师都叫过来，包括布伦特。他说，他要每个人都有‘紧迫感’，并且要‘手不离键盘，不能有闲人’。显然，我们没能有效整合起每个人的力量，而且……”
我叹了口气。我永远不会告诉他们，我和史蒂夫之间那些沮丧荒唐的会面。那是他和我之间的事。
在过去一个月里，我学到了两件事。第一件事，IT很重要。IT不是一个可以轻易委托外包的部门。公司的每一项重大活动都有IT的参与，而且IT对日常运作的方方面面都起着关键作用。”
一个伟大的团队并不代表他们拥有最聪明的人。使团队变得伟大的因素，是每个人都互相信任。当那种神奇的动力出现，就会让整个团队充满力量。
史蒂夫继续说：“我最喜欢的一本关于团队动力学的书是帕特里克·兰西奥尼的著作《团队发展的五大障碍》。他在书中写道，想要在团队中达成相互信任，你需要展现出自己脆弱的一面。所以，我要告诉你们一些关于我个人的事情，以及是什么让我有动力走到今天。
我们给你们付工资，是为了让你们思考，而不只是执行！”
如果你，或者其他任何人，知道某个项目会失败，我需要你们说出来。而且，我需要你们的观点有数据支撑。就像那个车间协调员给你们看的数据，我就需要那样的数据，那样我们就能明白缘由。对不起，比尔，我很看好你，但只根据直觉说‘不’是不够的。”
因为你完全不知道你们的实际工作能力有多少。你就像个一直在开空头支票的家伙，因为你不知道自己有多少钱，而且从不费心打开邮件。”
“每个人都知道，在生产中，半成品增加，交期性能就会下降。”
大幅度地做了个手势，说：“‘第二工作法’的一个关键部分是让等待时间可视化，那样就能知道你的工作何时在某人那里排了几天的队，或者还有更糟的情况，工作必须往后退，因为没有完成所有的部件，或者需要返工。”
无极限零部件公司最大的风险是停业破产。而你似乎一心想用你那些不周全的考虑和无关紧要的技术细节，让它加速倒闭。怪不得你会被边缘化！其他人至少都在想方设法帮助公司存活下去。
和应用程序，然后安放到机架上。接着，我们会确认它安装完毕。每一个步骤通常都是由不同的人完成的。也许，每个步骤就好比是一个工作中心，每个工作中心都有自己的机器、方法、人员和测评。”
别逗我了，伙计们。”韦斯说，“首先，我们的工作不是重复性劳动。其次，和那些只是安装部件或者拧螺丝的人不同，从事我们的工作需要非常多的知识。我们招聘的都是头脑灵活、经验丰富的人。相信我，我们没法像制造部门那样，把各项工作标准化。”我考虑着韦斯的观点，说：“如果是在上一周，我想我会赞同你的观点，韦斯。但上周，我用了十五分钟时间，考察了生产车间的一个总装工作中心。我被那里所进行的一切征服了。老实说，我几乎跟不上它。尽管他们已经尽可能地让每件工作都可复制、可重复，但是为了达成每日生产目标，他们仍然担负着很大的应变处置和故障处理的工作量。他们做的事比拧螺丝多得多。他们用点点滴滴的经验和智慧，每一天都在谱写着传奇。”
我不管每个人觉得自己的项目有多重要。我们要知道的是，项目能否提高我们在约束点上的工作能力，这个约束点指的还是布伦特。除非一个项目能够减少他的工作量，或者可以让其他人接手，否则的话，我们也许就不应该开展这个项目。另一方面，如果一个项目并不需要布伦特参与，那我们就没有理由不开展它。”
没错。他们每个人都拿到了。最早拿到电脑的几个人遇到了一些配置错误，或者缺了些东西。我们已经在工作指南里改正了，这两天，我们的电脑正确送达率好像已经达到100%了。”
首先，布伦特的‘任务’原来远不止是一个任务。其次，我们发现那是涉及多个人员的多个任务，而相关人员都有自己的紧急工作要做。每一次工作交接都是在损失我们的时间。按照这样的速度，如果没有大规模的干预，QA就得等上好几周才能拿到需要的东西。”
上次我们需要一个防火墙变更，约翰的团队几乎花了一个月时间才弄好。一个30秒的变更花了整整四个星期！”
如果我们能够把所有的经常性部署工作标准化，最终就能达到产品配置的一致性。我们现在的基础架构过于多样化，就像雪花一样，没有两片重样的。布伦特之所以会成为布伦特，是因为我们允许他建立起只有他能理解的基础架构。我们不能再让这样的事情发生。
告知真相是一种爱的表现。隐瞒真相是一种恨的表现。甚至更糟，是一种冷漠的表现。”
“好吧，这些年里，我大部分时间都在负责中型机工作组，你不太参与这方面的事。”我冷静地解释，“我们在网上找到了自己的安全指南。当我们和你沟通的时候，你只想把一大堆工作压给我。看，我很在乎安全性，我们一直在查找系统和数据的风险，但我们总是忙于先解决最紧急的事情，勉强维持生存。而我的新使命，就是要帮助公司生存下去
我把约翰的钱包还给他，又掏出自己的钱包付了钱。我帮约翰站起身，把他塞进出租车，又确认了一遍钱包和钥匙都在他的口袋里。我不想让约翰和出租车司机打交道，于是把车钱也付了。
再没什么比吐槽IT更能让人团结一致的了。
理想状态下，工作流应该只朝一个方向移动：向前。一旦看到工作向后移动，我就会想到‘浪费’。也许是由于不合格品、缺少规范，或者返工……无论是哪一种情况，我们都得开展修复工作。
我们把四个工作中心合而为一，排除了三十多个容易出错的人工步骤，使整个工作周期完全实现了自动化，形成了单一工作流，并且去掉了所有的准备时间。生产能力一飞冲天。”
你们应该创建亨伯尔和法利所说的‘部署管道’。那是从代码签入到投产的整个价值流。那不是一种技术，而是生产。你们应该对所有东西都进行版本控制。所有东西，不只是代码，而是创建环境所需的每一样东西。然后，你们应该把整个环境创建流程自动化。
令人惊讶的是，克里斯的反应最为激烈。“什么？我们究竟为什么要一天开展十个部署？我们的部署冲刺周期是三个星期。我们拿不出那么多东西来一天部署10次！”
返工和准备时间过长问题的另一个显著来源是代码打包流程，在此阶段，IT运维部对经过开发部检查的内容进行版本控制，然后生成部署包。尽管克里斯和他的团队尽可能地记录代码和配置，总还有东西会遗漏，这些东西只有在部署之后，代码无法在环境中运行时才会被发现
“这看起来很有希望。如果能把环境标准化，并把这些环境投入开发部、QA和IT运维部的日常使用，我们就能消除大部分在部署流程中因差异而导致的悲剧。”
我对威廉和布伦特说：“好吧，伙计们，你们有魔法棒了。你们要身先士卒。告诉我，你们会怎样设计生产线，让工作永远不会往回走，让工作流快速高效地向前移动？”他们俩都一脸茫然地看着我，我有些恼火地说：“你们有一根魔法棒！用它啊！”“这根魔法棒有多强？”威廉问。我重复了之前对玛姬说的话：“这是一根非常强大的魔法棒。它能做任何事。”
从很多方面来看，开发人员简直就是我所青睐的性情的对立面。我喜欢创造并遵守流程的人，喜欢重视严谨与纪律的人。而这些人偏偏喜欢心血来潮、异想天开，跳开流程办事。
“我们不需要任何新硬件。”这个开发人员回答，“我们投入了很多精力来建立我们能够部署的计算机图像。为什么不把它们发送到云上？在我们需要的时候，可以运转成百上千个计算实例，完成后再销毁它们，成本只是我们所用的计算时间。”
结果大放异彩！超过20%的受访者访问了我们的网站，超过6%的人购买了商品。这个转化率高得令人难以置信，可能比我们之前开展过的所有活动都要高出五倍。
玛姬很快同意了，但是开发人员仍然花了两个小时进行变更和部署。现在，可以通过一个配置设定来禁用这个功能，因此下一次我们就能在几分钟内弄好，而不需要一整套代码上线了。这才是IT运维友好型的研发设计嘛！在生产中管理代码变得越来越容易了。
独角兽团队简直棒极了。他们已经从每两周开展一次部署过渡到每周开展一次部署，而且我们正在尝试每天开展部署。由于批量规模缩小了很多，我们可以很快做出小型变更。我们正在随时开展A/B测试。简而言之，我们从未这样迅速地响应市场，而且我相信，我们一定会大有可为。”
从“库存型生产”转变为“订单型生产”
。根据“改善形”，这让我不会觉得自己完全无用武之地。让我尤为骄傲的是，整整一个月来，我的团队都达到了把15%的时间用于预防性基础架构项目的目标，并且体现出了成果。
我们需要建立起一种文化，强调勇于冒险以及从失败中汲取教训的价值观，并强调通过反复实践以致炉火纯青的必要性。
我不希望张贴宣传质量与安全的海报。我希望我们的改进能够体现在日常工作的所需所用上：应用到日常工作之中。
“你帮助我认识到，IT不只是一个部门。相反，它就像电力一样无处不在。IT是一种技能，就像能读会算一样。
希望每一个雇员都多少掌握这些技能。理解技术能够做什么、不能做什么，已经成为这家公司里每个部门必须具备的一种核心竞争力。要是业务经理领导了一个不具备这种技能的团队或项目，他们就会失败。
要是你能做到，我就准备培养你。我想把你放上一个两年计划的快车道。你将在销售和市场营销部门轮岗，管理一家工厂，积累国际经验，维护关键供应商的客户关系，以及管理供应链。相信我，这可不像度假那么轻松。你需要帮助，很多很多帮助。埃瑞克很好心地答应会指导你，因为我们俩都相信，这将会是你做过的最困难的事。
每一个称职的COO都会是从IT部门出来的。任何尚未精通IT系统就负责管理公司运行的COO，都只会是金玉其外的傀儡，需要依靠别人来开展工作。
史蒂夫就像是知道我在想什么一样，他说：“在好几个月之前，埃瑞克和我第一次见面的时候，他说IT部门和业务部门之间的关系就像是一场不协调的婚姻，双方都感到无能为力，并且被对方所挟持。我对此思考了好几个月，终于想清楚了一些事。”
所谓一场不协调的婚姻，是假定业务部门和IT部门是两个分离的实体。IT要么融入到公司的日常运行之中，要么融入到公司的业务内容之中。瞧！就是这样。没有矛盾，没有婚姻，也许连IT部门也没有
时的救世主固然好，但普世的圣经则更有用’。”
DevOps的很多做法都是反直觉的，与常规认知相悖，甚至有争议。
鲁兹先生分析了布伦特的两面性：独食者和分享者。他写道：“我也碰到过一些非常聪明的人，他们秉持这种错误理念，即只有他们自己知道解决方案，才能永葆职位。这些人就是知识独食者。这个观念不对。没有人无可替代，无论这人有多优秀。当然可能特殊情况下解决问题需要的时间更长些，但缺了谁地球都能转。”
DevOps原则和模式就是通过整合企业文化、企业架构和技术实践，让下降式螺旋变成上升式螺旋。
以前的经济环境里，商业通过移动原子创造价值，如今则通过移动比特创造价值。
正如爱德华·戴明博士的名句所言：“没人会强迫你学习……学习也并非生存必需。”技术的美好年代在等着我们，而非已经走远。进入技术领域永远都不晚，成为终身学习者也永远都不晚。
任何一个领域或学科想要取得进步和成熟，就需要认真反思它的起源，在反思中寻求不同的观点，并把这些不同观点的来龙去脉思考清楚，这对预见未来发展是非常有帮助的。
DevOps实践可以与ITIL流程兼容。然而，为了支持DevOps所追求的更短的发布周期和更频繁的部署，ITIL流程的许多方面需要完全自动化，以解决配置和发布管理流程相关的许多问题，例如保持配置管理数据库和最终软件库是最新的。由于DevOps需要在服务事件发生时进行快速的定位和恢复，因此这些其实还是和ITIL的服务设计、事件和问题管理方面的原则相一致。
在这个竞争优势需要被快速验证和持续实验的时代，那些还不能应用DevOps实践的公司注定会在市场上败给敏捷的竞争对手，并可能会倒闭，和当年那些没有采取精益原则和实践的制造厂的后果类似。
大多数公司都不能在几分钟或几小时内完成变更需要的所有部署，往往需要几周甚至几个月的时间。他们更不可能每天在生产环境中做到成百上千次的部署，而是在以月甚至以季度为单位进行部署。对他们而言，生产环境的部署并不是日常工作，因此服务中断和各种事故总是与部署如影随形，“填坑侠”们总是前赴后继。
技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息。
第一部曲开始于IT运维，我们的目标是让应用程序和基础设施持续运行，以便公司向客户交付价值。我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。这就是我们背负的技术债务，这就是我们每天所处的工作环境。我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来。
这样的背景下，我们进入了第三部曲，也就是最后一部曲。在这里，所有事情都变得更加困难，所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多。我们的工作耦合得更加紧密，即使是很小的行动也会导致较大的事故，我们更加害怕和拒绝做出变更。工作需要更多的沟通、协调和审批；团队必须等待更长的时间，等待相关的工作完成；我们的工作质量持续恶化。车轮开始嘎嘎作响地缓慢移动，要想使之继续转动，就需要付出
许多心理学家认为，创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏性的一件事——我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚、失败或危及生存而不敢做正确的事。这创造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。
想要让新功能生效，我们只需要改变一个功能开关或者配置项即可，而不再需要经历数天或者数周的辛苦工作。这个小变更使新功能对更大规模的客户群可见，一旦出现错误，就会自动地回滚。因此，发布新功能变得可控、可预测、可逆，且压力也小了。
。我们的团队文化体现了高度的信任与合作，而不是指责
人们会因为冒险而获得回报。他们可以无所畏惧地讨论问题，而不是把问题隐藏起来或者往后拖延。毕竟，我们只有先认识到了问题，才能解决问题。
而且，因为所有人都需要对自己的工作质量负完全的责任，所以每个人在日常的工作中都创建自动化测试，并且使用同行评审的方式来保证在问题影响到客户之前就解决它。与从管理层向下授权审批的方式相反，上述过程降低了风险，让我们能快速、可靠、安全地交付价值，甚至可以在挑剔的评审人员面前证明我们拥有一个高效的内部控制系统。
因为注重质量，所以我们甚至会故意在生产环境中注入故障，从而了解系统是怎样以预期方式发生故障的。
❏ 吞吐量指标；❏ 代码和变更部署次数（频繁30倍）；❏ 代码和变更部署前置时间（快200倍）；❏ 可靠性指标；❏ 生产环境部署（变更成功率高60倍）；❏ 平均服务恢复时间（快168倍）；❏ 组织性能指标；❏ 生产力、市场份额以及营业目标（大约2倍以上）；❏ 市值增长（3年内高出50%）。
当我们增加开发人员的数量时，由于沟通、集成以及测试开销，单个开发人员的生产力通常会显著下降。弗雷德里克·布鲁克斯在其著名的《人月神话》一书中强调过这一点。他解释说，当项目延迟时，增加更多的开发人员不仅降低了单个开发人员的生产力，而且也降低了整体的生产力。
“三步工作法”的原则：流动、反馈和持续学习与实验。
DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。
在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。同时，强调建立自组织的小团队，让成员在高度信任的环境中愉悦地工作。
因为前置时间是客户能够体验到的时间，所以我们把重点放在缩短前置时间而不是处理时间上。不过，处理时间与前置时间的比率是十分重要的效率指标，为了实现快速的流动并缩短前置时间，必须缩短工作在队列中的等待时间。
但是技术工作者很容易被打断，因为对所有人而言，这个中断的后果似乎是不可见的，即便它对生产效率的影响比制造业更甚。例如，将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本。
通过限制在制品数，还能更容易地发现工作中的阻碍。[插图]例如，当限制在制品时，可能会发现居然没什么工作可干的，因为要等待其他人。虽然进行一项新工作（即“干点什么总比什么都不干强”）可能很诱人，但此时更好的做法是查明导致等待的原因，并协助解决那个等待的问题。实际上，糟糕的多任务处理发生的原因，通常是同时给一个人分配多个项目，造成了很多优先级冲突问题。
一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证。这些工作可能还需要使用不同的工单系统或项目管理系统，编写技术规范文档，用会议、电子邮件或电话的形式进行沟通，可能还涉及文件共享服务器、FTP服务器和Wiki页面的使用。
例如，在瀑布型软件项目中，代码的开发可能花上一整年，在开始测试之前（甚至在向客户发布软件前），我们得不到任何质量反馈。在反馈稀少且滞后的情况下，工作结果是很难达到预期的。相反，我们的目标应该是在技术价值流的每个阶段（包括产品管理、开发、QA、信息安全和运维），在所有工作执行的过程中，建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更。
斯皮尔博士认为，群策群力的目的是遏制住问题，防止蔓延，然后定位和处理问题，避免复发。他说：“这样做可以让所有参与者都得到更深入的知识，理解如何管理系统，把无法规避的、早期的无知阶段变成学习的过程。
这就是休哈特提出的循环（即PDCA环）——计划（Plan）、实施（Do）、检查（Check）、改进（Act），后来由爱德华兹·戴明推广并得到了迅猛发展”。
触发了安灯绳时，我们就聚集在一起解决问题，停止开展任何新工作，直到问题解决。[插图]这给价值流中的每个人提供了快速反馈（特别是那个导致系统故障的人），让我们能够快速地隔离和定位问题，避免出现更复杂的状况，导致问题的因果关系变得模糊。
尽可能多用自动化方式执行通常由QA和信息安全人员来进行的质量检查
要在问题发生时识别问题，群策群力解决问题并构建新的知识，在源头控制质量，并且不断地为下游工作中心做优化。
第一步建立了从左到右的工作流，第二步建立了从右到左的快速、持续的反馈，第三步要建立持续学习与实验的文化。
工人犯了错就会受到惩罚，那些提出建议或指出问题的工人则会被认为是告密者或管闲事的人。当发生了上述情况时，领导层会故意压制，甚至进行惩罚，这导致了质量和安全问题的进一步恶化
4.3 把局部发现转化为全局优化
一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多的人从中获益
这样带来的结果是：在任何一组新船员出海时，他们都能迅速地从集体长期积累的智慧中获得成长。
在技术价值流中，我们也应该通过类似的机制建立全局知识库。例如，把所有事故报告转化成可搜索的知识库，让有需要的团队能更加方便地使用它去解决类似问题，同时建立起组织级的共享源代码库，让所有人可以方便地使用整个组织的代码、库和配置。这些机制有助于把个人的专业知识转化为服务更多成员的集体智慧。
另外，还可以通过演习的方式来预演大规模故障，比如关闭某个数据中心。或者在生产环境中注入大规模故障（如Netflix著名的“捣乱猴”，它会随机杀死生产环境中的进程和服务器），来验证系统的可靠性是否达到了预期。
领导者通过“做出所有正确的决定”来领导团队。
领导者可以使用下列问题来帮助和辅导实验者。❏ 上一步做了什么？发生了什么？❏ 你从中学到了什么？❏ 现状如何？❏ 下一个目标条件是什么？❏ 当前工作有什么阻碍？❏ 下一步做什么？❏ 期望的结果是什么？❏ 什么时候能进行复查？
三步工作法的第三步原则实现了学习型组织，实现了职能部门之间的高度信任和跨部门合作，接受了“复杂系统中总会发生故障”的事实，并鼓励谈论任何问题以建立一个安全的工作系统。它还要求将日常工作的改进制度化，把局部成果转化为可供整个组织全局使用和学习的知识，以及不断向日常工作中注入张力
参与者所面临的游戏复杂性和工作量会逐轮递增。每一轮游戏结束后，教练都将帮助参与者“回顾”（上一轮发生了什么，参与者做了什么，参与者从中学到了什么）“思考”（哪些可以做得更好或者采用其他方式）以及“决策”（下一轮游戏应该如何做）。只有这样，参与者才能够学习到如何持续不断地提升他们的业绩和工作能力，从而在面对更复杂的工作环境和更大工作量的情况下仍然能够游刃有余。
产品负责人不应该只关注具有创新性的产品和功能，还需重视维护工作和移除技术债务等优先级。
我从八年前就开始尝试用沙盘去进行培训教学，在教学过程中，我最大的感触是：用沙盘教学能给学员带来无以伦比的感受，这种感受很可能会颠覆学员顽固的思维、接受我们的理念。
国际最佳实践管理联盟源于欧洲，是由欧洲最佳实践联学会携手国际知名出版机构、资格认证机构、咨询机构和行业专家共同发起的一家推广国际最佳实践管理体系和框架标准的非营利性组织
笔记
搞死你的不是前期投入，而是后台的运行和维护。”
💭 任何事物都必须存在生命周期
DevOps是把精益原则应用到技术价值流中的结果，并探讨DevOps的三步工作法：流动、反馈以及持续学习与实验。
💭 正反馈