国外媒体最近对读者进行了一次调查，以了解他们对云服务（从平台到存储、虚拟化和应用程序）的认知。27%的回答者现在在使用云服务或计划在未来12个月内使用云服务，25%的回答者正在评估云服务，58%的回答者表示他们没有任何计划。没有计划的比例看起来很高，但是你要和去年7月的一次相同调查进行比较，当时65%的回答者并没有认真考虑云计算。不管云服务认知比例的提高是出于其经济性，厂商营销还是产品本身的吸引力，云概念开始逐渐深入人心总是不争的事实。
但是IT专家也表示对云计算的风险感到担心。
一位回答者表示："云计算最大的两个弱点就是它们的可靠性和安全性。云服务是否可以持续一周七天一天24小时地提供？如果发生互联网故障，将会出现什么问题？我们的数据和其他信息是否会遭到侵犯？如果确实遭到侵犯，我们如何才能知道这个情况？"
没有人可以回答全部这些问题。不过我们知道的其中一点就是由于云计算缺少标准的监控指标，云厂商不愿意披露性能参数，而我们自己又不能保证互联网的连接质量，对于那些采用了云计算但又没有合理规划的组织来说，这两个因素加起来有可能使性能问题从小问题变成大问题。
你可能会想，我们经常听到云计算采用的成功案例；如果性能很糟糕，那我们怎么没听到相关的案例呢？情况可能不是你所想的那样。由于迁移到云是一件相当容易的事情，没有人希望直面云的缺点。在我们的调查中，回答者确实出现某种程度的轻信：33%的回答者表示基于云的应用程序的性能比他们自己内部的应用程序的性能要好；54%的回答者表示基于云的应用程序带来了性能的提高。
请认真检查一下事实。
50%的使用云计算的回答者并没有监视应用程序的性能。只有16%的人使用了WAN（广域网）加速方案，而只有20%的人估计出了互联网架构上的云服务对他们的潜在影响。因此他们可能就根本就没有对性能进行量化。
做好调查和分析是有好处的。如果你的组织对云持审慎观点，那么你最好研究一下那些做得好的组织的案例。那些采用了适合的监视工具并进行了评估的回答者们在所有使用云计算的回答者中持有最高的满意度水平，而且他们在过去一年中对云计算性能的评价也最高。他们有比较现实的期望，而且已经部署了相应的技术和带宽来确保服务水平。那么那些没有做好调查和评估的回答者是怎样的呢？他们对云计算的评价最低。如果你没有制定合适的数据计划，没有制定好应对问题的方式，那么你就要自己面对所有问题。
幸运的是，现实中你确实可以采取一些方法来减少云计算的风险，有了这些方法和手段，即使出现问题–相信我们，你肯定会碰到问题–也可以让云厂商负责。第一个要记住的事情就是这些服务依赖于互联网的协作性结构。每个厂商–不管是ISP（互联网服务提供商）还是云初始厂商–都会在服务协议条款中表示对超出它们控制的事情概不负责。你想要让云存储厂商保证最基本的数据连接性吗？可以，让我们来看看怎么做。
现在，我们并不是说SLA（服务水平协议）中的免责条款会导致你不能保证获得良好的性能。但是在这种情况下，你确实需要有一个计划来尽量挖掘你的投资价值。越来越多的软件厂商正在更新和改进它们的应用程序，以便提供更好的性能监视功能和控制手段；不过，我们还没有看到一个可以为IT人员提供真正的端到端监视功能的工具。你还需要将现有可用的监视软件和来自ISP和云合作伙伴的数据整合起来。下面是五个步骤。
1. 认识到性能的好坏也和你自己的内部网络有关
一位回答者表示道："如果没有严格的服务水平协议，对性能不正常的情况没有足够的金钱处罚，那么我们很难放心地将核心应用程序托付给云服务提供商。"这种看法确实很正确，但是责任性是双方面的。对于我们来说，同样重要的是："即使在规划云扩展之前，我们也需要对自己的内部传输和带宽水平进行评估。"
要获得这个数据，关键就是要监视你现有的传输和连接性。不过，令人惊讶的是，许多组织对自己的内部运营没有整体的监视手段。GreenPages的托管服务总监John Drew表示，在他所接触的客户中，只有不到30%的客户部署了对内部网络进行监视的系统。
Drew表示："大部分客户忽视了内部性能，直至问题出现，然后在遇到问题的时候，他们才开始进行架构升级，而这种临时而短视的做法往往只是推迟了下一个问题的出现的时间。"
如果你不了解内部网络性能，那么你在判断云服务的时候就已经是建立在错误的数据基础之上。无论你是否计划采用云服务，对内部性能的跟踪都是必要的。你可以选择很多厂商的工具–这个领域很广，包含了CA、惠普、NetIQ和NetQoS等厂商。这种性能跟踪将为性能监视提供基本的架构，而且可以从你的站点一直扩展到应用程序本身。你可以看看Michael Biddick对九种APM（应用性能管理）软件的评价。
2. 同你的ISP一起协作
我们惊奇地看到互联网服务提供商许多地方的名声都不好。这可能是因为当我们遇到互联网问题的时候，我们首先想到的就是它们–就像你的Office办公软件出问题的时候，你会大骂比尔盖茨。
实际上，你的连接性服务提供商有着不可忽视的重要作用，它们可以帮助你理解、监视云应用程序并帮助你解决这方面问题，但是让我们惊讶的是，许多IT组织从来没有向ISP寻求帮助。这种情况不好，因为互联网服务提供商一般可以提供很多服务来帮助IT人员主动地监视传输。例如，一个地区性银行在遇到了连续几周的云应用程序性能问题之后，终于忍无可忍地找到了它的ISP并寻求帮助。这家互联网服务提供商利用它的监视工具，帮助这家银行将问题发作的区域隔离到了上游的云服务提供商，而不是这家银行的客户端站点或这家ISP本身。
记住，ISP的主要职责就是提供连接性及其相关工具。它一般不关心你拿它来做什么。SLA的触发是由于特定的故障，而不是特定站点或应用程序的性能监视。
如果你不能确定发生问题的来源，你可以通过数据流监视（包括协议分析）来帮助你确定这一点。ISP很可能已经有这种工具；虽然ISP不一定免费提供这种服务，但是你自己购买这种功能肯定是要花费一定成本的。
另外一点：监视远程站点的连接。一个简单的路由跟踪工具就可以帮助你描绘出所有的连接路径。你可以部署路由监视功能来监视你的站点、互联网服务提供商以及远程站点。这样你就可以充分掌握你的主站点和远程站点的情况。
我们惊讶地看到许多云服务提供商在许多情况下撒了谎，它们声称性能瓶颈是来自客户，而实际上许多情况下并不是如此。如果性能瓶颈是来自云服务提供商或ISP， 客户对性能的详细监视将有助于驳斥云服务提供商或ISP的声明。
3. 给你的远程工作人员提供一些监视工具
从多个站点来监视服务提供商所提供的服务是最好的查找问题原因的方式。给远程工作人员提供一些基本的工具，并确保他们可以在出现问题的时候提供报告。这些测试包括基线速度测试，如果有可能，还可以包括对连接路径的快照测试。
不过这个工作可能很繁重，因为远程工作人员的网络设置可能五花八门，但是如果你使用像VoIP（网络电话）这样的任务关键型系统，那么这些工具确实很重要。终端用户的网络情况往往很不相同，而查找原因往往会花费很多宝贵的时间。一个例子：我们的一个客户花了很多时间来解决远程VoIP系统的性能问题，结果发现抱怨最多的用户之所以遇到性能问题，其根本原因其实是他自己网络上的其他活动。
4. 时刻监视互联网整体状态
不是监视所有的行为，而是那些对你重要的核心部分。要监视你的传输模式，还要监视主要连接点，特别是和你的云服务伙伴有关的连接点。
有许多工具可以提供这样的报告，我们推荐的有Keynote Systems的Internet Health Report（互联网健康报告）这个报告可以让你测试不同主要服务提供商的延迟性；还有Internet Traffic Report（互联网传输报告），这个报告可以对不同站点进行量化的排名。对于特定站点来说，Akamai的Real-Time Web Monitor（实时互联网监视器）可以提供最为准确的报告。
5. 优化你的连接性
现在你已经有了基本工具，并认识到简单地将增加带宽作为解决云性能低下的问题的做法是短期做法，而且随着使用的增加，问题很快又将浮现。如果你仅仅是增加带宽，那么不仅你的ROI（投资回报）将受到削弱，而且还可能助长组织内使用视频流这样的占带宽的互联网应用程序。
有没有更好的解决方法？答案就是WAN优化。虽然只有16%的回答者使用了优化系统，但是我们预计随着IT组织认识到这种技术的好处，这种技术将逐渐得到推广。例如，F5，Packeteer和Radware等厂商提供具备流量整形功能的设备。这种设备可以确保核心系统应用程序的带宽优先级不会低于其他的像视频这样的应用程序。按照吞吐量的不同，这些设备的价格从1.5万美元/站点到8万美元/站点不等，不过，按照我们的经验，和增加带宽比起来，这些设备往往能够在一年内就收回投资。
思科和Riverbed等厂商提供广域文件服务和站点到站点压缩功能，不过这些技术的部署需要一定的技巧。我们同America Service Group的首席信息官Steve Hernandez进行了一番交谈。该公司为全美各大机构提供医疗信息系统。Hernandez表示有几家客户将Riverbed设备整合到它们自己的主数据中心中。许多组织通过Riverbed来弥补不同连接性性能上的差异。但是，他警告道，因为有许多DMZ（隔离区）和安全保护栅栏，因此将压缩设备安装在客户端站点是一个相当有挑战性的任务，也就是说，这种方式只适合于大型组织。
小公司可能会考虑采用它们的云厂商所推荐的整合工具。许多大型厂商提供多种方式，比如设备或是其他互联网服务，而用户可以从中选择一种。有许多厂商，比如Cast Iron这样的设备厂商，以及Boomi这样的服务提供商，它们不仅可以简化整合过程，而且还提供针对性能和应用程序整合的内置的性能统计工具。你可以利用这些工具来评价云厂商的性能。
