本文由DevOps Master Club实践案例组出品，是《万亿市值的帝国崛起-微软DevOps转型实践》系列的第四篇文章。本系列文章主要介绍微软DevOps转型的方法、历程和技术/组织层面的众多干货实践，请关注本公众号持续获取最新文章。
有效DevOps的七个习惯前期回顾：万亿市值的帝国崛起-微软DevOps转型实践（一）万亿市值的帝国崛起-微软DevOps转型实践（二）万亿市值的帝国崛起-微软DevOps转型实践（综篇）
在本系列文章中，我们曾经提到“有效DevOps的七个习惯”，由微软Azure DevOps团队产品经理Sam Guckenheimer提出，主要内容包括：
管理价值流动
管理技术债务
团队自组织和对齐
持续学习和实验
度量和收集数据
生产为先的思维模式
管理基础设施作为弹性资源
我们之前的第二篇文章《万亿市值的帝国崛起-微软DevOps转型实践（二）》主要介绍了如何管理技术债务。今天，我们来介绍另外一个关键点：“生产为先的思维模式”，一起来看看微软在运维阶段如何应用live site culture的十二个原则，如何以客户为中心，助力企业DevOps转型。
微软版的SRE - Live Site Culture
SRE是指Site Reliability Engineering（站点可靠性工程），最早起源于Google，强调通过组织、技术和企业文化手段，来提高系统可靠性。同样地，微软作为科技巨头，在重新崛起的过程中采纳了DevOps的很多实践，事实证明也非常成功，其SRE方法论在内部被称为live site culture。
为什么称为live site呢？要知道，微软是一个以售卖“盒装软件”起家和成功的公司。近几年来，跟随着互联网和云计算全球的脚步，微软提供的服务也转变为云化服务，通过在线站点提供。现在的“主力”已经是在线站点了。对微软内部人员而言，这意味着服务交付模式的巨大改变。
微软的SRE团队在一篇公开技术文章中提到：“时至今日，通过云和网络化服务，客户可以很方便地从一个服务供应商转移到另一个，这就意味着服务提供方和客户之间的信任关系比以往更为重要。在线站点能提供稳定的服务给客户显得十分重要。”
那么微软的live site culture具体是指什么呢？微软VSTS团队的SRE经理Tom Moore总结有如下十二个关键原则：
1. Live Site First。需要在组织内形成live site优先的氛围，形成一种全员共识，朝着一个方向共同努力。这是LSC前提和基础所在。
2. Feel The Pain。这里有两方面意思，一是和客户一样感受服务不稳定不可用带来的不便利和“痛苦”，以形成在组织内持续改善的文化；另一方面让研发团队可直接面对或感受客户的反馈。例如，让研发在深夜被客户反馈的问题所叫醒，来修复某个重大缺陷，这样可以帮助消除研发和运维的沟通壁垒。这点实际上已经体现在了微软团队的组织变迁上。
3. Drive with Data。用数据说话，用数据告警。微软VSTS每日产生大量的生产日志（约7TB，而且还在逐渐增加），必须采用专门的实时日志分析平台来处理和分析日志（在微软内部，该系统名为kusto）。
4. Root Cause Is Key。根因分析很关键，当发生生产事件时，优先修复是最重要的，但是事后的根因分析也很重要，这些分析动作可以放在8*5的工作时间进行。耗费团队时间但是很值得去做，分析出原因的同时，可以形成根治方案，这样可以避免同样的问题再次出现。
5. Detect Before Customers。先于客户发现问题。这里并不是指先于所有用户发现问题，这不现实也没有意义。微软采用了一种客户影响分析模型，可以得出到底有多少活跃用户受到影响，受影响的用户占总活跃用户的比例是多少，这些数据每隔5分钟更新一次，被当做微软最可靠的监控数据之一。
6. Automotive to Survive。随着业务规模、IT基础设施规模的扩大，只有自动化才能继续生存下去。包括批量的变更、简单的故障自愈等。
7. Be Open & Learn。需要有一个开放的心态，乐于学习、接纳和利用新知识。
8. Drive Down Time To Customers。缩短通知客户的时间。微软内部有指标名叫TTN(Time To Notify)，代表通知到客户的平均时间。在，微软的工作人员用excel里明文记录博客密码，然后用这些密码登录博客发布通知，平均耗时45分钟。到，VSTS团队的任务控制工具加密存储密码，之后需要经过三次编辑动作才能发布通知，平均耗费时间30分钟。到了，工具进一步完善，一次点击即可完成信息发布。平均15分钟就可以通过三种渠道（状态信息、博客、内部邮件）通知客户及干系人。
9. Lock it Down。将根因分析的改善方案，经过实践证明后，固化下来，并推广到整个组织。
10. Learn Once & Share。在实践中学习，并分享给客户。微软十分重视和客户的信息共享。每次事件发生后，微软都会进行根因分析，并形成行动方案去避免类似事情再次发生，而这些内容微软毫不避讳地公开并告知客户。客户知道微软在努力改进，这是一种正向的激励。
11. Cloud。VSTS团队通过Azure获得计算资源。这里并不是指微软团队必须要用自家的云计算产品，而是云计算的各种优势可以让运维变得更加简单。
12. Config As Code。配置即代码。通过自动化和配置管理工具将应用、软件、环境配置当做代码一样管理，让它们有版本、管理起来也很方便，不像以前一样需要手动管理，繁琐而且容易出错。
从微软live site culture的十二个原则来看，微软的SRE团队在组织、流程、工具技术和文化方面对客户进行全方位的支持，以客户价值为导向来服务于客户，并与客户建立牢固的信任关系。
Live Site Culture的变革之路
下面让我们回过头来看组织架构如何变迁才能构建起微软live site culture的十二个原则。
微软VSTS组织架构的变迁：
在过去，微软和其他的传统企业一样，研发和运维分离，研发将构建号的发布包扔给运维，之后运维手动地去操作环境、管理配置、部署发布、处理问题。然而事实证明这种老的组织模式无法适应LSC的需要。
经过几年的积累和转变，VSTS现在的DevOps和SRE团队架构如下图所示。从原来开发、测试、运维三个团队合并成两个团队，分别是特性开发工程师团队和活跃网站工程师（LSE）团队。而LSE团队中又区分为两个角色：一个是负责活跃网站工程的角色，另一个则是SRE。这两个角色分工有很明细的区别，前者是从特性开发团队中选取人员，以轮值的方式解决软件特性相关的生产问题；后者则是负责处理平台类的生产问题，而这些问题往往非业务相关。
那么这个组织又是如何响应生产事件的呢？VSTS团队在收到告警（客户反馈、自动告警、社会舆论、人为反馈）后，会通过人工和自动路由规则相互结合的方式反馈给LSE团队，LSE团队立刻对事件的影响度进行分析，之后会通过各种手段进行事件处理，例如隔离、修复、改善等等。VSTS团队7*24小时对生产事件进行影响面分析和处理，但是只在5*8小时的工作时间段内进行根因分析。
总结
从微软的Live site culture中我们可以窥斑见豹，始终以客户为中心、以积极的心态面对不足和新的市场变化，从组织、文化、工具等方面持续改善，这可能是微软这个科技巨头在DevOps时代成功再度崛起的原因之一。本篇对运维阶段的一些优秀实践给大家进行了介绍，下一期将带大家领略微软DevOps实践中关于敏捷转型的部分，敬请期待！
近期活动DevOpsDays 上海站·早鸟票
点击文末"阅读原文"，直达报名链接！
关于DevOps Master Club 案例组
我们继续欢迎志同道合的您的加入！！！
