ISO0体系文件服务级别管理程序DOC文档格式.docx
《ISO0体系文件服务级别管理程序DOC文档格式.docx》由会员分享，可在线阅读，更多相关《ISO0体系文件服务级别管理程序DOC文档格式.docx（11页珍藏版）》请在冰豆网上搜索。
（略）
2.2服务级别协议
服务级别协议是IT部门需要达到的正式文件。
2.2.1有效期
有效期在相关SLA文件中明确。
在有效期内，SLA有效，直到新的协议签定为止。
2.2.2授权
2.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部门引入的SLM过程能灵活的应对这些变更。
2.3.1服务需求的协议
在SLA中，IT部门将满足客户要求的服务级别。
每年定期由IT部门和客户进行评审。
变更可以在任何时间（非预定会议）根据SLA变更管理提出。
2.3.2服务目标
服务目标由服务级别协议描述。
更新的服务目标将列入服务管理委员会的日程。
如果达到服务目标存在困难（如目标无法达到），IT部门和客户将定期评审以解决问题。
2.3.3测量和报告
IT部门并每月向客户报告服务级别的达成情况。
下面的例子用来说明如何计算量测指标：
例如：
一个邮件服务器宕机影响1/3的用户2小时，则网络可用性：
NetworkAvailability=100%*（（30days×
24hours×
60mins）-（2hours×
60mins）×
1/3
customerimpacted）/（30days×
24hours×
60mins）=99.9074%
2.3.4纠正和预防措施
纠正和预防措施过程如下：
每天进行异常和趋势检测。
根据事件的性质，问题将被提升到管理层。
一般问题将在月度问题管理会议给予关注。
2.3.5服务改进计划
SLM过程负责人每月监控SLA
2.3.6SLA变更管理
如果需要变更，需要通过下述过程：
召开会议讨论SLA，两方代表必须参加。
E-mail沟通是另外的讨论SLA的渠道。
变更可以通过会议和电子邮件评估和决定。
3.0参考
无
4.0批准
技术总监日期：
信息安全管理（#cp-0011）
目的：
本方针的目标是保护公司的客户的信息资产免受威胁，无论此威胁来自内部还是外部，蓄意的还是无意的：
目标：
方针的实施对于在处理客户和供应商有关事务时，维护和展示我们的完整性非常重要；
此方针确保：
信息不被非授权访问
信息的机密性得到保证
信息不会被无意或故意泄露给未授权人员
需要时，信息对于授权人员具备可用性。
法律法规的要求得到满足
制定和保持业务持续计划，并进行实际的测试
所有员工能够得到信息安全的培训教育
所有违反信息安全的事件和潜在的弱点得以汇报和检查。
适用范围
公司所有人员和供应商，以及其他合约规定下的受雇佣者，只要可能接触到信息安全管理体系范围内的信息资产，都有责任遵守这一信息安全政策。
本政策由IT管理部批准，并支持。
遁过适当的风险评估，识别信息资产价值，明确那些会让其暴露于风险之中的弱点和威胁。
通过设计、实施和维护一套规范的信息安装管理制度将风险减低到可接受的程度。
需要遵守的法律法规包括：
公司法
数据保护法
计算机使用保护法
版权、设计和专利保护法
通信法
纵上均为现行有效版本
应遵从合同条款中关于信息安全方面的条款；
应遵从公司的要求；
符合IS020000:
2005标准的6.6条款的要求；
其他规定
其它方面的规定包括：
物理安全
对系统和数据的访问控制
安全教育和培训
员工行为准则
豆联网和邮件
数据备份
便携设备的使用
存储和处理机密数据
病毒防护和侦测
业务连续计划
参考
批准
变更管理程序（#CP-0014）
1．目的
定义职责和流程，管理变更请求的批准、实施、监控和测量。
2．范围
本程序适用于所有公司使用的硬件和软件产品变更需求，这些在配置管理数据库中列出。
这包括标准桌面软件，如微软XP标准版，微软Office2003,Symantec防病毒企业版9.0等等。
3．定义
3.1变更：
任何在配置管理数据库中配置项的变化。
3.2变更记录：
一个授权的变更对于哪些配置项有影响，以及影响的程度的细节性记录。
3.3配置项：
被配置管理所控制的基础设施或者其条目的组件。
3.4配置管理数据库（CMDB）：
包含每个配置项的相关细节和它们之间重要关系的细节的数据库。
3.5变更请求：
请求一个变更的过程需要使用在线表格（#CF-0013），以便记录对于服务或者基础设施的任何配置项的变更请求的细节。
4.职责
4.1变更经理负责对在公司CMDB列出的配置项（Cls）的所有变化。
变更经理一定要在发布前批准所有的变更Cls，并确保每次Cls变更后更新CMDB。
在公司内，变更经理默认是IT部门经理（IT部门经理或高层管理者可以根据情况指定其他人担任变更经理）。
4.2变更请求者通过识别IT业务需求，启动变更流程。
4.3变更指导委员会（CSC）负责响应、实施和监控变更请求。
CSC成员被视为变更技术专家。
5.变更管理过程
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.3CSC必须评审变更请求而且开始完成在线变更分析表格（#CF-0014），确定变更的范围。
5.4CSC必须完成变更请求的风险分析，评估风险、冲击和业务收益。
结果必须被记录在在线变更分析表（#CF-0014）。
5.5如果风险可接受，CSC必须识剐变更实施后不满意的回退或补救方法，结果必须被记录在在线变更分析表（#CF-0014）。
5.6CSC必须制订正式实施计划一包括变更日期，以及在变更分析表（#CF-0014）记录变更结果。
5.7完成以上步骤后，CSC必须把在线变更分析表（#CF-0014）标注为“等待批准”。
5.8变更经理必须评审和批准在线变更分析表（#CF-0014），并与所有受影响（正面的或者负面的）部门的负责人沟通实施日期和步骤。
5.9批准后，CSC可以所定义的范围内、在线变更分析表（#CF-0014）中约定之下，依照发布管理程序（#RM-0003）实施变更。
5.10由于变更而导致的所有问题，必须记录于在线变更分析形表（#CF-0014）中。
5.11CSC负责联络所有受影响的团体，确定他们的满意度并把结果记录在线变更分析表（#CF-0014）中。
5.12问题或客户抱怨必须记录于在线变更分析表（#CF-0014）中追踪，并由CSC来解决。
基于问题或抱怨的种类，新的变更或纠正措施可能被CSC提出。
5.13变更经理一定要在CMDB中记录所有执行的变更。
6.沟通和培训
6.1变更经理有责任确保IT部门的所有员工和所有部门领导们接受培训，了解他们在变更管理流程中的角色和职能。
7.0参考
变更请求表（#CF-0013）
变更分析表（#CF-0014）
变更管理流程图（#FL-014）
变更管理流程图
8.0批准
技术总监日期
配置管理程序（#CP一0017）
1.目的
定义管理硬件、软件和相关文档的配置职责和过程。
2.范围
本程序适用于所有硬件、软件、相关文档和其它被公司使用的配置项（Cls）的配置管理，这些CI由IT部门依照服务级别协议（SLA）管控。
员工个人购买使用的软件不在配置管理范围内，此外，不影响系统功能和完整性的内容或数据的变更也不在此范围中。
3.定义
3.1基线：
指定时刻的服务或个别的配置项状态的快照。
3.2变更：
对配置管理数据库内列出的配置的条目的改变。
3.3配置项（CI）：
3.4配置管理数据库：
3.5发布：
新的配置项，和变更的配置项，在经过测试和引进实体环境的集合。
4.责任
4.1醌置经理负责评审和批准所有的正常情况下的基线配置并批准对CMDB的建议变更。
在合适时，配置经理可以委派此责任给IT支持人员。
4.2不论是对IT硬件、软件或是文档所做的变更，变更经理或其代表负责此流程的符合性。
5.配置管理策略
5.1配置项包括被公司所使用的软件、硬件和文档，由IT部门按照所适用的服务级别协议管控。
必须根据这个程序执行配置管理，确保受控，和有效的策划、实施、维护和改进IT系统。
6.配置管理过程
6.1当Cls发生改变，变更经理或其代表必须访问“http:
//Log_nphp”登录到CMDB（如果变更经理或其代表没有口令，必须联系配置经理要求口令）。
6.2登录后，变更经理或代表必须根据在线提示完成CMDB的变更，并按下“同意"
按钮。
6.3配置经理必须登录CMDB，评审和批准所有提出的对CMDB的更新。
如果提出的CMDB的更新可接受，配置经理必须选择“同意更新”按纽，正式接受对CMDB的变更。
6.4配置经理必须每月回顾CMDB，验证其准确性，在每月的lT部门会议介绍变更摘要。
如果CMDB和实际检测到的配置项存在差异，必须触发纠正措施过程。
6.5配置经理负责更新CMDB，展示文档手册和硬件与软件之间的联系。
6.6当变更经理提出需求，配置经理必须提供信息，表明一个CI的变更对其它服务或基础设施配置的可能冲击。
6.7配置经理必须保证所有数字Cls的完整性，例如电子手册。
配置经理必须对CMDB中的Cls在系统中分类，仅配置经理有该操作的读写权限。
配置经理根据实际状况，决定谁对该操作和其中的数据Cls有读权限
6.8IT服务支持人员负责执行和验证CMDB与其它公司的信息服务器的正常备份。
7.沟通和培训
7.1配置经理负责对IT部门的所有员工和所有部门领导进行培训，确保他们了解其在配置管理流程内角色和职能。
8.0参考
无
9.0批准
问题管理程序（#CP-0019）
1.目的
定义管理问题和帮助请求的责任与过程。
2.范围
该程序覆盖所有问题和帮助请求，包括那些用户通报给IT部门的，或者由IT部门自行发现的。
3.定义
任何对配置管埋数据库所列配置项的更改。
3.2严重问题：
完全失去正常操作任何重大业务功能的能力。
（例如：
服务器或者网络硬件的故障）
包含每个配置项的相关细节和它们之问重要关系的细节的数据库。
3.5高风险问题：
一个严重限制应用程序、系统或一个设备的使用的问题，显著影响业务功能（如，备份服务器问题。
）
3.6突发事件：
任何不属于服务标准操作部分的事件，造成或可能造成服务质量的中断或降低。
3.7问题：
造成一个或多个突发事件的未知原因。
3.8常规问题：
只影响一个人，而且并不会影响个人执行重要业务操作能力的问题。
3.9发布：
4.0责任
4.1IT经理负责保证所有的问题都被及时和有效地解决
5.0问题管理程序
5.1发现配置项（CI）问题的人，必须在问题管理数据库（PMD）中明确地描述问题，PMD可以通过“http:
//Login.php."
访问。
5.2IT经理必须每天检查PMD,在PMD中对登录在案的问题划分优先级。
问题被划分为“常规”，“高风险”或“严重”。
5.2.1严重问题必须立即处理。
5.2.2高风险问题在严重问题解决后处理。
5.2.3常规问题可以在时间允许的情况下解决。
5.3IT经理必须分配问题给IT服务人员，要求分析根本原因并提供解决方案。
5.4IT服务人员必须立即采取措施，控制问题并最小化问题带来的进一步冲击。
5.5基于根本原因分析，IT服务人员可以根据变更管理程序（#CP-0014），提出变更请求。
变更请求必须包括所需要的，可能减少潜在问题的所有预防措施。
5.6IT服务人员须监控，并在PMD中记录变更请求的进展。
变更完成后，IT服务人员必须监控问题解决的有效性，在PMD中记录其发现，从PMD中提交最终的问题管理报告给l丁经理。
5.7由PMD生成的问题管理报告，将在每月的IT部门会议中被检查。
基于问题管理报告的结果分析的改进机会必须在会议中讨论。
会议议程项目的输出作为服务改进计划的输入。
6.0沟通和培训
6.1IT经理负责对IT部门的所有员工和所有部门领导进行培训，确保他们了解其在问题管理流程内角色和职能。
升级会员 