张献涛：就像我刚才谈到的，阿里云在虚拟化领域有较深厚的技术积累，当然愿意为客户利益最大化挑战技术上面临的巨大困难。从客户角度说，没有一个用户愿意自己的业务被中断数分钟。从阿里云角度来说，客户利益永远是第一位的，只要能帮用户从技术上解决免受损失，那么阿里云的技术团队将义不容辞去承担。
对于您的第二个问题，我想谈谈云服务提供商和用户签订的服务协议，从协议中都可以看出，每年是允许一些停机发生的，因为软硬件系统总是要停机维护的，比如做修复漏洞之类的事情。冷启动没有任何技术挑战，在满足协议的基础上可以选择重启机器，但我们要看到一旦这样做势必会影响到客户的业务，有些甚至是致命的影响。要想解决 Xen Hypervisor 热升级，面临的挑战非常多，真正能解决这个问题的人在全球范围内都是屈指可数的，因此几乎所有公司都不具备热修复 Hypervisor 的能力，所以没办法热升级。
谈到热修复门槛问题，我也想拿 Xen Hypervisor 热修复过程和 Linux 内核热修复过程做对比，从分析中就应该可以看出门槛在哪里。
首先，Linux 内核是很容易支持热修复的，并且主流公司也都有自己的热修复实现，新的 Linux 内核都原生支持，方法也相对简单直接，把问题的函数替换掉就行了，基本上没什么门槛。其次，从修复过程上看，Linux 系统的管理员可以访问系统的所有内存，并且内核天生支持模块插入，在这两个前提下，一旦某个函数出现漏洞，很简单地用C语言写个新的函数以模块形式插入内核，然后把所有对有问题函数的访问跳转到新的函数就可以修复了。
然而，Xen Hypervisor 作为一个安全域，它不允许任何用户，甚至是云运营商管理员访问器器内存，并且为了安全考虑，不支持任何的模块插入。缺失这两个条件的情况下，要想热修复 Xen Hypervisor 其难度可想而知。如果想做热修复，就要解决云运营商管理云访问 Hypervisor 内存的问题，如何计算有问题指令的物理地址问题，动态地修复有问题的机器指令的问题以及修复过程让用户业务无感知的问题。对于第一个最难的问题，在 CPU 不能访问内存的情况下，我们另辟蹊径利用设备 DMA 去读写内存，这个方法需要精准的操作，因为一个异常的 DMA 请求会导致 Hypervisor 内存污染或者设备异常，最终导致物理机宕机。具体的细节，我们考虑在下个月举行的 QCON2005 会议上披露。
5. 亚马逊也采用了热升级的方式，为何仍有 0.1% 的服务器需要重启，而阿里云的服务器则全部不会受到影响？
张献涛：热修复 Hypervisor 技术门槛很高，各种各样的软硬件组合都需要考虑，问题比较复杂，不是所有的公司都能解决所有问题。阿里云第一版修复方案也只能解决了 99.97 %左右的客户，但我们没有满足于这个成绩，而是连夜分析方案的缺陷，分析问题所在，最终达到了 100% 用户不用重启的目标。
6. 在热升级过程，是否会对阿里云的其他产品产生有影响？阿里云做了哪些预案来避免用户服务受到影响？
张献涛：这个修复过程对用户的业务完全无感知，不会对用户的业务造成任何影响，更不会对阿里云其它产品造成影响。就像我们公告中说的一样，我们虽有 100% 的修复能力和信心，但线上环境也在千变万化，为防止万一出现意外，从团队组织上，我们组成了故障应急团队，修复过程中一旦出现问题，马上和客户沟通，降低业务受影响的程度。从修复节奏上来看，我们采用了全自动、逐台机器修复的策略，一旦出现意外，只会影响一台机器，修复会马上停止，然后让技术人员分析问题，还有其它一些应急预案，我这里就不详细说了。
结果大家也看到了，我们的修复是平滑的，对用户业务无感知的，没有接到一个由于修复导致的问题工单。当然，我们的应急预案也没有用上。
7. 阿里云也提出了风险赔偿预案，具体赔偿细则有哪些？