--- doc_type: weread-highlights-reviews bookId: "27337404" author: 仲平 cover: https://cdn.weread.qq.com/weread/cover/74/YueWen_27337404/t7_YueWen_27337404.jpg reviewCount: 1 noteCount: 49 title: 凤凰项目：一个IT运维的传奇故事（修订版） description: 本书讲述了一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。小说揭示了管理现代IT组织与管理传统工厂的共通之处，让读者不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角来看待自己的工作环境。 keywords: - 凤凰项目：一个IT运维的传奇故事（修订版） - 吉恩·金 凯文·贝尔 乔治·斯帕福德 tags: - 阅读/文学-散文杂著 date: 2023-12-10 --- --- ## 简介 - **书名**：《凤凰项目：一个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更能让人团结一致的了。 > 理想状态下，工作流应该只朝一个方向移动：向前。一旦看到工作向后移动，我就会想到‘浪费’。也许是由于不合格品、缺少规范，或者返工……无论是哪一种情况，我们都得开展修复工作。 > 我们把四个工作中心合而为一，排除了三十多个容易出错的人工步骤，使整个工作周期完全实现了自动化，形成了单一工作流，并且去掉了所有的准备时间。生产能力一飞冲天。” > 你们应该创建亨伯尔和法利所说的‘部署管道’。那是从代码签入到投产的整个价值流。那不是一种技术，而是生产。你们应该对所有东西都进行版本控制。所有东西，不只是代码，而是创建环境所需的每一样东西。然后，你们应该把整个环境创建流程自动化。 ## 笔记 > 搞死你的不是前期投入，而是后台的运行和维护。” 💭 任何事物都必须存在生命周期 ## 书评 ## 点评