项目运维交接管理指导规范V10.docx
《项目运维交接管理指导规范V10.docx》由会员分享,可在线阅读,更多相关《项目运维交接管理指导规范V10.docx(16页珍藏版)》请在冰豆网上搜索。
![项目运维交接管理指导规范V10.docx](https://file1.bdocx.com/fileroot1/2023-6/10/1e9e9079-63d9-4e8b-a48e-a175a4404486/1e9e9079-63d9-4e8b-a48e-a175a44044861.gif)
项目运维交接管理指导规范V10
Confidential
拓维信息系统股份有限公司
项项目运维交接管理指导规范
2011.03
WrittenByTALKWEB
Talkweb
拓维信息系统股份有限公司©1996,2011
AllRightsReserved
1.文档说明
1.1.文档目标
本文档作为指导实施与运维交接的参考规范,其目的是使项目从实施阶段到运维阶段能有一个平稳过渡,运维人员具有清晰地职责分工和任务分配,同时通过有效的监控措施以及标准的服务流程为系统稳定、可靠的运行提供强有力的保障。
1.2.适用范围
本文档适用于拓维项目实施和运维交接所涉及的部门。
1.3.术语
交维:
是指项目从实施阶段过渡到运维阶段的交接过程,一般始于项目实施后期,运维人员开始进驻并参与了解项目信息,直到项目实施末期或运维前期实施团队完成能力以及相关资料交接,并且运维团队能够独立完成运维任务为止。
2.一般规则
2.1.交维通用流程
2.2.交维启动应具备的条件
运维人员一般需要在系统实施的后期就进驻现场并开始熟悉系统,因此在项目开始启动阶段,实施团队就需要把握好运维人员进入实施团队的时间点,并制定相应计划。
交维工作大部分情况下会在终验完成前就启动。
交维启动必须具备以下条件之一:
1)系统已完成初验;
2)系统上线完成;
3)系统实施已全部或大部分完成,并且满足客户需求,预期距完成项目终验时间基本符合运维人员培训交接周期;
4)运维人员已具备独立运维能力(如已有运维人员的情况);
2.3.交维资料的查验
实施人员需要提交的项目相关资料包括需求、设计、测试、部署、培训、运维手册等,具体请参考项目知识文档一节。
2.4.交维系统的查验
针对需要进入运维交接的系统,运维人员需要对其进行基本的核查、验收。
根据查验标准,需要确认项目满足各项查验技术要求。
查验细节,请参考对应项目的查验标准模板。
其主要包括以下三方面内容:
●查验范围(主要包括软、硬件及其相关各类组件)
●查验指标(主要包括功能、性能以及配置项)
●查验方法(主要包括各项指标的具体查验方法)
2.5.软/硬件交维
实施方需要提供项目所涉及的软、硬件清单和详细配置说明,同时,需要指明各类设施的采购方、归属方、保管方、运维责任方等。
2.6.人员招聘及管理
目前运维人员招聘工作由实施方项目经理配合运维部要求进行代招,人员招聘时间点应该由实施方项目经理提出招聘申请,运维部进行确认。
交维完成之前运维人员的管理由实施方负责,交维完成后由运维部统一负责。
2.7.代码管理
对于交维后的代码管理,请参照公司目前版本管理相关流程。
3.运维范围及要求
3.1.设备管理
项目是否涉及对网络设备、服务器、防火墙等各类硬件设备运行状况进行实时监控,并提供相应的维护管理。
如是,需要提供详细的任务说明。
3.2.应用管理
项目是否涉及对各种应用软件如数据库、中间件、应用服务器等各种通用或特定服务的监控管理。
如是,需要提供详细的任务说明。
3.3.业务管理
项目是否涉及业务系统运行情况的监控,业务系统更新、发布管理,以及业务数据管理、业务过程的操作(比如:
生产计划、指挥调度)等。
如是,需要提供详细的任务说明、流程、操作步骤等。
3.4.桌面管理
项目是否涉及提供企业内部桌面系统的管理和维护工作。
如是,需要提供详细的任务说明、流程、操作步骤等。
3.5.其它日常任务
除以上管理内容以外,是否还有其他日常工作内容需要特别声明。
比如:
Ø用户需求收集、跟踪、反馈
Ø配合售前、市场进行相关支持工作
Ø客户回访
4.日常运维作业计划
日常运维作业计划是用以保证系统正常运行的重要措施,运维人员根据制定的作业计划周期性或持续执行日常运维作业。
日常依据作业计划所执行的任务主要包括以下几类,项目需要根据需求确定相应的作业计划要求。
4.1.故障检查
作业计划工作中需要执行部分作业,来发现故障,例如:
●检查各个核心应用的主要功能;
●检查主机运行状况和日志;
●检查数据库运行状况和日志;
●检查中间件运行状况和日志;
●检查网络设备运行状况和日志;
●检查存储设备运行状况和日志;
●检查防病毒、入侵检测、防火墙、VPN运行状况和日志;
●检查应用软件运行状况和日志;
故障检查类的作业计划,在发现故障时会触发事件管理流程;
4.2.能力检查
作业计划工作中需要执行部分作业,对各类资源的处理能力的使用情况进行检查,例如:
●检查服务器cpu和内存占用情况;
●检查存储设备空间使用情况;
●检查网络带宽占用情况;
●检查网络设备端口占用情况;
●检查机房、机柜占用情况;
●检查软件许可权使用情况;
●检查业务的发展情况;
●检查数据的增长情况;
4.3.可用性检查
作业计划工作中需要执行部分作业,对可用性情况进行检查,例如:
●检查服务器性能超阀值情况;
●检查数据库性能超阀值情况;
●检查中间件性能超阀值情况;
●检查网络设备性能超阀值情况;
●检查存储设备性能超阀值情况;
●检查防病毒、入侵检测、防火墙、VPN性能超阀值情况;
●检查应用软件性能超阀值情况;
4.4.业务数据检查
对各种业务系统的数据进行稽核、比对。
4.5.安全检查
作业计划工作中需要执行部分作业,对IT环境安全性进行检查,例如:
●病毒库定期升级作业;
●对发现病毒日志进行分析;
●检查防火墙系统、入侵检测系统发现的安全事件;
●定期对用户的接入IT环境的权限进行审核;
安全检查是企业信息安全管理的一部分,也是信息安全落实到日常运维中的一个具体举措。
4.6.配置检查
作业计划工作中需要执行部分作业,对配置进行核查,例如:
●定期审核配置项属性以及配置项之间的关系,以确保其与实际的物理环境保持一致。
配置审核活动需要对配置项信息与配置项物理存在性进行双向验证。
配置核查与发现是配置管理的一部分,也是配置管理落实到日常运维中的一个具体举措。
5.资源配置
根据运维工作内容需要确定所需人员和设备。
5.1.一线运维角色
以下是针对目前运维项目中一线运维团队可能涉及到的各类角色进行说明,不同角色可能是由不同人担当,也可能多个角色由同一人担当,或角色不存在。
5.1.1.运维组长
负责运维团队人员及日常事务管理。
及时处理各类故障,并将运维情况及时通报给相关主管人员,及时完成上级交派的各项运维任务。
其主要职责如下:
●全面负责项目运维工作,并严格按照客户方及公司要求的标准的运维流程进行运维工作;
●掌握必要的技术运维技能,满足日常运维工作的需求;
●建立标准的运维流程,方便公司对运维进行更好的管理;
●良好的学习能力,不断的提高自身技术、管理水平;
●每周、每月、每年对运维工作进行总结,及时上报主管领导;
●做好各类文档的制定和管理工作;
5.1.2.服务台
服务台在服务支持中扮演着一个极其重要的角色。
服务台可以理解为服务流程的“前台”,它可以在不需要联系特定技术人员的情况下处理大量的客户请求。
对用户而言,服务台是他们的唯一连接点,确保他们找到帮助其解决问题和请求的相关人员。
作为与用户联系的“前台”,服务台首先对来自用户的服务请求进行初步处理。
当它预计无法在满足服务级别的前提下有效处理这些请求,或是这些请求本身就是它所无法解决的时候,它就将这部分请求转交给二线支持或三线支持来处理。
这样可以有效地降低其他IT服务支持部门的负担,提高了IT服务运作的整体效率,降低了IT服务运作的成本。
服务台的主要任务不仅负责记录、处理事故、问题和客户的咨询,同时还为其它活动和流程提供接口。
比如:
客户变更请求。
服务台日常主要职责如下:
Ø响应用户呼叫。
即对于用户发出的错误报告、服务请求、变更请求等事件进行记录和处理。
这是服务台的最主要工作。
Ø提供信息。
服务台是为用户提供IT服务信息的主要来源,一般可以采用布告栏、Email、屏幕消息等方式为用户提供有关错误、故障或新增服务等方面的信息。
Ø客户需求管理和客户关系管理。
服务台不仅仅是客户请求响应中心,同时也是客户关系管理中心。
因此服务提供方应采取必要的措施和使用适当的技术对服务台进行有效的管理,从而使服务台可以准确迅速地了解客户的需求,改善客户体验,提高客户满意度。
这些措施和技术包括结构化询问技术、详细了解客户和跟踪客户、维护客户数据库和在客户中推广服务台等。
Ø供应商联络。
在IT服务运作出现故障或因客户提出新的服务请求而需进行有关变更时,服务台通常需要负责与供应商进行联络以维修或替换有关的软硬件组件。
Ø日常运作管理。
服务台承担的日常运作管理任务包括数据备份与恢复、磁盘空间管理、建立新用户、管理用户口令等。
Ø基础架构监控。
利用相关工具对IT基础架构的运作情况进行监控,一旦检测到故障已经发生或即将发生,就应立即评估这种故障对关键设备可能产生的影响,并在必要时将检测到的故障报告事故管理部门。
5.1.3.运维工程师
对业务运行情况进行不间断监控,及时处理各类突发事件,各类故障,并将运维情况及时通报给运维主管人员,及时完成上级交派的各项运维任务。
其主要职责如下:
●全面负责运维工作,并严格按照公司的标准的运维流程进行运维和服务器管理等工作;
●掌握必要的技术运维技能,满足日常运维工作的需求;
●良好的学习能力,不断的提高自身运维技术水平;
●每周、每月、每年对运维工作进行总结,上报主管领导;
5.2.人员配置
根据项目运维需要以及相应角色设置进行人员配置,主要包括四方面的人员:
●运维人员(一线支持)
●需求及实施接口人员(二线支持)
●运维专家(三线支持)
●第三方厂商(三线支持)
其中只有运维人员(一线支持)是项目日常主要维护人员,其它人员主要是根据项目运维需要可以及时寻求支持的人员(需要与对应人员进行责任、优先级、响应时间要求等方面的确认),需要提供对应的联系方式/渠道。
如二、三线支持人员出现调动,需由项目研发部及时安排空缺填补,并通知运维部对应项目的运维主管。
如一线支持无法及时联系到对应的二线支持人员,由运维主管按照升级机制寻求二线支持人员的上一级主管安排资源。
5.3.设备及办公环境配置
根据项目运维需要进行办公设备及办公环境配置。
5.4.非驻地运维
如果项目运维人员不需要常驻客户方,将由运维部进行人员统一协调分配。
6.能力交接
为保证系统在运维阶段能够得到有效的运行、维护和更新,在项目由实施团队交由运维团队运维的过程中,实施团队需要根据项目运维需要进行有针对性的技能、知识的系统培训,完成系统能力交接,使运维团队成员掌握项目相关知识,并且能够胜任该项目的运维工作,达到能独立解决运维过程中所出现的各类系统相关问题。
6.1.培训计划
实施团队需要和运维团队一起协商制定能力交接的培训计划。
6.2.能力考核计划
为了确认运维团队成员是否真正足够掌握相关的运维知识和技能,需要制定对应能力考核计划。
7.运维相关技术与工具
为保证运维工作能准确、高效的执行,根据项目需要提供相应的技术、工具。
比如监控工具、流程管理工具、自动化工具等。
在提高效率的同时,减少由于手工误操作所带来的隐患。
7.1.自助服务
通过提供自助服务方便用户获取需要的信息,比如在网页上提供帮助菜单,用户可以通过帮助菜单查找所需要的信息、问题的原因、解决方案等。
这样可以缩短用户解决问题的时间,同时也可以减少运维团队收到的咨询类请求的数量。
7.2.监控工具
通过提供各类监控工具,使运维团队可以方便、及时、准确掌握系统的运行现状。
提高效率的同时,还可以减少由于手工误操作带来的隐患。
7.3.诊断工具
自动诊断分析工具可以帮助运维人员迅速定位、分析问题症结所在,缩短人为调查、分析时间,从而达到使系统能够尽快恢复正常。
7.4.远程控制工具
远程控制可以帮助运维人员控制、访问远端机器,以便他们进行问题诊断,配置修改等等。
7.5.流程控制工具
针对运维管理过程中所涉及到的一些管理流程,如果通过电子化的流程工具(比如基于工作流的服务管理流程工具)将促进这些流程的实现。
7.6.知识管理工具
通过有效的知识管理工具来实现运维知识、经验的记录和共享。
比如:
wiki
7.7.业务管理集成工具
通过提供(与)业务管理工具集成,从而实现对业务系统、数据有效管理。
8.运维制度
为保证运维工作的有效执行,需要制定对应的运维管理制度,其主要包括以下几个方面,需要根据项目的实际需要进行制定。
8.1.运维工作时间安排
工作时间分为日常上班时间(包括轮班)和节假日上班时间安排,需要根据项目实际需要进行安排。
注:
如客户方有特别工作时间安排,以服从客户方安排为主,并告知直接主管人员,以进行合理的资源调配。
8.2.交接班安排
为了防止出现交接班时遗留的故障处理不及时等情况,建立交接班遗留问题处理机制,可以通过交接班遗留问题表实现问题的有效交接。
8.3.办公网络设备管理制度
运维人员所使用的办公网络设备如由客户方提供,应严格遵守客户方对于办公网络设备的管理制度。
如由公司(拓维)提供,应严格遵守公司相关规定。
8.4.机房硬件维护管理制度
严格遵守客户方的机房环境及硬件维护管理制度。
8.5.安全管理
根据项目需要,确定安全需求、制定安全政策和策略,主要是从政策、策略和方法的角度阐述如何进行安全管理。
8.6.重要期间运维保障
为保证特定重要期间系统的稳定运行,需要制定特定运维保障。
8.7.例行维护规定
为了保障系统稳定运行,以及满足系统新需求的上线,有时需要进行例行维护(比如:
停机、数据整理)。
为保证例行维护的正确执行,减少错误发生几率,因此,需要根据项目实际需要制定相应的维护规定。
1.
2.
3.
9.服务流程
在项目的运维过程中,为实现运维人员对于咨询、请求、故障处理、变更、发布等工作执行规范化操作,需要根据项目实际协商制定相应的服务处理流程。
其主要包括,但不限于以下流程。
完整的运维流程说明可以参考运维流程指导规范。
9.1.服务请求管理
服务请求流程是对来自用户的低风险、低成本的例行请求进行处理的流程,包括服务请求记录、审批、执行、关闭等环节。
服务请求如:
信息咨询、建议、非系统类投诉、重置密码、桌面服务请求等等。
9.2.事件管理
事件管理流程是指对IT生产环境中导致IT服务的非计划性中断或IT服务质量下降,以及对IT服务已造成影响或潜在影响的事件进行管理。
其目标是尽可能快地恢复正常的服务运营,最小化对业务运营的负面影响,确保达到尽量好的服务质量和可用性水平。
因此,事件管理重在以恢复服务为首要目的,可能因为暂时无法在容许的时间范围内查明事件根本原因并解决,而采取临时解决方案。
事件的来源包括IT用户或IT客户报告的事件、监控系统自动发现/转发的事件,以及运维人员发现的事件等。
9.3.问题管理
问题管理流程是确定某一事件或具有相同症状的一组事件的根本原因,制定和实施解决方案,从而防止事件再次发生的管理流程。
9.4.变更管理
变更管理负责业务需求单、系统变更单的具体实施落实,包括变更方案、进度计划的制定、变更的审批、实施方案制定及审批、变更执行、验证测试等工作,其中功能开发类变更和系统维护类变更通过发布与部署管理完成变更到实际生产环境的部署。
通过对系统变更的控制,降低变更实施风险,提高系统稳定性。
典型的变更如新功能开发、软件版本升级、硬件扩容、系统核心参数修改等。
一个业务需求单可能对应多个系统的变更单。
9.5.需求管理
需求管理流程是对需求提出人提出的需求进行记录、分析、审批、跟踪、变更控制,对需求实施结果进行评估的管理流程。
通过需求管理,保证业务需求清晰、可行,从而可以及时、准确地响应和支撑,并确保从需求提出到最终实现全过程是可跟踪、可追溯的。
同时,通过明确IT需求管理流程的角色职责、各活动之间的接口,缩短IT需求处理历时,提高IT需求处理的及时率,规范IT需求的管理。
需求的实现过程是通过变更管理流程进行控制的。
9.6.发布与部署管理
发布与部署管理负责将通过测试验证后的变更按业务需要及技术要求、发布策略限制分批部署到生产环境,它包括发布包的设计与组建、发布包的测试、用户培训的组织、发布的业务准备、实际部署后的验证测试以及IT资源配置状态的更新等环节。
10.交维输出文档
10.1.项目知识文档
文档类别
文档名
说明
提供方
需求
软件需求规格说明书
详细描述系统的功能性需求和非功能性需求,包含相应的需求质量属性等。
实施部
设计
系统(概要/详细/集成)设计说明书
包括功能实现、模块组成、功能流程图、函数接口、数据字典、集成等软件开发需要考虑的各种问题。
实施部
测试
测试报告
测试结果报告
实施部
部署
系统(硬件/软件/网络/集成)部署方案
系统硬件设备、软件应用以及所涉及各类集成的安装、部署方案。
包括系统环境、运行平台、安装过程、初始环境设置、安装记录等。
以及网络环境的部署方案。
实施部
培训
培训讲稿
用户培训讲稿
实施部
运维手册
用户使用手册
系统/产品简介、功能列表、功能描述和解释、功能操作等。
实施部
系统维护手册
如果系统的运维需求包括后台维护支持内容,须提交《系统维护手册》,《系统维护手册》应说明系统的总体技术架构、系统逻辑与物理拓扑图、系统设备详细组成清单、系统软硬件部署方案和步骤(特别是须准确说明配置参数要求和关键步骤)、系统依赖的后台服务器、网络、数据库等的可用性与性能要求,以及日常维护任务及要求。
实施部、运维部(日常作业计划)
运维管理规范
作为项目/产品运维管理总指导规范,主要包括运维管理制度、流程管理、任务管理、风险管理等规范。
运维部
10.2.实施与运维内部交接记录单
由实施部(交接人)与运维部(接收人)共同完成交接记录单,具体格式请参考模板《实施运维内部交接记录单》。
10.3.服务合同
由市场部、咨询策划部、项目管理部、实施部与运维部、以及客户方等责任相关人共同确认并签订运维服务合同。