应用系统容量管理

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

应用系统容量管理

应用系统容量管理是构建IT服务的重要过程,是ITIL框架和ISO/IEC20000标准中的标准过程之一,应用系统容量体现了该应用系统的处理能力,特别是最大处理能力,对于系统的正常运行、业务的产能规划保障、市场活动的冲击等都有着非常重要的意义,而随着目前应用复杂度和系统架构复杂度的不断增加,对于容量的判断和管理是非常困难又非常必要的,这是ITSM体系中对于系统可用性、可靠性和健壮性的集中体现,同时,容量管理也决定了投入成本的最优化,随着业务地快速增长、对客户体验的关注度上升、对系统投入成本的管理等,都使得应用系统容量管理成为一个非常现实的需求和重要的管理目标。

应用系统容量管理作为打基础的项目,需要优先完成以下目标:

1、建立标准化的容量管理程序,从流程制度上规范各系统容量管理的目标和方法;

2、分批次对重要应用系统进行业务容量分析,完成关键容量指标(KCI)的制定;

3、结合业务产能规划,根据关键容量指标进行数据分析,建立关键容量指标的监控和预警体系,为下一步进行容量模型的分析建立基础。

一、容量管理目标

根据项目目标进行分解,分为管理办法发布、关键容量指标库制定以及关键容量指标监控三个子目标分别进行实现。

1、管理流程和规范制定:《业务系统容量管理办法》

该办法需明确业务系统容量管理的范围、涉及容量管理的一系列管理过程和环节,明确各参与方的工作内容和职责,制定容量管理程序,主要包括以下内容:(1)关键容量指标的建立、修改、监控、关闭等过程,明确需求、设计、开发、投产、运行等过程中关键容量指标的管理职责;

(2)业务产能规划中关键容量指标的应用过程,与业务产能管理相关办法相结合,明确业务产能变化、各类活动影响对于关键容量指标变化的管理过程;

(3)明确在达到系统容量指标阀值的情况下,对系统进行优化、扩容以及业务应对等活动进行的规范和管理环节,明确容量变化时各系统应采取的措施;

2、基础数据收集及分析:关键容量指标(KCI)梳理及入库

分批次对重要应用系统进行业务容量分析,完成关键容量指标的制定:按照各业务系统(或独立业务模块),根据应用系统对整体业务的影响程度,分批次建立各系统的关键容量指标,并对关键容量指标进行数据采集,为监控和分析建立基础,总体上分为6批次进行:

(1)运营类系统:根据目前的系统分布、影响程度,结合相关各系统的建设项目,分批次进行实施。具体而言,目前运营系统的关键业务指标和运行监控基本比较成熟,因此可直接运用目前的关键指标进行监控,且运营系统做为业务运营的关键性系统,产能影响明显,因此运营系统作为第一批关键容量指标系统纳入管理,运营类系统的容量指标重点是能够通过这些指标反应出系统对于业务产能的支持程度;

(2)互联网系统:从2013年开始,互联网类应用开始越来越重要,由于互联网应用系统具有周期短、变更频、社会影响大等特点,该批次的应用系统关键容量指标梳理作为年度容量管理项目的重点来进行,互联网类应用系统包括现有网站、商城、微信等应用系统,互联网系统容量指标应考虑能够承受的用户访问、客户端响应速度、集中的用户访问程度等;

(3)渠道类应用系统:渠道类应用系统是与客户直接交互的通道,其容量关系到对外通道的稳定性,是实现客户沟通的重要手段,对于容量的要求尤其重要,因此需对该类系统尽快完成关键容量指标的梳理和监控,渠道类系统关注的容量指标主要考虑一段时间内该系统的交易通过量;

(4)其他生产类系统:其他生产类系统按计划纳入第四批、第五批进行,主要包括基础架构类系统、风险控制类系统和其他辅助生产类系统;

(5)办公类管理系统:办公类管理系统也纳入容量管理计划;

应用系统关键容量指标的制定采用PDCA模式进行,即先根据最表面的业务应用场景为系统制定关键业务指标,再逐步深化分析影响业务指标的系统容量指标,逐步完成对该系统的容量数据的采集,为后期的模型建立数据基础,关键容量指标的完成标准为关键容量指标容量库的建立和管理状况,为系统建立容量阀值,定期发布系统容量报告。

3、监控管理系统建设:关键容量指标的监控与发布

建立重要系统关键容量指标的监控机制,应用系统关键容量指标库建立后,需要建立

常规性的容量监控机制,否则系统容量管理无法有效落实。

本着实用、高效的原则,经过若干软件产品的调研、评估和试用,我们觉得目前市面上并没有合适的软件可供试用,主要原因是:应用系统容量管理与实际的业务应用场景联系紧密,有其特定的要求,而一般软件产品为追求通用性,要么在功能上比较粗,为了适应某些场合需要进行大量的定制化开发,要么在功能上会有大量冗余,大部分功能根本不会用到,反而可能影响应用的效率,同时考虑到价格因素,我们觉得通过自建系统更容易贴合目前各系统容量管理的实际需要。

常规性的容量监控机制,主要包括以下几个方面:

(1)关键容量指标库数据采集:通过从各个系统或软件定期收集相应的数据,导入数据库,根据不同容量指标反应的容量状况,数据采集的频率有所差别,对于性能影响较大的数据,需要采取实时或准实时的方式进行,对于容量影响不明显的数据,则可将频率放宽,如天、周、月等;

(2)实时监控页面:对于变化频繁的关键指标,以实时的方式收集数据,经过计算后可直接反应到界面上,提供给值班人员、监控人员进行监控,同时具备报警功能,满足报警策略后即进行邮件、短信等报警;

(3)预测报告:根据运营产能规划,定期自动生成容量报告,具备一定的预测功能,即输入业务量预估后,自动进行容量影响分析,提供给容量管理人员进行分析,更好的对各类活动、扩容需求等进行数据支撑;

二、容量管理内容

不同的应用系统容量管理内容不尽相同,随着系统复杂程度的上升,容量管理的复杂度也几何上升,系统间存在的各种联系,进一步加剧了容量管理的难度,因此,我们对应用系统容量进行层次划分,以便更好地进行分类、分层次、有目标的实施。

系统容量管理代表了该系统的处理能力,即一段时间内系统能够承受或处理的最大负载,所谓负载,就是业务处理能力或者服务能力,不同的应用系统所表现的会因其功能不同而不同,比如信用卡审批系统中的审批处理量、客服中心的人工处理电话量等。容量管理包括动态和静态两种类型,静态类型的容量管理一般指相对固定的容器可装载量,比如存储空间、数据库表空间等,这部分空间事先分配,满了就溢出,一般设定阀值,达到阀值即报警、处理,清理空间或扩大空间等;动态类型的容量管理则比较困难,一般指负载

相关文档
最新文档