我国最大的IT项目管理门户网站,国内IT项目管理培训与咨询服务提供商

当前位置:首页 > DevOps > 正文

微软开发团队的DevOps实践启示

2018-11-13 来源:高效开发运维 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:创意的兑现速度