[不好分类]《凤凰项目》读后感

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

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

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

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

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

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

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

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

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

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

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

Bill促进变更流程的过程分为如下几步：

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

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

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

--“我们应该重点关注最有风险的变更。”我继续说，“80/20 法则在这里似乎同样适用：80%的风险是由 20%的变更造成的。”

--我们要预先定义好高风险变更目录，在目录中的变更项目不仅必须提交变更申请，而且必须在通过审批后才能安排实施。

3、分级分类管理变更：

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

--低风险变更，ITIL 称之为‘标准变更’，批准即可。对于之前已多次成功实施的变更，我们只需要提前批准就行。它们仍然需要提交，但可以不经过我们批准就安排操作日程。

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

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

5、严格遵守变更流程：禁止任何人通过变更流程以外，实施变更。

6、合理选择变更时间点：实施变更时，需要避开类似“凤凰项目”发布的重大节点。

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

--“很好，”他说，“你在把布伦特的工作标准化，让其他人能够执行。而且，由于你最终把那些步骤记录下来了，所以能在一定程度上保证稳定 性和质量。你不仅减少了需要布伦特的工作中心数量，还生成了一些将来能够让其中一些工作中心自动化运行的文档。”

--你得列出一张清单，表明有哪些变更需要布伦特（约束点）做哪些事，并设法让那些 3 级工程师满足清单上的要求。如果做不到这一点，那就试着确定它们的优先级，分类交给布伦特处理。

8、变更带来的好处：

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

9、计划外工作对变更的影响：尽量保护约束点不受计划外工作的打扰。

10、让变更关注重点业务：

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

 

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

 

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

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

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

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

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

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

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

6、“我们的时间快到了。这次会面实在太棒了。谢谢你抽出时间，和我们谈了你的日常工作情况。有什么我们可以帮到你的吗？”

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

第一张幻灯片：

CFO 的远期目标：

公司状况

收入

市场份额

平均订单金额

盈利能力

资产回报率

财务状况

从订单转化为现金的周期

应收帐款

准确及时的财务报告

借贷成本

第二张幻灯片：

我们有竞争力吗？

了解客户的需求和期望：我们知道要创建什么吗？

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

研发效能：我们能有效地创建产品吗？

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

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

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

客户保留：我们是在获得客户，还是在流失客户？

销售预测准确率：我们可以把销售预测准确率纳入销售计划流程吗？

 

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

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

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

 

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

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

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

 

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

 

 

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

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

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

2、如何确认是否可以接受新的工作任务：

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

3、如何让工作流最大化：

“‘第二工作法’的一个关键部分是让等待时间可视化，那样就能知道你的工作何时在某人那里排了几天的队— —或者还有更糟的情况，工作必须往后退，因为没有完成所有的部件，或 者需要返工。” “记住，我们的目标是使流量最大化。”

4、如何确定项目优先顺序？

给我三份清单。第一份是需要布伦特参与的项目清单， 第二份是可以提高布伦特生产能力的项目清单，还有一份是其他项目的清 单。在每一份清单里，都确定最重要的几个项目。别花太多时间给它们排 序——我不希望我们成天只是争论。最重要的是第二份清单。我们需要通 过减少压到布伦特身上的计划外工作量，来不断提升他的工作能力。”

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

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

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

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

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

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

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

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

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

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

 

【更多资源】

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

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

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

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

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

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

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

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

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

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

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