ISO20000体系文件-服务级别管理程序

1、服务级别管理程序(#CP-0010)目的本过程描述公司采用的过程方法以有效地管理服务级别管理过程。该文件表明公司IT部门符合IS0 20000中对服务级别管理过程(IS0 20000-1:2005 6.1)的要求。范围IT服务管理体系中的服务级别管理覆盖Internet服务、管理网络服务、管理安全服务和数据中心服务。1.服务级别管理过程1.1服务级别管理策划（计划）开发服务级别管理并以ITSM计划为目标。1.2定义服务级别管理（执行）SLM建立框架使IT部门通过计划、实施和进行服务交付管理关注客户。服务级别管理管理和协调服务级别，包括：服务要求、服务目标和期望的协议测量和报告达到的服务级别调查

2、纠正措施和正在进行的服务改进项目1.3 SLM的控制和评审（检查）为符合IS0 20000-1:2005, IT部门引入框架检查服务级别管理过程的结果。IT部门有责任每月评审可用性级别并提交关键绩效报告。1.4 SLM反应行动（改进）IT部门应按月评审不同服务的服务级别并指定员工评估和监控服务级别。如果没有达到服务级别，IT部门应采取改进措施确定问题。2.服务级别管理程序2.1服务目录服务目录定义IT部门提供的所有服务。（略）2.2服务级别协议服务级别协议是IT部门需要达到的正式文件。2.2.1有效期有效期在相关SLA文件中明确。在有效期内，SLA有效，直到新的协议签定为止。2.2.2授权2.

3、2.3 沟通2.2.4联系2.2.5服务时间所有服务需要7*24小时的服务。这在服务目录中有描述。2.2.6计划和协定的中断2.2.7客户职责2.2.8冲击和分级指南2.2.9升级和告知过程2.2.10投诉程序2.2.11服务目标2.2.12工作负载限制下述工作负载限制由lT部门提供并被客户接受。2.2.14财务管理2.2.15内务工作程序2.2.16例外2.2.17可用性初始评审报告可用性初始评审报告必须附在相应的SLA后面作为记录。2.3服务级别管理(SLM)过程SLM是一个持续改进循环过程。由于业务变更、增长、业务重组或合并造成的要求变更，服务级别需要重新定义或临时暂停。IT部门引入的S

4、LM过程能灵活的应对这些变更。2.3.1服务需求的协议在SLA中，IT部门将满足客户要求的服务级别。每年定期由IT部门和客户进行评审。变更可以在任何时间（非预定会议）根据SLA变更管理提出。2.3.2服务目标服务目标由服务级别协议描述。更新的服务目标将列入服务管理委员会的日程。如果达到服务目标存在困难（如目标无法达到），IT部门和客户将定期评审以解决问题。2.3.3测量和报告IT部门并每月向客户报告服务级别的达成情况。下面的例子用来说明如何计算量测指标：例如：一个邮件服务器宕机影响1/3的用户2小时，则网络可用性：Network Availability =100%*( (30 days

5、15;24 hours× 60 mins) -(2 hours×60 mins) × 1/3customer impacted) /(30 days ×24 hours × 60 mins)=99.9074%2.3.4纠正和预防措施纠正和预防措施过程如下：每天进行异常和趋势检测。根据事件的性质，问题将被提升到管理层。一般问题将在月度问题管理会议给予关注。2.3.5服务改进计划SLM过程负责人每月监控SLA2.3.6 SLA变更管理如果需要变更，需要通过下述过程：召开会议讨论SLA，两方代表必须参加。E-mail沟通是另外的讨论SLA的渠道。变更

6、可以通过会议和电子邮件评估和决定。3.0 参考 无4.0 批准技术总监 日期：信息安全管理（#cp-0011）目的：本方针的目标是保护公司的客户的信息资产免受威胁，无论此威胁来自内部还是外部，蓄意的还是无意的：目标：方针的实施对于在处理客户和供应商有关事务时，维护和展示我们的完整性非常重要；此方针确保：信息不被非授权访问信息的机密性得到保证信息不会被无意或故意泄露给未授权人员需要时，信息对于授权人员具备可用性。法律法规的要求得到满足制定和保持业务持续计划，并进行实际的测试所有员工能够得到信息安全的培训教育所有违反信息安全的事件和潜在的弱点得以汇报和检查。适用范围公司所有人员和供应商，以及其他合

7、约规定下的受雇佣者，只要可能接触到信息安全管理体系范围内的信息资产，都有责任遵守这一信息安全政策。本政策由IT管理部批准，并支持。目的遁过适当的风险评估，识别信息资产价值，明确那些会让其暴露于风险之中的弱点和威胁。通过设计、实施和维护一套规范的信息安装管理制度将风险减低到可接受的程度。需要遵守的法律法规包括：公司法数据保护法计算机使用保护法版权、设计和专利保护法通信法纵上均为现行有效版本应遵从合同条款中关于信息安全方面的条款；应遵从公司的要求；符合IS020000:2005标准的6.6条款的要求；其他规定其它方面的规定包括：物理安全对系统和数据的访问控制安全教育和培训员工行为准则豆联网和邮件数

8、据备份便携设备的使用存储和处理机密数据病毒防护和侦测业务连续计划参考 无批准技术总监 日期：变更管理程序(#CP-0014)1目的定义职责和流程，管理变更请求的批准、实施、监控和测量。2范围本程序适用于所有公司使用的硬件和软件产品变更需求，这些在配置管理数据库中列出。这包括标准桌面软件，如微软XP标准版，微软Office2003, Symantec防病毒企业版9.0等等。3定义3.1变更：任何在配置管理数据库中配置项的变化。3.2变更记录：一个授权的变更对于哪些配置项有影响，以及影响的程度的细节性记录。3.3配置项：被配置管理所控制的基础设施或者其条目的组件。3.4配置管理数据库(CMDB)：

9、包含每个配置项的相关细节和它们之间重要关系的细节的数据库。3.5变更请求：请求一个变更的过程需要使用在线表格(#CF-0013)，以便记录对于服务或者基础设施的任何配置项的变更请求的细节。4.职责4.1 变更经理负责对在公司CMDB列出的配置项(Cls)的所有变化。变更经理一定要在发布前批准所有的变更Cls，并确保每次Cls变更后更新CMDB。在公司内，变更经理默认是IT部门经理(IT部门经理或高层管理者可以根据情况指定其他人担任变更经理)。4.2 变更请求者通过识别IT业务需求，启动变更流程。4.3 变更指导委员会(CSC)负责响应、实施和监控变更请求。CSC成员被视为变更技术专家。5.变更

10、管理过程5.1 当业务相关的IT新需求被识别时，公司的员工必须填写在线变更请求表(#CF-0013)触发一个变更。通过变更管理工具软件自动把变更请求以E-mail方式发送给变更经理。5.2 收到变更请求通知后，变更经理负责登录变更管理工具软件，评审所有递交的变更申请表(#CF-0013)，然后变更经理必须：5.2.1 把所有评审过的变更请求标注为“收到”。5.2.2 把所有的不完全的变更请求标注为“由于不完全而拒绝”5.2.3 指派CSC成员负责某个变更请求。5.2.4 将变更分类为“紧急的”、“应急的”，“重大”或“轻微”。5.2.5 转发所有的完整变更请求发送到CSC并标注为“审核中”。5

11、.3 CSC必须评审变更请求而且开始完成在线变更分析表格(#CF-0014)，确定变更的范围。5.4 CSC必须完成变更请求的风险分析，评估风险、冲击和业务收益。结果必须被记录在在线变更分析表(#CF-0014)。5.5 如果风险可接受，CSC必须识剐变更实施后不满意的回退或补救方法，结果必须被记录在在线变更分析表(#CF-0014)。5.6 CSC必须制订正式实施计划一包括变更日期，以及在变更分析表(#CF-0014)记录变更结果。5.7完成以上步骤后，CSC必须把在线变更分析表(#CF-0014)标注为“等待批准”。5.8变更经理必须评审和批准在线变更分析表(#CF-0014)，并与所有受

12、影响（正面的或者负面的）部门的负责人沟通实施日期和步骤。5.9 批准后，CSC可以所定义的范围内、在线变更分析表(#CF-0014)中约定之下，依照发布管理程序(#RM-0003)实施变更。5.10 由于变更而导致的所有问题，必须记录于在线变更分析形表(#CF-0014)中。5.11 CSC负责联络所有受影响的团体，确定他们的满意度并把结果记录在线变更分析表(#CF-0014)中。5.12 问题或客户抱怨必须记录于在线变更分析表(#CF-0014)中追踪，并由CSC来解决。基于问题或抱怨的种类，新的变更或纠正措施可能被CSC提出。5.13 变更经理一定要在CMDB中记录所有执行的变更。6.沟通

13、和培训6.1 变更经理有责任确保IT部门的所有员工和所有部门领导们接受培训，了解他们在变更管理流程中的角色和职能。7.0参考变更请求表(#CF-0013)变更分析表(#CF-0014)变更管理流程图(#FL-014)变更管理流程图8.0 批准技术总监 日期配置管理程序(#CP一0017)1. 目的定义管理硬件、软件和相关文档的配置职责和过程。2. 范围本程序适用于所有硬件、软件、相关文档和其它被公司使用的配置项(Cls)的配置管理，这些CI由IT部门依照服务级别协议(SLA)管控。员工个人购买使用的软件不在配置管理范围内，此外，不影响系统功能和完整性的内容或数据的变更也不在此范围中。3. 定义

14、3.1基线：指定时刻的服务或个别的配置项状态的快照。3.2变更：对配置管理数据库内列出的配置的条目的改变。3.3配置项(CI)：被配置管理所控制的基础设施或者其条目的组件。3.4配置管理数据库：包含每个配置项的相关细节和它们之间重要关系的细节的数据库。3.5发布：新的配置项，和变更的配置项，在经过测试和引进实体环境的集合。4. 责任4.1醌置经理负责评审和批准所有的正常情况下的基线配置并批准对CMDB的建议变更。在合适时，配置经理可以委派此责任给IT支持人员。4.2不论是对IT硬件、软件或是文档所做的变更，变更经理或其代表负责此流程的符合性。5. 配置管理策略5.1配置项包括被公司所使用的软件

15、、硬件和文档，由IT部门按照所适用的服务级别协议管控。必须根据这个程序执行配置管理，确保受控，和有效的策划、实施、维护和改进IT系统。6. 配置管理过程6.1当Cls发生改变，变更经理或其代表必须访问“http:/Log_nphp”登录到CMDB（如果变更经理或其代表没有口令，必须联系配置经理要求口令）。6.2登录后，变更经理或代表必须根据在线提示完成CMDB的变更，并按下“同意"按钮。6.3配置经理必须登录CMDB，评审和批准所有提出的对CMDB的更新。如果提出的CMDB的更新可接受，配置经理必须选择“同意更新”按纽，正式接受对CMDB的变更。6.4配置经理必须每月回顾CMDB，验

16、证其准确性，在每月的lT部门会议介绍变更摘要。如果CMDB和实际检测到的配置项存在差异，必须触发纠正措施过程。6.5配置经理负责更新CMDB，展示文档手册和硬件与软件之间的联系。6.6当变更经理提出需求，配置经理必须提供信息，表明一个CI的变更对其它服务或基础设施配置的可能冲击。6.7配置经理必须保证所有数字Cls的完整性，例如电子手册。配置经理必须对CMDB中的Cls在系统中分类，仅配置经理有该操作的读写权限。配置经理根据实际状况，决定谁对该操作和其中的数据Cls有读权限6.8 IT服务支持人员负责执行和验证CMDB与其它公司的信息服务器的正常备份。7. 沟通和培训7.1配置经理负责对IT部

17、门的所有员工和所有部门领导进行培训，确保他们了解其在配置管理流程内角色和职能。8.0参考无9.0批准技术总监 日期：问题管理程序(#CP-0019)1.目的 定义管理问题和帮助请求的责任与过程。2.范围该程序覆盖所有问题和帮助请求，包括那些用户通报给IT部门的，或者由IT部门自行发现的。3.定义3.1变更：任何对配置管埋数据库所列配置项的更改。3.2严重问题：完全失去正常操作任何重大业务功能的能力。（例如：服务器或者网络硬件的故障）3.3配置项(CI)：被配置管理所控制的基础设施或者其条目的组件。3.4配置管理数据库：包含每个配置项的相关细节和它们之问重要关系的细节的数据库。3.5高风险问题：

18、一个严重限制应用程序、系统或一个设备的使用的问题，显著影响业务功能（如，备份服务器问题。）3.6突发事件：任何不属于服务标准操作部分的事件，造成或可能造成服务质量的中断或降低。3.7问题：造成一个或多个突发事件的未知原因。3.8常规问题：只影响一个人，而且并不会影响个人执行重要业务操作能力的问题。3.9发布：新的配置项，和变更的配置项，在经过测试和引进实体环境的集合。4.0责任4.1 IT经理负责保证所有的问题都被及时和有效地解决5.0问题管理程序5.1发现配置项(CI)问题的人，必须在问题管理数据库(PMD)中明确地描述问题，PMD可以通过“http:/Login.php."访问。5.2IT经理必须每天检查PMD,在PMD中对登录在案的问题划分优先级。问题被划分为“常规”，“高风险”或“严重”。5.2.1严重问题必须立即处理。5.2.2高风险问题在严重问题解决后处理。5.2.3常规问题可以在时间允许的情况下解决。5.3 IT经理必须分配问题给IT服务人员，要求分析根本原因并提供解决方案。5.4 IT服务人员必须立即采取措施，控制问题并最小化问题带来的进一步冲击。5.5基于根本原因分析，IT服务人员可以根据变更管理程序(#CP-0014)，提出变更