《凤凰项目—一个IT运维的传奇故事》读书笔记
2021-09-18 15:46:43 1 举报AI智能生成
讲述无极限汽车零件公司如何在痛苦中通过团队的努力，共同实践三步工作法实现浴火重生的故事，三位作者现在都是公司管理层，所以书中既有运维工程师微观视角，也有管理者的宏观视角。整本小说的主人公叫做比尔，担任运维总监的角色，比尔通过自己的努力，让运维部、开发部、测试部、业务部门联合起来，为公司实现了业务的成功。所以小说的视角主要是在运维领域。
作者其他创作
大纲/内容
1.书籍介绍
故事概述
讲述无极限汽车零件公司如何在痛苦中通过团队的努力，共同实践三步工作法实现浴火重生的故事，三位作者现在都是公司管理层，所以书中既有运维工程师微观视角，也有管理者的宏观视角。整本小说的主人公叫做比尔，担任运维总监的角色，比尔通过自己的努力，让运维部、开发部、测试部、业务部门联合起来，为公司实现了业务的成功。所以小说的视角主要是在运维领域。
作者
Gene Kim: Tripwire有限公司创始人，一直热衷于研究如何提高IT组织的效率
Kevin Behr：创建了信息技术流程研究院
George Spafford：行业分析师
Kevin Behr：创建了信息技术流程研究院
George Spafford：行业分析师
扩展阅读
http://ijyun.github.io/2016/04/23/phoenix-project.html
https://riboseyim.github.io/2018/04/10/DevOps-Phoenix/
微信读书搜索书名可阅读原著
2.书中的运维问题
公司层面问题
前任CEO重掌董事会，公司管理层动荡，目标不一致
股东打算拆分公司
业务总监阴谋私下联合董事会反对运维改进
既要保持竞争力，又要削减成本
公司经过多轮裁员，人心不稳
公司市场占有率下降
公司股价下跌严重
业务总监利用凤凰上线预期效果绑架CEO的决策
运维管理层面问题
业务总监反对
高管变动太快
CIO和运维总监离职
CIO=Career Is Over
IT预算和人员申请总是被驳回
培养人太难
运维关键资源一直是瓶颈
CEO支持力度小
不正视资源与任务的失衡，不正视凤凰项目面临的巨大风险
不给资源，只派活
CEO被业务总监灌了迷魂汤
运维层面问题
重点问题：没有实质上的变更管理，运维工作处于失控状态
工资核算系统故障
重点问题：运维团队超负荷工作，没有资源，尤其是关键资源一直处于饱和状态。作为运维总监，比尔对团队的工作内容与状态一无所知
SOX-404审计合规问题
重点问题：此次事故充分暴露了运维团队缺乏事故处理机制与预案，团队缺乏信任，推卸责任严重。过度依赖关键资源
1级严重级别事故：信用卡处理系统故障
重点问题：IT设备采购周期太长
SAN驱动器故障
重点问题：CEO无视运维的基本规律，擅自干涉运维工程师的工作，逼迫工程师瞎忙碌
发票系统故障
重点问题：基本集齐了所有我们遇见的项目问题，延期，质量低下，着急上线，环境不一致，未经测试，互相指责，工期不考虑测试与部署
凤凰项目
3.比尔的改进措施
破冰会议
信任是非常重要的
运维团队需要限制在制品数量，提高整个系统的流量
大胆的举动：冻结除已知重要以外的所有工作
运维团队需要限制在制品数量，提高整个系统的流量
大胆的举动：冻结除已知重要以外的所有工作
提高流量
监控很重要，可以提高预防性
可视化资源的等待时间
基于约束点，最大化流量
变更管理
分级授权
可以把一部分变更审核委派给代理人
脆弱变更
列出了十大最脆弱的服务、应用程序和基础架构列表，可能会影响到其中任何一个的变更申请都将立刻标上记号，由 CAB 详细审查
标准变更
对于之前已多次成功实施的变更，我们只需要提前批准就行。它们仍然需要提交，但可以不经过我们批准就安排操作日程。
外部影响变更
对于‘复杂的中等变更’ 变更提交者有责任向可能受到影响的人员进行咨询并得到其认可，做完这些之后才可以将变更卡片送入审核流程
禁止条款（透明化）
禁止未经授权的变更，禁止在服务中断期间出现未经公开的变更
基于约束点的优先级排序
在非约束点做的改进都是假象
识别约束点；
利用约束点；
让所有其他活动都从属于约束点；
把约束点提升到新的水平；
寻找下一个约束点。
最大的瓶颈是人
布伦特
可视化工作区和看板实践
目标导向
简洁性
灵活性
工期估算和安排
“完成”的真正定义 并非开发部完成了编码，而是只有在代码经过充分测试并按设计在生产中运行时，代码才算“完成”
优化内部项目
基础架构可靠性
供应商升级
支持内部业务
审计和安全
数据中心升级
改进日常工作：预防性维护
技术债务
它来自于走捷径，那在短时间内也许行得通。但是就像金融债务一样，久而久之，利息成本会越滚越高。
运维的本质：帮助业务实现成功
和COO对话
了解运维到底在如何支撑业务
和业务负责人对话
销售负责人罗恩
凤凰发起人玛姬
运维与业务的融合
运维与公司业务目标达成一致
区分关键业务及对应的业务系统
主要风险及改进措施
反常识
系统要经常出些故障
保持弹性
人力资源使用率与效率成反比
每个人都需要空闲时间
如果大家都没有松弛时间，半成品就会卡在系统里。或者更确切地说，卡在队列里，只是干等着。
削减非必要人工环节、管理交接工作是提高资源周转率的关键
等待时间取决于资源使用率
重新定位安全与审计
只有三种内部控制目标
确保财务报告的可靠性
符合法律法规
运营的效率和效果
将安全审计置于开发构建过程之中
4.危机解除，获得新生
概述
在这个阶段，比尔带领研发团队、运维团队、测试团队和业务团队一起快速交付了独角兽项目。为公司实现了盈利，赢得了竞争。
价值流图：从代码提交，到上线运营的全流程
开发环境
集成环境
测试环境
预发布环境
生产环境
持续改进，让团队形成持续的竞争力
三步工作法
1.构建快速工作流
从开发到技术运营，再到客户的整个自左向右的工作流
为了使流量最大化，我们需要小的批量规模和工作间隔
不断为了整体目标（相对于开发功能完成率、测试发现/修复比例或运维有效性等局部目标）进行优化
实践：持续构建、持续集成、持续部署，按需创建环境、限制半成品，构建起能够顺利变更的安全系统和组织。
2.持续反馈流
如何缩短及放大反馈环路，从而在源头上解决质量问题，避免返工
关于价值流各阶段自右向左的快速持续反馈流
像电力一样无处不在
具体实践
在部署管道中的构建和测试失败时“停止生产线”
日复一日持续的改进日常工作
创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态
在开发和技术运营之间建立共同的目标和共同的解决问题的机制
建立普遍的产品遥测技术，让每个人都能知道，产品和环境是否在按设定的运行，以及是否达到了客户的目标
3.建立文化
既能鼓励探索，从失败中吸取教训，又能理解反复的实践是精通工作的先决条件
实践
营造一种勇于创新、敢于冒险（相对于畏惧和盲目服从命令）以及高度信任（相对于低信任度和命令控制）的文化
把至少20%的开发和技术运营周期划拨给非功能性需求，并且不断鼓励进行改进
四种工作类型-任务追踪
业务项目
由 PMO 跟踪的正式项目
IT内部项目
这些项目通常分散管理，没有集中跟踪，有具体预算所有者负责，DevOps需要对IT内部项目进行管理
变更
变更一般是由业务项目和IT内部项目这两种工作类型引起，一般会在问题跟踪系统中进行管理，在价值流的两个部分，开发和运维中分别管理变更会引起工作交接的问题
计划外工作（救火工作）
0 条评论
下一页
为你推荐
查看更多
