本帖最后由 monicazhang 于 2015-8-27 14:14 编辑
20150827 淡然
续上
2. 流程详细说明
2.1. 指导方针
指导方针是为客户和最终用户设计与实施服务的策略。指导方针可以是普遍适用的－它可以应用在各种不同的功能，或应用于特定的功能。
正是这些指导方针协助流程设计，当为组织设计流程时，所需的输入正是从指导方针中得到。
若没有经过很好设计的指导方针，将会使流程既不能满足客户的期望，也不能满足服务实施的标准。
下面就是某公司在设计、运行容量与性能管理流程时应遵循的指导方针： ITSS考试
指导方针1：容量与性能管理流程为每个业务部门和实施的服务提供了分析需求，形成可测量的交易的方法
指导原则/最佳实践：
l IT容量必需满足业务需求
l 通过定义和测试端到端的业务交易来确保业务目标与IT目标的整合
l 业务设定了需求，IT分析和决定内在含义和成本
暗示：
l IT必须首先去理解业务部门的工作流程
l 业务部门必须提供资源帮助IT部门理解他们的业务
l 业务部门必须将IT视为有价值的合作伙伴
l 需制定一个让所有业务部门支持和参与的计划
好处：
l 提供了量化客户需求方法
l 根据业务需求确定IT方向和实际的实施方法
l 通过对业务需求的准确支持增加客户满意度
指导方针2：容量管理流程应提供对需求、资源、工作量、性能和容量计划的日常更新机制
指导原则/最佳实践：
l 容量计划的计划周期必须与预算周期匹配
l 需求与工作量计划的计划周期必须至少一年进行2次
l 资源计划必须每2月执行一次
l 性能计划必须每月执行一次
暗示：
l 部门内应支持和集成多个计划
l 需引入环境分析和计划检查与更新方法
l 需建立支持IT基础架构灵活性和不断变化的架构
好处：
l 减少由于没有预料到的容量缺乏而引起的问题带来的风险
l 容量利用在预算范围内
l 购买额外的硬件、软件许可和服务的成本降低
l 用于弥补差距的人员费用降低
指导方针3：容量管理流程应向每个业务部门提供关键交易的报告
指导原则/最佳实践：
l 关键交易的阶段性报告以及对每个业务部门的指标必须一致
l 集中化的报告定义和报告制定为组织提供了统一性和有效性
暗示：
l 需要建立负责制的文化氛围
l 应能够识别预测需求的偏差
好处：
l 客户关系基于良好的定义和沟通
l 成本因素被识别和协商
指导方针4：容量管理流程为关键业务单元交易定义测量方法和支持这些交易所需的内部指标
指导原则：
l 指标必须是容易理解和测量的
l 每个指标均有助于理解组织的目标
l 每个指标都应该与组织的内在价值匹配
l 所有的指标应该是平衡的
暗示：
l 业务部门认为IT懂得业务
l 建立测量系统以便得到测量指标
l IT应充分理解业务部门的使命
l 引进适合指标的方法论
好处：
l 提高服务性能的特性水平
l 提高服务质量
l 提高客户满意度
指导方针5：容量管理流程应提供历史数据来支持趋势分析和额外容量需求预测
指导原则/最佳实践
l 测量数据的保存期限应首先定义
l 为了有效地分析趋势变化，应集中存储测量数据
l 应主动决定何时何地增加容量
l 应识别出平衡性能和峰值的成本
暗示：
l 必须具备支持存储和趋势分析的技术
l 应建立趋势分析方法论
l 在问题出现以前就已经进行了容量投资
好处：
l 对系统、网络和应用的执行情况进行更加准确的预测 ITSS认证
l 对计划提供有效支持
指导方针6：容量管理流程是所有容量测量和报告的联络点
指导原则/最佳实践：
l 为服务级别定义提供准确的有价值的输入
l 理解现实的测量来支持端到端的服务定义
l 在业务部门和IT基础架构定义一套一致的方法
l 支持端到端业务交易的配置被很好地理解
暗示：
l 必须采用没有人工干预的先进的技术来实现收集、存储、报告
l 容量管理流程角色必须与服务级别管理流程和运维管理流程角色紧密工作
l 平衡领导力和技术水平
好处：
l 采用一致的渠道与业务部门沟通
l 有效的IT资源
指导方针7：容量管理流程为上限分析提供技术支持
指导原则/最佳实践：
l 端到端的交易减少了本地系统、网络或应用的优化
l 现有的容量必须有效使用来快速解决性能问题
l 现有的服务级别措施应被验证
暗示：
l 这个技术支持不能被看作另一个解决问题的资源
l 需建立根本原因分析方法
l 保持IT基础架构系统的视角
l 必须在组织内建立合作的氛围
好处：
l IT基础架构的容量理解的持续提高
l 更有效地利用IT资源
2.2. 流程关系图
下图示出了与P03其他流程间的关系和数据流。
l 可用性管理
性能和容量问题导致系统不可用，由于容量和可用性间的相互依存的关系，所以可用性与容量管理应紧密结合。容量管理需要了解可用性技术手段，以便准确计划容量。容量管理与可用性管理常采用相同的工具，他们均需要采用通用的计划、监测和告警工具，以及CMDB。
制定容量计划时，需要从可用性计划中提取容量相关的需求。
l 连续性管理
容量管理确定了恢复方式中的容量需求，在调用过程中为了达到预定的性能和交易水平所需的最小硬件和软件配置。
很重要的一点，恢复所需的容量必须与生产环境的容量相匹配。容量计划应能够满足IT服务连续性的需求，RFC应评估针对每一种恢复方式的影响。
l 安全管理
容量管理为安全管理提供容量计划，安全管理制定安全计划，供容量计划分析。
l IT预算管理
容量计划中包含成本概要，采购建议等，制定采购建议应与预测的预算相比较。
IT预算管理评估容量管理提供的容量设计与计划来确定满足这些容量计划的适当的成本。
l 变更管理
容量管理代表变更管理委员会（CAB）来评估对现有的容量基础上变更所产生的影响，并且识别出额外的容量需求。容量管理需要密切监测容量变更所产生的累计效果。
容量计划中额外的容量需求形成变更请求（RFC），其他提交RFC的原因还包括计划内升级、调优、增加新的监控工具等。
变更管理发出工作单、容量与性能管理返回工作单状态。
l 服务级别管理
容量管理支持服务级别管理来保证达到新的或变更的需求的性能与容量目标。性能依赖于特定的工作量，这些是在SLA中定义的。当出现容量或性能问题时，需要容量管理协助服务级别管理流程制定和检查OLA和外部合同。
容量管理向服务级别管理提供性能数据和交易量数据。
l 配置管理
容量数据库（CDB）是CMDB的子集，配置管理为容量管理提供CI信息，CDB中存储有业务数据、服务数据、技术数据、财务数据（如成本数据）和利用率数据。容量管理通过CMDB为其他服务流程提供如性能数据、CI信息等数据。
l 上线管理 ITSS培训
容量管理流程协助确定上线发布策略，尤其通过网络进行发布时。容量管理提供性能与容量计划和专家来支持上线管理。
上线管理流程为容量管理提供系统需求说明书，在上线之前，使用自动化的工具对系统进行容量审计，若没有足够的容量来支持上线计划中的系统需求，将推迟系统上线。
本帖关键字：ITSS
转播
分享
淘帖
()