作者：北京老李：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技术转型之路：DevOps敏捷2.0之路
1.1 微软为什么要改变：VUCA时代的蝴蝶效应
在过去，微软在Windows和Office等大型产品上取得了商业上的成功。测试标准提供了基于非常正式的质量度量的产品验收。这让微软有信心宣布一个产品已经准备好发布了。测试标准在测试技术和工具方面建立了深厚的专业知识。瀑布模型的好处之一是，当准备做一个产品收尾时，会让测试标准带来一个非常正式的收尾标准和质量方面的正式度量。
这真的有用吗?NO
微软开始也遇到了一些问题，但在某种程度上被产品的商业成功所掩盖。（北京老李：很多公司都是这样，以巨大的销售额，掩盖了管理与技术上的问题）到了2000年，微软这个问题爆发了。开发人员将代码扔向SDETs。SDETs将测试自动化抛给了STEs。维护也是非常昂贵。测试成为了一个瓶颈，导致了产品延迟，但是我们无能为力。
1.2 微软2000年第一次DevOps转型：打破传统瀑布
在2000年左右，微软进行了第一次转型：整个公司终于都意识到了这个问题以及这个问题的严重性。全公司做出了一个决定，取消STE角色（专职的软件测试工程师），让SDETs不仅负责开发测试，还负责运行和维护自动化（实现DevOps1.0的模式）。对微软来说，这是一个痛苦的转变。努力将STEs转移到其他角色，有些人做到了，但很多人没有做到。它改进了sdet的责任和激励机制，使sdet能够编写更好、更自动化的代码。但核心问题依然存在。sdet无法跟上扔到墙上的代码。
通过扩展发布周期中的验证阶段来进行补偿。对这个持续问题的另一个响应是引入一个称为MQ(质量里程碑)的概念。这是在一个新的发布周期开始时添加的一个特殊阶段，以赶上上一个发布中积累的所有测试债务。（DevOps是提到的技术债）
这个想法本意很好，但由于几个原因在实践中行不通。它创造了一段已知的时间来提高质量，这将导致人们推迟测试。由于有一个致力于质量的里程碑，它将解放团队，让他们从事随机的质量计划。MQ经常创建优先级倒置。它需要固定数量的人来处理质量问题，有时没有良好的优先级意识，或者错误的人来处理那些在大计划中只是低优先级的事情（北京老李：基于原有模型的改进是很难有有本质上的改变的）
1.3 微软2015年第二次DevOps：云中应用敏捷
随着云时代的到来，情况发生了戏剧性的变化。这给工程系统带来了新的压力，要求它走得越来越快。长期的稳定阶段已经过去。不通过Beta里程碑或dogfooding(在微软内部部署代码)来获得客户验证。必须要应用DevOps2.0.因为在DevOps2.0框架里微服务是独立且持续地部署的。服务需要保持高可用性，并且必须支持无停机部署。
DevOps Master课程：DevOps1.0与DevOps2.0对比图
对这些新挑战的最初反应是继续做我们知道怎么做的事情，但要更快。通过只运行受变更影响的测试，可以使现有的测试自动化运行得更快、更智能。最初的方法没有奏效。测试成为了一个主要的瓶颈。我们达到了一个临界点。从理论上讲，我们是以云的节奏运行的，但“火车”没有按时运行。在Azure DevOps中，有时我们会在sprint结束后花3周的时间来稳定和部署—有效地终止下一个sprint（北京老李：DevOps中应用敏捷的方法=Scrum、看板）
云中的质量怎么做？
微软重新定义了质量所有权，重新确定了责任。为了频繁地发布，Master分支必须始终保持与release分支一样健康。我们定义了一个核心原则——Master总是可交付的（北京老李：DevOps中重要的持续交付）。
这个原则涉及到一切——源代码管理、代码实践、构建等等。从测试的角度来看，微软推动了两件事:左移测试(即更加强调单元测试)和消除片状测试。换句话说，将测试向左推，将测试向右推，并在中间删除了大部分测试。这与过去的大多数测试都发生在实验室的中间集成风格测试中是不同的。（北京老李：DevOps中Effective DevOps的概念）。
2.微软的DevOps文化转型之路：全面DevOps化
伟大的公司来自于伟大的使命，而不是命令，全面DevOps化需要领导伟大的魄力与魅力。微软的使命是予力全球每一人、每一个组织、成就不凡。全面DevOps化本身就是一次不凡的文化转型之旅
转型的不凡之旅：伟大的公司来自于伟大的使命，而不是命令
2.1 现场服务文化：以客户为中心
现场文化比以往任何时候都更重要。现在，使用云计算和基于internet的服务，客户可以相当容易地跨服务提供商移动，这增强了您和客户之间信任的重要性。重要的是，您的现场网站总是可用的，并向您的客户承诺。把现场体验放在首位是一个成功平台的重要组成部分。您不能把所有的注意力都放在新的、闪亮的特性上，而忽略这些特性呈现给用户的方式。
全面DevOps化：微软新文化的建议
2.2 高效的DevOps文化：全面DevOps化
微软把EXIN DevOps Master教材《Effective DevOps》做为组织文化变更的首要指南。这是整个公司的一大文化转变。这种变化首先发生在一个组织中，但是几年之后，微软的每个团队都转向了这种模式（全面DevOps化）。这个模型有一些变化，但是目前微软没有单独的开发和测试团队。他们只是具有组合工程师角色的工程团队。
微软的文化转型之路：DevOps Master官方认证指定教材
https://www.douban.com/note/660291760/ DevOps Master：如何一次通过DevOps Master考试（指定教材说明）
2.3 组织全面转型：全面DevOps工程师化
微软做了“组合工程”——微软使用这个术语来表示将开发和测试的职责合并到一个单一的工程角色中。这不仅仅是将开发团队和测试团队放在一起的组织变更。它是一个实际的学科合并，具有单一的工程师角色，具有SDE和过去SDET学科的资格和职责。
每个人都有一个新的角色，每个人都需要学习新的技能。这是非常重要的一点。谈到组合工程时，一个常见的问题是如何培训以前的测试人员？必须双向训练。一名前开发人员必须学习如何成为一名优秀的测试人员，而一名前测试人员必须掌握良好的设计技能。管理人员必须学习如何管理端到端特性交付。
在这个模型中，测试不需要移交给其他人或团队。每个工程师都拥有他们构建的特性的E2E质量——从单元测试，到集成测试，到性能测试，到部署，到监视活动站点等等。与其他工程师的合作仍然受到重视，甚至更为重要。现在更加强调同行评审、设计评审、代码评审、测试评审等。但是交付高质量特性的责任并没有跨多个规程进行稀释。如何实现这种转变的?
要非常小心!
微软仔细地记录了测试团队所做的每件事，并重构（北京老李：经典重构2.0发布了）了所有这些活动在新世界中是如何完成的。我们特别关注测试“暗物质”——测试团队所做的事情，开发人员要么不知道存在，要么不知道如何去做。
组合工程的一个核心原则是消除从一个团队传递到另一个团队的任务。切换引入了延迟并削弱了责任。没有专门的中央团队来完成特定的任务。每个特性团队都有交付特性的端到端责任。
同时，我们也明白了专业技能的重要性。性能测试可以是一项专业技能。安全测试可以是一项专业技能。如何在组合工程模型中完成这样的专门任务?
通过组建虚拟团队(v-team)来实现这一点，每个特性团队的特定工程师被要求在正常的特性开发角色之外承担特殊的角色。换句话说，我们保留了一些任务所需的专门化，但是将这些工作从中心团队分配到功能团队中。微软创建了一个测试团队，并让一些最资深的工程师参与其中。负责构建新的测试框架，并通过组织支持变更。
微软创建了另一个v-team，其中包含质量原则(如安全性和可访问性)方面的主题专家。创建了高效的 v-team，该团队确定了产品中常见的性能瓶颈，并推动了更改。另一个v-team负责监控CI管道的健康状况，并推动快速行动。这些特殊v-team中的工程师共享专业知识，但是他们的职责与他们工作的功能团队保持一致。
更高的速度
从表面上看，似乎每个工程师现在所做的工作都是以前的两倍或更多，因此特性速度会减慢。但是由于开发团队和测试团队的合并，功能团队的总容量并没有改变。转向组合工程无疑需要增加对每个工程师的培训和新技能开发的投资，但这被减少交接和新的测试实践带来的效率收益所抵消。自实现此更改以来，我们已经看到了在特性速度方面的持续且相当显著的增长。
2.4 微软的DevOps改变：全面敏捷2.0-DevOps实现
微软的DevOps改变：全面敏捷2.0-DevOps实现
3.微软中国 DevOps Master培训
3.1 微软的EXIN DevOps Master培训
感谢微软，邀请中国最早一批中推广DevOps的布道师：北京老李。微软的DevOps改变，全面敏捷2.0-DevOps实现中提到：Everyone in Master，正是基于这样的全面DevOps的转变才有了微软中国 DevOps Master培训。
北京老李：首批DevOps Master布道师，全栈IT经理教练
风靡全球的DevOps Master中的《凤凰项目大型实践沙盘》
风靡全球的DevOps Master中的《凤凰项目大型实践沙盘》
3.1 DevOps Master带给微软专家的价值
1.理解了全面的并且是正确的DevOps体系，可以正确地“念经”，与全球正确思想一致；
2.认识到了软件转型依据的《Effective DevOps》的核心，可以更好地实现本企业及客户企业转型；
3.结合Azure DevOps可以体系化地售前DevOps工具链，可以更好地服务客户；
4.识别了正确地DevOps工程师及DevOps Master的区别，可以更好地指导项目落地；
3.2EXIN DevOps Master课程体系
3.3送：中国银行实现DevOps的三架马车
送：中国银行实现DevOps的三架马车
欢迎爬楼，看更多北京老李-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/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，别让惰性成为约束，持续不断地改善；