IT运维人员的四类工作和三步工作法

《凤凰项目》是一本讲述IT运维转型的小说，书中提到了四类工作，分别是：

• 业务项目：由业务部门发起，为了实现某个业务目标而进行的项目，比如开发新功能，上线新产品等。
• 内部IT项目：由IT部门发起，为了提升IT部门的能力或效率而进行的项目，比如建设自动化平台，优化监控系统等。
• 变更：对现有的系统或应用进行的物理、逻辑或虚拟的操作，比如升级版本，修复缺陷，调整配置等。
• 计划外工作：由于突发的故障或问题而进行的恢复性工作，比如处理线上故障，应对安全事件等。

这四类工作都是IT运维人员日常要面对的工作，但是它们之间有着不同的特点和影响。我们应该如何理解和管理这四类工作呢？

首先，我们要明确每种工作对于业务价值的贡献。一般来说，业务项目和内部IT项目都是创造性的工作，它们可以为公司带来新的收入或节省成本。变更和计划外工作则是维持性的工作，它们可以保证现有的系统或应用正常运行，避免损失或风险。因此，我们应该优先关注创造性的工作，尽量减少维持性的工作。

例如，在《凤凰项目》中，凤凰项目就是一个业务项目，它是为了让公司能够在电子商务领域与竞争对手抗衡而开发的一个新平台。如果成功上线，它可以为公司带来巨大的收益和竞争优势。而内部IT项目则是为了提升IT部门自身的能力和效率而进行的项目，比如建设自动化部署平台、优化监控系统等。这些项目可以帮助IT部门更快更好地完成业务项目和变更工作，节省时间和成本。

其次，我们要控制每种工作的数量和规模。根据二八定律和Google SRE理论 ，大部分的线上故障都是由变更引起的。因此，我们应该尽量减少变更的频率和复杂度，避免引入新的问题或风险。同时，我们也要限制在制品的数量 ，即还没有交付给用户或上线的项目或功能。过多的在制品会占用资源和时间，导致交付速度变慢，甚至无法为公司产生回报。因此，我们应该采用小批量和快速迭代的方式，尽快完成从0到1的过程。

例如，在《凤凰项目》中，凤凰项目就是一个典型的在制品过多导致交付延迟和失败的案例。由于开发团队没有按照小批量和快速迭代的原则进行开发测试，而是积累了三年才上线一次，导致了大量的缺陷、冲突、依赖等问题。这些问题不仅影响了凤凰项目本身的质量和进度，也影响了其他的业务项目和变更工作。而变更工作也是一个重要的风险源，如果没有有效的管理和控制，就会导致线上故障的增加，进而引发计划外工作。

最后，我们要建立有效的管理机制和流程。书中介绍了三步工作法 ，分别是：

• 流动原则：关注从开发到运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小批量规模和工作间隔，决不让缺陷流向下游工作中心，并且不断为了整体目标进行优化。
• 反馈原则：关注价值流向各阶段自右向左的快速持续反馈流。放大其效益已确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。
• 持续学习与实验原则：关注创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。

通过这三步工作法，我们可以实现DevOps的转型，提高IT运维的效能和价值。

例如，在《凤凰项目》中，主人公比尔就是通过实践这三步工作法来改变IT部门的困境的。他首先建立了一个看板系统，来管理所有的业务项目、内部IT项目、变更和计划外工作，使得工作流变得可视化、可度量、可优化。他其次建立了一个故障处理分级机制，来加强对变更和计划外工作的反馈和控制，使得故障能够快速发现和修复，并防止再次发生。他最后建立了一个持续学习与实验的文化，鼓励IT部门的员工不断尝试新的方法和技术，从成功和失败中学习，并通过重复和练习来提高技能。