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