容量管理的趋势分析（ITSS）
.20150626 MONICAZHANG续上
容量管理流程 1. 流程政策在设计和实施面向最终客户或用户的IT服务时，政策可以起到指导作用。政策可以是全局的，适用于IT提供的各项功能；也可以仅适用于IT部门提供的某项功能。 ITSS培训流程政策推动了流程设计。在设计流程时，可以从流程政策中提取输入信息。如果流程政策没有被清楚定义，流程往往无法满足用户的期望值，也无法确保能够持续一致地提供高质量的IT服务。在容量管理流程中，共有8项流程政策。政策1: 业务交易(Transactions)针对每一个业务部门和提供的服务，容量管理流程提供了一种方法，将业务需求转换成可衡量的事务(Transaction)。
原则/最佳实践:89. IT容量必须符合业务的需求。90. 通过定义和衡量端对端的业务交易(Transaction)，确保IT和业务的目标相吻合。 ITSS团购
91. 业务部门确定需求，IT部门分析和判断其影响和成本。启示：92. IT必须主动地去了解业务部门的工作流。
93. 业务部门必须提供资源，帮助IT了解其业务。94. IT部门必须设置全职的角色，支持该工作。
95. 必须制定计划，获得所有业务部门的支持。政策2: 容量规划周期 ITSS认证容量管理流程定期更新需求、资源、工作负载、性能和容量计划等。
原则/最佳实践:96. 容量规划周期必须和财务规划周期吻合。
97. 对需求和工作负载的规划周期至少每季度次一次。98. 对资源的规划每两个月一次。
99. 对性能的规划必须每月一次。 ITSS工具启示：100.必须支持和集成多个不同的规划周期。
101.必须制定一个被大家广泛理解的方法，用以分析环境、回顾和更新计划。102.IT架构本身必须具有足够的灵活性，支持对架构的不断改进。政策3: 关键事务(Transaction)报告容量管理流程必须向每个业务部门提供其关键事务的报告。
原则/最佳实践:103.定期的关于关键事务及其指标的报告，必须简洁，并采用图形化方式。104.报告的定义和生成是集中式的，以保证在整个组织内的一致性和提高效率。启示： ITSS考试
105.必须建立问责制。106.对预测的需求和实际需求之间的差异，必须评估其后果。政策4:衡量指标的定义容量管理流程定义了对关键业务事务的监控和衡量，以及为了支持这些关键事务，定义了内部衡量指标。
原则/最佳实践:107.衡量指标必须易于理解和易于测量108.衡量指标必须有助于理解IT部门的目标 ITIL培训
109.每个指标必须和IT部门的根本价值相吻合110.对衡量指标必须进行综合平衡考虑启示：111.必须建立监控和测量系统以收集衡量指标
112.必须充分理解IT部门的使命113.必须引入一种方法，确保随着时间迁移，及时修订衡量指标政策5: 趋势分析和预测容量管理流程提供了业务、服务和资源的历史监控数据，支持对容量需求的趋势分析和预测。
原则/最佳实践: 114.必须定义监控数据的保存时间和周期115.为了提高趋势分析的效率，需要将业务数据和内部监控数据集中存储
116.需要预先主动式地确定在何处以及在何时增加容量 ISO20000培训117.必须结合成本因素平衡考虑提供的容量－－是提供充足的容量，还是支持负载峰值。启示：
118.针对存储和趋势分析，必须有相应的技术支持119.必须建立趋势分析的方法
120.必须在问题发生之前预先进行投资政策6:单一接口点容量管理流程是所有容量监控定义和报告的单一接口点
原则/最佳实践:121.为服务级别定义提供有价值的、精确的输入
122.了解现实可行的监控，支持端对端的服务定义123.必须在各个业务部门和IT部门之间建议一个统一的方法 ITSS体系
124.充分了解支持端对端业务交易的各个配置项启示：125.必须采用相应的技术，实现收集、存储和汇报的自动化，尽可能减少人为参与
126.容量管理流程的角色必须和服务级别管理、运维管理的角色密切合作127.对这些角色，需要均衡发展的领导能力和技术技能政策7:性能管理容量管理流程为超出阀值的异常分析提供技术支持
原则/最佳实践:128.通过对事务的端对端的全局了解，尽可能减少对系统、网络、应用的局部优化129.必须充分利用现有的容量，以迅速解决性能相关的突发事件
130.当前的服务级别测量指标需要通过实际得到的指标进行验证启示：131.这种技术支持是推动持续流程改进的主动式资源，而不应该被视作另一种形式的被动式响应的资源
132.必须建立根源分析机制，支持主动式的持续流程改进和被动式的问题管理133.该角色必须维护一个总体的IT架构图
134.建立指导原则，促进各个部门间的合作和支持 ITSS软件政策8:持续改进容量管理流程引导流程持续改进项目，寻找机会平衡业务需求和相关IT费用。
原则/最佳实践:135.必须正式定义和采用持续改进的方法
136.采用低成本的服务改进措施，减少服务成本137.必须充分了解IT架构的优缺点
138.必须了解潜在的性能和容量问题，以防止突发和紧急的事件启示：139.对所有的改进项目必须进行投资回报分析
140.需要将企业文化从“发生问题后再修复”转换成“主动的持续改善”141.在企业内部推动对全面质量管理工具和方法论的深入理解142.必须了解和避免不切实际的期望
待续http://ITIL-foundation.cn/thread-51225-1-1.html本帖关键字：ITSS ISO20000
页:
[1]