由于公有云服务水平协议遭到IT专家的谴责，惠普高管表示计划为企业客户修订该公司的基础架构即服务运行时合同。

　　上个月惠普云计算服务水平协议条款引来了一些困惑，惠普表示对SLA增加了前言，总结整个目的以及解释一个案例场景，惠普云服务产品经理Blake Yeager表示。

　　现在用户有责任检验惠普云计算的失败实例，因为实例是短暂的，Yeager表示。另外的一个服务在惠普的块存储中是更加的持久的服务器实例，将会在未来被惠普主动监控。

　　惠普也针对用例失败发布了额外的服务进行监控和通告；这项服务下个月将会以私有测试模式出现。他们也在尝试改善报告的精准度，这项报告是惠普内部接收的，年中会向客户优先发送通知。

　　此外，随着惠普服务的成熟，惠普将提供基于SLA的比可用性更多的内容，Yeager如是说道。“我们计划将其作为我们的进步，主要是围绕服务性能的SLA，以及具体单独资源的可用性，再者是这些单独资源的性能，”他说。在大规模宕机事件中，惠普在适当的地方限制应用程序接口（API）来保护整体的控制平面，Yeager补充道。

　　同时亚马逊Web服务（AWS）高官们反复重申在其低利润、高容量的基础架构上的可靠性是客户要管理的事情，而且也是这样做的。高调的AWS客户网飞公司拥有开源的工具，意味着改善了运行在亚马逊基础架构上的应用的可用性。

　　云SLA的这些细微差别让客户和分析师感到困惑，他们都希望厂商简化SLA术语。

　　Gartner分析师Lydia Leong上个月撰写的一份报告中写道，惠普的LSA需要在一个地区的所有可用区域之间复制工作负载，类似于AWS提供的SLA。

　　惠普澄清并不需要服务客户在一个地区的所有可用区域之间复制数据。惠普的一位发言人说惠普的SLA和亚马逊不同，是按月计算的而不是按年计算，所以要比AWS提供的有保证时间更多。

　　然而，Leong在博客中表达了对惠普的SLA更新的一些方面不满，主要是惠普的SLA语言不够清晰，会导致误解。“惠普和AWS在这个领域都存在过失，很多拥有良好SLA的提供商仍会强迫你来读一些空话，让你来分析他们目的是什么，”Leong写到。

　　其他分析师对于惠普和亚马逊提供的云SLA做出了进一步的评价，和其他的公有云基础架构即服务（IaaS）提供商一样，他们认为这些SLA将过多的监测和解决失败的责任转嫁到终端用户身上，而不是服务提供商。

　　“整个的公有云计算市场在这一点上毫无秩序，”Virtualization Practice分析师Bernd Harzog说道。

　　比如，惠普的SLA要求用户监测失败实例，而且在用户调用惠普API失败期间在最初的六分钟时间里计算宕机时间。Leong更新的博客也批评了这一点，在她眼中用户尝试重启实例就是对于宕机情况下API性能的潜在妥协。

　　简单的运行或者宕机可用性来衡量IaaS的服务质量太不靠谱，Harzog补充道。“如果你在尝试进行在线的金融交易，要用10秒钟，可接受吗？”他说，“现在任何公有云厂商在这部分上都不能够保障要花多长时间。”

　　随着AWS扩展其企业云基础，和其他IaaS厂商一样引入了catch-22（22条规定），分析师说道。AWS高容量、低利润的基础架构在成本上同那些初出茅庐的IT厂商较量，主要就是以可用性为代价。

　　然而，尝试同亚马逊竞争的IT厂商通过提供加强的可用性还经常会被问为什么比AWS贵，专家解释道。

　　同时，“如果亚马逊真的想要进入到企业中，他们就要对SLA做出改变，”Robust Cloud的云计算咨询师Larry Carvalho说道，“但是我不知道他们是否准备这样做。”