《凤凰项目》读书笔记（下篇）

查看原文

其他

《凤凰项目》读书笔记（下篇）

2017-10-21 李强 DevOps时代

《凤凰项目》这本书我读了三遍。第一遍感觉很过瘾，但是没记住什么；第二遍有所思，但头绪太多；第三遍干脆记笔记进行了梳理。

本篇是《凤凰项目》读书笔记下篇，上篇请见：

《凤凰项目》读书笔记 I

凤凰项目Scenario 8 – 提高瓶颈利用率

Roles：

布伦特：运维技术大牛

比尔：IT运维副总裁

Event：

60%的变更没有按时完成，大多因为依赖的资源不能到位，布伦特就是其中一项关键资源。
比尔意识到CAB就相当于车间的任务发布台，而布伦特就是瓶颈。

Action：

梳理变更，确定哪些需要布伦特参与，把需要布伦特的变更交给三级资源库。如必须布伦特处理，对变更进行优先级分类，在交给布伦特。

凤凰项目Scenario 9 – 凤凰部署惨败

Roles：

布伦特：运维技术大牛

比尔：IT运维副总裁

Event：

凤凰部署期间发生了一些状况：

无法在QA环境部署；
代码版本还在不断更新；
配置参数还不清晰，如防火墙端口；
数据库转换过慢，需要几天时间，POS系统无法正常使用，影响门店销售，市场形象受损；
凤凰上的订单经常多付费或者订单丢失；
董事会考虑外包整个IT部门
变更板让变更变得清晰，然而凤凰部署失败造成100%变更无法执行。

Learning：

了解四类工作是业务项目，IT运维项目，变更，计划外工作（救火）
识别约束点，利用约束点（不要让约束点等待其它资源），用约束点控制速度，设定工作节奏

Action:

派布伦特去参加开发会议，解决技术债务：稳定性、安全性、可扩展性、可维护性、可操作性、持续性

凤凰项目Scenario 10 – 矛盾激化

Roles：

帕蒂：变更流程负责人

比尔：IT运维副总裁

史蒂夫：CEO

Event：

发票系统故障，3天没有给客户提供发票，也无法完成检索，没有收到客户的钱，受影响金额约5000万美元。

Action:

帕蒂展示72小时变更时间线；
问题范围在不断缩小，调查有条不紊的开展；
CEO要求全员参与，立刻动手解决问题。比尔辞职。CEO要求的行动造成更多的系统出现故障；
CEO向比尔道歉。决定为其两周，除了凤凰项目外，冻结所有项目部署；
凤凰的进度明显加快；

凤凰项目Scenario 11 – 第一工作法

Roles：

埃瑞克：公司未来董事和最大投资人

比尔：IT运维副总裁

Event：

项目冻结期结束后，该如何解冻并避免造成混乱？埃瑞克又一次带比尔参观MRP-8车间。

Leaning：

就像工厂车间一样，运维部门也包含多个工作中心,每个工作中心包含机器（开展工作需要的工具）、人员、方法（标准化流程）和测评
太多的工作中心依赖布伦特，而布伦特同一时刻只能呆在同一工作中心
将布伦特的工作标准化，变成文档，让其他人能够执行，减少依赖布伦特的工作中心。
首先发布不需要布伦特的项目；
准备一个资源清单：需求类型以及所需工作中心和工艺的清单，再加上工作订单和你的资源，你就能够理解自己的生产能力，最终决定是否可以接受一个新工作。以服务器设置为例，它几乎是所有运维任务的活动中心。
管理好工作交接：等待时间=资源使用时间/空闲时间
改进形：以一个固定的周期，不间断的实施“计划-执行-审核-落实”。

Action:

拿出最常见的服务请求，明确写下操作步骤以及哪些人力资源可以执行这些步骤，并且测定每个操作所需的时间。
为标准服务请求建立看板，每一行分为三列：待办、在办、已办。
变更版用不同颜色标记变更，为冻结解除做好准备。紫色卡片代表五大最重要业务项目的变更，黄色代表其它业务项目变更，绿色代表内部IT改进项目，20%的时间专门用于这些项目。粉色代表被卡住的变更。
将项目进行分类，标记出哪些项目不需要依赖布伦特。

凤凰项目Scenario 12 – 第一工作法

Roles：

布伦特：运维部技术大牛

比尔：IT运维副总裁

柯尔斯顿：PMO

Event：

柯尔斯顿反馈说布伦特的QA环境准备工作延误。

Reason：

QA环境准备更像是一个小项目，工作超过二十个步骤，涉及至少六个团队，而这些团队的人都很忙碌，最终造成QA环境准备延误。

Learning：

管理好工作交接：等待时间=资源使用时间/空闲时间。如果每个人都过于忙碌，就造成过多等待，WIP增多，造成浪费。

Action:

收集20个最常见任务，将其标准化，建立看板，初期安排一个新角色，兼顾项目经理和稽查员，确保工作在每一个工作中心快速有效交接。

凤凰项目Scenario 13 – 系统思维

Roles：

比尔：IT运维副总裁迪克：CFO

玛姬：零售项目高级总监罗恩：销售副总裁

Event：

和CFO沟通，了解公司的近期目标和远期目标，KPI，理解企业的真实环境，美好的一天和糟糕的一天；

公司的目标包括：

了解用户需求和期望，正确的产品系列，销售预测准确率，上市时间，销售渠道等；
CFO并不清楚公司的目标和IT的关系；
和业务流程负责人罗恩沟通，了解业务流程如何支持公司的目标：
销售预测准确率很差，屈服于董事会的武断要求，过高的销售目标；
不知道客户究竟要什么，库存信息不透明；
CRM系统很难使用，销售很难拿到数据报告；
MRP，电话系统经常故障；
和玛姬沟通，了解到：
了解客户的需求和期望：理想情况下，销售数据会告诉我们客户究竟想要什么，订单系统和库存管理可以帮上忙，但数据总是不准确，需要依赖两个月第一的门店经理访谈，半年一次的核心用户访谈。期望每天收到销售和缺货报告。基于报告设计市场推广活动，发现客户认可的价格，推进生产计划，出产正确的产品，管理好库存，每客户订单额上升，平均订单金额也会上升。
产品应6个月内上市，否则创意被剽窃，同时锁定资本是没有回报的，CFO希望研发投入的平均回报为10%，否则不如炒股票。

Learning：

改善库存信息，了解客户的需求，增强销售预测准确率，最终提高销售额；
凤凰依旧不能解决上述问题；
把IT改进融入到业绩指标；

Action:

更大范围内同业务流程负责人进行讨论，定义由IT引发的业务风险，把风险融入到业绩指标；
启动独角兽项目，完成业务急需的特性；

凤凰项目Scenario 14 – 上帝再降临

Roles：

埃瑞克：公司未来董事和最大投资人

比尔：IT运维副总裁

Event：

再次参观MRP-8车间。埃瑞克要求要求运维要配合开发完成一天十个部署，保证敏捷开发的每个阶段都有可推出的代码，同时具备部署代码的环境。

Learning：

节拍时间，跟上用户需求所需的周期时间。为了跟上节拍时间，建立部署管道，那是从代码签入到投产的整个价值流，对所有的相关内容进行版本控制。不止是代码，而是创建环境所需的每一样东西，把整个环境的创建自动化，包括测试环境和生产环境。这样才能跟上开发的节奏。
把布伦特脑子里的知识自动化，这样他才不会一直是瓶颈。

Action:

整理从开发到运维的工作步骤，发现几乎在每一个步骤都曾经犯过严重的错误。
QA：开发环境下的自动化测试—>创建和开发吻合的QA环境—>部署代码—>运行所有测试—>部署至QA模拟环境—>负载测试—>交付运维
运维：获取代码包—>准备新的服务器实例—>安装配置操作系统—>数据库及应用—>防火墙—>负载均衡—>测试
估计每个步骤的工作时间，确定哪些工作步骤是需要等待的（WIP），确定工作中心，使整个价值流可视化。
建立通用构建过程，支持开发、QA和生产环境的自动生成。开发人员可以在类生产环境下编写代码，避免环境差异造成的悲剧，避免工作和开发、QA和运维之间前后传递，造成浪费。
布伦特加入团队冲刺，敏捷开发的每个阶段不仅要有可部署的代码，也要有确切的环境，代码和环境自动化（infrastructure ascode）都要进入版本控制。

凤凰项目Scenario 15 – 大结局

Roles：

比尔：IT运维副总裁

Event：

独角兽项目真正满足了业务部门的需求，业务部门基于拿到的数据进行了市场促销活动，取得了空前成功，为了应付爆表的市场反应，使用了云计算技术支持高峰期的访问。同时启动功能开关，关闭促销功能，确保已有交易可以正常完成。

比尔被任命为CIO，同时被公司送入一个“两年培养计划”的快车道，两年内，管理一家工厂，在销售和市场部门轮岗，为成为公司的COO做准备。

Learning：

IT要融入业务之中，每一个称职的COO都会是从IT部门出来的，任何尚未精通IT系统就负责管理公司运营的COO，就只是金玉其外的傀儡。