《凤凰项目 一个IT运维的故事传奇》读后感

《凤凰项目 一个IT运维的故事传奇》

  最近读了《凤凰项目-一个IT运维的传奇故事》，本书讲了一个IT运维经理临危受命，通过三步工作法，以及同事间协作帮助的情况下，拯救了一家历史悠久的汽车配件制造商。在此之前，我并不明白现在IT组织与公司管理共通之处，只是觉得IT组织在一个非技术驱动型公司，其存在的价值是公司业务的附属品。在读完本书之后，才明白，IT运维不仅仅是代码维护实现那么简单，其支撑着整个公司的线上业务维护，致力于给用户更好的体验，其涉及到各个部门之间的协作，以及很多管理的理念。在不断的事故、会议、事故、会议中反思，及时梳理IT运维部门与其它部门之间的协作关系，致力于建立一条完整的IT业务工作流。

  文中有很多极具个性的观点，与作者一样，在数次的合理的建议被CEO史蒂夫拒绝之后而果断提出离职一样，很值得深思。

1、三步工作法：

  作者从埃瑞克那里学会了三步工作法，逐渐发现工作中的不足之处，并用其指导改善公司的IT业务流。三步工作法很好的阐明和指导开发运维的流程与实践的价值观。当然，很多公司都在践行其中的一些理念，这当然不能用几句话去概括的。但是一个高度概括的方法论，可以将我们的工作按照这种方法论去具化，有助于我们更好的理解现在的工作。文中对三步工作法进行了一个高度的概括，有助于我们记忆。但最好的践行方式，是经过反复练习巩固，并在工作中不断去学习了解，实践加理论才是正道。

  第一工作法，从开发到IT运维再到客户的整个自左向右的工作流。通过建立完整的持续构建、集成以及部署和严控半成品，帮助我们形成一条迅速、可预测、持续不断的计划内工作流、从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏，逐步提供稳定的、可预期的、安全的IT服务。

  第二工作法，价值流各阶段自右向左的快速持续反馈流，放大其效益以防止问题再次发生，或者更快地发现和修复问题。加速问题的反馈，可以缩短及放大反馈环路，在源头上解决问题，避免问题逐步放大。一旦问题反馈不及时，后续基于此产品的工作，只会让错误成倍的放大。此外，合理的反馈流可以减少意外工作的干扰。

  第三工作法，关于创造公司文化，该文化可带动两种风气的形成。当成功的构建了第一和第二工作法，下来就是需要增强产品信心，营造一种勇于创新、冒险的环境，高信任度的文化。这就要不断给系统施加压力，不断强化学习并加以改进，比如反复的故障演练、反复的安装部署等。

  现在的工作中，公司也在一直践行这样的理念，去构建一个产品的完整的交付反馈环路，尽管还是存在很多问题，比如流程、体制、亦或是版本架构设计问题，但是，产品的质量确实是在不断提升改进。

  三步工作法的理念中每一步都涉及很多事情，需要在工作中不断践行。

2、四种工作类型：

  一个公司的IT从事着四种类型的工作：

  S1、业务项目：公司的业务举措；

  S2、IT运维项目：包含业务项目衍生出的基础架构或IT运维项目，以及内部的改进项目（例如创建新环境以及部署自动化）；

  S3、变更：经常由上面两种工作引起，对现有的应用程序、系统、设备等进行操作，并可能对服务产生影响；

  S4、计划外工作：操作事故以及操作问题等。

  四种工作类型的识别，有助于对现有的工作进行划分，将其进行归类并按照相应的方法去处理。对工作的划分，总是会有一些问题，之前在工作的时候，由于未作统一规划，部门内的人做了很多非法的操作，导致自己被计划外的工作占据，现有工作受到了严重的阻滞，这是非常大的问题，自己却不觉察，因为自身对工作的划分存在盲区，导致主要的、次要的工作不能有很好的划分。

  任何时候，如果不加控制，计划外的工作就会越来越多，从而严重阻滞其它三类工作的开展。因此前期的规划，应该是从各个角度去出发，收集各类信息，确保交付的技术产品是有效、可靠，而不是为了赶时间，而给出的一个捷径的半成品。并且，对于变更的项目，一定要记录在案，并评估其影响，因为80%的变更问题是由20%的变更引起。IT运维项目而言，运维不是为开发去收拾烂摊子，需要更好的跟开发协作，发现其中的问题，

要更好从事生产工作，需要对工作需求、优先等级、工作进度、可用资源有所了解。我们的目标是为了提高整个系统的生产能力，而不是提高完成工作的数量。

3、快速部署

  之前，公司在做云计算产品的时候，每一次线上的部署，都要经过数个星期的验证，几乎是将整个产品的特性用例执行了一遍，并且还要经过一整天的线上环境准备、部署、验证，也就是说，基于这种情况下，我们的效率相当于一个月只能给客户提供一次线上更新，并且，每次更新都会导致数十人精神紧绷，因为产品里面耦合非常严重，一旦出现问题，可能会是连锁反应，并且这种情况会很复杂，难以有效的形成经验、方案处理，这种效率是非常低下的，之前一直没有觉察，直到现在产品开始进行架构服务解耦，期望将我们的服务从月部署提升至天部署。而作为开发运维人员，应该是有一个有效的反馈、并推动开发提出有效的解决方案。openstack、docker之类的热门社区产品，就是从开发运维提出并实现的。服务架构解耦，各部件进行单独的构建，提升部署效率，按照这种方式，可以提升至每天进行服务更新发布，但实际的效果还是有待验证。服务的快速部署、更新，有着极其重大的意义：可以更快的响应客户的需求，而不是收集到客户的需求之后，等到一个月之后，才能对客户的线上环境进行更新发布，并且，快速的服务更新发布，意味着可以有更快、更完善需求、故障处理方案。

  IT运维为现代的公司提供了基础性的服务，作为行业的云计算头牌，亚马逊的部署效率在业界处于佼佼者的角色，而这种快速的部署，可以很容易的化解公司的核心冲突，提供更高的可靠性、稳定性和安全性，因为快速的部署，意味着更快的故障问题处理，因为每次部署的量是非常小的。

  之前产品的持续集成，一直是从产品的级别去考虑，每次大的更新，都需要将所有的测试用例执行一遍，这样的过程是极为复杂、不可靠的，因为对版本缺乏一定的信心，并且架构方面的一些问题，也导致我们的产品、补丁在发布前，不得不经历上万个用例的测试。因此需要维护反馈，从而催促开发进行架构的解耦、提升快速部署的能力，而不是作为运维人员，需要理解整个系统才能进行有效的部署。

  附参考Amazon的持续交付：http://www.yuntoutiao.com/dongtai/6192.html

4、明确业务模型，改进约束点

  第一次从书里知道了约束点这个词，之前在我们的项目组里，有人在从事持续集成的事情，版本的CI问题，基本都从他这里入手，导致的结果就是不得不频繁的加班，反观其他人，倒是不紧不慢，这就有点约束点的味道了。理论上，这就是不应该出现的事情，不应该让整个产品的进展阻塞到一个人上。当然，我们需要很多方法去改变我们的约束点，比如：建立知识库、看板展示、建设工具提升约束点效率。尽量避免将工作集中到某一个人的身上，这会导致极为严重的后果。

  此外，任何基于约束点的改进都是无效的。打个比方，假设流程中的某一步一分钟只能完成一个产品，那么流程中的其他阶段每分钟会完成100件产品，整个产品也必然会受限于这个关键关键一步的效率。所以，从开始项目工程规划、维护的时候，就必然需要事先考虑到这些事情。

  在不着急交付的时候，应该从改善约束点的情况下出发考虑。确保项目的进展。这就要深入分析到业务的具体模型，确认项目的整体的开发交付方式，不要采用大批量、长时间的交付方式，而要考虑小批量、短时间，不断发现、改进优化点，才能更好的实现产品的开发交付。高德拉特《目标》中的五个聚焦步骤，前三个是：第一步是确认约束点、第二步是利用约束点、第三步是将约束点置于次要的地位。

  如果一个产品需要N个部门协作，而每个部门的忙碌程度是50%，那么等待时间就是：50%/50%*N=N小时，但如果忙碌程度提升到90%，那么等待时间就是：90%/10%*N=9N个小时，瞬间等待时间就扩大了9倍。虽然这个比率不是很准确，但是是具有非常强的参考价值的，可以作为一个约束点评估的标准。从公司级别的角度来讲，约束点可能是某一个部门，而针对这个部门，约束点就可能具体到某一个人，我们可以逐层去分析。当然，如果仅仅是局限于部门内部，那么约束就可能是某一个人或是某一个流程。当每个人都要从扩展性、有效性、存活性、持续性、安全性、保障性、防御性去施加压力的时候，你必须清楚的了解到这些中，哪个才是真正是我们需要做的。

5、看板的重要性

  所有的项目都应该是可视化的，而不应该存在无法触及到的暗礁，这就要论看板的重要性。一个好的看板应该是可以很好的看到项目团队进展，否则就其中一个环节拉出来进行讨论是没有意义的。比如，我们要建设模块的CI能力，但是看不到版本的发展、项目，这都是没有意义的，因为很可能是会走偏的。

  当然，不要为了数据好看而去做看板。现在对于公司来讲，看板里面存在多少不为人知的造假，想方设法的缩短时间，提升效率，这就是大公司的一些通病，但是我们应该积极去改进。

6、如何确定一个项目的优先级：

  一个项目的优先级，应该是有多重因素的，如果一个项目的优先级仅仅是因为领导的喜恶，那就是屁股决定脑袋，那么产品的前景就会存在很多风险。产品想要实现、部署的功能是非常多的，如果企图全部实现，那几乎是不可完成的工作量，因此需要对这些工作进行排序、确定优先级。那么如何在多条工作流进行时，去确定我们的工作安排呢?很多时候，这是很难确定的。本书中就提供了一种很好的方式，那就是从约束点的方式考虑，在安排工作的时候，应该考虑到约束点的状况，打个比方，假设只有1个美术人员，那么工作重点就不应该以美术设计为主。

  当然，作者比尔甚至对项目的优先级提出了一个非常震惊的建议，就是09.23日提议将整个项目进行冻结，集中精力完成凤凰项目，因为凤凰项目事关公司的生死，而其其它项目如果失败了，不会影响公司的业务。这感觉有点像华为终端的发展，当年在余承东上台后，砍掉了80%的机型，集中精力完成荣耀品牌等，从而造就了华为终端的崛起。这是一个很了不起的决定，因为冻结其他项目同样可能会有巨大的风险，这个就需要根据实际情况去判断项目的优先级。集中精力做好一项工作，是很容易聚焦并达成目标的。