[很差分类]《凤凰项目》读后感

【版权声明】如需转载请联系做者。

《凤凰项目》是一个偶然的机会读到的，是从朗读新概念英语朋友的QQ那儿看到的这本书。春节期间看到图灵上有电子书促销，我就下手买了回来。总体说来，这是一本有趣的书，感谢图灵社区；也感谢做者为咱们描写的那个Eric老头、那个车间和那个项目。

这本书主要讲的是Bill带领的团队在Eric协助下如何改进IT运维、促进业务提高，并最终使得公司起死回生的故事。读彻底书，我开始尝试着回答下面这些问题，并给出一些初步的见解。有一些见解可能还须要继续打磨，有一些答案也可能会有些重叠，由于一样的答案能够解决不一样的问题。

第一：如何改进IT，可以下降IT系统带来的业务风险或中断故障？

第二：项目建设与运维如何衔接，可以确保IT系统在运维时期可以高效？

第三：IT对于业务的价值到底在哪里？或者说每一年花了很多钱，能不能说一说公司为什么要持续投入到IT？

第四：IT安全如何与IT融合到一块儿，再也不有“拖后腿”的感受？

对于问题一，我想能够从如何开展变动标准化、如何开展预防性维护、如何改进约束点对变动的制约、如何将DevOps理念应用到团队中等方面来改进和思考。

关于变动标准化，书中主要是从Bill提高为运维副总裁后，开始处理工资核算故障开始的。

以前无极限零部件公司也实施过“变动流程”，但你们都很抵触。如何让团队成员易于接受“变动流程”呢？

为何帕蒂曾经在IT运维团队内部推进过“变动流程”改进没有成功呢？

Bill促进变动流程的过程分为以下几步：

一、从易到难：使用纸笔等简易工具，要求团队成员开始仅记录“”核心要点：

“我但愿每一个工做组都把计划内的变动所有写下来，一张索引卡片上写一个变动。我但愿看到三条信息：变动计划的制定者、将要实施变动的系统以及一条一句话的概述。”

二、化繁为简：使用80/20法则应对员工们提交的“过多”的变动。

--“咱们应该重点关注最有风险的变动。”我继续说，“80/20 法则在这里彷佛一样适用：80%的风险是由 20%的变动形成的。”

--咱们要预先定义好高风险变动目录，在目录中的变动项目不只必须提交变动申请，并且必须在经过审批后才能安排实施。

三、分级分类管理变动：

--重大变动（含一些影响业务的脆弱性程序，如无人支持的旧程序）须要CAB审批。变动人员须要提交报告供CAB审查。

--低风险变动，ITIL 称之为‘标准变动’，批准便可。对于以前已屡次成功实施的变动，咱们只须要提早批准就行。它们仍然须要提交，但能够不通过咱们批准就安排操做日程。

--对于‘复杂的中等变动’，咱们决定，变动提交者有责任向可能受到影响的人员进行咨询并获得其承认。作完这些以后，他们就能够把变动卡片交给咱们审核并安排操做日程。” 

四、利用变动时间线辅助诊断故障：在故障时，分析变动记录、查看故障点前的变动时间线，来辅助故障分析。(p156）

五、严格遵照变动流程：禁止任何人经过变动流程之外，实施变动。

六、合理选择变动时间点：实施变动时，须要避开相似“凤凰项目”发布的重大节点。

七、变动受到约束点制约，没法按时完成，则要保护好“约束点”，任何针对约束点以外的改进都是无效的：

--“很好，”他说，“你在把布伦特的工做标准化，让其余人可以执行。并且，因为你最终把那些步骤记录下来了，因此能在必定程度上保证稳定 性和质量。你不只减小了须要布伦特的工做中心数量，还生成了一些未来可以让其中一些工做中心自动化运行的文档。”

--你得列出一张清单，代表有哪些变动须要布伦特（约束点）作哪些事，并设法让那些 3 级工程师知足清单上的要求。若是作不到这一点，那就试着肯定它们的优先级，分类交给布伦特处理。

八、变动带来的好处：

伙计们，今天早上，新的变动流程保住了咱们的饭碗。 今天，有两组人同时对物料管理数据库及应用程序服务器开 展变动。他们都不知道对方的事。 拉吉夫在变动墙上看出了潜在的冲突。咱们决定，先做个人 变动，咱们这边完成后再给他打电话。 咱们本来会把事情搞得一塌糊涂的。

九、计划外工做对变动的影响：尽可能保护约束点不受计划外工做的打扰。

十、让变动关注重点业务：

“哦，我没告诉过你吗？咱们在用不一样的颜色区分不一样种类的卡片，一旦项目冻结解除，这能帮助咱们作好准备。咱们必须 想办法确保你们都在作最重要的工做。所以，紫色卡片是支持五大最重要 业务项目的变动，支持其余项目的变动卡片则是黄色的。绿色卡片是内部 IT 改进项目，咱们正在尝试，划拨 20%的工做周期专门用于这些项目，就 像埃瑞克建议咱们作的那样。只要看一眼，就能确认工做中紫色和绿色卡片取得了正确的平衡。” 她继续说：“粉色的即时贴表示一些卡片因为种种缘由卡住了，所以 咱们会天天检查两次。咱们还把全部这些卡片都放回变动跟踪工具里，这 样就能给每张卡片也都设置变动标识（ID）。这件事有点儿繁琐，但至少 如今有一部分跟踪是自动化的。”

 

对于第二个问题，项目建设（开发）和运维如何有效集成，我以为能够从如下几个方面改进：让两个团队及早充分接触、团队领导以前增进互信、采用DevOps要确保开发环境、测试环境与生产（运维）环境一致、在开发测试阶段作好测试尽可能不把缺陷带入生产（运维）环节、作好版本控制、将系统安全融入每一个前期开发测试过程。

 

对于第三个问题，IT团队的确要始终关注业务，也能够说让IT内化成为公司的一种理念。

让咱们先看看约翰一蹶不振以后重出江湖时，对迪克提出的六个问题。我以为这六个问题不只仅是对迪克有效，也值得IT职场人士和IT团队思考。（P234）固然，更重要的是你能够在与业务部分沟通时使用。

一、"为了确保我没有理解错误或者先入为主，能否先请你跟咱们讲讲，你在无极限零部件公司究竟是作什么的？你的确切职能是什么？"

二、“你怎样区分美好的一天和糟糕的一天？”

三、“你今年的远期目标、近期目标以及评估指标是什么？”

四、“这些评估指标中，哪些是最有风险的？”

五、“这里的每个项目和评估指标，分别是由哪几位经理负责的？”

六、“咱们的时间快到了。此次会面实在太棒了。谢谢你抽出时间，和咱们谈了你的平常工做状况。有什么咱们能够帮到你的吗？”

迪克针对远期目标、近期目标展现的两张幻灯片，分别展现了从财务角度以及公司总体角度出发的目标。迪克不只仅关注局部目标，也按照第一工做法要求关注总体目标。

第一张幻灯片：

CFO 的远期目标：

公司情况

收入

市场份额

平均订单金额

盈利能力

资产回报率

财务情况

从订单转化为现金的周期

应收账款

准确及时的财务报告

借贷成本

第二张幻灯片：

咱们有竞争力吗？

了解客户的需求和指望：咱们知道要建立什么吗？

产品系列：咱们有正确的产品吗？

研发效能：咱们能有效地建立产品吗？

上架时间：咱们能尽快把产品推向市场并占有一席之地吗？

销售机会渠道：咱们的产品能带来感兴趣的潜在客户吗？ 咱们的效率高吗？

按时交货：咱们遵照了对客户的承诺吗？

客户保留：咱们是在得到客户，仍是在流失客户？

销售预测准确率：咱们能够把销售预测准确率归入销售计划流程吗？

 

以后约翰和比尔访谈了迪克团队的经理，肯定了IT价值链，让IT可以关注到业务的关注点，并分析出IT故障与业务风险之间的关联度。而后通过与迪克的再次会谈，因为IT与业务之间有了关联，更容易争取到了迪克对于IT团队获取更多资源的支持。

--“一旦你创建起价值链，把迪克的目标任务与 IT 对这些目标任务的影响关联起来，你就作好和迪克会面的准备了。收集之前 IT 问题如何影响那些目标的具体案例。确保你本身准备就绪。”

此外，对于防止故障而言，IT预防性工做要作在哪里呢？其实也就是那些影响核心业务运行的地方。

 

对于第四个问题，安全要融入开发、测试、运维的全过程，安全也须要关注如何保护业务，而不是仅从IT安全自己角度提出一大堆改进措施。

这方面能够参考约翰关于安全与IT的五条建议：

“为了将咱们与安全性相关的工做量减小 75%，我要提出五条建议。” P258

 

书中还提到了三步工做法，这个工做法会在做者的新书《DevOps handbook》进行更进一步的阐述。你能够先参考这里：the-three-ways-principles-underpinning-devops。做者用了三张图生动的说明了三步工做法。

 

 

我这里仅列举一下我读书时思考的关于三步工做法的部分问题：

一、如何在冻结工做流后，解冻项目，保持适当的工做流量，不会过多，也不会太少：

“是的。”他继续说，“咱们先从你的第一个问题开始。项目冻结解除 后，发布哪些项目是安全的？知道了工做如何流经某些工做中心，以及哪些工做中心须要布伦特，哪些工做中心不须要他，你认为答案是什么？” 我把埃瑞克刚才说的话慢慢地重复了一遍，设法拼凑出答案。 “我知道了。”我微笑着说，“发布那些不须要布伦特的备选项目是安全的。”

二、如何确认是否能够接受新的工做任务：

“好吧，更确切地说，你实际上是在构建一份资源清单。也就是材料清单以及所需工做中心和工艺的清单。一旦有了这个， 再加上工做订单和你的资源，你最终就可以理解你的生产能力和需求是什么。这将让你最终明白，是否能够接受一个新工做并对其做出实际安排。”

三、如何让工做流最大化：

“‘第二工做法’的一个关键部分是让等待时间可视化，那样就能知道你的工做什么时候在某人那里排了几天的队— —或者还有更糟的状况，工做必须日后退，由于没有完成全部的部件，或 者须要返工。” “记住，咱们的目标是使流量最大化。”

四、如何肯定项目优先顺序？

给我三份清单。第一份是须要布伦特参与的项目清单， 第二份是能够提升布伦特生产能力的项目清单，还有一份是其余项目的清 单。在每一份清单里，都肯定最重要的几个项目。别花太多时间给它们排 序——我不但愿咱们整天只是争论。最重要的是第二份清单。咱们须要通 过减小压到布伦特身上的计划外工做量，来不断提高他的工做能力。”

五、如何缩短项目或任务的处理时间？

我告诉他们，埃瑞克在 MRP-8 对我说过，等待时间取决于资源使用率。 “等待时间是‘忙碌时间百分比’除以‘空闲时间百分比’。也就是说，若是一个资源的忙碌时间是 50%，那么它的空闲时间也是 50%。等待时间就 是 50%除以 50%，也就是一个时间单位。就说是一个小时吧。因此平均来 说，一个任务在处理前的排队等待时间为一个小时。” “另外一方面，若是一个资源 90%的时间是忙碌的，等待时间就是‘90% 除以 10%’，也就是 9 个小时。换言之，咱们的任务排队等待的时间，将 是资源有 50%空闲时的 9 倍。” 我得出结论：“所以，对这个凤凰任务来讲，假设咱们有 7 个交接步 骤，并且每个资源都有 90%的时间是忙碌的，那么任务排队等待的总时 间就是 9 小时乘以 7 个步骤……”

这本书中，我也看到了如何有效沟通的一些不错的案例。选一些和你们分享。

一、约翰和比尔用一个精彩的问句打开了采访对象的话匣子。

“你怎样区分美好的一天和糟糕的一天？”约翰继续问。

当我问他，他以为糟糕的一天是什么样的，他的话匣子真的打开了。

二、对于一些须要开拓思路的方案，试试那根无所不能的魔杖。

“假如你能挥舞魔杖，你会怎么作？”我问。

 三、若是多个目标冲突时，如何平衡、确保团队利益？书中的史蒂夫，采用了第二优秀资源去知足另外一个目标。这是个好办法。并非任何目标都非得第一优秀的资源去支持。

“布伦特是独一无二的。独角兽须要一个受到开发人员尊重，对咱们全部 类型的 IT 基础架构都有足够深刻的经验，并能描述开发人员应该构建什么 样的东西才能在投产后真正管理和操做的人。这些技能是罕见的，目前， 没有第二我的可以胜任这个特殊的角色。”  “那么，若是你把第二优秀的人派去加入迪克的特别工做组，会怎么样？”他问。 “我猜测，拆分方案会不那么精确，但仍然能够顺利完成。”我回答。

 

【更多资源】

一、Phoenix Project英文原版部分章节节选（前16章）

二、Phoenix Project英文原版朗读 AUDIOBOOK：soundcloud上面搜索便可听到节选部分（前16章）。

三、读书过程看到的一些好的理念：

--你应该知道，与实现企业目标息息相关的是什么，不论它是项目、运营、战略、 法律法规合规、安全性，仍是其余别的什么。” 他继续说：“记住，重要的是结果——而非过程、管理，或者你完成了哪些工做。

--‘改进平常工做比开展平常工做更重要’。（意思是养成持续改进的习惯很重要）

--“迈克·罗瑟说，改进的内容几乎是可有可无的，关键是你要不断改进。为何？由于若是没有改进，无序状态必将使状况恶化，也就不可能达到零失误、零工做相关事故以及零损失的状态。”

 --“工做流只朝一个方向移动：向前。在 IT 部门建立一个向前的工做系统。 记住，目标是单一工做流。”

 四、关于DevOps：一天十次部署如何实现？

--咱们把四个工做中心合而为一，排除了三十多个容易出错的人工步骤，使整个工做周期彻底实现了自动化，造成了单一工做流，而且去掉了全部的准备时间。生产能力一飞冲天

--“阿尔斯帕瓦教导咱们，只要开发部和运维部协 同工做，连同 QA 和业务部门一块儿，这个‘超级部落’就可以成就各类难以想象之事。他们也知道，在代码投产以前，实际上并未产生任何价值， 由于那只是困在系统里的半成品。他不断缩减批量规模，实现快速功能流。 从必定程度上说，他确保了部署环境时刻准备就绪，按需投产。他把建立 和部署流程自动化，而且认识到，能够把基础架构看成代码同样对待，就像开发部推出的应用程序同样。这让他得以构建一步到位的生产环境和部署流程，就像咱们想出一步到位的喷涂和烘干方法同样

--去和克里斯一块儿想办法，如何才能保证在敏捷开发流程的每一 个阶段，不只有可推出的代码，还能具有可以部署这些代码的工做环境