《凤凰项目》读书笔记一

这本书的价值，可能需要一定的阅历才能认识到。这本书可以引导和启示大家更容易的、更深入的理解ITIL对一个企业的实际价值。

变更

变更，就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。

高风险变更目录

在目录中的变更项目，不仅必须提交变更申请，而且必须在通过审批后才能安排实施。

注：归纳出真正的高风险变更，数量要少、风险性要大，范围在覆盖到那些最脆弱的服务、应用程序和基础架构。操作人员需要针对这些变更形成一些报告，说明变更的成功概率以及相关联的故障时间。

低风险变更

ITIL称之为标准变更。对于之前已多次成功实施的变更，只需要提前批准就可以执行。这类变更仍需要提交申请，但可以不经过显式的批准流程就可以安排操作日程。

中等风险变更

变更提交者有责任向可能受到影响的人员进行咨询并得到其认可。完成以上工作后，拿到此次变更的受影响人员的确认函，他们就可以提交变更申请，在审核通过后即可以安排操作日程。

未经授权的变更

不准出现未经授权的变更，也不准在服务中断期间再出现未经公开的变更。

排查故障的实战演练

需要让每个人都养成运行合理的方式来解决问题的习惯。

约束点

总有那么一小部分资源，不论是人、机器还是原料，决定了整个系统的产出，我们称之为约束点--或者瓶颈。任何一项团队工作都是如此，不管你怎么称呼它，在你建立起一个可信赖的系统用以管理通向约束点的工作流之前，约束点经常是被闲置的。也就是说，约束点可能在很大程度上未被“充分”利用。这么说，意味着即便已经在日以继夜得忙碌着，却不代表约束点得到了充分利用。

高德拉特（目标）五个聚焦步骤：

• 第一步是确认约束点，直到确定那的确是整个部门层面的约束点，对非约束点的任何改进都只是幻觉，得不到实际任何价值；
• 第二步是利用约束点，寻找突破这些约束的办法，确保不让约束点浪费任何时间，永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项，一直都要这样；
• 第三步，使企业或部门的所有其它活动服从于第二步中提出的各种措施；
• 第四步，具体实施第二步中提出的措施，使第一步中找出的约束环节不再是整个部门的约束点；
• 第五步，回到步骤1，别让惰性成为约束，持续不断地改善；

运维工作的四种类型：

• 业务项目，以新立项开发的项目为主，这类项目需要设计、开发和运维人员协同工作以实现产品设计的功能与非功能需求。
• IT运维项目，以已经在线运行并不定期进行应用更新的项目为主，这类项目需要消耗很多运维人员精力进行监控，以保障服务的可用性和性能。
• 变更，涵盖所有的系统与网络优化工作以及应用发布上线工作，变更又可划分成高、中、低多个不同风险级别。
• 计划外工作，包含全部的救火事件和所有的从天而降的意外工作，计划外工作不是免费的，它的代价就是牺牲计划内工作，计划外工作会让你丧失开展计划内工作的能力，因此必须不惜一切代价去消灭计划外工作，如果不加控制，技术债务必将导致公司里唯一能够完成的工作就是计划外工作；

注：计划外工作有一个副作用，当你把所有时间都用来救火，就没有时间和精力去制定计划了。当你所做的只是被动应付，就没有足够时间开展繁重的脑力劳动，弄清楚是否可以接受新的工作。当被塞进了越来越多的项目，每个项目的可用工作周期都变短了，就意味着会有更多有害的任务处理，出现更多走捷径的情况。

技术债务

技术债务是那些因为仓促上线或是疏于管理而造成的系统、网络与应用缺陷。技术债务是产生计划外工作量的主要来源，需要确认最主要的技术债务，推动开发部门对其进行处理，以减少问题应用程序所产生的计划外工作量。