张骥
中盛瑞达 系统架构师
13年企业级IT服务经验，前IBM LinuxONE售前工程师，曾经在神州数码、HP、Symantec（Veritas）、IBM、OneAPM工作，经历过数据库开发、DBA、运维、测试、售后、售前多个工作岗位，目前正在学习和实践DevOps，认定这是帮助传统企业的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管理的人才能成为合格的现代企业运营主管。
至此故事结束了。
当然最终的结局你懂的，一部分坏人变好人，冥顽不灵的坏蛋都死光光领便当，好人升官发财，回家陪老婆孩子过周末 。
在这个故事中有几点值得深思
DevOps 没有站在ITIL的对立面，相反，几乎所有的 DevOps 动作都是在ITIL框架内完成的。
DevOps 成功变革后，一个很自然的结果是IT可以随时应对来自紧迫的业务需求的挑战，最终结果导致了该公司公有云技术的应用。
本书的角色全部是公司中高层管理人员，显然 DevOps 革命需要自上而下发起，但是变革目标的实现，需要全员的理解和热情参与。
本书对于如何实现持续交付的细节没有展开描述，在全书最后给出了延伸读物列表，这是不是在说，具体用什么样的技术实现本身不是 DevOps 的重点，如何通过 DevOps 项目改变思路，实现优雅的管理才是最重要的。
DevOps 没有说基础架构必须由某一种特定的基础架构或者技术，例如x86 服务器和开源工具来实现，在本书的结尾提到甚至是古老的 Cobol 语言开发的系统同样可以在标准化的前提下成为 DevOps 策略的一部分。
在 DevOps 管理理念已经实现以后的剧情中提到主角提出一个倡议，回购一套已经外包出去的，之前被假定为对业务发展无影响的，运行在古老的大型主机系统上的业务系统，来确保能够实现按订单需求生产产品（工业4.0？）业务目标的达成。为什么我看到大型主机这么兴奋？
第三十六届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：content
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
