【IT168 资讯】本文描述来自云计算用例组的 “云计算用例白皮书” 版本 4.0 —— 由开放 web 社区的 1,400 多位参与者(在版本 3.0 时为 900)所创建的信息仓库。它最初是由一组开放云宣言的支持者所创建，后来参与者增长到包括大小公司的代表、政府机构、咨询机构、以及供应商。

　　“云计算用例白皮书” 的范围非常全面，因此，我们没必要一次读完整个文档。在本回顾中，我们重点关注组织对云中服务级别管理问题的评价，这点很重要，因为 SLAs 描述了云提供者和云客户之间的关系，从本质上定义了，可信云服务客户的基础是具有云服务提供者交付基础设施服务的能力。

　　什么是 SLA?

　　作者同意 SLA 应当包含：

　　提供者所提供服务的列表，以及每个服务的完整描述。

　　确定提供者正提供其所承诺服务的度量标准，以及用于监控服务的审计机制。

　　供应者与消费者各自的职责，以及如果未达到 SLA 条款时，针对各方的补救措施。

　　有关 SLA 随时间变化的描述。

　　作者讨论了两类 SLAs —— off-the-shelf 协议和定制，协商协议。注明了具有关键数据需求的客户不适合采用 off-the-shelf 协议，因此，迁移到云之前的第一步是确定您的数据及应用有多重要。

　　公共云经常提供非协商 SLA ，这是关键任务应用或数据无法接受的。

　　什么是 SLO?

　　SLA 包含服务级别目标(SLOs)，其客观定义了服务的可测量条件;一些例子包括有关吞吐量的参数以及数据流的频率和时间，VMs 以及其他资源和实例的可用百分比，或者用于 SLOs 重要性分级的紧迫性评价(比如 “可用性比响应时间更重要”)。

　　SLO 期望应当依据应用及应用所访问的数据是否位于相同的云而不同。

　　监测与测量

　　服务级别管理，基于 SLOs，是如何搜集和处理云的性能信息。其使用方式为：

　　云提供者利用服务级别管理来进行基础设施方面的决策;例如，如果吞吐量无法持续满足客户需求，提供者可以重新分配带宽或者增加更多硬件。或者决定通过牺牲其他客户来取悦这一客户。对于提供者，SLM 设计用于基于业务目标和先进技术，来辅助最优决策。

　　云客户利用 SLM 来决定如何使用云服务;比如是否在该价位增加更多虚拟机，因为价格太高而不划算。有时候还涉及如何自动化这些决策。

　　关于 SLA 条款，应考虑哪些要素?

　　作者提出在定义 SLA 条款时需要考虑的 10 个要素：

　　业务级别目标：组织在准确定义需要哪些服务之前必须先确定为何 要采用云服务。这一点不是技术问题，而是组织策略问题：一些组织将会削减经费或者放松对基础设施的控制。

　　双方的职责：平衡提供者与客户的职责很重要。例如，提供者将对 Software-as-a-Service 方面负责，但是，客户主要对其采用授权软件及处理敏感数据的 VM 负责。

　　业务连续性/灾难恢复：客户要确保提供者维持着足够的灾难恢复能力。有两个相关的例子：在云中存储有价值数据用于备份和云爆破 (当 in-house 数据中心无法处理进程负载时，进行切换)。

　　冗余：考虑提供者如何实现系统冗余。

　　维护：采用云的最大好处之一是，由提供者进行维护。但是，客户应当知道，提供者何时处理维护任务：

　　在这期间服务是否可用?

　　是否服务可用，但是提供较低吞吐量?

　　客户是否有机会针对升级的服务进行应用测试?

　　数据位置：依照规则，不同类型的数据只能存储到特定的物理位置。提供者可通过一个保证来响应这些需求，该保证是，客户的数据将只存储在特定位置，并具有对该情况的审计能力。

　　数据索取：如果法律要求提供者的设备要能够捕获属于特定客户的数据和应用，该获取可能影响采用同一提供者的客户。考虑通过第三方来提供附加备份。

　　提供者失败：考虑提供者的财务状况，制定应变计划。

　　区域：再次强调，理解管理供应商以及管理客户的本地法律。

　　代理商和经销商：如果供应者是云服务的代理商或经销商，需要理解提供者的策略和实际提供者。

　　SLA 要求

　　作者提出在考虑 SLA 时，需要关注的 14 个职责：

　　安全：客户必须了解其安全需求，以及需要什么控制与联合模式来满足这些要求。提供者必须了解，他们需要向客户交付哪些内容，来确保相应的控制与联合模式。

　　数据加密：数据在活动以及闲置时必须进行加密。必须指定加密算法的细节以及访问控制策略。

　　隐私：基本隐私问题包括数据加密、保持、以及删除。SLA 要说清云提供者如何在多企业架构环境中隔离数据和应用。

　　数据保持、删除：提供者如何遵守保持规则和删除策略?

　　硬件擦除、销毁：与 #4. 同。

　　政府监管：如果由于数据类型的原因，必须执行法规，云提供者必须能够证明其对法规的遵守。

　　透明度：对于关键数据和应用，当违反了 SLA 条款时，提供者必须主动通知客户。这包括类似停电和性能问题之类的基础架构问题，以及安全事件。

　　证明：提供者应当负责所需的证明并保持其当前状态。

　　性能定义：运行时间 意味着什么?每个洲上的所有服务器是否可用?或者只有一个可用?有必要确定这些定义。(本文章的作者建议标准化性能术语，来方便使用。)

　　监测：对于潜在违反问题，您可能希望指定中立的第三方组织来检测供应者的表现。

　　可审计性：由于消费者负责任何导致数据或可用性缺失的违背，重要的是，消费者能够审计提供者的系统和程序。SLA 应当明确如何以及何时进行审计。这将给提供者带来破坏性和成本。

　　度量标准：这些是在事中可监测，事后可审计的有形事务。SLA 的度量标准必须进行客观而毫不含糊的定义。接下来是一列公共度量标准。

　　提供机器可读的 SLA：这允许自动、动态选择云代理商。换句话说，SLA 可能需要代理商为一些任务采用最廉价的可用提供者，而为另一些选择最安全的提供者，这一类自动化是可能的。(然而此类服务并不真实可用，而是在讨论云 SLA 标准化时要牢记在心的。)

　　人机交互：按需自服务是云计算的基本特性之一，但是 SLA 应当考虑在需要人员时，就有可用的人。

　　一些公共的性能度量标准(关注 #12)包括

　　吞吐量：系统响应速度。

　　可靠性：系统可用性。

　　负载均衡：有关弹性问题。

　　耐久性：数据丢失的可能性如何。

　　伸缩性：资源能增长多少。

　　线性：系统性能随着负载的增加而增长。

　　敏捷性：提供者响应负载变化的速度。

　　自动化：不需人工干预的请求处理百分比。

　　客户服务响应时间。