1
0
wiki/Book/文学/凤凰项目:一个IT运维的传奇故事(修订版).md

142 lines
14 KiB
Markdown
Raw Normal View History

2023-12-10 12:57:33 +08:00
---
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更能让人团结一致的了。
> 理想状态下,工作流应该只朝一个方向移动:向前。一旦看到工作向后移动,我就会想到‘浪费’。也许是由于不合格品、缺少规范,或者返工……无论是哪一种情况,我们都得开展修复工作。
> 我们把四个工作中心合而为一,排除了三十多个容易出错的人工步骤,使整个工作周期完全实现了自动化,形成了单一工作流,并且去掉了所有的准备时间。生产能力一飞冲天。”
> 你们应该创建亨伯尔和法利所说的‘部署管道’。那是从代码签入到投产的整个价值流。那不是一种技术,而是生产。你们应该对所有东西都进行版本控制。所有东西,不只是代码,而是创建环境所需的每一样东西。然后,你们应该把整个环境创建流程自动化。
## 笔记
> 搞死你的不是前期投入,而是后台的运行和维护。”
💭 任何事物都必须存在生命周期
## 书评
## 点评