作者：北京老李：EXIN授权EXIN DevOps Master（大师级）讲师(首批全国十名) 、EXIN授权EXIN Agile Scrum 、Product  Owner、Lean IT 认证讲师、PMI-ACP、首批ITIL Expert讲师、PMP、Prince2专家级、EXIN云安全管理、EXIN 云服务管理、ISO20000 LA、ISO27001 LA等多项认证。先后在北京、上海、广州等地主导软件开发、系统集成、咨询服务等工作，主要研究方向云安全管理、DevOps落地实施。

1.DevOps与企业变革的经典理论

北京老李：“Just do it....do what can be done, is much better than waiting all the time, from what we can't do to what we can do”。

DevOps经常通过敏捷开发、自动化和持续交付进行来实现，通过敏捷1.0的方法整合，实现DevOps，DevOps理论落地需要理论、流程、技术、工具多个方面，才可以实现企业转型。DevOps不仅仅简单的教练技术与教练方法，DevOps Master课程培养的是数字化转型必须的人才。

根据波士顿咨询过去10年调研,85％的企业进行过一项或多项转型行动.2013中国企业转型升级调查报告显示,67.8％的企业有过转型的经历.然而,尽管频频进行转型活动,但大部分企业尚未从转型中真正受益,只有24％的企业在自身的行业中通过转型获得了压倒竞争对手的长期或短期优势. 如果把企业视同一座冰山,企业转型如同改造冰山,我们发现如果只移动冰山的顶部,冰山最大的部分即冰山下面的根基并没有移动,也就是说人的因素被忽略了,转型必然失败.21世纪最需要的是人才。企业变革转型不仅仅要了解DevOps Master内容，也需要了解领导变革的方法。领导变革的黄金八步法是全球领导力大师、领导与变革约翰p．科 特在1996年开创性著作《领导变革》中总结的内容，科特教授提出的领导变革的黄金八步法已经成为和全球化组织实施变革的基础。

科特领导变革的黄金八步法

步骤一，增强紧迫感：任何一场变革必须是公司的高层领导来提出，让相关人员心中有一种紧迫感，这个相关人员并不是几个人，而是公司的多数员工，必须让大家在变革中有一种紧迫感，有一种压力感，这时候大家感到了变革的重要性，并表示愿意为此采取行动。

1.1DevOps变革，人才入手：敏捷2.0DevOps变更一定是自上而下的变革，IT的紧迫感来自于业务的压力、市场的竞争、网络安全法监管、等保2.0的要求、行业的新标准（指引），让企业了解更多的市场生态变化、行业敏捷应用，可以帮助企业实现增强紧迫感.通过敏捷转型，打造敏捷2.0人才体系。

敏捷转型：打造敏捷2.0人才体系

步骤二：建立指导团队。当有了变革的紧迫感之后，成功的变革领导者就会召集一些具有技能的、分析的、专业的这些人员共同构成一个指导团队，这就是我们讲的变革工作组、变革领导小组，这个指导团队有非常强的责任感，能够获得大家的信任来去推动这项工作。

1.2DevOps变革一：建立敏捷转型团队，敏捷2.0DevOps变更需要企业建立敏捷转型办公室或敏捷转型团队，实现DevOps推进有人推，有人管，把DevOps最佳实践的原则变为企业的制度与流程，实现DevOps从无到有的阶段性成果。

敏捷2.0转型团队建立：DevOps团队

步骤三：确定变革愿景。这时候指导团队就会对自己的组织变革提出合理的、明确的、振奋人心的愿景和相关战略，让大家共同看到我们的愿景、方向是什么？

1.3DevOps变革二：确定业务愿景，《Effective DevOps》书中指出如果组织长期存在的“DevOps团队”，并且他们始终存在，那么这与“把它扔到墙上”有什么不同呢?它只是it和工程之间的中介团队（DevOps实现模式的第四种模式）它并不是一个真正好的长期策略。但是，它可以帮助组织克服最初的变革，从而实现DevOps的愿景，即实现AWS的“You build it and then run it”。

创建DevOps团队存在的理由通常是非常积极的，只是实现没有像DevOps运动的愿景那样完善。可以做为一种短期策略，你需要有一个长期的策略。平衡好独立的DevOps团队与独立的敏捷变革组织存在的价值。

独立的敏捷变革组织：以业务为驱动的DevOps愿景

步骤四：有效沟通愿景。这个步骤就是将愿景和战略传达给相关的所有人员，并且能够通过一个信息渠道传达给我们更多的员工，让大家达成一种共识，形成一种责任感，并且释放组织中更多人的能量，让大家一起参与其中共同看到愿景的一种召唤力。

1.4DevOps变革三：沟通先行，DevOps的文化之一就是沟通。所有成功的DevOps实现的核心都是认识到糟糕的沟通会导致摩擦与阻碍变革。摩擦将导致瓶颈和管理不善。所有这些都减缓了开发和部署过程，使我们更难完成自动化与智能化的任务。通过DevOps改善沟通，可以提高组织内部流程改进。最好的开始方式是建立统一的DevOps变革的意愿并进行沟通，然后继续前进。

DevOps的文化之一就是沟通

步骤五：授权行动。这时候领导者应该授权我们的变革指导团队来开展行动，变革指导团队要获得权利，他们在推动过程中能够勇往直前地把工作推向前进。

1.5DevOps变革：授权行动，每个敏捷转型组织都必须遵循的DevOps核心文化、思想、方法和度量。这有助于组织形成一个关于DevOps的共识、愿景思维。不管组织中的小型或大型企业业务模型是什么，DevOps的优势在于，它能够铺设有效的部署流水线，然后是基础设施即代码进行组织转型支持。将业务思想转换为代码，增加了开发团队和操作团队之间的沟通和协作（DevOps模式一）

步骤六：创造短期成效。这指的是行动之后我们不要仅仅拘泥于很大很大的成效，其实一个组织非常需要在变革中取得短期的成效，快速受益。往往是很多大的项目由于时间拖得很长，会对整个组织团队造成一种质疑，就会对变革功亏一篑。所以要选择一些好的流程，挑选一些早期的项目、小的项目入手取得短期成效，团队会看到振奋人心的目标和方向。

1.6DevOps变革：速赢，快速向市场发布新产品或新功能对于全世界的组织来说都是一项具有挑战性的任务。最困难的工作是将所有不同的组(如开发、质量保证和IT操作)聚集在一起，以最快的方式完成工作，并尽快发布产品。为了克服这些挑战，进程和做法在不断演变。十年前就没有这样的词叫做DevOps企业界存在,但在2009年晚些时候,一个方法定义一组流程开发、进行协作和沟通质量保证,和IT运作显著减少产品上市时间,这通常被称为DevOps.

DevOps助力企业转型：快速向市场发布新产品或新功能

DevOps方法是一组实践，旨在通过有效的沟通和协作，结合持续集成过程和自动化部署，克服开发、QA和操作之间的差距。其目的是建立一个快速、可靠地开发、测试和发布软件产品的环境。将得到的最重要的好处是，它通过弥合负责任的团队之间的差距和遵循持续的开发过程，显著缩短了产品上市的时间。

步骤七：不要放松。它指的是在取得短期成效之后，我们的领导者和我们的变革指导团队千万不能放松，要积极的、继续的推动大家来前进和思考，同时也要防止大家犯急性子的毛病，要防止一蹴而就，不断地鼓舞团队继续寻找新的变革方向，把变革推向前进，直到最后胜利。

1.7DevOps变革：持续改进，《Kata》的改进最初来自于丰田的生产系统，是一个让你不断改进的过程。改进型的第一步，就是要了解方向。本质上，这个想法是你必须理解你想要进行项目的愿景和方向。然后，你需要分析你所处的位置，了解你目前的状况。

您需要建立下一个目标条件，然后计划、执行、检查并调整到该目标条件。例如，如果您的远景是没有缺陷，而您当前的条件是在每个版本中都有20个缺陷。然后，也许你会说，下一个版本我们将有十个缺陷。通过《Kata》与持续改进PDCA结合，不断改进变革成果，不要放松，就能见到阶段的成果。

步骤八：巩固变革成果。这指的是在变革最后落地的时候，我们其实已经逐步培养起来了一种新的企业文化，把变革成果固化下来，成为了人们的一种行为指南，每个人都有了新的一种价值观。同样我们也会通过新员工培训、通过案例传递让大家重新认识到价值观的重要性，最后变革的努力成果被固化下来。

1.7DevOps变革：巩固成果，DevOps之父Patrick说过DevOps核心是人的问题，也是领导力的问题。构建DevOps文化需要的不仅仅是给开发人员提供自动化或智能化技术手段。更需要影响到人、过程和技术的各个方面。然而，对于任何正在考虑或已经踏上成为DevOps忍者之路的企业来说，人员方面将会是最大的收获，也是最大的挑战。

2.DevOps变革五原则：

Patrick《团队的五种功能障碍》是一本杰出管理书籍，它总结了影响团队绩效的团队的五种功能障碍模型。这些总结可以与DevOps关联在一起。帮助企业 巩固成果。团队的五种功能障碍分别是克服团队协作障碍1：建立信任、克服团队协作障碍2：掌控冲突、克服团队协作障碍3：兑现承诺、克服团队协作障碍4：增强责任感、克服团队协作障碍5：关注结果。

Patrick《团队的五种功能障碍》

结合《凤凰项目》的总结，我们进行DevOps转型原则应以如下五个方面进行：

1. 以防止局部优化的方式对齐：让开发人员随时准备使用自己的软件，可以帮助ops从只处理所有问题的人员，转变为能够让软件运行的所有服务的专家。虽然会有痛苦和挫折，但这对于在你最宝贵的资源中建立信任是至关重要的。

2. 从一个有动力的小团队开始，并取得一些成功：我们已经看到，当组织试图采用DevOps原则时，有一种强烈的趋势，那就是试图把大海烧开。为了实现这种转变，你必须让改变事物的实验变得安全。甚至不要使用DevOps这个词，只要关注问题，并获得开始修改它的许可。

3.让你的老板成为冠军：不用说，为了建立信任，你必须确保你的老板能够解释你在做什么，为什么或者至少能够为你提供空中掩护。

4. 获得尽可能多的度量标准：指标不要巨多，应以业务为导向设计精益的指标管理，不要像KPI一样，要适应。

5. 庆祝你的成功：庆祝早期的胜利不仅对团队的士气很重要，而且庆祝你所带来的改变能让每个人花点时间来反思正在取得的进展。

3.案例：汇丰银行DevOps转型

一直在向“云第一世界”迈进，汇丰银行通过向CloudBees投资1000万美元(合780万英镑)。CloudBees是一家持续交付软件提供商，也是开源自动化服务器Jenkins的竞争者。自2015年以来，汇丰银行(HSBC)为了加强其软件交付系统，大量使用CloudBees软件。

2017年，汇丰(HSBC)首席信息官达里尔•韦斯特(Darryl West)在旧金山谷歌Next上登台，讨论了两家公司的合作。West指出，汇丰DevOps方面仍在继续扩展。公司开始招聘大数据DevOps工程师。这份工作位于金丝雀码头(Canary Wharf)，要求具备谷歌云或其他合适云供应商的经验，以及编程方面的Java、Scala和Spark技能，以及SQL、关系数据库和Elasticsearch专业知识。

汇丰共享服务(HSBC shared services)首席技术官迪内什•凯什瓦尼(Dinesh Keswani)表示:“我们投资于对我们业务具有战略重要性的技术，这些技术有助于我们更好地服务客户。”“随着我们这样的组织将自动化、智能和安全推进软件交付方式，DevOps市场正在快速增长。CloudBees已经是汇丰银行的战略商业伙伴;我们为自己的投资感到兴奋，也为有机会参与到持续交付的故事中来感到兴奋。”

4.推荐书

5.广告：敏捷1.0课程开课了：）

敏捷1.0课程开课了：）

欢迎爬楼，看更多北京老李-DevOps相关内容，ITIL内容请关注”豆列“

9.欢迎爬楼

DevOps Master课程：如何一次通过DevOps Master考试 https://www.douban.com/note/660291760/ 

DevOps Master课程：DevOps Master教练十二条原则 https://www.douban.com/note/718124778/

DevOps Master课程：DevOps Master教练的三个层次 https://www.douban.com/note/719145305/

DevOps Master课程：招聘DevOps工程师必问的12个问题（送DevOps实现的三个路径） 相关主题 https://www.douban.com/note/709308373/ DevOps Master ：

敏捷管理课程：如何一次通过EXIN Scrum Master  https://www.douban.com/note/722250431/ 

敏捷管理课程：如何一次通过EXIN Scrum Master https://www.douban.com/note/722250431/ 

敏捷管理课程：如何一次通过PMI-ACP  https://www.douban.com/note/720287998/

DevOps Master：如何一次通过DevOps Master考试 https://www.douban.com/note/660291760/ 

敏捷管理课程：如何一次通过PMI-ACP https://www.douban.com/note/720287998/

DevOps Master课程：事半功倍的系统化学习  https://www.douban.com/note/717180422/

https://www.douban.com/note/713613037/  DevOps professional课程：只讲技术之CHEF（1）

https://www.douban.com/note/708968150/ DevOps Master课程总结：知否知否，应是DevOps肥ITIL瘦（送ITIL4前生今世）

https://www.douban.com/note/708218842/  DevOps Master课程总结：学习没有捷径（送DevOps安灯正确方法）

https://www.douban.com/note/694641377/ DevOps Master凤凰项目沙盘总结：DevOps黄金三步法

https://www.douban.com/note/700603657/ DevOps Master凤凰项目沙盘总结：履霜坚冰至，转型应自强不息

https://www.douban.com/note/693053178/ DevOps Master凤凰项目沙盘总结：通过DevOps实现IT组织转型

https://www.douban.com/note/689504940/ DevOps Master凤凰项目沙盘总结：DevOps起始质量之独孤九剑

https://www.douban.com/note/645016138/ DevOps凤凰沙盘：一场精益敏捷探索之行

https://www.douban.com/note/629890513/DevOps凤凰沙盘：一场百玩不厌的质量感悟

https://www.douban.com/note/630638887/DevOps课后总结之DevOps游戏系列-DevOps的独孤九剑

https://www.douban.com/note/637665261/DevOps Master课程:回忆我与DevOps之父Patrick的交流

https://www.douban.com/note/647732431/ DevOps：10本DevOps推荐书及47个DevOps兼容工具

https://www.douban.com/note/647732431/ DevOps：10本DevOps推荐书及47个DevOps兼容工具

https://book.douban.com/review/9110485/ DevOps：转型从正确地认知开始

https://www.douban.com/note/651734552/ DevOps：从I型人才到E型人才

https://www.douban.com/note/651734953/ DevOps：智能服务台是企业不能缺少的基石

https://book.douban.com/review/8928323/ DevOps布道师:终身学习是终身成长的源动力

https://book.douban.com/review/8820627/ 《把读到的知识转化为能力三步法及完美学习的四步法》

https://www.douban.com/note/643862694/ DevOps Master课程:脚踏实地学Pre-Master，一步一个脚印成为DevOps Master

https://book.douban.com/review/8805640/ DevOps布道师为深度工作写的序：深度工作是心身的一种修练方法

https://book.douban.com/review/8795275/ 咨询基本功：咨询顾问基本功之书面沟通及“补充大餐”

https://www.douban.com/note/643251358/ DevOps定义编年史：通过DevOps定义看DevOps发展

https://www.douban.com/note/637838681/ DevOps应用：光大银行DevOps1.0到DevOps2.0研讨会

https://www.douban.com/note/639093367/ DevOps应用：民生银行IT一体化管理与自动化发展（1）

https://www.douban.com/note/638965340/ DevOps应用：工商银行DevOps进行时

https://www.douban.com/note/696842302/ DevOps应用：工商银行DevOps进行时（2018年）

https://www.douban.com/note/722820106/  DevOps Master课程：微软 DevOps的成功之路（送中行DevOps三架马车）

https://www.douban.com/note/641427886/ DevOps应用：DevSecOps云下安全与云等保（云博会内容提前曝光）

https://www.douban.com/note/646007197/ 敏捷辩论

https://www.douban.com/note/655617439/ 敏捷服务管理：数字化转型核心

https://www.douban.com/note/696148785/ DevOps Master课程总结：IT运维的昨天、今天、明天（IT运维四大“坑”）

DevOps Master:课程总结之变更与DevOps集成  https://www.douban.com/note/660466481/

艾利·高德拉特  “在瓶颈之外的任何地方作出的改进都是假象，在瓶颈之后作出任何改进都是徒劳的，而在瓶颈之前作出的任何改进则只会导致瓶颈处堆积更多的库存。”

【1】精益管理方法的术语

【2】高维度思考法

【附】高德拉特《目标》五个聚焦步骤：

第一步是确认约束点，直到确定那的确是整个部门层面的约束点，对非约束点的任何改进都只是幻觉，得不到实际任何价值；

第二步是利用约束点，寻找突破这些约束的办法，确保不让约束点浪费任何时间，永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项，一直都要这样；

第三步，使企业或部门的所有其它活动服从于第二步中提出的各种措施；

第四步，具体实施第二步中提出的措施，使第一步中找出的约束环节不再是整个部门的约束点；

第五步，回到步骤1，别让惰性成为约束，持续不断地改善；