![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
要衡量云服务的执行效果，应该检查用户、开发人员和技术维护人员三个预期类型。让我们仔细研究一下开发人员和技术维护人员正在做些什么来促使那些用户预期出现。
在这里，云用户正常使用云服务，没有发现任何问题。由于一切都运行顺畅，就像其应该的那样，用户可以预期他们能迅速地在应用程序中找到一些元素（比如登录对话框），而且可以正确无误地伸缩应用程序。噢，那个应用程序总是可用。用户还可以预期下载速度很快，应用程序对用户请求的响应速度很快，同时供应商在后台备份数据。
每位用户都很开心。他们认为供应商拥有良好的商业信誉（可靠、迅速、安全、高效）。应用程序运行正常。用户期望开发人员和技术维护人员恰当地使用性能指标来确保应用程序顺利运行，不会出现问题。他们需要来自应用程序的信息以制定业务决策或继续业务操作。
开发人员可以预期所有在内部数据中心中运行良好的应用程序都能够在云中正常运行。他们可以预期云中的应用程序具有状态（稍后再介绍这一点），已经对新版本进行适当修复并且能快速运行，可迅速响应用户的数据请求，资源可顺利伸缩，并且不会出现问题。
所有开发人员预期都依赖于用户预期。他们希望用户对为他们开发的应用程序感到满意。开发人员使用云服务衡量策略中规定的指标监控和测试性能。
如果缺乏任意一项性能指标，开发人员就无法检查云应用程序的运行效果。性能不良可能会导致意外服务停用，使用户无法得到制定重要决策或继续业务所需的信息而陷入困境。
技术维护人员通常是供应商或其第三方。他们确保使用适当的技术，将内部应用程序迁移到云中。之后，他们使用云服务衡量策略中指定的指标来监控和测试性能。
确保良好性能对于维持供应商可靠、迅速、安全和高效的商业信誉非常重要。如果缺乏任意一项性能指标，开发人员就无法检查云应用程序的运行效果。性能不良可能会导致意外服务停用，最终导致：
- 用户无法得到制定重要决策或继续业务所需的信息而陷入困境。
- 开发人员在云中的应用程序监控和测试中举步维艰。
有一天，在云服务环境中，用户无法访问应用程序，也无法从应用程序获得响应。他们突然遭遇了服务停用。然后，他们的屏幕上出现一条来自供应商的消息：“由于计划维修，我们无法提供服务，很抱歉！”
开发人员开始忙碌起来，手忙脚乱地寻找快速解决方案，试图挽救供应商的信誉，但一切都是徒劳的。首先，他们是停止生产环境的应用，然而却假装正在进行计划维修。他们在用户的浏览器上显示一个通知 “服务临时停用，请耐心等待”。 然后，他们开始在内部处理应用程序。
与此同时，用户正在焦急等待。很快，用户怒火冲天，他们要求退钱，理由是服务太差。他们不能制定重要业务决策或继续业务，因而无法增加收入。有些用户甚至面临客户流失或信誉受损的风险。
以前以可靠而高效著称的供应商现在被认为既不可靠，效率又低。如果服务在几小时内还得不到恢复，用户会立即取消对该供应商的续约，转向另一个长期拥有提供可靠性、可用性、安全性和高效率信誉的供应商。
下面是技术专家发现的几个故障：
- 首先，开发人员发现很难定位导致有状态性 (statefulness) 问题的代码。应用程序没有正确响应后续状态。
-
其次，开发人员发现，在内部运行效果非常好的应用程序是由前面的开发人员所编写的单个冗长的单元，而不是由一些（比如 500 个）模块部件组成的，但现在才发现这一点已经为时已晚。当现任的开发人员试图修补应用程序时，新版本破坏了运行 SaaS 应用程序的网站的功能。开发人员草率地将程序划分为一些模块部件（约 10 到 20 个以节约时间）。当他试图使用新版本修补其中一个模块时，结果发现版本控制破坏了网站的功能。
- 第三，当开发人员使用新版本修复问题后，他在云中测试应用程序，以确定资源被均等分配以运行应用程序的效果如何。他发现，由于一个达到最大值的单个资源失败，负载平衡（资源阈值）也失败。其他只达到其最大容量的 75% 的资源也无法从失败的资源实例中接管业务事务。对其他性能参数（响应阈值和数据请求阈值）也造成了一种多米诺骨牌效应。
在迁移之前，由于开发人员没有实现一个阈值来让每个资源实例都使用其容量的 50%。所以，当一个资源实例失败，其他健康的资源实例也无法接管业务事务。他无法查看在健康资源实例中运行的应用程序是否能快速响应，以及并发访问有状态应用程序的用户是否已超过用户许可中所规定限制。
当您修复这些问题时，有三个时间点：问题发生之前、之际和之后。“之前” 是避免潜在问题的最佳情景。
您应该监控云中应用程序的性能，以便在问题出现之前发现它们。否则，一旦无法履行提供服务可用性的承诺，您就必须根据服务水平协议(SLA) 条款向用户提供信用、补偿以及数月的免费服务。每个服务水平协议 (SLA) 都是基于每个服务器上的应用程序的服务水平协议 (SLA) 对其服务、事务和服务器进行测量。
日志分析是最流行的性能监控工具，用于检查响应时间和并发性。但在监控位于多个位置的多个应用程序的性能时，这个工具使用起来很不方便。
更好的性能监控方法是设置一个性能指标指示板，以便在问题发生时查明问题性质。当某个指标显示负面效果即将出现时，您可以访问手边的指标工具，在用户发现问题之前，提前轻松地消除潜在的应用程序问题。
建议的性能指标包括：
- 有状态性
- 版本控制
- 资源阈值
- 用户阈值
- 数据请求阈值
- 响应阈值
有状态性指标描述应用程序在后续状态中正确响应的效果。尽管大多数应用程序本质上是有状态的，但您永远也不会知道它们什么时候会变为无状态。
版本控制指标描述新版本是否能有效避免破坏现有应用程序的功能，即使先前应用程序的有状态性在任务结束之前正确地从一个状态响应到另一个状态。给应用程序指定重复的版本名称或编号时，会破坏版本控制。
资源阈值描述云中的应用程序的资源消耗的动态平衡效果。阈值水平应该等于或低于能够被消耗的额外资源实例的最大数量。当资源消耗在工作负载需求峰值期间超过阈值水平，要分配额外资源实例。当需求返回至阈值水平或之下时，会释放已创建的资源实例并将其用于其他用途。
用户阈值描述用户根据供应商的用户许可中所规定的数量限制并发式地访问应用程序的效果。例如，如果许可将并发用户数量限制在 3,000 户但只允许最多 2,500 户同时访问，那么阈值水平可以设置为 2,000 个并发访问用户。如果并发用户数量等于或低于应用程序阈值，并且假设资源消耗和数据请求都低于它们各自的阈值水平，那么应用程序将持续可用。
数据请求阈值描述能够被快速处理的数据请求。这个阈值水平被设置为低于用户能同时发送的数据请求的最大数量和最大规模。如果数据请求数量超过阈值水平，将弹出一条消息，显示队列中有多少数据请求正在等待处理。
响应阈值描述应用程序响应用户的数据请求或应用程序的一部分响应另一部分的速度。阈值水平设置为低于最大可忍受响应时间。
响应阈值还描述应用程序提供的服务超时将发生的事。
在指示板开始显示潜在问题之前和您提前发现它们之后（在用户发现问题之前），都应该测试性能。性能测试不仅仅需要负载平衡工具。更好的性能测试方法是使用以下指标：
- 有状态性
- 版本控制
- 资源阈值
- 用户阈值
- 数据请求阈值
- 响应阈值
有状态性：描述应用程序从一个任务流向另一个任务的效果。功能状态从一个任务（比如一个图书馆用途是正确地提供识别信息）转到另一个任务（其中图书管理员检查书籍）吗？
版本控制：描述应用程序的新版本的执行效果。它正在破坏应用程序的逻辑吗？
资源阈值：描述多个应用程序使用多个资源的效果。资源实例正在使用的服务器的容量有多大？每个服务器占用的容量不应该超过 50%；在需求负载高峰期（比如圣诞节购物高峰期）有足够的额外资源实例吗？
用户阈值：描述有多少用户可以同时访问应用程序。系统能够承受并发用户数量突然增加的压力吗？
数据请求阈值：描述一个队列能容纳的数据请求的数量和时间。队列移动请求的速度快吗？
响应阈值：描述应用程序响应用户或数据请求的效果。应用程序中的任务超时时将发生什么事？应用程序会转到另一个任务继续服务用户吗？
如果您不了解如何开始构建自己的性能指标策略，下面是策略中应该包含的元素清单：
- 目的：策略和什么有关？
- 范围：确定策略的边界。
- 背景：什么人在做什么事？
- 动作：准备行动。
- 约束：利用它们。
下面详细讨论每个元素。
- 目的：策略和什么有关？
- 要帮助用户弄清楚策略和什么有关，阐述一下策略的目的。下面有一个模板示例，供您参考。
这个策略的目的是根据所有性能指标，确保所有云服务类型运行良好。这些指标包括有状态性、版本控制以及 4 种阈值类型：资源、用户、数据请求和响应。
- 范围：确定策略的边界。
- 通过确定策略的边界来定义范围。在这个范围内，指定供应商所提供的和用户所租用或订阅的云服务类型。如果供应商在接受用户承诺遵守约定的同时超出了范围，则应指定供应商需要做的事，以及用户如何单独或组合使用 SaaS、PaaS、IaaS 组件来报告性能的问题。
下面是每个指标的建议分值：
- 有状态性：任务的当前状态 100% 成功地响应后续状态。
- 版本控制：不破坏应用程序逻辑为 100% 成功率。
- 资源阈值：实例资源占用高达 50% 的服务器容量。
- 数据请求阈值：队列能够容纳的数据请求的指定数量。
- 用户阈值：最多允许许可中指定的用户数量的 70%。
- 响应阈值：用户察觉不到的响应延迟秒数（比如 5 秒）。
- 背景：什么人在做什么事？
- 用户最想了解的事是供应商是内部的还是外部的。其次，用户想了解的是供应商会使用什么性能指标工具来衡量内部应用程序在云中的运行效果。
用户可能也想了解性能指标与服务水平协议 (SLA) 中规定的服务可用性级别承诺之间的关系。
- 措施：准备行动
- 下面是一些关于采取行动的建议：
- 措施 #1：参考云计算指标策略中指定的指标工具。
- 措施 #2：表明是否一天 24 小时监控和测试性能。
- 措施 #3：需要关于使用指标工具监控和测试性能的培训计划。
- 措施 #4：预先通知用户访问管理、数据保护技术和虚拟机方面的计划维护和更新。
- 措施 #5：通知用户在使用性能指标方面将采取的前瞻性措施。
- 措施 #6：向其发送云计算性能指标策略副本供其审阅以及用户订阅云服务之前所要解决的问题。
- 措施 #7：设置一个性能指标指示板，以便在问题发生时查明问题性质。
- 约束：利用它们
- 有些约束可能会碍事，比如：
- 根据组织分配给用户的角色，不同的用户组被赋予不同的服务优先性。拥有管理权限（包括使用日志监控性能）的终端用户比没有这些权限的，只能访问 SaaS 应用的终端用户拥有更高的优先权。
- 性能指标和服务水平协议 (SLA) 例外服务。给您一些提示：这些例外服务为供应商不能直接控制的，如：光缆意外中断、计划维护（计划内和计划外）、以及从内部迁移到云的应用程序的前瞻性行为变化。
- 当系统性能大幅度低于承诺的服务可用性水平时提供服务赔偿。只要未能履行的服务保障不属于例外服务，则可充许用户有权要求获得信用、补偿或免费月份的补偿。在关于用户行使权利终止云服务的流程的退出条款中做出规定。
当您发现约束碍事时，最好的办法是利用它们。首先，您可以使用约束来增强性能指标策略的安全状态。其次，如果某个性能指标无法令人满意，当系统性能下滑至承诺的服务可用性水平之下时，应该准备采取补救措施来保护用户。
- 根据组织分配给用户的角色，不同的用户组被赋予不同的服务优先性。拥有管理权限（包括使用日志监控性能）的终端用户比没有这些权限的，只能访问 SaaS 应用的终端用户拥有更高的优先权。
如果您错失保持前瞻性的机会，会发生什么事？应该对前面讨论的场景 “服务停用的噩梦” 做出不同反应吗？即时修补并不总是有效；试图修补模块可能会失败，就像负载平衡一样。资源、用户、数据请求、响应阈值等性能参数以前就没有设置。
您可以求助于以下措施：
- 在一个远程位置备份应用程序、系统和数据（在灾难恢复计划中非常重要，以防发生地震）。
- 使用故障转移机制确保服务器将从失败的服务器接管应用程序和事务。
- 在服务水平协议（SLA）中作出解释，向用户提供因未能保障服务可用性的赔偿如信用、补偿或免费月份。
在快速恢复备份，立即执行故障转移机制，供应商制定未能遵守服务可用性承诺的服务水平协议（SLA）条款之后，您应该开始准备采取前瞻性措施：监控和测试性能，构建性能指标策略并付诸实施。
通过云计算性能指标获得前瞻性需要一点预先计划：您必须决定如何监控和测试性能；如何将云计算服务考虑在内来制订您的性能指标。
开发人员和技术维护人员必须与云服务用户沟通，了解他们对云服务性能的预期，以便在问题发生之前发现它们。
像生活中的所有事情一样，作为云用户，最重要的事是从供应商那里获取一份云计算性能指标策略副本并进行审阅，从您的立场来解决与供应商谈判之前的所有问题。
学习
-
本文作者在 “在云环境中平衡工作负载”、“云计算与网格计算” 和 “在云上构建积极的阀值策略” 三篇文章中讨论了阈值策略。
-
本文作者在文章 “改变应用程序行为：从内部转到云上” 中讨论了在将应用程序迁移到云时修改应用程序的前瞻式和反应式方法。
-
本文作者在文章 “云服务：降低风险，保持可用性” 中讨论了云服务安全性，以及如何减小云服务风险，确保更高的可用性。
-
在 developerWorks 云开发人员资源 专区中，查找并共享应用程序和服务开发人员为云部署构建项目的知识和经验。
-
在 developerWorks 上的 developerWorks 中国网站 SOA and Web services 技术专区 和 Industries 专区 中查找与本文主题相关的更多 developerWorks 资源。
-
后续步骤：了解如何 访问 IBM SmartCloud Enterprise。
- 加入云计算讨论组，了解和讨论云计算的最新技术、解决方案、趋势等内容。
获得产品和技术
-
获取用于 IBM SmartCloud Enterprise 的 产品镜像。
讨论
-
访问 developerWorks 上所有 优秀的云博客。
- 加入 developerWorks 中文社区。查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。