|
|
知识路径： > 信息系统开发和运行管理知识 > 系统运行管理知识 > 系统的成本管理、用户管理、安全管理、性能管理 > 性能及能力管理 >
|
被考次数：12次
被考频率：高频率
总体答错率：37%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：19个
|
|
|
|
|
系统性能评价围绕计算机系统本身开展，将对其系统基础设施的工作性能指标进行综合评测，并采取必要的技术和管理措施使系统资源效能最大化。前一节所述的系统性能评价和调优实际上作为能力管理流程中的一个步骤为IT系统的能力管理提供技术分析和支持。能力管理从一个动态的角度考察组织业务与系统基础设施之间的关系，它要考虑这三个问题：
|
|
|
|
.IT系统的成本相对于组织的业务需求而言是否合理。
|
|
|
|
.现有IT系统的服务能力能否满足当前及将来的客户需求。
|
|
|
|
|
|
|
|
|
|
能力管理是一个流程，是所有IT服务绩效和能力问题的核心。它所涉及的管理范围包括：
|
|
|
|
（1）所有硬件设备，包括PC、工作站和各类服务器等。
|
|
|
|
（2）所有网络设备，包括LAN、WAN、交换机和路由器等。
|
|
|
|
（3）所有外部设备，包括各种的大容量存储设备、打印机等。
|
|
|
|
（4）所有软件，包括自主开发和外购的系统和应用程序软件。
|
|
|
|
（5）人力资源，所有参与IT系统运营的技术人员和管理人员。
|
|
|
|
能力管理的流程将涵盖以上每一项内容。IT系统的业务支持能力不仅取决于IT系统的各类基础设施的良好运转，还离不开一套规范的能力管理流程和技术、管理人员对技术和管理流程的正确把握。
|
|
|
|
|
|
能力管理的目标是确保以合理的成本及时地提供IT资源以满足组织当前及将来的业务需求。具体而言能力管理流程的目标有以下几点：
|
|
|
|
（1）分析当前的业务需求和预测将来的业务需求，并确保这些需求在制定能力计划时得到了充分的考虑。
|
|
|
|
（2）确保当前的IT资源能够发挥最大的效能、提供最佳的服务绩效。
|
|
|
|
（3）确保组织的IT投资按计划进行，避免不必要的资源浪费。
|
|
|
|
（4）合理预测技术的发展趋势，从而实现服务能力与服务成本、业务需求与技术可行性的最佳组合。
|
|
|
|
|
|
能力管理的过程是一个由一系列需要反复循环执行的活动组成的流程。下图中显示了这一流程的各个环节，即各项具体的技术和管理活动，它们包括能力数据监控、能力评价和分析诊断、改进调优和实施变更。这些活动的前提是构建一个存储所有业务、管理、技术和财务等类型数据的能力数据库作为管理和评价的平台，规划和构建这个数据库也是能力管理中的一项重要准备活动。
|
|
|
|
|
|
|
|
|
|
|
|
能力数据库是成功实施能力管理流程的基础。能力管理需要将管理流程中采集到的各类与系统运营有关的数据存入能力数据库中。这些数据主要包括技术数据、业务数据、资源利用情况数据、服务数据以及财务数据。规划和构建能力管理数据库时应当考虑如下问题。
|
|
|
|
|
|
（2）指定专人负责能力数据库的更新和维护，其他人只有查阅权限。
|
|
|
|
|
|
能力数据库可能是一个概念上的数据库，它可能由许多个物理上被彼此分开的存储空间组成。造成这种状况的原因很可能是不同的硬件和软件上的监控工具记录数据的格式不一致，从而很难转移到同一个存储空间。
|
|
|
|
能力管理数据库中的数据信息有两个用途：第一，为制作提交给管理层和技术人员的绩效报告和能力管理报告提供基础；第二，用于预测未来的能力需求。
|
|
|
|
|
|
一个成功的能力管理流程的基础是能力管理数据库。该数据库中的数据被所有的能力管理的子流程存储和使用，因为该信息库中包含了各种类型的数据，即业务数据、服务数据、技术数据、财务数据和应用数据。
|
|
|
|
能力数据库中的数据构成了性能评价和能力管理报告的基础，这些报告将会提交给技术和管理部门。同时这些数据也用来进行更多的能力预测，为将来的能力需求规划提供支持和依据。
|
|
|
|
|
|
|
|
①业务数据。拥有高质量的业务数据对于系统能力管理和规划十分重要，因为IT系统乃至整个企业组织的管理层需要考虑组织当前和未来的业务计划对IT系统的容量的影响，从而一方面对IT系统进行能力规划，另一方面有效、合理地指导财务和人力预算，更好地进行成本控制。这些业务数据也可以用来预测和证实业务驱动的变更是如何影响系统的能力和绩效的，一般而言，业务数据包括如下的内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
②服务数据。能力管理流程要不断考虑IT架构对于用户工作的影响。为了使能力管理做到以服务为导向，服务数据需要被存储到能力数据库中。举个例子，交易响应时间是一种典型的服务数据，说它是服务数据的关键在于它是与一定服务级别相对应的，反映了服务的水平状况。
|
|
|
|
另一个服务数据的例子是对作业进行批处理的时间。总的来说，在服务级别协议和服务级别需求中确定的要求将会提供能力管理流程需要记录和监控的数据，为了保证达到服务级别协议中的服务目标，服务级别管理的阈值应该被包括进去，这样监控活动就能根据这些阈值进行测量然后产生异常报告。
|
|
|
|
通过设置高于或低于实际目标的阈值，可以唤起一个系统动作或人为操作来避免破坏既有的服务级别协议。
|
|
|
|
③技术数据。IT系统的大部分组件的使用都应受到一定的限制。如果不考虑使用级别的限制，资源一旦被过度使用，就会影响使用这些资源的服务的质量。例如，推荐的CPU的最大利用率为80%，一个共享的局域网带宽的使用不能超过40%。
|
|
|
|
当然某些组件还有物理上的使用限制，例如通过一个网关的最大连接数不能超过100，对某种类型的硬盘的使用不能超过其物理容量15 GB。这种对于独立的组件的物理约束和限制，可以被监控活动用来作为产生警告和异常报告的阈值。
|
|
|
|
④财务数据。能力管理数据库里还可能存有财务数据。比如，能力计划中实现IT基础设施组件升级所需耗费的成本的信息、目前的每期IT预算等信息。这些财务数据的来源如下。
|
|
|
|
|
|
|
|
|
|
这些数据应该在IT系统的财务管理中已有充分体现，在这里出现是因为能力管理需要考虑IT服务能力的调整来应对未来的业务需求的变化。
|
|
|
|
⑤资源应用数据。系统中包含的资源数据种类繁多，能力管理数据库中应该能提供有关各类资源组件的按分钟、小时和天等各个时间粒度存储的使用状况的应用数据。考虑丰富的粒度结构的同时要考虑一个数据过时合理丢弃的问题。举个例子，上一周的按分钟粒度搜集的数据这周可能不再有用，上个月按天粒度搜集的数据可能不再有用，不过上个月每天平均的数据却可能需要通过统计并保存起来。无用数据的不断累积是对数据库资源的极大浪费，应该定时丢弃，而有用的历史信息仍然需要被存储。能力数据库应该考虑这些需求并提供相应支持。
|
|
|
|
资源应用数据的搜集应当是针对每一个组件和每一项服务的，我们举例如下表所示。
|
|
|
|
|
|
|
|
能力管理将存储一切与IT系统、服务和客户相关的数据。目前已有很多跨平台的监控和存储性能数据的软硬件工具，对这些工具的选择一定要基于对能力管理需要的考虑。
|
|
|
|
|
|
对应于输入的数据能力数据库也有数据输出。能力数据库主要提供与系统能力和性能相关的数据信息，供决策者和其他相关管理部门在其他管理流程中使用。这些信息主要以报告的形式提供。
|
|
|
|
①服务和组件报告。每个基础组件都应该有相应的负责控制和管理的技术人员和负责整体服务的管理人员。生成的报告说明服务和相应的组件的运转性能和最大性能的使用情况。
|
|
|
|
②例外报告例外报告在某一组件或者服务的性能不可接受时作为能力数据库的输出产生。例外可以是针对任何存储在能力数据库中的组件、服务和评测。举个例子，某台服务器的CPU的使用率连续3个小时超过70%，这远远地超过了预期，因此会产生一个例外报告。例外报告可以作为判断服务级别是否被打破的数据来源。
|
|
|
|
③能力预测。为了保证IT服务提供商提供持续可靠的服务水平，能力管理流程必须对未来的成长需求进行预测，必须具体对每个组件和每项服务做出预测。预测方法很多，因具体组件技术的不同而不同。由新的系统功能引起的负载变更应当被认为是业务需求的成长带来的负载变更。举个简单的例子，服务器CPU的使用率与企业的系统用户数之间就是这个关系，通过分析这类数据可以发现用户数量的增加对系统配置中各组件的负载影响。
|
|
|
|
如果对未来能力需求的预测显示需要增加某类系统资源，那么这项需求就应该被加入IT预算中。
|
|
|
|
|
|
对每个组件运行和系统整体运营进行持续性监控的目的在于保证所有的软件和硬件都能得到最佳利用，确保所有的为业务服务的目标都能被实现。并且能够根据监控结果对组织业务量进行合理预测。在选择监控对象时，如果对所有组件都进行监控，其成本是相当昂贵的，也是相当难以实施的。因此，必须选择基础设施中对关键业务提供支持的组件进行监控。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这些监控数据大体上被分为两类，一类是监控系统容量（比如吞吐量），另一类是监控系统的性能（比如响应时间）。
|
|
|
|
对部分组件的监控活动应当设有与正常运转时所要求基准水平，亦即阀值。一旦监控数据超过了这些阀值，应当触发警报，并生成相应的例外报告。这些阀值和基准水平值一般根据对历史记录数据的经验分析得出。一种情况是为特定的组件设定监控阀值，比如监控一个CPU在某一小时内的使用率不超过80%；另一种情况是为特定系统服务设定基准水平，比如监控某一项在线服务的响应时间不超过2秒，或者该系统服务一小时内处理的服务请求数不能超过10 000。
|
|
|
|
以上这些阀值必须低于不影响该项资源（或者该项服务所依赖的资源）正常运转的最大值，或者低于服务级别协议（SLA）中规定的相应值。因此，超过阀值的时候应该还有机会采取纠正措施，以防止超过SLA规定，使得系统性能进一步恶化。
|
|
|
|
|
|
很多的系统服务级别协议都将终端用户响应时间（user response time）列为监控对象，但对这项监控需求的支持往往不力，在这介绍几种获取系统和网络服务的用户响应时间的方案：
|
|
|
|
（1）在客户端和服务器端的应用软件内植入专门的监控代码。这可以提供“端到端”的服务响应间隔或者定时采样，将系统总体响应分解为各个组成部件的响应。这类工具提供对应某一项服务的用户端真实的响应时间。
|
|
|
|
（2）采用装有虚拟终端软件的模拟系统。这类客户端系统上装有终端模拟软件和专门用于检测作业响应时间的软件，它们可以提供“端到端”的服务响应时间，尤其针对复杂的多阶段作业可以提供具有代表意义的时间响应值。与前一种相比，这里提供的响应时间是虚拟的，而不是真实的。
|
|
|
|
（3）使用分布式代理监控软件。分散在网络各节点（比如Internet上不同的国家）的代理组成了一个分布式监控系统，它可以生成大量来自不同地域的作业，并不定期对它们进行监控评测。这类响应时间数据也不是真实用户的响应时间。
|
|
|
|
（4）通过辅助监控设备来跟踪客户端样本。这种方法依赖于网络监控系统，即通常被安插在合适的网络节点位置的“嗅探器”。“嗅探器”可以定时监控和记录通过某一网络节点处的通信量。而对这些记录下来的通信量做进一步分析便可以得到服务的响应时间。这类响应数据与真实世界的数据的相似和接近程度取决于“嗅探器”在系统基础架构中的物理和逻辑位置。
|
|
|
|
当然在很多情况下，以上这些系统或者方法常常会被混合使用。由于IT系统涉及到众多的单位和部门，以及种类繁多的信息技术，对响应时间的监控是一个相当复杂的过程。
|
|
|
|
|
|
首先，能力监控活动获得了有关系统本身运行的部分性能指标，其中包含各类监视项目的具体性能参数。这些项目既包括各类服务器的CPU、内存、磁盘，也包括网络交换机、路由器，还可能包括服务器运行环境中的各类电力和空调等辅助设备。利用这些数据采用本章第一节中相关合适的性能评价方法和工具，可以完成部分或所有的系统工作能力评价任务。
|
|
|
|
除此之外，更重要的是，经过对由监控活动所搜集的数据进行的分析可以得出其有关情况的变化趋势，从而帮助确定系统服务正常的使用情况或服务级别，或者为它们制定基准线。通过定期的监控并将监控结果与这些基准线进行比较，可以确定单个设备或组件的使用情况或服务运营的异常情况，从而据此报告对SLA的履行情况。此外，根据这些分析的结果还可以预测未来资源的使用量以及比照预期增长率来监控实际的业务增长率。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对每一类资源和服务的使用需要分别从短期、中期和长期三个角度进行考虑，考虑它们在每一个时间跨度上的最大、最小及平均占用情况。通常，短期可以理解为一天24小时，中期为一周到一个月，长期为一年。这样，不同IT服务的使用情况随时间跨度上的变化便可以一目了然。
|
|
|
|
分析某一项资源的使用情况时，既要考虑该资源的总体利用情况，还要考虑各项不同服务对该项资源的占用情况。这样，在某些系统服务需要做出变更时，我们可以通过分析该服务目前的资源占用情况对变更及其对系统整体性能的影响进行预测，从而对系统变更提供指导。举个例子，如果一个被A、B两项服务占用的处理器在高峰时段的使用率是75%，我们需要知道这75%的处理器资源被A、B两项服务各自占了多少。假设系统本身占用5%，那么剩下的70%如果被A、B两项服务均分为35%和35%，不管A还是B对处理器占用翻倍，处理器都将超出负载能力；如果剩下的70%中A占60%，B占10%, A对处理的占用翻倍会导致超载，但B对处理器的占用翻倍并不会导致处理器超载。
|
|
|
|
|
|
在对监控活动采集的数据进行分析后，应当确认可以对哪些配置项进行调整以提高系统资源的利用效率和改进相关IT服务。
|
|
|
|
在实施调优方案之前，最好对调优方案进行测试以验证它的可行性和必要性。通过测试可以了解是否可以通过需求管理来避免实施有关调整，或者在实施前通过模拟测试表明计划的某项变更的有效性。
|
|
|
|
|
|
.均衡负载。作业请求可能会通过某一特定网关到达服务器主机，这取决于请求开始的位置。通过平衡到达各个网关的作业比例，可以达到调优目的。
|
|
|
|
.均衡磁盘I/O。有效和有策略地存储数据，减少对数据的竞争使用。
|
|
|
|
.定义一套良好的锁规则说明锁的级别以及何时应该用锁。一般来讲，尽量延迟锁的使用（比如延迟至记录更新之时）可以提高其性能。
|
|
|
|
.有效利用内存。根据实际情形调整应用对内存的占用大小。
|
|
|
|
关于有效利用内存的问题，一个进程调用已被读入内存的数据而进行处理比顺序读取数据文件的效率高，况且，进程也会竞争更多的内存资源，过多的请求还会导致页面交换时CPU使用率超载和延迟。
|
|
|
|
此外，在执行调优措施之前，最好充分考虑是否有别的特殊的调整办法可以达到同样的目的，这样不必实施上面所述的这些变更，从而节省成本和精力。
|
|
|
|
|
|
实施的目的主要在于将监控、分析和调优活动所确定的变更引进实际的服务运营之中。任何变更的实施都必须通过一个严格而正式的变更流程来进行，这样，可以将变更的影响及响应的风险控制在可接受的水平内。
|
|
|
|
在实施有关变更后，仍然需要进一步地监控以便合理评估变更的影响。根据评估结果。管理人员可以决定是否需要进一步实施其他变更或撤销已经实施的变更。系统实施变更后将会影响其提供给客户的主要应用服务。这些类型的变更所带来的影响和风险会大于其他类型的变更，在一个正式的变更管理流程的控制下来实施变更会带来以下好处。
|
|
|
|
|
|
|
|
|
|
|
|
在实施有关变更后，仍然需要进一步地监控以便合理评估变更的影响。根据评估结果。管理人员可以决定是否需要进一步实施其他变更或撤销已经实施的变更。
|
|
|
|
|
|
能力管理的高级活动项目包括需求管理、能力测试和应用选型。
|
|
|
|
|
|
需求管理的首要目标是影响和调节客户对IT资源的需求。需求管理既可能是由于当前的服务能力不足以支持正在运营的服务项目而进行的一种短期的需求调节活动，也可能是组织为限制长期的能力需求而采取的一种IT管理政策。
|
|
|
|
短期需求管理，一般在IT基础设施内某个关键组件发生局部性故障时进行，而长期需求管理一般发生在进行某个组件的升级显得很必要却又似乎“不划算”的情况下。需求管理需要掌握有哪些服务项目在多大程度上需要依赖某项IT资源，以及各项服务必须运营的时间安排。这样，需求管理才能确定对某些资源进行调节所带来的影响。
|
|
|
|
|
|
模拟测试的目标是分析和测试未来情况发生变更对能力配置规划的影响。在能力管理流程中，它可以帮助能力管理人员在系统资源和系统服务的管理上回答“如果……怎么办”一类的问题，从而增强能力规划的前瞻性和适应性。
|
|
|
|
|
|
应用选型作为能力管理的一种活动也是整个应用系统设计开发过程的一个基本部分，进行应用选型的主要目的在于对计划性应用系统变更或实施新的应用系统所需的资源进行估计，从而确保系统资源的配置能够满足所需服务级别的需求。
|
|
|
|
应用选型要考虑的第一个问题是在初始的系统分析和设计阶段就必须确定所需的服务级别。这样可以保证在应用系统设计开发过程中可以采取恰当的技术和手段，从而更好地满足期望的服务级别。在应用系统设计开发周期的开始而不是后来的某个时候考虑所需的服务级别，可以降低整个系统开发过程的成本和难度。
|
|
|
|
应用选型需要考虑的另一个问题是新建应用系统的弹性。有时候单个组件的故障可能导致整个IT基础设施的瘫痪，但如果在资源管理中充分考虑到IT基础设施中脆弱但关键的那些组件并采取适当的预防措施，就可以降低单个组件的故障对整个系统的影响，从而提高IT基础设施的弹性。
|
|
|
|
|
|
|
|
开展能力管理流程中的各项活动的同时，活动产生的信息一方面被存储到能力数据库中，另一方面还必须根据这些数据信息编制和更新能力计划。编制能力计划的主要目的是记录当前资源利用程度及服务绩效，以及在充分考虑业务战略和计划后预测组织未来IT服务所需要的IT资源。
|
|
|
|
能力计划的编制和更新必须按照规定的时间间隔进行。重要的是，它作为一个投资计划必须根据业务员或预算周期每年发布一次，并且要在新的预算谈判开始之前完成。同时，为了反映业务计划的变更，每个季度对能力计划进行一次更新也是必要的，季度能力计划更新还可以表明以前所做预测的准确性并据以制定或修改有关建议。
|
|
|
|
一份典型的能力计划应该包括，计划范围、假设条件、管理概要、业务说明、服务概要、资源概要、服务改进方案、成本核算模型及建议等内容，其中服务概要和资源概要均包括对当前情况的介绍和对未来情况的预测两部分。
|
|
|
|
|
|
管理人员需要定期对能力管理流程实施的效率和效果进行评价和考核，以确保能力管理流程的运营符合成本效益原则。
|
|
|
|
|
|
在对能力管理流程的运营结果进行评价和考核之后，能力管理人员应当向IT服务提供方和组织的高层管理人员制作和提交能力管理报告。能力管理报告的内容主要包括能力计划实施的控制信息、流程实施中所用的资源以及有关服务能力和绩效改进活动的进展等方面的情况。
|
|
|
|
此外，当能力管理流程的过程中出现特殊情况时，还应针对以下情况提交有关例外事项报告。
|
|
|
|
|
|
|
|
|
|
|
