避免云计算SLA陷阱

　　几乎所有的云计算用户都认为服务水平协议（SLA）对云来说很重要，但是大多数用户都承认他们没有执行任何加强SLA的措施。没有正确的考量和工具，即便是一个好的SLA都有可能失败，因为你不会知道它已经被违反或者原因是什么。要做出正确的云计算SLA决策，你需要将你的云划分成责任区域，使用分析工具来设置应用的行为基准条件，并将SLA故障当作一个有自身流程的“项目”来处理。

　　划分云责任区域

　　云计算SLA挑战之一是，云应用交付的体验是三个或更多个实体的性能总和。搞清楚到底哪一个可能会引起问题是一大挑战，所以在为云创建一个SLA决策框架时的首要任务是建立一个简单的实体图，显示云服务的每一部分都是由谁来提供的，又会传输到何处。

　　一个典型的云应用从提供用户连接的用户自有设备开始。它可以是一个移动设备或者是整个公司网络。云应用从用户提供的这一组件通过WAN，通常是互联网，连接到云提供商的基础设施。一些用户使用VPN服务从固定地点访问云，而其他人可能拥有多个云服务供应商，因此在你的云里可能会有比这三个标准的责任区域更多的责任区域。

　　云应用产生横跨这些区域的工作流，对于每种运行的云应用你会想了解这种活动究竟是如何发生的。你可以基于应用的名字说出这些工作流是如何满足其用户的需求。此工作流是你的SLA决策的基础。

　　为了获得良好的SLA管理和政策决定，你需要衡量每一个供应商在你的应用云区域内的行为。你应该始终从衡量响应时间的机制开始，再到测量区域边界点条件。

　　端到端响应时间的测量最好在用户连接的时候进行，这样你可以获得完整的响应时间。在某些情况下，这意味着将响应时间监控构建到应用里，尽管通常一个设备的TCP/IP软件可以通过一个管理接口提供一些数据。

　　对于区域边界监测任务，某些形式的流量或协议监控可能是最好的选择。这些工具在网络的各个地方放置探测器，软件工具或硬件，它们可以通过一个中央管理控制台，使用深度包检测来对应用进行梳理，以查看数据包流量。

　　避免网络分析陷阱

　　用户在这一点上会犯的一个很大的错误是变得越来越注重监测本身而不知道什么才是好的和坏的。网络管理系统（NMS）可以自动收集在一个数据存储库里的数据（例如OpenNMS）。该数据集合允许你运行一个查询来分析一段时间内的性能和条件，并设置正常行为的基准以及你认为会违反SLA的阈值。如果你的管理系统没有提供一个数据存储库，你需要添加网络分析工具来收集和关联管理数据并设置你的性能基准。

　　网络分析可以为围绕云计算服务水平协议的决定奠定坚实的基础。确保工具有将从云管理系统API获得的性能数据添加到你自己的NMS获得的网络数据的功能。如果你有一个VPN或一个拥有大数据中心的混合云，它甚至可以智能的首先开始在你的主网络厂商里选择可能的工具。这些对维护你的IT和网络基础设施的性能颇有助益，也有助于管理基于云SLA的决策。

　　当然，这一切最后都归结到如何检测SLA故障。一个好的系统为云计算SLA的决策过程提供三种输入。一种是主观的用户对于性能不佳的报告；第二种是一个检测到的一个或多个应用的端到端的响应时间问题；第三种是在一个区域边界的特定问题报告。在任何情况下，你应该先评估该问题的影响，然后再定位可能的原因。

　　你的工作流程区域地图会让你看出这是否是几个应用在一个区域边界点的一个普遍问题，还是只有某一个应用的问题在前一种情况下，你可能遇到的是网络或云基础设施的问题，在第二种情况下可能是云应用本身的问题。对于第一种情况，你需要使用监控工具来检查受影响的工作流的所有区域边界，看看问题到底出在哪里。这个问题应表现为两个区域边界点之间更长的延迟或一个区域内的包丢失。你的流量探测器通常都可以确认其中任何一种故障。

　　以项目的方式来处理云计算SLA决策

　　如果发生问题，那么修复的过程应该被视为一个小项目，配备一个项目经理和一组固定的任务集，通常称为升级程序。有些用户甚至会使用简单的软件项目管理或故障跟踪工具来追踪从发现问题到解决云计算SLA问题的整个过程。有时候可以使用那些用于软件项目的故障跟踪工具，还可以使用某些包括故障跟踪选项的网络分析工具。

　　要让云计算SLA以及它提供的服务能够成功，采取有组织的方式和作出加强的决策是至关重要的。如果你在开始审议时就计划支持SLA决策，那么你会在整体上获得更好的业务体验。除非你能按照一个小项目的方式来处理云计算服务水平协议的过程，否则云计算SLA将会失败。专家Tom Nolle提供给我们3个步骤来创建一个有效的云SLA。