微软徐明强谈 Windows Azure：从开发到部署的自动化进程

作为一个全球规模的云服务，微软的 Windows Azure 是一个庞大的项目，其开发、运维团队分布在全球各地的研发中心。微软亚太研发集团在上海的团队参与了其中大计算和大存储组件的研发。近日，InfoQ 编辑与研发集团 Windows Azure 首席架构师徐明强博士在上海进行了一次深入的沟通，对 Windows Azure 的开发部署流程、团队的组成、以及云存储系统应如何设计等话题进行了探讨。在未来的一段时间，我们将把这次对话的内容分为三部分分享给大家。

今天分享的是三篇当中的第一篇，介绍 Windows Azure 的开发、部署、测试、监控等方面的一些经验和思路。

InfoQ：今天我们的沟通主要是想了解一下 Windows Azure 研发和部署的一些情况。首先，现在研发都讲究敏捷，像以前 Windows 的软件交付，可能开发周期很长，几年才出一个发布。现在 Windows Azure 的开发周期大概是多久？

徐明强：长短根据不同的软件部件或服务而定。常见的周期 30 天、三个月和六个月不等。我们团队主要负责两部分：大计算和大存储服务。大计算部门是微软亚太研发集团在上海设立最早的一个，始于 2005 年；大存储部门是最新成立的，迄今一年左右。两个部门有不同的经历。在 2010 年前，大计算部门名称为 HPC（高性能计算）。当时的产品是 Windows HPC Server，周期为两年。当时开发模式完全是瀑布式的，而现在是持续发布的模式。之前，在瀑布式的开发模式最后阶段主要做代码稳定化，这段时间出的软件错误的修复率需要降低，需要系统测试和彻底验证，使系统达到一定稳定程度，即最后的软件错误率随时间推移呈飞机降落的轨迹 —— 非常缓慢地趋向于零的过程。在发布前很长一段时间（比如，半年）新的功能也就不再考虑加入了。需要这么长的原因是微软软件是被大量用户使用，每次新发布，哪怕是 Service Pack，代价都是非常高的。而服务却不同，更新相对廉价。所以，在服务持续发布的模式下，不可能有这么长的时间做代码稳定化，产品的性能和服务的功能都在不断地持续发布，部件或功能按其成熟度酌定。

从测试的方面来说，在瀑布式的开发模式阶段，测试会有足够的时间满足缓慢降落的过程。这些测试方法在连续发布的云服务阶段已经不适用了，因为从开发到发布的时间周期短。为了适应新的模式，测试方法也变成连续测试，即服务部署后，一方面通过部分用户使用的情况测试，另一方面开发同时也在测试。在许多情况下，尽快发布成为了一个比较优先的考量。以前软件发布的概念越来越弱了，因为一直在发布。

具体的发布周期，在不同的服务和产品是不一样的。有一些是按月的发布，比如云计算工具类。以前云存储服务也按月发布，现在因为云存储比较稳定，同时云存储又是非常关键的一个产品，对测试质量的要求比较高，所以现在是三个月一个周期。

对于发布的模式，我有一个比喻：原来的项目经理只要有一个发布管理的列表，一个一个核对（check）就行了。现在就不行了，服务发布就像离开车站的火车，不同发布周期是不同的车厢。作为项目经理必须会开直升飞机，根据开发团队现在情况，找准车厢，把货物放进去，这样才能发布出去。

货物就是整个服务本身，也有一些小的功能，但它只是其中一部分的功能，要放到某一节车厢。比如说，在云存储三个月一次的发布周期内，这次发布哪些东西真正可以准备好，放进去，很多决定都不是能在六个月前决定的，可能一个月或者半个月才能做出决定。

InfoQ：发布是否有灰度？从开发到部署上线的测试流程是怎样的？

徐明强：首先，我们内部不断在测试。我们美国有团队，中国有团队。异地开发的方式对于产品组来说，因为有物理上时差的问题，沟通会造成了很大的不方便。现在不同了，对于全球服务来说，不同的时区就变成了一个优势。举两个例子，拿测试来说，测试的时候在美国早上九点到晚上的这段时间，美国队伍负责 Azure 测试。在他们工作时段结束，对于没有解决的问题，移交到中国，中国团队再继续测试，这就是“跟着太阳走”的测试模式。

在云服务时代，快速帮助全球客户解决问题也变成了产品组的责任。对于这个变化，我们叫做开发者的运营模式（DevOps）。既然支持客服成了产品组的责任，就意味着产品组必须负责 24x7 的服务。用户问题进来，先是在客户服务部，然后到运维部门。如果运维部门没有办法解决技术方面的问题，就要交给产品开发部，即我们团队。

InfoQ：从产品组提交代码，最终由运维团队部署，如何确保中间的审查是充分的？

徐明强：从我们产品组把编译的代码（Build）做出来，到交给运维团队去部署，整个流程分几个部分：一个是集成，就是在发布前，不同团队要提交新组件到一个集成的开发环境里。到了集成开发环境里就有初步的测试，测试通过后，下一步要进入测试环境继续测试，最后再投入生产环境测试（Production Test）。中间任何一个步骤如果出现新的错误，就要回到之前的一个环境，这个步骤叫 Retake，这也是经常发生的。

InfoQ：跟以前相比，测试的频率会快很多吧？

徐明强：测试的频率会加快。以前，开发者自己很少写单元测试。现在我们要求开发者自己做单元测试，就是在 Check-in 代码的时候，必须确认单元测试已经跑过了。在测试环境下，就只是做端到端集成、场景式和规模测试。这是流程上必须做到的一些。

我们的测试都是自动化的。软件错误收集有一个统一的错误追踪系统（Bug Tracking System）：客服、Ops 都会在我们的系统里开 Bug；我们系统还有很多警示，自动可以报告一些信息、提醒、报警信息；我们自己也有监控。要看一些度量，KPI 满足的情况。我们每一个开发人员都可以看到当前的负载情况 / 监控的信息、报警信息、以及客服、运维部门发的报告。这三方面都通过错误追踪系统汇总在我们的 Bug 数据库。

InfoQ：Bug 收集回来之后，可能有些 bug 遇到的人特别多，或者 bug 造成了比较大的影响，需要优先修复。修复的优先级是如何决定的？

徐明强：Windows Azure 有几个严重级别。0 级是最严重的，影响整个 Windows Azure。1 级对应一个组件（component），比如整个存储不运转了。2 级对应一个客户。

对于云存储，最高级的 bug 就是有可能要丢失数据了。第二是我们的 KPI：响应的时间，响应的速度，可用性等。我们为客户承诺的可用性是 99.9%，那在我们的监测中，比如在某两分钟区间内，好像可用性不到 99.9% 了，系统就立刻提醒我们，我们的 DevOps 就做原因监察分析（Root cause Analysis）。大部分情况，问题主要是负载高所引起。在负载高的情况下的，就调一些配置参数，使得整个负载可以降低。大部分是自动的，但是某些情况下，我们还是要加一些微调，使整个负载均衡的效果更好。

还有网络。云服务好不好和网络情况有很大关系。有时候，南太平洋渔船一钩把我们的光缆给钩断了，致使我们数据中心之间的带宽降低。在这种突发情况下，我们要将某一些流量，比如异地备份的流量稍微调低一点，使正常用户的流量带宽能够得到保障。这还是一个很复杂的事情，很多不可控的因素在里面。我们虽然不能防止每个类似事件，但是我们尽全力保证用户的体验。

在全球监控体系下，我们可以在仪表盘上看到全球的数据中心之间的网络忙闲情况。我们定义了几个颜色来标识网络连接的负载，蓝颜色是冷的，即带宽是足够。黄颜色指带宽基本到 50% 至 60% 了，我们就要开始谨慎。红色后网络就开始会丢数据包。要避免黄到红的情况，就要控制一些后端的作业悬挂起来，比如清理作业，会消耗我们内部的带宽。

InfoQ：感觉对于 Windows Azure 的更新，一个很大的挑战在于要在全球的数据中心做部署。

徐明强：对。我们整个升级的过程不可能是一下子全部升级的。我们的数据中心都有自己的更新域（Update domain），按照 Update domain 逐个升级。这样有几个好处：一旦升级以后发现错误，只会影响那个域，不影响任何用户。为什么呢？对于我们云服务，特别是存储服务来说，我们的数据备份都是跨不同的更新域，所以升级的时候即使出错了，用户照样可以访问数据，因为有其他的副本。最关键的是升级的可靠性。这是最重要的。不能在升级的过程中有数据丢失，或者对服务有影响。为了确保可靠性，我们有主数据中心（Primary Data Center），还有次数据中心（Secondary Data Center），我们一般是从次数据中心开始升级，因为那里没有用户访问，用户用的是主数据中心，数据再被备份到次数据中心上来。一旦有问题，我们可以提早在此数据中心上发现，不会影响到主数据中心，等主数据中心更新的时候，软件已经有一定的稳定性。

InfoQ：观察期大概是多久？

徐明强：大概是一天左右。大部分问题在部署后立即会出现，比如设备、硬盘的操作。

InfoQ：你们的监控是怎么做的？都监控哪些指标？

徐明强：我们现在内部的监控还是用自己写的。比如我刚才说的存储来说的话，我们是以集群为监控单元。我们和用户都有服务级别协议。我们监控用户使用的流量等指标。我们还监控整个系统 CPU 使用率，硬盘的负载情况，网络的负载情况等。现在系统发的警报都有排序，有些警报比较高，有些比较低。数据中心里网络设备的情况，也都有全面的监控，每一个帐号每两分钟就要看它们这段时间的响应情况。 我们也和一些外部的互联网公司合作监控两个方面：一个是先看终端的网络能否访问我们的网关；另一个是通过第三方服务在全球不断地在我们存储进行存储操作。前者能保证网络级别的连接是正常的，后者能保证存储系统级别的操作是正常的。这两个一旦有问题，系统自动发警示给我们。

InfoQ：为了确保云服务可用性，Netflix 他们开发了一个叫做 Chaos Monkey 的工具，它会在集群里随机杀死一些服务器进程来测试系统自我修复的能力。Windows Azure 中有没有一些类似的机制？

徐明强：这些测试我认为是比较基本的。我们上海团队做了一个比较重要的工作：很多时候你会发现，云服务在测试环境里头都很好，真正使用的时候，负载和规模上去后，就会出现一些问题。我们引用量子力学里海森堡测不准定律。对于这个情况，我们团队做了一个框架，它能够让你在测试环境里模拟“完美风暴”。我们要保证系统在各种压力情况下都能正常工作。如果我们测试人员希望能够测试某些故障的特定排列组合，而这种排列组合单纯用应用负载很难重现。我们的框架就是这个目的，即可以在测试环境下创造这些状况出来。比如网络拥挤因为可能导致响应的数据包丢了，用我们框架模拟可以很容易创造这个场景，测试人员可以验证系统的行为是否正常。

还有一种情况，某些状况可能只在 20% 的情况下出现。这种状况对于系统有什么影响呢？我们的框架也可以模拟 20% 操作不成功的情况。我们可以随机创造数据中心里各种比较险恶的情况，即压力点。

至于在线上杀 VM，这对有一些服务是可以的。对我们的存储的话，不能在生产环境上随便测试：这是用户的数据。如果是其他的 VM，杀几个 VM 可能没什么；数据对我们来说，还是非常谨慎的。

InfoQ：您觉得从测试环境到生产环境，从存储系统的角度，最大的难点在什么地方？

徐明强：做任何测试、开发的时候，很难预测考量某些操作对于云规模、在数十万台服务器产生的影响。云存储是一个非常复杂的分布式系统，其性能和 CPU、内存、硬盘／SSD、网络都有很复杂的依赖关系。 这一点，当开发人员经验丰富了以后会考虑得更全面。

另外，我们的存储有很多规则是可调的，并不是硬写进去的，这些规则非常丰富，表达式也非常灵活。这就帮助程序员不需要改程序，只通过配置的条件就可以对服务进行调整。其中很重要的应用就是负载平衡。前一阵有一个报告出来，说 Windows Azure 是性能最好的，重要的原因是我们的负载比较好：一是负载的算法确实比较好，另外一个是很容易可以做调整。我们一旦发现有问题的和时候，在两分钟内，DevOps 就可以进去，将参数调一调。很可能用户都还没有发现有这样的问题，即使发现，也已经很快的恢复到了原来的服务公约。这对我们来说比较重要。

InfoQ：监控的自动化方面，现在你们是怎样做的？

徐明强：我们在不断地自动化过程中，这也是我们部门作的一个主要贡献。比如我们最重要的 KPI 是用户请求响应的时间及成功率。如果两分钟、四分钟、六分钟之内发现请求没有办法答复，或者连续三个两分钟区间都发现没有达到三个九的话，立刻有警示发出。我们这边经常处理美国晚上出现的警示。原来，我们进去一个程序，要花四个钟头的时间搜索日志找出到底问题根结。后来我们发现，搜索有具体的步骤，步骤的可重复性很强，所以我们自己开发了一个工具，把日志都在本地存下来，自动化地找性能问题的根结。很多情况下，这个搜索自己就能找到问题了，比如发现一个数据不大，写操作花很长的时间，可能是一个机器上的硬件、硬盘的控制器有问题；又例如，看到一个网络传输，某个点到点的传输时间比较长，可能是一个网络上拥堵。这个系统能够越来越快的自动发现这些问题。即使根据现有的知识无法找到根结，也能找到很多相关证据和数据，开发者再介入会非常省时间。现在平均三十分钟就可以把一个这样的问题搞定，找到问题根结。从 4 小时到 30 分钟，提高了 8 倍的效率。

我们发现自动化的工具非常重要。第一，云不断地扩展，规模会越来越大，事件会越来越多。我们要不断地把刚才我们所说的工具变成自动化流程的一部分，当我们机器检测到警示，程序就应该自动跑起来。

现在，我们不断通过 DevOps 的实践发现自动化的可能性。服务器规模要到数十万到百万，这么大规模的系统，硬盘和控制器，网络故障将是常态。最好是 60-80% 能够自动发现，自动修复或启动修复工作流，这样可以真正的扩展，规模才可以上去。

InfoQ：有没有这种情况：出现了一个 bug 需要快速修复，但是修了个把小时还没修好？

徐明强：这涉及到两部分：程序员都非常想很快找到原因，但是最重要的是第一步要先看怎么把状态恢复。着了火，先要灭火，第二步再去找起火的原因。

我们内部现在做了一个大红键（Big Red Button），一按以后，就可以把很多设置设得保守一点，使得整个环境不是那么热，网络也不拥挤。让整个系统降温，使得系统“融化”。然后我们让我们有时间仔细研究错误出处和修复。

InfoQ：按下大红键之后，它会做什么？

徐明强：常见的场景是用户写的特别多进来，把我们的带宽快占满了。带宽占满了以后，用户觉得网络很慢，原因可能是我们正在做异地备份，也使用带宽。这个时候，大红键的功能是稍微缓一下，先把数据在本地存，让带宽使用小一点，先让它全能写进来——这是最重要的，写不进来我们也没东西备份。还有其他的一些参数可以调整，让数据中心不要太热。冷却下来以后，用户的体验会比较好。

在接下来的对话中，徐明强博士会介绍 Windows Azure 团队的招聘理念、管理理念，团队协作，以及人才培养等方面的经验。敬请期待！

嘉宾简介：徐明强博士是微软亚太研发集团 Windows Azure 首席架构师，负责开发面向大存储（Big-Storage）和大计算（Big-Compute）应用的云服务平台。

2004 年，徐明强博士加入当时成立不久的微软高性能计算（HPC）团队，带领了一个跨国团队（雷德蒙和上海）完成 Windows Compute Cluster 2003 和 Window HPC Server 2008 的开发工作。2008 年徐明强博士回到上海，作为首席架构师，领导高性能云计算中国研发团队团队，负责并行计算运行时系统、编程模式、管理和用户门户系统的设计和开发。

加盟微软之前，徐明强博士在 1996 年之 2004 年间担任 Platform Computing 公司（HPC 中间件的领导者）的首席架构师，负责其旗舰产品的设计和技术战略规划。1993 年至 1995 年，徐明强博士专注于并行语言的编译和支撑系统的研究，并在阿冈国家实验室完成博士后研究。在此之前，徐明强博士先后在英国埃克塞特大学取得计算机博士学位，在曼切斯特大学担任研究助理员。