历久弥新 - 微软万亿市值背后的文化支撑（下）|DevOps案例研究-CSDN博客

内容来源：DevOps案例深度研究-Microsoft文化支撑研究战队（本文只展示部分PPT研究成果，更多细节请关注案例分享会，及本公众号。）

本案例内容贡献者：陈飞（Topic Leader）、陈雨卿、郭子奇、刘晨胜、善园林、赵英美、周银燕

本次案例解读：徐磊

640?wx_fmt=jpeg

（图片来源于网络）

前文回顾：DevOps案例研究：历久弥新 - 微软万亿市值背后的文化支撑（上）

纳德拉时代微软的文化变革

为微软按下“刷新”键

其实在纳德拉时代之前，微软内部的敏捷和DevOps实践就已经在很多团队中逐渐推开了。但是在外界看来，微软仍然还是那个拥有超长产品线的巨无霸，以至于在美国硅谷乃至全球很多公司眼中都唯恐避之不及。加上互联网与移动设备的兴起、开源和Linux的流行，微软一下子变成了众矢之的。在2010年到2014年这一时期，微软颇有点举步维艰的感觉，好似一头身体强壮的大象受到了猎豹的围攻，无论怎样突围都无法找到正确的方向。

640?wx_fmt=png

2014年2月4日，微软宣布比尔·盖茨不再担任微软董事长，其新职位为技术顾问，同时宣布萨提亚·纳德拉（Satya Nadella）为微软下一任CEO。

纳德拉自1992年加入微软，以后的20多年中，他帮助微软推出了云计算版本的Office365，并使之成为微软历史上增长最快的产品之一；纳德拉也是微软多项重要技术的开发者之一，包括数据库、Windows服务器版本和开发者工具，还曾直接负责微软云计算Azure业务。微软董事会认为，这位在微软摸爬滚打了20多年的老兵更加熟悉微软内部的复杂环境，能够比“空降兵”更快地推动新产品和业务的发展。

640?wx_fmt=png

2018年1月，纳德拉出版了自己的首部作品《刷新：重新发现商业与未来》。正如他自己在书中所述，他要做的就是为微软按下“刷新”按钮，让这家步入不惑之年的公司重新启动，找回自己。而他的诀窍就是书中用了大量篇幅所描述的：同理心。

上任后，萨提亚·纳德拉做的第一件事就是要求公司的所有高管都去阅读马歇尔·卢森堡的《非暴力沟通》这本书。纳德拉希望通过谈话和聆听，结束企业内部无休止的斗争，使公司各个部门和谐相处。同时，他通过一系列的实际行动逐步改变业界对微软的看法和认知。

微软与开源

640?wx_fmt=png

这一系列的事件都在很自然地发生着，把它们罗列在一起的时候，我们才发现微软已经不再是那个痛恨Linux、痛恨开源，并与众人为敌的微软；而是一个在Github上贡献了最多开源代码、允许并欢迎他的竞争对手在自己的云平台上运行软件（比如：AWS和Google），同时发布了丰富的iOS/安卓应用的公司。这些策略对于2014年之前的微软完全是不可想象的。

640?wx_fmt=png

2018年6月，微软以75亿美金的天价收购了全球开发人员最喜爱的代码托管平台Github。这一举动在当时引起了技术社区的各种波动，很多人认为Github完蛋了，被一家与开源为敌的公司收购之后，一定不会再友好对待开发人员。

但之后微软的一系列举动却让这些人大跌眼镜，微软不但没有改变GitHub免费的属性，而且还通过GitHub与自家的全流程DevOps平台的集成为全球开发人员提供了免费的CI/CD流水线资源，只要你的项目是开源的，就可以无限量免费使用10条并发流水线，并同时在全托管Windows/Linux和macOS上构建你的代码。

这场历久弥新的刷新运动在本来就具备了文化多样性土壤的微软内部开始发展壮大。

640?wx_fmt=png

在本案例一开始我们就曾见到过这张图，相信当时大家都觉得这应该是微软的死穴。但实际上，正是因为这样相对独立自治的环境，使得微软内部对于不同的做事方式具备非常高的容忍度。基本上每个部门都有自己独立的流程、做事方式和工具，可以根据自己的情况及时调整方向应对市场的变化。大家开始沟通的时候，这种文化多样性所体现出来的敏捷程度给予了整个组织超强的活力。

Power BI

640?wx_fmt=png

Power BI是微软从2015年才开始开发的全新的数据可视化工具，它的对标产品包括刚刚被Salesforce以157亿美金收购的Tableau，以及被谷歌以26亿美金收购的Looker。

脱胎于微软传统数据平台SQL Server的Power BI，从2015年的无人理会，只用了不到4年的时间就超越了以上所有对手，站位于Gartner的魔力象限之首。

我们不去猜测原先作为龙头老大的Tableau被Salesforce收购是否与此有关，值得注意的是，Power BI每周一个内测版本，每3个月一个公开发行版本的疯狂发版速度。在这疯狂的发版速度背后，是扎实的工程能力和已经成熟的敏捷文化的驱动。

这一阶段的微软汲取了之前产品研发中的经验教训，非常重视在开发过程中引入用户的反馈来进行产品的持续改进。

下图来自2013-2015年的微软DevOps工具Visual Studio Team Services (也就是今天的Azure DevOps）的产品首页。

640?wx_fmt=png

可以看到通过界面的简化，VSTS的开发团队最终支持用户无需跳转页面就可以直接创建新的项目。这一功能一开始是通过“功能开关”的方式埋藏在产品生产环境之中，通过对比用户对于不同界面的转化率，最终决定选择更加简洁的项目创建界面。

下图是在激活以上改动以后，用户成功完成项目创建的转化率从18%提升到了30%（1.7倍）。

DevOps的7个习惯

640?wx_fmt=png

作为微软内部最早实践敏捷和推行DevOps的团队，开发工具事业部（DevDiv）一直都在微软以及整个软件研发过程中使用最先进的理念和工具。在这个过程中DevDiv也总结出了七个重要的DevOps实践领域，被微软称为DevOps的七个习惯：

640?wx_fmt=png

1）敏捷的调度和团队管理

这一点与敏捷是相同的，但更轻便。涵盖多个领域的功能团队从一个通用的backlog中领取任务，通过尽可能少的工作完成整个流程，并在每个sprint结束后交付可供部署的成果。

2）技术债管理

任何技术债都蕴含风险，最终会导致各种计划外的工作，例如可能干扰计划内交付的线上问题。我们会慎重对待任何类型的技术债，并会通过周密的安排在它们影响到所交付的服务质量前顺利解决。

3）价值流

这意味着按照对客户的影响决定积压工作的优先级，专注于为客户提供价值。敏捷方法中我们经常会谈到为用户交付价值的重要性，但直到我们具备了充分的DevOps遥测机制，我们才可以度量这样做的成功与否，以及是否需要调整方向。

4）基于假设和实验的需求

在使用DevOps前，产品负责人会根据有关人员的最佳反馈“美化”backlog。但现在，我们将backlog视作一种假设，需要将其转变为实验，因此需要收集能够支撑这些假设的数据。我们会根据证据来决定后续的工作优先级，以及是否应该放弃某些工作。

5）证据和数据

我们监控一切并尽可能地收集数据，不仅仅是为了了解运行状况、可用性、性能，以及有关服务质量的其他指标，也是为了更好地理解使用情况，并收集与backlog的假设有关的证据。例如，我们会对有关用户体验的改动进行实验，衡量对漏斗转化率的影响。我们会对不同用户群的使用情况数据进行对比，例如工作日和周末的使用情况，借此假设出每种情况下可以继续改善体验的方法。

6）生产为先的心态

只有服务质量始终卓越，才能得到可靠的数据。我们会不断追踪线上网站的状态，对造成各种问题的根源进行补救，主动发现性能方面的异常，并判断造成这种情况的原因。

7）为云做好准备

只有对架构进行持续完善，重构为更独立、相互分离的多个服务，并借助公有云灵活的基础架构，才能提供24x7x365不间断运行的服务。我们开发的每个新功能都首先以云端为主，随后才会被纳入本地运行的产品，仅有少数有意为之的例外情况。于此同时，我们可以确信自己的产品经过了大范围的加固，并能通过客户的坚持使用获得持续不断的反馈。

1ES运动

在纳德拉重塑微软的过程中，One Engineering System (1ES）的运动非常重要，纳德拉自己也在《刷新》一书中提到过这个运动。为了改变微软内部各自为政的状态，更是为了能够让微软更加迅速、准确地交付用户需要的价值，纳德拉在推行“同理心”的软性措施的同时，也在微软内部通过推行大规模敏捷和统一的工程实践来优化微软价值交付的效率。

640?wx_fmt=png

Azure DevOps之父、微软院士Brain Harry在2017年的一篇博客中总结了微软推行1ES的原因和痛点：

不同的部门和团队重复投资建设重复的工具；
无法重点发展那些优秀的工具；
因为流程和工具的不同，员工在不同部门和团队之间切换工作非常困难；
不同团队之间很难共享代码；
太多的“微软工具”让外部招聘的工程师很难融入；
等等 … …

在微软内部一直都有“吃自己的狗粮”的说法，也就是说自己做出来的产品首先要自己用。“云为先，移动为先”战略驱动下的微软，首先从内部动手，逐步将自己的IT系统全部迁移至微软的公有云Azure之上，同时在内部全面推行Azure DevOps平台作为统一的DevOps工具链。

从2014年到2016年，在1ES的推动下，微软内部产品使用Azure DevOps的开发人员数量翻了4倍，达到了62000人之多。

640?wx_fmt=png

2017年5月24日，经过3个月的奋战，Windows开发团队终于全面迁移至基于Azure DevOps的Git进行Windows的产品开发。Windows的Git库也成为了全球最大的单个Git仓库，有300GB大小，3500万文件，440个分支；有超过4000名开发人员，每天在这个repo上进行着超过1760次构建和上千个Pull Request。

640?wx_fmt=png

在如此巨大和复杂的Git仓库上，Azure DevOps的Git服务的性能表现仍然让人非常满意。

640?wx_fmt=png

Windows团队迁移到Git的成功，可以说是微软内部1ES运动的一个重要里程碑。其实，所谓的1ES运动完全可以理解为微软内部的DevOps推广运动。

经过大概3年的推行，微软基本上统一了内部的工程系统（Azure DevOps）和IT系统基础设施（Azure），为其后续的继续发力打下了良好的基础。

破坏性创新

2019年，微软第四季度财报发出之后，微软市值再超万亿美元，超过苹果和亚马逊，成为全球市值最高的公司。很明显，微软的“刷新”非常成功，最近一段时间有关微软的各种文章也都开始频繁刷屏。但革新永远是痛苦的，微软的刷新不仅仅让自己重归最高市值，也付出了极大的代价。

2017年，微软宣布进一步裁剪智能手机业务，裁掉1850名员工，带来的是9.5亿美元的资产减值。这些裁掉的员工基本上都来自2013年微软花费72亿美元收购的诺基亚手机业务部门，而在这次裁员之前，微软已经陆续裁掉了2.215万名员工。最终微软在手机部门所失去的员工数量高达2.665万人，甚至高于当初从诺基亚加入微软的2.5万人。

不仅仅是手机部门，微软的看家产品-Windows 10也在2018年连续爆出多次严重质量事故，这不禁让人惊呼微软怎么了？其实在微软内部，Windows部门已经被拆分。组织的变动以及更加激进的持续发布策略是否是造成这些质量问题的根源，我们无从考量。但可以肯定的是，Windows在微软历史上作为主角的日子已经过去了。

640?wx_fmt=png

为了能够跟上时代的步伐，纳德拉时代的微软并非只学会了“同理心”而变得温柔，相反，它对自己动手非常狠毒。

从2014年到2018年的这段时间，微软各种自断武功的做法不仅包括Windows产品组的拆分，还包括自家代码分享平台Codeplex的停服、SQL Server对于Linux的支持、Windows Container对Docker的全面支持、Visual Studio Code全面免费开源对Visual Studio企业版的冲击、.net core开源造成Windows平台重要性的降低等等。

这些做法在一定程度上都会为微软其他产品销售带来不利因素，微软为何能够在这些策略中采取如此果断的决定，其实都是一种破坏性创新的体现。

Martec定律下，组织如果希望通过无痛的方式让自己追赶上技术和市场的变化基本是不可能的，必须在某一时点进行跳跃式的发展。微软2014年之后的很多做法正是Martec定律的体现。

微软的文化根基到底是什么？

分析了这么多微软的过去和现在，我们最终总结了微软文化的根基，也就是沙因组织文化三个层次中最底层的假设到底是什么，我们认为微软的文化假设有两点在整个40多年的过程中一直没变，那就是：

永远用最优秀的工程师和最优秀的工程实践；
允许内部文化的多样性，鼓励和允许不同的同理心。

纳德拉在《刷新》中曾经提到，“同理心”在微软的文化中一直存在，只是被忽视了，他所做的只是唤醒微软文化的本源，让微软能够再次回归少年。

640?wx_fmt=png

参考资料

https://www.barryovereem.com/microsofts-agile-transformation-journey/
https://www.forbes.com/sites/stevedenning/2015/10/27/surprise-microsoft-is-agile/#1efc856a2867
https://www.forbes.com/sites/stevedenning/2015/10/29/microsofts-sixteen-keys-to-becoming-agile-at-scale/#583c8c7115ce
https://stories.visualstudio.com/scaling-agile-across-the-enterprise/
https://stories.visualstudio.com/devops/#
https://devblogs.microsoft.com/bharry/scaling-git-and-some-back-story/
https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/
https://www.qdaily.com/articles/27390.html