大规模开发团队如何实现大规模开发团队如何实现DevOps转型？转型？
微软全球开发平台工程团队从敏捷到DevOps的转型
2013年11月13日，我们宣布了Visual Studio2013，以及微软研发云Visual Studio Online (VSO) 的正式商用。紧接着我们经历
了一次长达七小时的服务中断。我们的服务运行在一个“弹性扩展单元”中，为大约一百万用户提供服务。当时恰逢峰值流量时
间段，欧洲和美国东西海岸的用户均已上线，在市场部门对外公布正式商用的同时，我们正在通过“功能开关”启用各种本被隐
藏的新功能。随后发现负责服务间通信的IP端口，这个重要的网络层组件未能如期生成我们需要的遥测数据。当时因为新功能
发布，已经产生了大量请求。从技术的角度来看，这造成了一个很尴尬的情况，如图1所示。当时的细节情况可以参阅这里。
[i]
图1：VS 2013的发布因为VS Online服务一系列尴尬的中断而面临窘境。
从市场的角度来看，本次发布活动无疑是一个巨大的成功。VS Online服务借助这一转折点，成功地实现了两位数的用户数月
增量。（增长的趋势还在继续，随后一年里，百万级别的用户数顺利翻倍。）
功能与后端保障之间的权衡
那段时间里，VSO只有一个托管在芝加哥数据中心内的弹性扩展单元。我们很清楚，需要通过多个单独部署的弹性扩展单元
进行横向扩展，但我们总是更重视与功能有关的工作，忽略了使用多个弹性扩展单元为网站提供更周全的保障这件事情。发布
会上遭遇的情况让我们改变了自己的想法。相关团队决定将本已计划好的功能改进工作延期，全力解决后端的保障工作。我们
需要通过某种方式对VSO的后续更新进行“金丝雀部署“。原本使用的芝加哥弹性扩展单元（我们称之为SU1）保持不变，但我
们打算在该弹性扩展单元之前增加另一个单元，新增的单元被命名为SU0。
在这一过程中，首先我们会将所有冲刺（sprint）版本部署至圣安东尼奥 (Scale Unit 0)，在这个位置运行一段时间。如果感觉
一切正常，才会将其滚动部署至芝加哥的单元 (Scale Unit 1)，如图2所示。当然，如果SU0遇到问题，还可以修复问题并重新
启动新一轮的部署。后来我们又在这个序列中加入了更多Azure数据中心。到2014年秋季，我们增加了阿姆斯特丹作为第五个
数据中心。随着业务继续扩展至全球更多地区，很快我们还将加入澳大利亚。在以上过程中，我们都在使用Visual Studio
Release Management来处理部署流程和自动化滚动更新等操作，每一个冲刺版本都是这样部署的。
图2：2013年11月之后，VSO从原本的一个数据中心扩展至多中心，借此实现“金丝雀”部署和全球落地。
对于线上环境服务质量的重视立刻获得了立竿见影的效果。从2014年4月服务月度点评（图3）中可以看到，2013年11月共出
现了43个线上问题（LSI），六个月后骤降至7个，其中仅两个来自正式发布（非预览）的服务。我们还在持续完善自己的
DevOps实践和运维实践，注重保持线上环境的健康状况，不过接下来还有很长的路要走。
评论0
最新资源