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

《凤凰项目》是一本小说体的DevOps书籍，它模仿了精益书籍《目标》的小说体风格。《凤凰项目》的故事思路围绕着DevOps三步工作法进行。这篇读书笔记介绍了DevOps三步工作法，并把凤凰项目的故事总结为15个场景。读书笔记分为上下篇，本篇为上篇。

DevOps三步工作法

第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，我们需要小的批量规模和工作间隔，决不让缺陷流向下游工作中心，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。

必要的做法包括持续构建，集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。

第二工作法是关于价值流各阶段自右向左的快速反馈流，放大其效益以确保防止问题再次发生，或者更快的发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。

必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；创建快速的自动化测试套装；开发和运维之前的频繁沟通；持续改进日常生活；

第三工作法时关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。

必要的做法包括营造一种勇于创新、敢于冒险以及高度信任的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。

凤凰项目background

无极限零部件公司是一家汽车零件生产制造企业，具有惊人的研发和制造能力。在过去30天内，股票暴跌19%，与其三年前的最高股价相比下跌了52%。这家公司不断被其劲敌——一家在预测并及时响应用户需求方面声名鹤起的公司击退。现在，无极限零部件公司在销售增长、库存周转率和盈利能力等方面完全处于弱势。

长久以来，公司一直许诺将通过整合零售和电子商务渠道的凤凰项目来恢复盈利能力。但是项目比预期拖延2年，超支1000万美元。

凤凰项目Scenario 1 - 新官上任

Roles：

公司CIO和IT运维副总裁被公司解聘。比尔是IT运维中型机团队的leader，因过去的良好表现被任命为IT运维副总裁。Scenario 1发生在接受任命的同时。

Event：

• 工资核算系统发生故障，员工领不到工资，工会介入，公司的公众形象受损。

• 安全部门因为应对PII（个人信息）存储的紧急审计问题，部署了一个标记化应用，损坏了数据库的SSN（社保卡）字段，但变更没有被登记，没有人知道发生了这个变更。发生故障的同时，公司SAN固件升级，工程师判断是SAN升级导致的故障，进行SAN回滚，导致更大面积的故障，更多数据库宕机。

Learning：

• 没有测试环境进行测试就部署在生产环境

• 没有变更登记

凤凰项目Scenario 2 - 故障频发

Event：

• 凤凰项目进展缓慢

• 开发批评运维没有准备好环境，平时也不参加开发的会议。

• 运维说2周前开发才给出一些技术参数，目前还没提供基础架构，没有产品和测试环境配置的具体参数。平时只提供一个网络文件夹作为部署输入。

• 关键人物布伦特因处理工资系统故障，延误了凤凰项目环境的准备。

Learning：

• 没有测试环境，没有变更登记

• 关键业务系统不断出现故障，修复的优先级高于凤凰项目。计划外工作不断中断高优先级工作。

凤凰项目Scenario 3 - 雪上加霜

Roles：

帕蒂：变更流程负责人

比尔：IT运维副总裁

Event：

• 电脑安全更新时导致蓝屏，比尔作为IT运维副总裁更换不到一台理想的电脑；

• 比尔参加CAB（变更管理会议），只有帕蒂一个人参加；

• SOX-404 IT审计发现重大缺陷：95条IT常规控制缺陷，16条重大缺陷，2条潜在重要缺陷；

• 大多数审计发现都需要布伦特的介入，已经聘请了同样资深的人员，但知识都在布伦特脑中，布伦特忙的没有时间对其他人进行培训；

• 只有业务项目清单，没有IT基础架构项目清单；

Learning：

• 大部分人力资源上都在凤凰项目上，更换电脑的流程混乱，效率底下；

• 变更管理流程和工具花了大量的咨询费，但因为过于复杂没有人愿意用；

• 业务人员私下找熟悉的人员执行变更，其他人都意识不到变更的存在；

• 每个人忙着处理手上的“高优先级”任务，事故和故障修复工作占用了员工75%的时间。

Action：

• 在现有清单的基础上，使用谈话的方式整理项目清单。

• 共整理出35个业务项目，70个运维项目，人均一个项目。

凤凰项目Scenario 4 - CAB会议

Roles：

帕蒂：变更流程负责人

比尔：IT运维副总裁

Event：

新的CAB会议上，运维人员指出变更管理系统过于复杂，过多的字段设置，大量的输入以及不合理的设计造成的无法使用。同时批准的速度太慢。

Action：

• 引入变更看板，在日程表中加入变更索引卡片，包含3个信息：变更计划制定者，变更实施目标系统，一句话变更概述。

• 收集下周内要实施的变更；

• 定义变更：对应用程序、数据库、操作系统、网络或者硬件进行物理、逻辑或虚拟操作，这样的操作坑能对相关服务产生影响。

Result：

• 收集到400+变更，要在一周年实施完毕。

• 定义审批流程：

• 高风险：列出十大脆弱的应用、基础架构和服务，相关的变更必须审批；

• 中度风险：无须审批，但变更提交者有责任向可能受影响的人员进行咨询并得到认可，审核后安排变更热日程，如标记化应用。

• 低风险：标准变更，只需登记，无须审批。

凤凰项目Scenario 5 -上帝降临

Roles：

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

比尔：IT运维副总裁

Event：

埃瑞克带比尔参观无极限零件公司的一家工厂的MRP-8车间。介绍这家工厂原来的情况是这样的：

任务发布台的工作人员按照先进先出的原则发布任务，从不考虑其它工作中心的工作负载和效率。几十年来，工厂里堆满了半成品，库存堆积，工作从未按时完成。

Learning：

• 应该按照瓶颈资源的工作速度安排工作。瓶颈之外的任何改进都是假象。

• 埃瑞克给比尔提供了一些建议：

  作为IT运维副总裁，你的工作是确保形成一条迅速，可预测，持续不断的计划内工作流，从而向业务部门交付工作价值，同时降低计划外工作的影响和破坏。

Homework：

• 搞清楚在运维中心里，等同于任务发布台的角色是什么？

• 找出运维中心四种类型的工作是什么？

凤凰项目Scenario 6 – 失控变更

Roles：

布伦特：运维技术大牛

比尔：IT运维副总裁

帕蒂：变更流程负责人

Event：

• 1级严重事故：信用卡处理系统故障

• 故障讨论会议中，大家彼此推卸责任，互相指责。事故在讨论会议期间被布伦特快速解决，因布伦特意识到是之前的一个操作造成故障发生，快速回滚。

Action：

• 比尔要求帕蒂在开会前整理出变更时间线，对可能造成故障的变更进行讨论，找出问题；

• 禁止在找出造成故障的原因之前，尝试解决问题，避免造成更严重的问题；

• 举行两周一次事故处理演练；

凤凰项目Scenario 7 – 保卫布伦特

Roles：

布伦特：运维技术大牛

比尔：IT运维副总裁

Event：

业务部门再次投诉布伦特没有按时完成凤凰项目的任务。比尔到布伦特座位附近观察布伦特的工作，发现布伦特的工作总是不断的被打断。虽然凤凰的优先级最高，但是因为只有布伦特了解关键系统，业务领导威逼利诱，导致他无法聚焦凤凰。

Action：

建立三级人力资源库用来解决问题，让布伦特的电话静音，只有三级人力资源库可以接触布伦特，记录学习到的知识，同样的问题不允许布伦特出手第二次。

以上是《凤凰项目》读书笔记的上篇，下篇包含后续的8个场景。

本文转载自公众号「DevOps」

END

更多相关文章阅读

无服务器化的微服务持续交付

基于DevOps、微服务以及k8s的高可用架构探索与实现

From Agile To DevOps - 微软开发部门 DevOps 经验谈

持续集成和几种工作流

华为专家 | 轻量化微服务测试实践

一个理论，三个原则，多个步骤 | 阿里游戏异地多活设计之道

来自Facebook的大规模持续交付实践

性能哥 | 腾讯的专项测试之道

2017年11月17日-18日

GOPS2017.上海站，DevOps 道法术器专场

乐神，赵班长，许颖维，廖君仪四位大神 等着你......

独乐乐不如众乐乐，DevOps 时代社区长期欢迎原创作者投稿，DevOps 时代社区愿陪伴您共同成长。投稿邮箱：liuce@greatops.net

点击阅读原文关注GOPS2017.上海站活动官网