mod

极客时间专栏/DevOps实战笔记/转型案例篇/29 | 向前一步：万人规模企业的DevOps实战转型案例（上）.md

@@ -0,0 +1,178 @@
+<audio id="audio" title="29 | 向前一步：万人规模企业的DevOps实战转型案例（上）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1c/51/1c5bb812429cbde1fe16e6f49f0d8551.mp3"></audio>
+
+你好，我是石雪峰。
+
+“向前一步”这个名字，来源于Facebook的首席运营官谢丽尔·桑德伯格的一本书《向前一步：女性，工作及领导意志》。她在书中鼓励女性在职场中向前一步，勇于面对挑战，追求自己的人生目标。
+
+我之所以选择用这个名字作为案例的标题，是因为在企业中，DevOps转型并不是一件容易的事情，我们也需要有勇气向前迈出一小步，去承担这个使命。哪怕只是改变了一个小问题，也是转型过程中不可忽视的力量源泉。
+
+在专栏最后的案例环节，我会用两讲给你介绍下微软这些年的DevOps转型故事，以及我在国内企业中的实践总结和经验。
+
+今天，我们先从**管理实践**和**文化层面**入手，来看看这家传统的软件巨头是如何在经历了移动互联网时代的迷失之后，在容器云和AI时代再一次独占鳌头的。
+
+微软的DevOps转型并不是一个突然的决定，**随着云服务的兴起，用户需求激增，对发布节奏的要求越来越高**。这些通过**需求的数量**就能体现出来。2016年的用户需求数量比过去4年的总量还要多，到了2017年，需求数量达到了2016年的2倍，这就要求团队能够以更快的速度完成交付。
+
+要知道，如果你期望的优化水平是提升10%的交付能力，那在原有的组织架构、流程规则下做局部优化就有可能实现。但是，如果要达到200%的优化效果，就需要做出巨大的改变了。
+
+## 建立面向交付的特性团队
+
+微软之前的组织架构跟很多公司一样，也是按照职能划分的，比如分为项目管理团队、开发团队、测试团队和运维团队。每个团队都比较封闭，部门墙的问题非常严重，给团队内部的协作效率造成了很大的影响。
+
+<img src="https://static001.geekbang.org/resource/image/32/68/326fa5282fc147f5d1ab5f8a90431868.png" alt="">
+
+为了应对需求交付的压力，微软首先进行了一次组织架构调整，**将开发团队和测试团队整合为工程团队**。于是，测试的职能在团队中消失了，转而变成了面向开发的开发工程师和面向测试的开发工程师，他们和产品管理团队一起完成项目的敏捷推进。在敏捷的理念中，测试活动应该内嵌于开发环节之中，通过把两个部门整合起来，就完成了测试注入研发的工作。
+
+<img src="https://static001.geekbang.org/resource/image/63/bc/630746e8acd92ec3ab7a83306e3493bc.png" alt="">
+
+虽然开发和测试团队融合到了一起，但是交付工作依然依赖于独立的运维团队来完成，这就造成了一个问题：**即便开发效率再高，如果运维能力跟不上，那也是没有意义的**。
+
+于是，微软开启了第二次组织变革，这一次的核心是**构建特性交付团队，并赋予团队自治的能力**。
+
+所谓的特性交付团队，就是我们常说的“全功能团队”，实际上，这就是把横向的按照职能划分的组织变成垂直跨职能的组织。这个团队中包含了要完成功能交付的所有角色（比如产品、开发、测试和运维），可以闭环地完成整个交付工作。
+
+在这个过程中，微软引入了一种叫作**自组织团队**的形式。与传统的管理层自上而下安排组织的方式不同的是，员工可以自由地选择想要加入的特性团队。这种新的自由组队的方式为每个人都提供了学习新知识的机会。
+
+你可能觉得，这么搞的话，组织不是乱掉了？高手都希望跟高手在一起，那剩下的同学怎么办呢？其实，我在国内的一家公司也见过类似的玩法，他们解决这个问题的核心方法就是“**传帮带**”模式。
+
+比如，一个职能依赖某种特殊技能，但这种技能在团队内部非常稀缺，无论拥有这种特殊技能的这名成员去到哪个小队，剩下的组都会出问题。所以，这家公司就强制采用“老带新”的模式，也就是师傅对新人进行集中培训，给新人快速赋能。而且，这种“师徒关系”会长期存在，如果新人遇到什么问题，都可以请教师傅。当然，对于新人来说，也会有相应的考查机制。这种模式就有助于公司达成内部成员互相学习的目标。
+
+根据数据统计，虽然只有不到20%的员工选择了岗位变化，但是这种方式却给100%的员工提供了选择的可能性。对于一家官僚政治出名的公司来说，这就可以大大地调动员工的积极性。
+
+<img src="https://static001.geekbang.org/resource/image/30/2f/30ef61022920bbc0eaa6cc7bf28d292f.png" alt="">
+
+实际上，特性交付团队还有几个显著的特征：
+
+1. 拥有团队独立的办公空间，大家都坐在一起，在沟通时基本可以靠“吼”；
+1. 一般由10～12个团队成员组成；
+1. 具有明确的工作目标和职责；
+1. 为了保证稳定性，一旦组队成功，未来的12～18个月不再改变；
+1. 自己管控特性向生产环境部署；
+1. 团队自治。
+
+无独有偶，国内某大型公司在推进DevOps转型的初期，也做了类似的事情。为了加速研发和运维的融合，它们将一个大的应用运维团队拆分到了各个业务线里面。
+
+不仅如此，研发开始向全栈转型，承接运维工作，而运维自身的工作释放出去后，就要求团队进行能力升级。运维团队需要具备研发能力，来不断地开发和优化运维工具，以降低研发、运维的成本。
+
+这个过程说起来轻松，但实际在做的时候，就需要非常强的组织执行力，甚至还需要高层背书，自上而下地贯彻这样的要求。转型的过程对于每个人来说都是很痛苦的，但也只有经过这样剧烈的变革，才让DevOps转型成为了现实，而不仅仅只是说说而已，或者只是在几个小部门之间搞来搞去。
+
+我经常说一句话：“**想在不改变流程的前提下，实现企业的DevOps转型是不现实的**。”至于团队的组织架构是否要调整，还是由交付效率来决定的。
+
+转型初期的引入工具和推广阶段对组织的冲击力没有那么大，但是，当转型到达了“深水区”之后，**组织的变革**就成了一个非常现实的问题。
+
+根据“康威定律”，**一个团队交付的系统结构和他们的组织结构是相同的**。其实换个角度来说，软件交付的流程也是跟当前的组织结构保持一致的。只要有一个独立的测试团队，就总会有一个独立的测试阶段。而正是因为这样的一个个阶段，才带来了内部协作的部门墙和效率瓶颈，而这都是DevOps转型需要考虑的事情。
+
+## 自组织敏捷团队
+
+回到案例部分，为了促进特性交付团队的自治，微软在敏捷开发计划方面也进行了一定的调整。
+
+首先，按照不同的维度，他们分为四种计划。
+
+- 迭代维度：设定为3周一个迭代；
+- 计划维度：包含了3个迭代；
+- Season维度：6个月包含了两个计划周期；
+- Scenario维度：长达18个月的远景图。
+
+<img src="https://static001.geekbang.org/resource/image/f4/6d/f4f990e10213aa0be6202d6ac643ba6d.png" alt="">
+
+其中，管理层负责规划长期目标和全景图，也就是回答“我们要去哪里”的问题；而中短期目标，也就是迭代和计划，由自组织团队自行决定，这回答的就是“我们如何去到那里”的问题。
+
+交付节奏按照迭代来进行，每3周的迭代会有一部分价值产出。随着迭代的不断推进，再逐步更新、优化计划目标，并反馈给长期规划，进行互动和调整。也就是说，6～18个月的长期计划并不是一成不变的，团队会基于每个迭代和计划的交付增量以及用户的反馈进行调整，建立起一种“**计划 - 交付 - 学习**”的闭环路径，不断地校准产品目标和整体方向，保证长期规划的有效性，从而规避了原本瀑布模式下的在项目初期决定未来开发路径的潜在问题。
+
+毕竟，在这个快速变化的时代，谁也无法保证你的计划是一成不变、永远有效的。
+
+<img src="https://static001.geekbang.org/resource/image/cb/7d/cb84537437ba1cc7f62879a5019ea07d.png" alt="">
+
+现在，特性交付团队的迭代和计划是由自己来决定了，但是你别忘了，每个成功的项目都需要成百上千人的协作。那么，如何保证团队目标的一致性和互相的配合度呢？
+
+微软引入了三种实践方法，分别是**迭代邮件**、**团队交流**、**体验评审**。
+
+**1.迭代邮件**
+
+在每个迭代的开始和结束时，团队都会发出迭代计划和状态邮件。在邮件中，除了明确本次迭代的特性完成情况以及下个迭代的交付计划之外，为了帮助其他团队成员更好地了解这个迭代的功能，他们还将这些功能录制成视频附在邮件里。不仅如此，**待办事项的列表**和**看板状态**也都以链接的形式被附在了邮件中。
+
+<img src="https://static001.geekbang.org/resource/image/40/de/403b15202f5ba2181cc8c0c583ed0ade.png" alt="">
+
+**2.团队交流**
+
+在每次迭代完成的时候，团队成员都要问自己三个问题：
+
+- 下一步的待办事项中包含哪些内容？
+- 有哪些技术债务的累积和非功能特性？
+- 有哪些遗留问题？
+
+团队中的每个成员都要亲自完成这项任务，这不仅是为了减少信息传递的损失，更重要的是建立一种仪式感，帮助大家更加理性地安排迭代计划。毕竟，一旦把任务安排好了，就要按时完成。
+
+**3.体验评审**
+
+在分析需求之初，采用用户故事的形式，站在用户的角度，以场景化的方式来描述用户所处的现状，以及这个特性想要解决的问题。那么，不同团队的成员就可以站在用户的视角来实现这个功能。
+
+特别有意思的是，微软在管理特性的时候，**会尽量保持对原始用户需求的关联**。他们会在特性旁边附上原始的用户需求。
+
+很多时候，开发要处理的任务都是**被产品人员翻译过的用户需求**，而并非原始的用户需求，以至于在开发的时候，**我们并不知道要解决的核心问题是什么**。通过关联原始用户需求，每个人都能在开发、测试、交付的过程中，站在用户的视角来重新审视一下，我们交付的功能到底是不是用户想要的。
+
+这些环节的变化带来了一系列积极的影响。
+
+首先，团队成员的积极性大大提高。因为他们觉得自己是用户体验的首要负责人，他们有责任自己修复并解决用户的实际问题。
+
+其次，团队无需再等待领导的规划。在符合整体项目计划的前提下，他们可以自行制定计划。
+
+最后，计划的更新是由持续学习来驱动的。比如，团队会给用户经常使用的功能添加埋点，观察用户使用的数据情况，定期关注和解决用户反馈信息。
+
+**持续的增量交付和不断的反馈建议，也是现在保证产品需求有效性的最佳手段**。毕竟，业务敏捷是DevOps的源头，如果业务自己对需求都没有明确的衡量方法，那么即便拥有了最强的持续交付能力，也是跟“蒙眼狂奔”一样。所以，想要推进DevOps，**敏捷开发实践和需求价值分析**都是必不可少的要素。
+
+在微软，为了促进有效反馈，他们的**度量体系**也很好，非常值得一说。对于微软来说，**获取用户的真实行为数据至关重要**。他们在建设指标体系的时候，出发点大多落脚在**考量哪些指标对业务衡量有直接作用**上，而不是衡量团队的产出以及个人的产出。
+
+他们采用的指标包括以下几个方面：
+
+- **使用维度**：用户增长、用户满意度、特性交付情况等；
+- **效率维度**：构建时长、自测时长、部署时长等。
+- **在线站点健康度**：错误定位时长、用户影响时长、线上问题的遗留时长等。
+
+但是，某些国内流行的指标却并没有被纳入绩效考核，比如**完成时长**、**代码行数**、**缺陷数量**等。
+
+<img src="https://static001.geekbang.org/resource/image/0d/a2/0d845455a931027e8a974bcd5ab5b7a2.png" alt="">
+
+你可能会说，这也没什么特殊的啊，但是，你要知道，微软对于用户的关注不止如此。
+
+我给你举个具体的例子。一般情况下，我们在度量系统可用性的时候，都是面向系统整体的，比如保证整体可用性达到4个9，也就是在99.99%的情况下是可用的。但是，微软认为，系统可用性应该更进一步，**要以账号的维度来进行度量和统计**。
+
+当我们站在系统整体的视角时，很多个人用户的行为就被整体数据掩盖了，也就是我们常说的“被平均”了。但是，如果站在账号的视角，也就是每一个用户的视角来看待这个问题的时候，我们就会发现，用户是真真切切地遇到了一些问题。
+
+比如，某一个账号下服务不可用的情况出现频率比较高，那么，与其等着用户上网吐槽，倒不如提前跟用户取得联系，主动帮助他们解决问题。在联系用户的邮件中，不仅要清楚地描述团队观察到的客观情况，还要提供建议的解决方案。如果用户无法自主完成定位和修复，还可以通过邮件中的联系方式和团队取得联系，寻求进一步的帮助。
+
+微软对用户的关注不仅体现在系统可用性的度量方面，在特性开关方面也是如此。
+
+特性开关是一种比较常见的在运行时控制特性是否对外可见的技术手段。在微软的产品中，也大量地使用到了特性开关的技术，但他们的特性开关可以**细化到用户级别**，也就是可以将用户添加到或者移出列表中，从而控制每一个用户的可见特性。
+
+这样一来，如果某些新特性影响了特定用户的使用，就可以通过这种方式处理，无需部署，直接将特性下线。这不仅有助于问题的快速解决，还提供了一种更加精细化的实验机制。与灰度发布相比，基于特性的发布也更加灵活。
+
+## 团队转型从中型团队入手
+
+在转型团队的选择方面，微软的经历带给我们的启示是，**尽量避免从大型团队开始入手**。
+
+在DevOps转型的过程中，常见的思维方式是，先把企业内部最核心和最大的团队搞定。只要把最复杂的部分搞定了，其他中小团队的需求也就都可以满足了，他们会自然而然地跟上转型的节奏。
+
+但是事实上，这些大团队往往都有一些独特的流程以及特殊的需求，对系统工具和流程的定制化程度较高，实现起来也最复杂，甚至对他们来说，转型工作的优先级并不是最高的，总会因为这样那样的需求导致转型工作一拖再拖。这对于转型工作来说，并不是一件好事。
+
+所以，微软调整了他们的策略，采用了“middle-out”的方法，也就是**专注于中型团队**（40到100人）。这些团队由于资源不像大团队那样充足，对外有充分的需求。而且，这种规模的团队可以快速地评估现状，收集团队的必要信息，而不是猜测他们到底需要什么。
+
+通过持续细小的改进，帮助这样的团队做得更好，内部的传播让更多的团队主动联系他们并寻求帮助，从而建立了一个有效的持续改进循环。
+
+## 总结
+
+今天，我给你介绍了微软DevOps转型的上半部分内容。我们来简单总结一下。
+
+- 为了满足快速交付的需求，他们打破组织的原有架构，建立了面向特性交付的跨职能组织；
+- 通过团队自治，他们将计划分为短期目标和长期目标，短期目标（包括迭代和计划）都由特性团队来自主决定；
+- 在度量方面，他们更加关注业务指标的表现。而且，无论是在系统可用性方面，还是在特性开关方面，他们都细化到了具体的用户级别，以保证每个用户的使用体验；
+- 在选择转型团队方面，他们主动避开了最复杂的团队，而是从能够把握住的中型团队做起，积累成功经验，然后不断传播。
+
+最后，我再提一点自己的想法。这两年来，在DevOps领域，特性的出镜率越来越高。因为特性是更加符合DevOps快速交付原则的需求颗粒度。所以，业界的各大公司在基于特性的需求管理、基于特性的分支策略、基于特性的发布和价值追踪策略等层面，都有很多实践和思考。比如，今年CloudBees公司发布的SDM产品就是基于特性维度的。
+
+我相信，未来的DevOps也会朝着这个方向发展。打造一整套基于特性开发的研发模式，是一个值得我们花精力好好思考的点。
+
+## 思考题
+
+你认为，基于特性维度的开发和交付，有哪些流程、工具、规则是有效的呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，也欢迎你把文章分享给你的朋友。

极客时间专栏/DevOps实战笔记/转型案例篇/30 | 向前一步：万人规模企业的DevOps实战转型案例（下）.md

@@ -0,0 +1,182 @@
+<audio id="audio" title="30 | 向前一步：万人规模企业的DevOps实战转型案例（下）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/8d/94e4d81db1e00f8c9b4ddfa77265e88d.mp3"></audio>
+
+你好，我是石雪峰。今天，我们接着上一讲的内容，继续来聊一聊微软DevOps转型的故事。
+
+经常有人会问，企业的DevOps转型应该由哪个团队来负责，是否要组建一个全新的DevOps团队呢？带着这个问题，我们来看看微软是怎么做的。
+
+## 1ES
+
+微软有一个特殊的团队，叫作1ES。1ES是One Engineering System的缩写，直译过来就是“一套工程系统”的意思。从这个名字，相信你就可以看出来，**在微软内部，有一套统一的工程能力平台来支撑微软内部各种形态产品的研发交付工作**。没错！这个1ES团队包含了近200名工程师，作为组织级的研发效能团队，他们的目标就是**通过一整套通用的工程能力平台，来提升内部的研发交付效率**。
+
+1ES团队的工作职责可不仅仅是开发通用工具平台，他们还要负责公司的文化转型、最新的工程方法导入试验、研发过程改进、安全合规性检查、内部研发效率咨询以及在工程团队推广最佳实践等等，可以说是一个“全功能”的企业研发效能和生产力团队。截至2018年，数据显示，总共有近10万名用户在1ES提供的平台上协同办公。
+
+<img src="https://static001.geekbang.org/resource/image/41/b8/41d63ec1588a2655d75d7f55cb8ffab8.png" alt="">
+
+但国内的现状是，很多企业对于研发效能的关注才刚刚起步。即便有人员负责类似的事情，也大多分散在各个业务内部，难以形成合力。组建了企业级统一的研发效能团队，而且规模能够跟微软的1ES相提并论的企业，基本上一只手就可以数得过来，就更别提建立一套统一的工程能力平台了。我曾见过一家大型企业，他们内部的工具平台有1700多个，殊不知，这里面有多少的重复建设和资源浪费。
+
+那么，你以为微软的1ES团队天生就是这样“一统天下”的吗？还真不是这么回事。
+
+事实上，1ES团队的历史可以追溯到2014年。当时，微软新上任的CEO萨提亚·纳德拉非常重视研发能力建设，他致力于通过最好的工具来赋能研发团队。结果，微软的每个部门都会根据自己的实际情况采购自己习惯的工具平台，这就导致整个公司内部的工具、流程和成熟度差异巨大。差异化的工具和流程进一步增强了不同团队之间的共享和协作，内部人员转岗的成本极高，因为他们到了新团队以后，要从头开始适应一切。
+
+为了解决这个问题，1ES团队识别了三大领域：**工作计划管理**、**版本控制**和**构建能力**。他们先在企业内部识别哪些团队没有使用公司构建的统一工具，然后自顶向下强推。这背后的核心理念就是“Use what we ship to ship what we use”，也就是使用他们对外发布的工具来研发团队自己的工具。
+
+不知道你发现没有，这三个领域都是软件交付的主路径，**需求和任务管理、版本控制和构建系统无一不是核心系统**。当你想要建立一个统一的效能平台的时候，最重要的就是抓住主路径上的核心系统。
+
+关于“如何基于核心系统扩展一整套解决方案”，我给你推荐一篇GitHub的[博客](https://github.blog/2019-11-13-universe-day-one/)，你可以看看他们是如何思考这个问题的。
+
+在接下来的几年里面，1ES团队推动VSTS（也就是现在的Azure DevOps）成为了微软内部的工具平台标准，平台的用户也从最开始的几千个人增长到了后来的10万多人。
+
+正是从2010年开始至今150个迭代的千锤百炼，才造就了后来Azure DevOps产品的大放异彩。可以说，无论是从设计理念、功能，还是用户体验等方面，微软的Azure DevOps平台在当今业界都是首屈一指的。
+
+<img src="https://static001.geekbang.org/resource/image/dd/ba/dd0189b0de10caf513fdd018e7fadbba.png" alt="">
+
+## 持续交付
+
+持续交付是DevOps转型的核心部分，1ES提供的统一工程能力平台让这一切成为了可能。那么，微软的持续交付做到了什么程度呢？
+
+从2019年3月份的数据来看，他们每天部署82,000次、创建28,000个工作项，每个月有44万个提交请求、460万次构建和240万次的提交数量。
+
+无论把这些数据的哪一项拿出来，都是非常惊人的，这体现了微软卓越的工程能力水平。
+
+<img src="https://static001.geekbang.org/resource/image/8c/c2/8c67f5153f568acd746021bbe918ebc2.png" alt="">
+
+那么，微软是如何一步步走到今天的呢？我们先来看看DevOps中最重要的、也是“老大难”的测试部分，看看微软是如何实现在6分钟内完成6万个测试用例的。
+
+其实，早在2014年，微软在测试中遇到的问题跟大多数公司没什么两样：测试耗时太长、测试频繁失败、主线质量不可靠、迭代周期末端的质量远远达不到发布门槛。
+
+这些问题严重到什么程度呢？我给你列举几个数字，你就明白了。
+
+- 每天的自动化测试耗时22个小时；
+- 全功能自动化测试长达2天；
+- 仅有60%的P0级别用例可以执行成功；
+- 在过往的8年里面，甚至没有一次每日自动化测试是全部通过的。
+
+不仅如此，团队成员之间对单元测试存在着巨大的分歧：研发不愿意花时间写单元测试；团队不认为可以通过单元测试替代功能测试；甚至连用不用Mock，他们在理念上也存在着冲突。
+
+历史总是惊人的相似。在我之前的公司里面，研发总能找到各种理由苦口婆心地说服你他们不需要写单元测试，或者是，各种环境问题导致单元测试压根没法执行完成，因为引用了大量的外部服务。
+
+微软的解法是，**停止这种无意义的争论，为了达成预期目标前进**。他们**先从能达成共识的部分开始推进，并重新整理了内部的测试模型**，如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/bf/da/bf6f84d0c3ecf36719c7d287f667a3da.png" alt="">
+
+- L0级：这是没有外部依赖的单元测试。这部分在代码合并请求中执行，执行时长小于60ms；
+- L1级：这是存在外部依赖的单元测试，测试时间一般小于2秒，平均400ms左右；
+- L2级：是面向接口的功能测试，在预发环境执行；
+- L3级：也就是在生产环境下执行的线上测试。
+
+在明确了整体策略之后，团队开始对测试活动进行改造。整个改造过程可以划分为四个阶段：
+
+**阶段一：从L0/L1级测试入手**
+
+在这个阶段，尽可能地简化L0/L1级测试的执行成本，编写高质量的测试用例。
+
+根据我在企业里面推行单测的经验，抛开“到底应不应该写单测”这个事情不说，最大的争议点就是**分工**的问题。从做事的角度来说，包含几个方面：工具和框架选型、规则整理输出、工具平台开发、数据的度量和可视化建设。
+
+为了加快单测的推行，我建议，前期工具和框架选型，由自身的开发和测试工程师或者有经验的DevOps工程师一起完成，并在试点项目跑通。接下来，研发完成规则的梳理，包括单测的书写规则、工具环境配置规则等等，平台方面启动单测相关的能力建设，目的就是研发只需要写单测代码，具体的执行、数据分析、报告统计都交给平台完成。最后，在团队内部进行推广，并持续更新迭代规则和工具。在这个阶段，**尽量不要新增每日测试用例**。
+
+**阶段二：分析已有的每日测试用例**
+
+在这个阶段，重点要识别几个方面的内容：
+
+- 哪些测试用例已经过时，可以删掉？
+- 哪些测试用例可以转移到L0/L1级完成？
+- 哪些测试可以整合进SDK中专项进行（比如性能测试）？
+
+这一步骤的目的就是让每日测试用例集合尽可能地“瘦身”，加快执行速度。毕竟，每次跑几十个小时，一旦失败的话，就没有第二次机会了。
+
+**阶段三：将每日测试转化为L2级测试**
+
+接口测试是一种性价比相对更高的测试类型，所以，推进面向接口的自动化测试建设可以兼顾测试的执行效率和业务的覆盖情况。
+
+在这个阶段，我们需要完善接口自动化测试框架，提供代码、配置和多接口验证等多种测试类型。除此之外，要集中统一的管理系统的API，一方面进行API的治理，另一方面，加强研发和测试基于API的协作，把所有的变更版本线上化。一旦研发更新了API定义，测试可以在同一个地方更新他们的测试用例和Mock数据，从而实现基于API的在线协同工作。
+
+**阶段四：建设L3级测试**
+
+这就是在生产环境的线上测试，主要是通过监控机制来诊断系统的健康度。这部分内容我在[第17讲](https://time.geekbang.org/column/article/167353)中提到过，如果你不记得了，可以回去复习一下。
+
+随着L0/L1级测试的不断增多，这些测试都可以纳入到代码合并请求中自动执行。另外，L2级的API接口测试同样可以纳入到流水线中。
+
+通过40多个迭代的持续努力，以及考核机制的促进作用，整个测试的分布情况发生了明显的反转。
+
+你可以看到，每日测试的数量不断减少，L0级别的测试不断增多，到后来，L1/L2级的测试也相对稳定下来。你要知道，这40多个迭代可是花了将近3年的时间。如果以后谁再跟你说“3个月就能搞定单测”，你可千万别跟他聊天。
+
+<img src="https://static001.geekbang.org/resource/image/64/eb/6497a8b396e9b125b45934616a7f4beb.png" alt="">
+
+## 持续部署
+
+持续交付的终点是持续部署，那么，微软在部署层面又做了哪些事情呢？
+
+首先，微软不承认半自动化部署这个事情。其实很多时候，部署动作都不是一次性完成的。有些命令或者步骤并没有线上化，或者就是非高频的动作没有做到工具里面，还是需要通过手动复制一段命令的方式来实现。
+
+经常有人会问：“我们的大部分操作都实现了自动化，这算不算做得不错了呢？”我的回答也很简单：“对于一个没有基础或者非专业的人来说，他是否可以完成这项任务？”坦率地说，这有点“抬杠”的性质，但事实上，如果一个平台做完了，结果还是要依赖于指定人去操作，那你就得想想这个事情的意义和未来的价值了。
+
+之前我在做一个项目的时候，就遇到过类似的案例。为了解决配置变更的问题，团队成员实现了一个非常复杂的任务，但是在评审的时候，我们发现，这个任务并不能解决所有问题，到头来还是需要他手动入库操作。手动入库的成本其实还好，但是为了自动而自动，结果得不偿失，这就有点浪费时间和精力了。
+
+那么，**要想解决所有人都能部署的需求，要做的就是完全的自动化**。把所有的操作都内嵌于流水线之中，并且纳入版本控制，用于记录变更信息。使用同一套工具实现多环境部署，通过配置中心完成不同环境的配置下发。
+
+这样做的好处有很多，一方面，可以在不同的环境中完善部署工具的健壮性，避免由于部署方式或者工具的差异带来的潜在风险。另一方面，与生产环境的部署相比，测试环境的部署心理压力没有那么大。当大家都熟悉测试环境的部署过程之后，对生产环境的部署就是小菜一碟了。
+
+为了实现安全低风险的部署，微软引入了“部署环”的概念，你可以把部署环理解为**将部署活动拆分成了几个阶段**。每一次生产部署都需要经过五环验证过程，即便是配置变更，也是如此，不存在额外的紧急通道。这五个部署环分别是：
+
+1. 金丝雀（内部用户）
+1. 小批量外部用户
+1. 大批量外部用户
+1. 国际用户
+1. 其他所有用户
+
+通过渐进式的部署方式，每一个新的版本都缓慢地经过每一环的验证，并逐步放量，开放给所有用户。其中有几个点值得我们借鉴。
+
+**1.通过流水线打通CI/CD**
+
+我们可以这样理解CI/CD：
+
+- CI的目的是生成一个可以用于部署的包。这个包可以是war包、tar包、ear包，也可以是镜像，这**取决于系统的部署方式**。
+- CD的目的是将这个包部署到生产环境，并发布给用户。
+
+所以，CI和CD的结合点就在于**制品库**，通过流水线调度部署包在制品库中的流转，从而完成制品的晋级。我发现，很多大厂都是用部署前重新打包的方式，人为地将CI和CD的过程割裂开来，这并不是一种好的处理方式。
+
+**2.持续部署并不意味着全自动**
+
+我们都知道，持续部署能力是考查一个公司DevOps能力的最好指标（比如前面我提到的微软每天能够部署8万多次）。那么，这是不是说，每次变更都要经过自动化过程部署到生产环境呢？答案是不一定。
+
+你可以看一下这幅微软开发的全景图，其中，在CD过程中，每一环的部署都需要人工确认来完成，这背后的核心理念是控制“爆炸半径”。
+
+<img src="https://static001.geekbang.org/resource/image/cb/42/cb221e6fd8e2e06b9cd1850dbf7e0e42.jpeg" alt="">
+
+既然无法彻底阻止失败，那么是否能够控制影响范围呢？“部署环”的设计理念正是如此，为了做到这一点，**适当的人工管控还是很有必要的**。
+
+那么，如何确认部署是成功的呢？
+
+微软定义了非常详细的保障在线服务可用性的规则，其中最重要的就是，**明确线上服务状态永远处于第一优先级**。你可能觉得，本来不就应该是这样的吗？但是，在实际工作中，我们会发现，内部工具团队经常专注于实现新功能，而把线上的报警放在一边。
+
+要想解决这个问题，除了明确线上为先的理念之外，制定相应的规则也是很重要的。比如，微软的值班工程师叫作DRI（Designated Responsible Individual），也就是“指定责任人”。微软明确要求，每个在岗工程师必须在工作日5分钟内、休息日15分钟内响应问题，并把这纳入到了人员和团队的考核之中。另外，通过每周、每月的线上服务状态报告，以及每次事故的详尽故障分析，不断在内部强化线上为先的理念。
+
+## 总结
+
+在这个案例中，我给你介绍了微软在转型过程中的几个重点，包括自动化测试能力、统一工程平台和工程团队、分级持续部署、组织变革、团队自治和文化转变等。这些都是在实际的DevOps转型过程中，企业所面对的最为头疼的事情。微软的经历是否给你带来了一些启发呢？当然，想要做好DevOps，可绝对不只是做好这几点就够了的。
+
+对于DevOps的转型过程，微软的理念是：
+
+> 
+A journey of a thousand miles begins with a single sprint.
+
+
+这就是咱们常说的“千里之行，始于足下”。DevOps不是一种魔法，可以立即见效，而是每次变好一点点，每个人都在不断地思考“我能为DevOps建设做点什么”。这就像微软的自动化测试转型过程一样，你能看到整个趋势在不断变好，慢慢变成了现在这样，每次提交可以在10分钟左右完成近9万个自动化测试。
+
+微软一直在致力于推广DevOps，并且不断把自己的经验通过各种形式分享出来。仅仅从这一点上，我们就能看出微软的文化转变、向开放开源的转变。我再跟你分享一些微软DevOps转型的资料，你可以参考一下。
+
+> 
+资料1. [https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/](https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/)
+
+
+> 
+资料2. [https://azure.microsoft.com/en-us/solutions/devops/devops-at-microsoft/](https://azure.microsoft.com/en-us/solutions/devops/devops-at-microsoft/)
+
+
+你还记得我在[第6讲](https://time.geekbang.org/column/article/154695)中提到的DevOps转型的J型曲线吗？其实无论是DevOps转型，还是研发效率建设，都是一个长期、琐碎的过程。你要做的，就是树立自己的信心，做正确的事情，并期待美好的事情自然发生。
+
+## 思考题
+
+通过案例学习DevOps是一种特别好的方法，在案例中，你不仅能借鉴别人的经验，也能学习到系统背后的设计理念。那么，你有什么好的案例学习途径吗？可以分享一下吗？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，也欢迎你把文章分享给你的朋友。