《凤凰项目, 一个 IT 运维的传奇故事》
《凤凰项目》三位作者,向他们致敬。
- 基恩・金:Tripwire 有限公司的创始人,他担任公司 CTO 长达 13 年之久。在 Tripwire 公司,他一直热衷于研究如何提高 IT 组织的效能。
- 凯文・贝尔:他创建了信息技术流程研究所,他拥有 25 年的 IT 管理经验,为 CEO 和 CIO 们提供指导和建议。
- 乔治・斯帕福德:行业分析师,帮助 IT 组织更好地找到目标,明确必要条件,发现实现目标的方法。
故事内容
讲述了一位 IT 经理临危受命,在未来董事的帮助和自己
三步工作法
理念的支撑下,最终挽救了一家具有悠久历史的汽车配件制造商的故事。
小说揭示了管理现代 IT 组织与管理传统工厂的共通之处,让读者不仅能对如何管理 IT 组织心领神会,更重要的是将以完全不同于以往的视角来看待自己的工作环境。
核心概念
三步工作法
本书中阐述了一个原理:所有开发运维模式都来自 三步工作法
,可以说它是我们平台开发运维的指导思想。
第一工作法
(流程自动化,快速迭代):关于从开发到技术运营,再到客户的整个自左向右的工作流。为了使流量最大化,我们需要小的批量规模和工作间隔,绝不让缺陷流向下游工作中心,并且不断为了整体目标(相对于开发功能完成率、测试发现 / 修复比例或运维有效性等局部目标)进行优化。
实践: 持续构建、持续集成、持续部署,按需创建环境、限制半成品,构建起能够顺利变更的安全系统和组织。
第二工作法
(保证上游的质量,避免返工):是关于价值流各阶段自右向左的快速持续反馈流,放大其效益以确保防止问题再次发生,或者更快地发现和修复问题。这样,我们就能在所需之处获取或嵌入知识,从源头上保证质量。
实践: 在部署管道中的构建和测试失败时 “停止生产线”、日复一日持续的改进日常工作、创建快速的自动化测试套装软件,以确保代码总是处于可部署的状态、在开发和技术运营之间建立共同的目标和共同的解决问题的机制、建立普遍的产品遥测技术,让每个人都能知道,产品和环境是否在按设定的运行,以及是否达到了客户的目标。
第三工作法
(不断试错,持续改进):是关于创造公司文化,该文化可带动两中风气的形成:不断尝试,这需要承担风险并从成功和失败中吸取经验教训、理解重复和联系是熟练掌握的前提、尝试和承担风险让我们能够不懈地改进工作系统,这经常要求我们去做一些和以往做法大不相同的事。一旦出现问题,不断重复的日常操作赋予我们的技能和经验,令我们可以撤回至安全区域并恢复正常运作。
实践: 营造一种勇于创新、敢于冒险(相对于畏惧和盲目服从命令)以及高度信任(相对于低信任度和命令控制)的文化;把至少 20% 的开发和技术运营周期划拨给非功能性需求,并且不断鼓励进行改进。
四种工作类型
-
业务项目:多数开发项目所包含的业务举措,即业务部门的所有正式项目。
-
IT 内部项目:可能由业务项目衍生出的基础架构或 IT 运维项目,以及内部生成的改进项目(如创建新环境和部署自动化)。这些项目经常并非集中跟踪, 而是属于预算所有者(例如数据库经理、 存储管理经理和分布式系统经理) 。
当IT运维成为瓶颈时, 这会导致问题, 因为不能轻易查明已经在内部项目中投放了多少生产能力。
-
变更:由上述两种类型的工作引起,往往在报修系统中被跟踪。在价值流的两个部分,开发和运维中应该统一管理变更。
-
计划外工作或救火工作:包括操作事故和操作问题,通常由以上三种类型工作导致,往往会牺牲其它计划内的工作为代码,成本往往很高。通过采用三步工作法,减少计划外工作,即使发生计划外工作,也能快速解决。
建立 ITSM 系统,并归类知识库,减少重复故障发生。
总结
目标:即拥有一条不断改进,能够自我反馈的自动化流水线。
-
开发运维并不仅仅是简单的自动化工具的集成,虽然自动化是开发运维的很大一部分内容。更重要的是价值流导向,自始至终拥有共同的目标并共同解决问题,需要把视野放得更大一些,而不是局限在运维的主机或服务上。
-
开发运维要提升自己的价值,就需要将自己的工作与最终的业务关系挂钩,了解自己运维的系统是如何影响着业务,所以开发运维需要有同公司一致的目标。
如书中比尔 与 约翰 在了解到公司业务目标后,思维一下子打开了,不再局限在眼前的系统与应用,而是有了更大的视野。他们一起约谈各业务部门负责人,清楚了解到各系统在业务上的位置,从而能够更好地去分配工作的优先级。
评论