过去几年，微软的工程师团队已经接受了DevOps的工作方式，本文是一名微软总部的工程师为我们讲述微软在这个过程中积累的经验。

纵观整个软件产业，坦白地说，从我们一路的经验来看，DevOps的实践和方式对于服务和其它产品的交付起到了至关重要的作用。而且，据我们观察：在拥抱DevOps过程中，组织的变化和文化导向也是很有意义的。这导致了我们团队的组织结构变化，每个人职责的变化，以及开发、运维和业务文化的变化。

举例说明，在过去Windows、Office和其它的项目产品，都使用不同的工具和工程实施方法。但是现在，每天有43000位来自不同工程师团队的内部用户使用VSTS（Visual Studio Team Services），并且这个数量还在继续增长，我们非常希望VSTS能成为支持工程师团队实践的默认工具。

在本文中，我总结了微软工程师团队（尤其是云&企业团队和Bing团队）分享过的演讲以及内部讨论，希望有助于大家的DevOps实践。

团队组织

过去在工程师团队中有三个角色：项目经理，开发人员和测试人员，从组织和团队的角度来说，开发和测试是完全区分开的。并且，运维团队又是工程师团队之外的一组人。

我们希望减少开发人员和测试人员的交接时间，让他们专注于软件的质量，所以我们将传统的开发人员和测试人员合并为软件工程师。目前产品功能实现的所有方面都由软件工程师负责，他们还要保证在生产环境的稳定运行。这并不意味着测试被抛弃了，相反的是测试和软件质量成为了每个人的责任。

并且，为了交付最好的服务给用户，我们需要开发团队和运维团队在从设计到生产环境部署的整个周期中都可以紧密协作。于是，我们首先将运维团队不再独立、被合并到了工程师团队中，运维人员的心态和职责都发生了重大改变，出于这个原因我们称运维团队为服务工程师（service engineer）。

为了交付出最好的服务，我们必须将团队统一。写代码的人员和服务维护人员的高度耦合，让我们能够更快地交付功能到生产环境。因此最新的组织形式就像下图所示的样子，开发、测试和运维共同构成了工程师团队。

从那之后我们的团队按照功能划分，整个团队专注于同一个解决方案、功能或产品。从目前的员工岗位数目统计上来看，目前在工程师大部门共计有4307人，其中有436人属于售后服务团队，这些人需要负责共计35个功能团队。

每个功能团队由10-12个人组成，负责一个任务功能，并且自我管理项目进度，这个团队大概会保持12-18个月不发生变化。

下面是一个功能团队的组织图：一个项目经理，一个工程师leader，多个软件工程师和服务工程师，服务工程师隶属多个功能团队，但这些功能不会跨产品。

另一个有趣的变化是团队的座位，功能团队有其特有的办公区域。它自己的办公区域是一个开放办公区，大家可以随意坐和布置。因此，每个人都会也需要知晓这个区域内所有的工作对话。团队的办公区域还需要有会议和打电话的隔间，也就是说办公区域的规划需要开放办公区和传统的工作室相结合。

团队职责

但是以上所有行为最重要的目的是配合团队职责的变化，从而让软件工程师和服务工程师为用户提供最好的服务。而且，还有metrics功能被实现用来帮助评估进度，和鼓励正向的文化转变。比如，测试覆盖和用户SLA是团队共同的职责。

软件工程师的职责将不仅是构建和测试，还要保证最终的产品稳定运行。这种职责转变有两方面意义：第一，我们希望功能团队为了能解决遇到的问题，去试着理解用户；第二，我们需要功能团队和每个工程师对他们交付的产品拥有自主权。功能团队有权控制整个软件流程。

服务工程师们要知道应用架构是更有效率的问题解决方向，如果基础设施架构的改变，能让团队像IAC（infrastructure as code）或自动化脚本的方式开发和测试，对服务设计和管理都能有正向作用。自动化是微软在软件周期的各个方面中持续追求的关键主题，提高了向用户扩展和交付服务的效率。比如像测试，环境创建，发布管理这些原先是手工的操作都被自动化服务工程师为团队带来了无价的技能，尤其是动态部分和失败增多的时候。

下表展示了运维的功能及其职责的变化：

*代表这部分功能已经部分自动化了

**代表这部分功能已经大部分或全部自动化了

值得注意的是变更管理（Change Management）这个任务在运维和开发之间发生的转变，这是因为新服务和热修复是由一个对等的审核系统自动部署到生产环境的。自动测试、部署以及功能标记的引入，降低了风险。

这些变化已经被团队很好地吸收了。过去作为微软BizSpark项目的一员，我曾和很多非常有潜力的初创公司共事过。但是最近在和微软内部的功能团队交流的时候，从他们身上我感受到了和那些初创公司一样的驱动力和激情。

这些变化带来了以下好处：

·                     提高了成就感；

·                     功能团队愿意去理解用户；

·                     有了明确的界限来解耦服务；

·                     专注于自动化和遥测。

更多的信息可以看在Build 2016上的两个演讲：『Our DevOps Journey 』和『Our DevOps Journey 』。

部署

从像VSTS（Visual Studio Team Services）的托管服务，到OneDrive iOS版这种移动应用，微软团队已经意识到了canary发布（等同灰度发布，如下图）带来的好处。在VSTS团队中，canary发布被称为部署环。团队自动化了构建和测试过程，并自动部署到内部或早期的feedback账户或开发者的物理设备中（也叫dogfooding，即团队的内测）。这样能够控制软件的发布，并获得早期的反馈和实验。

VSTS团队采用了部署环的方式，服务的更新被分解为4个部署环（ring），分布在Microsoft Azure不同区域的12个可扩展单元里。（备注：部署环是一种灰度发布的概念，4个部署环是对不同用户的区分；可扩展单元就是一个完整的vsts实例，会被部署到对应的数据中心里）

部署是批量的，VSTS账户在第一个部署环的第一个部署单元中，在其它3个部署环将更新推送给全球其他11个用户扩展单元之前。第一个部署环中的发布需要经过功能团队leader的批准，后续的发布都是自动的。由于团队内部首先获取更新，他们会首先亲身测试：在工作时间，还有合适的工程师负责修正。如果有错误发生，他们希望能最先知道。

大多数被部署的代码，都带有功能标志，来进行另一个层面的发布控制。常言道，能自己编译的才是好的编译器。下图中每行都代表一天中热修复的一项条目。在VSTS的环境任务是按照逻辑分组的，可能有前后关系，这样并行或串行地执行任务，能保证VSTS团队部署环的正常运作。

如下图所示：155号版本的发布被成功发布到了4个部署环，同时相关的工作项也被部署到12个扩展单元中。

另一个例子是OneDrive移动团队。他们使用VSTS去自动化编译和测试iOS应用，然后VSTS会通过一个叫 HockeyApp的产品，自动推送这些编译到物理设备中。HockeyApp还能分析所有的冲突数据，这样开发团队的成员都能解决问题。他们使用HockeyApp发布更新到团队和内部使用者上。

在OneDrive团队用HockeyApp将发布扩展到开发者和内部用户之外后，这些发布会通过苹果的TestFlight给更多的beta用户，最终加上功能标志，发布到生产环境。一旦一个功能有了够多的正向反馈和测试，就会最终发布给所有的用户。

这样做带来的好处如下：

·                     可以得到早期的反馈，促进了实验；

·                     控制了发布流程；

·                     内部团队第一个测试，提高了代码质量；

·                     有助于减少解决问题的时间。

从用户中学习：直接反馈

有很多分析和遥测技术来支持用户的反馈环路，提高持续交付和假设驱动的工程。

但是我们发现，给用户提供简单和直接的反馈形式，比如在Microsoft Office应用中『tell us what you like』和『tell us what you don’t like』这样的弹出框，有助于形成一个社区，提高产品质量，拉近用户和开发团队的距离。毫无疑问，等待用户在tweet上发布应用或服务的问题，并不是收集直接用户反馈的最好机制。所以，Microsoft Office，Bing的主页和Azure Portal等几个产品上都有精心设计的feedback按钮，用户可以直接将反馈发送给功能团队，获得他们的技术支持。

以下是Microsoft Office应用上的反馈图标：

很多团队还实现了UserVoice功能，或者类似的反馈地点，对反馈进行收集和分组，这些会成为团队的待办项目。User Voice被用来提供建议和想法，而不是提交bug，以下是Visual Studio的UserVoice页面。

这里是一个移动应用的例子：OneDrive团队在应用的每个平台上都添加了『contac us』的反馈机制。为了高效地处理这些反馈，他们使用了一个叫做Parature的产品。控制台收集了用户数据，集中他们所有的反馈给团队去审核。

直接的用户反馈方式带来了以下好处：

·                     提高质量；

·                     有助于形成社区；

·                     功能团队可以更好地理解用户，并获得直接反馈；

·                     提高了用户满意度。

Idea Velocity：创意的兑现速度

最近Idea Velocity是微软团队都在关注的话题，Idea Velocity代表实验的速度，代表从一个不成熟的想法到这个功能对用户的影响分析。

个人雇员被鼓励产生新创意，实现它们，并尽快在生产环境中测试。这大部分发生在有成熟的持续交付流程的团队中，它们有稳定的自动测试基础设施，以及各个层面的遥测功能。最重要的指导原则是一个功能的创意来源是多样的。

在Bing团队，一旦他们的持续交付和大规模测试就绪后，他们就会集中精力到团队中每个人的亲身测试上。这样个人得到了授权，产品的决策真正出自于用户数据，创造力得到了鼓励。那种认为自动化测试是成功关键的说法是非常保守的。

我们将开发团队变为高效的创意漏斗，能尽快地迭代终端用户的想法，从而吸收进来尽可能多的创意。这影响到了团队中的每个人，也真正地拉近了开发者和用户的距离。可以通过一些活动做到这一点，比如增长黑客，孵化器，和Hack Day。

增长黑客是VP级别的，所以是影响组织方向的很好方式。比如，提高开发系统的效率或快速提高用户订单。

BingCubator 是一个IT运维管理社区，企业可以在其中找到值得投资的创意。这些创意在公开出来融资前，被一个专门的团队（v-team）管理着。
Hack Day则是模拟了工程师们典型的日常交互，但是让他们暂时放下平时的工作，做一些工作职责之外的事情。

在Bing团队，工程师们可以通过工具，在几分钟之内获得外部用户对他们想法的反馈。工程师们提交他们的mockup和问题，并选定目标受众。他们的实验就会被发送给上千位用户并获得反馈。微软有自己的众包平台，其中包括了几千个外部用户，这样通常2个小时内就能得到反馈，工程师们甚至不用写代码就能验证自己的想法。

你想知道自己关于Hack Day的一个想法怎么样？可以做一个快速的原型，形成一个调查问卷，推送给大家，并评估这个原型的可行性。这样开发者们可以获得实时反馈，从而理解他们的创意是否适合被扩展到生产环境中的终端用户。

一旦这个想法被证明了，就会通过持续交付的方式被发布。Idea Velocity的实现带来了以下好处：

·                     解耦了工程师和市场团队；

·                     支持早期的反馈和验证；

·                     保证了创意的来源是多样的；

·                     支持共享标准的文化；

·                     减少了HIPPO（Highest Paid Person Override）的决定；

·                     鼓励创造性；

·                     提高了持续交付，大规模测试和遥测的技术。

总结

这些变化帮助提高了编码效率、质量和产量，从而提高了产品的质量和用户的满意度，但最重要的是对开发者们的支持。我们将他们从繁琐的工作中解脱出来，鼓励了最佳的工程实践，从而形成了更好的工程师团队，他们在工作、生活的平衡上也更加得心应手。团队的高效意味着他们感到自己所做的无用功减少了，这带来的是他们工作各个方面的提高。

（Thiago Almeida原创）

过去几年，微软的工程师团队已经接受了DevOps的工作方式，本文是一名微软总部的工程师为我们讲述微软在这个过程中积累的经验。

纵观整个软件产业，坦白地说，从我们一路的经验来看，DevOps的实践和方式对于服务和其它产品的交付起到了至关重要的作用。而且，据我们观察：在拥抱DevOps过程中，组织的变化和文化导向也是很有意义的。这导致了我们团队的组织结构变化，每个人职责的变化，以及开发、运维和业务文化的变化。

举例说明，在过去Windows、Office和其它的项目产品，都使用不同的工具和工程实施方法。但是现在，每天有43000位来自不同工程师团队的内部用户使用VSTS（Visual Studio Team Services），并且这个数量还在继续增长，我们非常希望VSTS能成为支持工程师团队实践的默认工具。

在本文中，我总结了微软工程师团队（尤其是云&企业团队和Bing团队）分享过的演讲以及内部讨论，希望有助于大家的DevOps实践。

团队组织

过去在工程师团队中有三个角色：项目经理，开发人员和测试人员，从组织和团队的角度来说，开发和测试是完全区分开的。并且，运维团队又是工程师团队之外的一组人。

我们希望减少开发人员和测试人员的交接时间，让他们专注于软件的质量，所以我们将传统的开发人员和测试人员合并为软件工程师。目前产品功能实现的所有方面都由软件工程师负责，他们还要保证在生产环境的稳定运行。这并不意味着测试被抛弃了，相反的是测试和软件质量成为了每个人的责任。

并且，为了交付最好的服务给用户，我们需要开发团队和运维团队在从设计到生产环境部署的整个周期中都可以紧密协作。于是，我们首先将运维团队不再独立、被合并到了工程师团队中，运维人员的心态和职责都发生了重大改变，出于这个原因我们称运维团队为服务工程师（service engineer）。

为了交付出最好的服务，我们必须将团队统一。写代码的人员和服务维护人员的高度耦合，让我们能够更快地交付功能到生产环境。因此最新的组织形式就像下图所示的样子，开发、测试和运维共同构成了工程师团队。

从那之后我们的团队按照功能划分，整个团队专注于同一个解决方案、功能或产品。从目前的员工岗位数目统计上来看，目前在工程师大部门共计有4307人，其中有436人属于售后服务团队，这些人需要负责共计35个功能团队。

每个功能团队由10-12个人组成，负责一个任务功能，并且自我管理项目进度，这个团队大概会保持12-18个月不发生变化。

下面是一个功能团队的组织图：一个项目经理，一个工程师leader，多个软件工程师和服务工程师，服务工程师隶属多个功能团队，但这些功能不会跨产品。

另一个有趣的变化是团队的座位，功能团队有其特有的办公区域。它自己的办公区域是一个开放办公区，大家可以随意坐和布置。因此，每个人都会也需要知晓这个区域内所有的工作对话。团队的办公区域还需要有会议和打电话的隔间，也就是说办公区域的规划需要开放办公区和传统的工作室相结合。

团队职责

但是以上所有行为最重要的目的是配合团队职责的变化，从而让软件工程师和服务工程师为用户提供最好的服务。而且，还有metrics功能被实现用来帮助评估进度，和鼓励正向的文化转变。比如，测试覆盖和用户SLA是团队共同的职责。

软件工程师的职责将不仅是构建和测试，还要保证最终的产品稳定运行。这种职责转变有两方面意义：第一，我们希望功能团队为了能解决遇到的问题，去试着理解用户；第二，我们需要功能团队和每个工程师对他们交付的产品拥有自主权。功能团队有权控制整个软件流程。

服务工程师们要知道应用架构是更有效率的问题解决方向，如果基础设施架构的改变，能让团队像IAC（infrastructure as code）或自动化脚本的方式开发和测试，对服务设计和管理都能有正向作用。自动化是微软在软件周期的各个方面中持续追求的关键主题，提高了向用户扩展和交付服务的效率。比如像测试，环境创建，发布管理这些原先是手工的操作都被自动化服务工程师为团队带来了无价的技能，尤其是动态部分和失败增多的时候。

下表展示了运维的功能及其职责的变化：

*代表这部分功能已经部分自动化了

**代表这部分功能已经大部分或全部自动化了

值得注意的是变更管理（Change Management）这个任务在运维和开发之间发生的转变，这是因为新服务和热修复是由一个对等的审核系统自动部署到生产环境的。自动测试、部署以及功能标记的引入，降低了风险。

这些变化已经被团队很好地吸收了。过去作为微软BizSpark项目的一员，我曾和很多非常有潜力的初创公司共事过。但是最近在和微软内部的功能团队交流的时候，从他们身上我感受到了和那些初创公司一样的驱动力和激情。

这些变化带来了以下好处：

·                     提高了成就感；

·                     功能团队愿意去理解用户；

·                     有了明确的界限来解耦服务；

·                     专注于自动化和遥测。

更多的信息可以看在Build 2016上的两个演讲：『Our DevOps Journey 』和『Our DevOps Journey 』。

部署

从像VSTS（Visual Studio Team Services）的托管服务，到OneDrive iOS版这种移动应用，微软团队已经意识到了canary发布（等同灰度发布，如下图）带来的好处。在VSTS团队中，canary发布被称为部署环。团队自动化了构建和测试过程，并自动部署到内部或早期的feedback账户或开发者的物理设备中（也叫dogfooding，即团队的内测）。这样能够控制软件的发布，并获得早期的反馈和实验。

VSTS团队采用了部署环的方式，服务的更新被分解为4个部署环（ring），分布在Microsoft Azure不同区域的12个可扩展单元里。（备注：部署环是一种灰度发布的概念，4个部署环是对不同用户的区分；可扩展单元就是一个完整的vsts实例，会被部署到对应的数据中心里）

部署是批量的，VSTS账户在第一个部署环的第一个部署单元中，在其它3个部署环将更新推送给全球其他11个用户扩展单元之前。第一个部署环中的发布需要经过功能团队leader的批准，后续的发布都是自动的。由于团队内部首先获取更新，他们会首先亲身测试：在工作时间，还有合适的工程师负责修正。如果有错误发生，他们希望能最先知道。

大多数被部署的代码，都带有功能标志，来进行另一个层面的发布控制。常言道，能自己编译的才是好的编译器。下图中每行都代表一天中热修复的一项条目。在VSTS的环境任务是按照逻辑分组的，可能有前后关系，这样并行或串行地执行任务，能保证VSTS团队部署环的正常运作。

如下图所示：155号版本的发布被成功发布到了4个部署环，同时相关的工作项也被部署到12个扩展单元中。

另一个例子是OneDrive移动团队。他们使用VSTS去自动化编译和测试iOS应用，然后VSTS会通过一个叫 HockeyApp的产品，自动推送这些编译到物理设备中。HockeyApp还能分析所有的冲突数据，这样开发团队的成员都能解决问题。他们使用HockeyApp发布更新到团队和内部使用者上。

在OneDrive团队用HockeyApp将发布扩展到开发者和内部用户之外后，这些发布会通过苹果的TestFlight给更多的beta用户，最终加上功能标志，发布到生产环境。一旦一个功能有了够多的正向反馈和测试，就会最终发布给所有的用户。

这样做带来的好处如下：

·                     可以得到早期的反馈，促进了实验；

·                     控制了发布流程；

·                     内部团队第一个测试，提高了代码质量；

·                     有助于减少解决问题的时间。

从用户中学习：直接反馈

有很多分析和遥测技术来支持用户的反馈环路，提高持续交付和假设驱动的工程。

但是我们发现，给用户提供简单和直接的反馈形式，比如在Microsoft Office应用中『tell us what you like』和『tell us what you don’t like』这样的弹出框，有助于形成一个社区，提高产品质量，拉近用户和开发团队的距离。毫无疑问，等待用户在tweet上发布应用或服务的问题，并不是收集直接用户反馈的最好机制。所以，Microsoft Office，Bing的主页和Azure Portal等几个产品上都有精心设计的feedback按钮，用户可以直接将反馈发送给功能团队，获得他们的技术支持。

以下是Microsoft Office应用上的反馈图标：

很多团队还实现了UserVoice功能，或者类似的反馈地点，对反馈进行收集和分组，这些会成为团队的待办项目。User Voice被用来提供建议和想法，而不是提交bug，以下是Visual Studio的UserVoice页面。

这里是一个移动应用的例子：OneDrive团队在应用的每个平台上都添加了『contac us』的反馈机制。为了高效地处理这些反馈，他们使用了一个叫做Parature的产品。控制台收集了用户数据，集中他们所有的反馈给团队去审核。

直接的用户反馈方式带来了以下好处：

·                     提高质量；

·                     有助于形成社区；

·                     功能团队可以更好地理解用户，并获得直接反馈；

·                     提高了用户满意度。

Idea Velocity：创意的兑现速度

最近Idea Velocity是微软团队都在关注的话题，Idea Velocity代表实验的速度，代表从一个不成熟的想法到这个功能对用户的影响分析。

个人雇员被鼓励产生新创意，实现它们，并尽快在生产环境中测试。这大部分发生在有成熟的持续交付流程的团队中，它们有稳定的自动测试基础设施，以及各个层面的遥测功能。最重要的指导原则是一个功能的创意来源是多样的。

在Bing团队，一旦他们的持续交付和大规模测试就绪后，他们就会集中精力到团队中每个人的亲身测试上。这样个人得到了授权，产品的决策真正出自于用户数据，创造力得到了鼓励。那种认为自动化测试是成功关键的说法是非常保守的。

我们将开发团队变为高效的创意漏斗，能尽快地迭代终端用户的想法，从而吸收进来尽可能多的创意。这影响到了团队中的每个人，也真正地拉近了开发者和用户的距离。可以通过一些活动做到这一点，比如增长黑客，孵化器，和Hack Day。

增长黑客是VP级别的，所以是影响组织方向的很好方式。比如，提高开发系统的效率或快速提高用户订单。

BingCubator 是一个IT运维管理社区，企业可以在其中找到值得投资的创意。这些创意在公开出来融资前，被一个专门的团队（v-team）管理着。
Hack Day则是模拟了工程师们典型的日常交互，但是让他们暂时放下平时的工作，做一些工作职责之外的事情。

在Bing团队，工程师们可以通过工具，在几分钟之内获得外部用户对他们想法的反馈。工程师们提交他们的mockup和问题，并选定目标受众。他们的实验就会被发送给上千位用户并获得反馈。微软有自己的众包平台，其中包括了几千个外部用户，这样通常2个小时内就能得到反馈，工程师们甚至不用写代码就能验证自己的想法。

你想知道自己关于Hack Day的一个想法怎么样？可以做一个快速的原型，形成一个调查问卷，推送给大家，并评估这个原型的可行性。这样开发者们可以获得实时反馈，从而理解他们的创意是否适合被扩展到生产环境中的终端用户。

一旦这个想法被证明了，就会通过持续交付的方式被发布。Idea Velocity的实现带来了以下好处：

·                     解耦了工程师和市场团队；

·                     支持早期的反馈和验证；

·                     保证了创意的来源是多样的；

·                     支持共享标准的文化；

·                     减少了HIPPO（Highest Paid Person Override）的决定；

·                     鼓励创造性；

·                     提高了持续交付，大规模测试和遥测的技术。

总结

这些变化帮助提高了编码效率、质量和产量，从而提高了产品的质量和用户的满意度，但最重要的是对开发者们的支持。我们将他们从繁琐的工作中解脱出来，鼓励了最佳的工程实践，从而形成了更好的工程师团队，他们在工作、生活的平衡上也更加得心应手。团队的高效意味着他们感到自己所做的无用功减少了，这带来的是他们工作各个方面的提高。

（Thiago Almeida原创）