一个引发全球 IT从业者强烈共鸣的故事

作者介绍：

张骥
中盛瑞达 系统架构师

13年企业级IT服务经验，前IBM LinuxONE售前工程师，曾经在神州数码、HP、Symantec（Veritas）、IBM、OneAPM工作，经历过数据库开发、DBA、运维、测试、售后、售前多个工作岗位，目前正在学习和实践DevOps，认定这是帮助传统企业的IT向互联网+转型的最优选择。

《 凤凰项目 – 一个IT运维的传奇故事 》，一个关于IT，开发运维的故事，一本关于如何让你的职业生涯成功的非励志小说。

当我向身边的销售同事推荐这本小说的时候，他惊讶地说，你们搞技术的都出小说了！？这是个让我一想起来就会哈哈大笑的梗。

这本书不像英国喜剧《IT狂人》那样把IT人都描述成为可笑的nerd；也不像美剧《硅谷》那样把IT人都描述成为孤僻、恃才傲物、唯利是图的小丑；也没有像美剧《奔腾年代》中所描述的IBM销售帅哥和程序员美女。

这本书很认真的在讲述每一个做过开发、运维、管理的IT人自己的故事。

IT部门的主管、IT服务供应商、IT民工们，无论是身处互联网企业、独角兽公司、传统企业的IT人，还是卖硬件、软件、咨询顾问销售们，这本书值得花点时间，泡一壶功夫茶，慢慢看看。

故事梗概

某生产制造零售企业的IT高管们遇到了很大的麻烦，小说男一号是刚刚被提升为IT运维主管的比尔，出场基本处于蒙圈状态。但是，就像金庸小说中的男主角一样，他的命运值得期待。

狗血的是，他还有个扫地僧帮忙。

公司正在经受长时间无法盈利和市场竞争对手的压力，本应该马上根据市场需求上线的凤凰项目无法按时发布；同时重大事件频频发生，所有技术人员疲于奔命，无法完成既定任务；导致变更积压；ITIL 流程成为摆设；开发部门和运维部门互相指责；信息安全部门就像是在给每一个人添乱；零售运营主管摆弄权术上蹿下跳。

CEO 迫于公司市场发展压力，不顾IT技术部门的劝阻，坚持让新项目上线，最后这个凤凰项目成为了全公司层面的重大灾难。

这是每一家公司都有可能碰上的故事，商业公司内部IT部门的问题是否是缺人、缺钱、缺少先进技术、缺乏相互信任、勾心斗角权利争斗？

在小说里，这家公司的IT部门面临可能会被全面外包的惨淡境地，因为公司管理层已经对自己的IT部门失去了信心。

男一号受到扫地僧启发，将生产工厂车间的成熟管理思路和流程代入到IT管理思考中。与此同时，迫于共同的威胁，开发主管和运维主管在酒馆的一次谈心后，两人基情满满地互相理解和谅解了，剧情开始转折。

改变！改变！改变！

努力改善所有工作流程中最大的瓶颈是解决问题的第一步，在ITIL管理流程的框架下，利用看板工具，他们实现了工作流程和资源管理可视化。

改变管理规定，将重要的首席运维工程师资源从无休止的中断型计划外救火工作中解脱出来，合理使用，保障了最重要的项目进展。同时新的措施还保证了 ITIL 变更流程的严格执行，降低了重大事件的发生几率。

但是仅仅这样并不能解决全部的问题，很多变更虽然看起来简单，却需要投入大量准备和协调工作，需要管理部门跟踪所有流程才能完成。

改善行动的第二步是保证IT产品配置的一致性，基础架构不再是个别技术高手才能理解的内容，而是成为一种标准。同时，在 IT 部门内部人员工作交接上，尤其是开发和运维工作的交接上需要做到更为有序和平滑。

第三步的改善，此处剧情利用一个失意的信息安全主管的醒悟来推动，IT主管们向公司 CEO、COO、各个业务部门负责人询问他们的目标和最关心的事情是什么？

此刻，IT 开始真正将业务目标做为驱动力，在充分了解公司的业务发展愿景和阶段性目标之后，根据业务部门所需要的的 SLA 来做出前瞻性的IT管理 KPI ，类似运输公司车队需要定期保养维护才能保证业务的持续运转，这样的比喻为 IT 管理 KPI 的改善带来了灵感。

第四步终于来到最激动人心的地方，整个 IT 部门气氛前所未有的融洽，但是大家仍然面临一个共同的严重问题，一个业务需求从代码开发到最终上线的周期过长，长到公司的业务发展无法忍受的地步，不解决这个问题，IT 部门仍然无法跟上业务的发展节奏。

此时扫地僧提出，请所有IT部门的人尝试考虑改变目前新IT功能几个月发布一次的规律，看看能否改变为一天之内发布十次的频率。所有IT人最初都认为这是一个不可能完成的任务，但是在认真讨论之后大家发现并非不能尝试。结果就是任何的业务需求开发、测试、变更和发布都不再成为问题。

公司的业务发展一帆风顺，男一号也被列为公司 COO 的培养对象，该公司的管理层也认为，一个懂得IT管理的人才能成为合格的现代企业运营主管。

至此故事结束了。

当然最终的结局你懂的，一部分坏人变好人，冥顽不灵的坏蛋都死光光领便当，好人升官发财，回家陪老婆孩子过周末 。

Happy Ending！

上述剧情描述绝对有遗漏的地方，原书很精彩，不要被我的粗糙剧透所迷惑，去买书看吧。

在这个故事中有几点值得深思

1. DevOps 没有站在ITIL的对立面，相反，几乎所有的 DevOps 动作都是在ITIL框架内完成的。

2. DevOps 成功变革后，一个很自然的结果是IT可以随时应对来自紧迫的业务需求的挑战，最终结果导致了该公司公有云技术的应用。

3. 本书的角色全部是公司中高层管理人员，显然 DevOps 革命需要自上而下发起，但是变革目标的实现，需要全员的理解和热情参与。

4. 本书对于如何实现持续交付的细节没有展开描述，在全书最后给出了延伸读物列表，这是不是在说，具体用什么样的技术实现本身不是 DevOps 的重点，如何通过 DevOps 项目改变思路，实现优雅的管理才是最重要的。

5. DevOps 没有说基础架构必须由某一种特定的基础架构或者技术，例如x86 服务器和开源工具来实现，在本书的结尾提到甚至是古老的 Cobol 语言开发的系统同样可以在标准化的前提下成为 DevOps 策略的一部分。

在 DevOps 管理理念已经实现以后的剧情中提到主角提出一个倡议，回购一套已经外包出去的，之前被假定为对业务发展无影响的，运行在古老的大型主机系统上的业务系统，来确保能够实现按订单需求生产产品（工业4.0？）业务目标的达成。为什么我看到大型主机这么兴奋？

读后感

讲实话老外写的小说很难啃，细节和场景铺垫很多，但是看到书中主角开始解开一个又一个你可能在现实工作中也会遇到的问题，就会推动读者继续读下去。

剧中花费一些篇幅描述了男一号的生活和家庭，西方人的幸福的评估标准是陪伴家人一起度过愉快的周末，当然在 DevOps 真正实现之前这一切都是IT民工的奢望。

结语

在玩偶实验室 2012 年的“开发运维报告说明”中，为了更好地理解企业在采用开发运维各阶段的情况和习惯，我们用基准问题测试了 4039 家 IT 企业。

• 第一点出人意料的是，在敏捷性性指标（agility metric）和可靠性指标（reliability metric）方面，运用开发运维的高绩效公司远远胜过表现平平的同行：

• 代码部署频率快30倍

• 代码部署交付期快8000倍

• 变更成功率高2倍

• MTTR（ Mean Time To Repair，平均修复时间 ）快12倍

换言之，他们更为敏捷。他们的部署代码的频率快 30 倍，从“代码提交”到“成功投产运行”的速度快了 8000 倍。表现突出企业的交付期以分钟或小时计算，而表现较差企业的交付期以周、月甚至季度计算，如此发展，这些表现差的企业终究会被淘汰。

由《凤凰项目》的真实故事衍生出的“凤凰项目”沙盘演练作为 DevOps 的模拟实战，将在国内首家EXIN授权的高效运维 DevOps Master 培训班中重磅推出。

如何让一个几乎失败的项目死灰复燃？

如何挽救濒临拆分抛售的公司？

如何化腐朽为神奇？

让国内的小伙伴们在了解 DevOps 理论的同时也不失实战经验，感同身受的体验 DevOps 理念在工作中真实运作。

在当下
谁先懂得 DevOps
谁就先踏上了通往职业巅峰的捷径

参加 高效运维社区的 DevOps Master 培训，迈向职业巅峰的第一步

详情请看这篇文章：

《DevOps Master 认证培训：北上深近期轮番开班啦》

如果你对 DevOps Master 有更多疑问，快来 GOPS2016 · 北京站将为你揭秘更多 DevOps理念。

点击“ 阅读原文 ”报名 GOPS2016 · 北京站今日起购票将可在大会现场免费领取《凤凰项目》特别版