微软技术研究员Mark Russinovich恐怕比世界上大多数人更了解Windows的内部原理。自从2006年加盟微软以来他担任过好多角色。微软在2006年收购了Winternals，这是他与别人共同创办的一家系统恢复工具厂商。如今身为Azure首席技术官(CTO)，他肩负的重任是，让微软的公有云运行起来如同上足了油的机器那么顺畅。

多年来，Russinovich一向是微软最受公众欢迎的演讲者之一，主要是由于他是那种为数不多的有远见的技术专家，能够以一种连门外汉也听得懂的方式讲解和诠释信息。眼下Russinovich在微软刚谋得了也许最重要的职位，因为Azure俨然就是首席执行官Satya Nadella倡导的“云优先，移动优先”战略的基石。

Russinovich最近接受了我们的深入采访，他探讨了微软处理最近Azure停运事件的方法，积极接受Docker容器以及整个开源软件，它与谷歌一起支持容器管理方面所做的工作，以及他为何认为跨云移植工作负载这一概念仍然难以实现。以下是那次访谈的文字记录，内容略有编辑。

现阶段微软是否在云方面摸到了门道，还是说你们仍在搞清楚一些问题?

我认为，付出多年的努力之后，我们已到了成熟阶段。如果你看一下Azure，发现它在2006年年底还是个孵化项目，如今运作范围却扩大到了全球19个地区，其规模达到了100多万台服务器。而且，我们在将几十种服务堆放在该平台上面。

话虽如此，Satya对于我们应如何作为一家公司来运营抱有愿景，这种运营方法名为growth hacking(按照维基百科的定义，growth hacking是科技初创企业开发的一种营销手段，运用创意、分析思维和社交衡量指标，来销售产品、提高曝光率。)也就是说，从不满足于现状，总是考虑颠覆自己，不断发展、不断学习。这就是我们对待Azure的方式。

我们知道，我们做得不够好，所以这始终是不断逼迫和推动自己变得越来越好的问题。

在过去几个月，出现了几起小小的局部停运事件。尽管这些停运事件只是区域性的，但还是让一些客户和合作伙伴很头痛。微软在如何竭力防止未来出现停运事件呢?

我们趋于成熟的一个表现就是，深入根源分析每一起事件，了解问题的根源。然后，我们提出短期内解决的方案，另外考虑从长远来解决问题。

就拿最近一起停运事件来说，它之所以会发生，是因为我们往其中一个工具中输错了一个命令，结果影响了意料不到的其他服务器。我们需要在加固工具方面做得更到位，以免有人犯那样的错误。这是系统中的一个缺口，我们之前没有做好认真审查的工作。而现在这种类型的问题不会再出现。但愿，一整批这种类型的问题不会再出现。

这始终是我们力争实现的目标，尤其是在软件总是不断变化的环境下。你总是在引入新的软件，改动现有软件。我们还在以惊人的速度发展，规模变得相当庞大。系统一定要适应这样的规模。这关系到能否让向云迁移的这趟旅程充满乐趣。我们在构建和完善运作系统，以便能够在这种规模下运行。

如果你看一下其他云服务提供商，大家都在经历这个学习阶段，学习如何让自己的系统变得越来越好。

微软如何测试Azure 处理繁重使用量的能力?你们有没有像Netflix的Chaos Monkey那样的工具对Azure进行压力测试?

我们称之为故障注入系统，它们可以对软件施加压力，那样你能看出软件在不同寻常的情况下会有怎样的表现。有时候，如果你把软件放到生产环境中，偶尔会出现异常情况。你要确保软件忍受得了那种情况。

说到我们将软件部署到生产环境中，早期阶段之一就是进行特殊的部署，也就是完全注入故障，然后给系统添加负载，确保它能够以我们期望的方式顺利运行。

如今大家都在谈论混合云，微软涉足混合云领域已有一段时日了。为什么混合云对客户来说很重要?

在过去几年间，客户的态度发生了变化，之前是“云到底是啥东西?”，现在想弄清楚如何迈向云端。但这不是说你轻轻拨动开关，就可以说“OK，现在我们到了云端”，事情没有这么简单。

一旦你开始用云来做任何事，都会出现这个问题“我如何将我在内部部署的系统与云联系起来?”而这意味着“我如何安全地联系起来，如何配置网络，如何管理那个系统?要是我想编写一个既在云端运行又在企业内部运行的应用程序，会怎么样?”

我们让客户能够按自己的步伐开始这趟旅程，为他们提供能够做到这一点的工具。一个例子就是ExpressRoute，这种服务能够以一种安全、高带宽的方式连接到云端，并确保你从现有服务提供商获得的服务级别协议(SLA)有保障。

我们说，如果你想要一种办法来管理、部署、编写在企业内部或云端都能运行的软件，那么你可以关注Azure平台的这个一致的子集(公有云)，获得在两种环境之间易于移植和易于移动的那种优点。

微软很早就有所行动，积极支持Docker。为何容器技术那么重要呢?

我们与Docker的合作在往纵深方向发展。我们在几个方面进行了密切合作。我们有一种基础设施即服务(IaaS)扩展模式，这是我们的云特有的模式，它让人们可以将自己的代理注入到虚拟机中。那样，客户来到门户网站后，可以使用命令行工具，然后说‘我想要反病毒软件注入到该虚拟机中。’

首批代理之一是Docker。假设我想要Docker代理安装到虚拟机中。我们在Azure市场(Azure Marketplace)中的映像一并预先安装了Docker。你只要轻松点击几下鼠标，可以在Azure中将Docker系统建立起来。

我们还在与Docker合作，确保Docker API与Windows容器兼容;确保同一API可以用来支持两种容器。

微软还在开发Docker和容器方面的其他什么技术?

Docker拥有可将代码部署到系统上的容器。下一步就是如何编排协调一大批虚拟机上的容器。我们与包括谷歌在内的许多公司合作，在Azure上支持Kubernetes(一种开源容器管理技术)。

容器编排方面还有大量的创新工作要做;另外，大规模管理容器以及使用大规模资源集群上的容器，以整体性的方式支持应用程序生命周期，这方面也有大量创新工作要做。我们在与许多公司合作，确保它们的容器编排系统在Azure上顺利工作，我们对此非常关注。

您可以更具体地介绍一下微软与谷歌一起支持Kubernetes方面所做的工作吗?

这有点像是草根做法。我们的现场工程师有朋友在谷歌，实际上，Kubernetes团队就在西雅图。所以，之前一直就有某种相互得益的交流。所以，这是一种友好的事情，在咖啡馆碰碰面，相互探讨。

与其说是这是一种战略性宏伟愿景，倒不如说我们在一起工作，我们看到有机会合作，对我们双方和整个社区都能带来好处，既然这样就不妨做一下。

云正在消除相互竞争的厂商之间由来已久的障碍，而微软与谷歌在Kubernetes方面的合作可以看作是这方面的一个典例，这个观点正确吗?

绝对正确。我认为，你看到旧的一套理念(有点愚笨的理念)渐行渐远，一种更极其周到、极其合作的理念开始流行起来。

如果公司都彼此你争我斗，试图各自为政，那会伤害他们的客户，最终会伤害自己，因为客户不再寻求这种局面，他们在寻找选择。

我们觉得，我们该合作的时候就要合作，该分开的时候就要分开。但是千万不要因为彼此的公司标识不一样而竖起一道无形的屏障。

微软支持开源技术继续让许多行业观察人士大跌眼镜。这给微软带来了哪种好处?

明显的一点就是，客户找上门来;如果客户为整个架构的某个部分选择的技术迫使他们离你远去，或者迫使他们陷入孤岛环境，对话就会变得简短而尴尬，也就是说话不投机。

就拿Linux上的.NET或Mac中的.NET来说，如果有人非要为Linux或Mac做一个技术上的选择，现在他们就能选择放到上面的微软技术，他们想要这么做的话。

而一旦他们做出了这样的选择，这让他们成为潜在客户，可能会购买.NET生态系统中在其上面的一些服务。比如说Visual Studio。它确实让人们利用可以添加到上面的一些微软服务更有助益，因为他们是在整个架构的某个地方利用核心的微软技术。

如果三大云服务巨头联合起来，确保各自的架构彼此能协同操作，那将意味着什么?

这正是我们有意识地探讨的话题。如果我们完全联合起来、实现标准化，会怎样?这项工作做起来有多难?而阻止我们做这项工作的其中一个障碍就是，即便在低层，虚拟机和存储仍不太成熟，不过这方面仍有创新工作要做。

所以我认为眼下还没有到那些种类的服务已完成差异化的地步，即便在整个堆栈的那个层面。还有更多的工作有待完成，未必是从中赚钱，而是有一种方法能够在这上面支持独特的使用场景。所以，不是说每个人的云都是用水泥搭成的，剩下来要做的事情就是，想办法在上面放一个合理的层，可将底层的那些差异隐藏起来。

我们听说微软对嵌套虚拟化(nested virtualization)颇有兴趣，也就是在虚拟机里面运行虚拟机管理程序。微软怎么看待这项技术?

这是我们之前绝对关注的技术，如今也在关注。如果你谈论这些平移(lift-and-shift)场景，即有人部署了面向基础设施的管理系统，迁移到云意味着将其中一部分留下来，然后拣选出其中较高层面的部分，将它移到云端。

如果你有嵌套虚拟化技术，一个优点就是，你基本上可以将整个管理系统(从下到上)平移到云平台。你没必要做一些工作将应用程序的管理和基础设施的管理分开来，这两种管理在一些情况下可能紧密联系。

我们确实认为这是嵌套虚拟化技术的一个潜在优点。当然，还有技术成本、复杂性以及支持它的开销需要考虑。所以，我们仍在考察这项技术。

微软在Azure中如何使用软件定义网络(SDN)?

早在SDN成为热门的新技术之前，微软就在Azure上使用它了。就因为你的产品组合中有这项新技术，你能以10亿美元的价格卖掉贵公司。夸张一点来说，公有云的立足之本是虚拟网络或者说软件定义网络。

我们在Azure中有第3层虚拟化网络，这个我们一开始就有了。我们后来逐渐完善了这项功能，加入了VPN解决方案，以支持点到站点到云、站点到站点到云以及ExpressRoute，后者是客户站点与Azure之间的一条专有连接。

另外，我们在Azure上最早做的工作之一就是虚拟负载均衡，现在它可以扩展到成千上万台服务器这种环境。我们还使用虚拟网络用于分布式拒绝服务保护。我们还在关注面向容器的虚拟网络支持，因为这增添了另一种规模，甚至增添了另一个动态层，这是哪怕在虚拟机规模下也看不到的。