IT外包运维服务方案详细完整版样本.docx
《IT外包运维服务方案详细完整版样本.docx》由会员分享，可在线阅读，更多相关《IT外包运维服务方案详细完整版样本.docx（51页珍藏版）》请在冰豆网上搜索。
IT外包运维服务方案详细完整版样本
XX信息技术
IT外包服务方案
[键入文档副标题]
DADA
-11-29
第1章
项目概况
1.1项目背景
多年来为适应业务发展需求，XX企业进行了大规模电子商务建设，包含采购桌面PC约300台，打印机约100台，这些应用系统及硬件设备投入使用极大推进了XX企业信息化建设进程。
伴随越秀工商局对整体IT系统（硬件、软件、网络通讯…）可用性要求日益提升，系统运行保障和维护管理就成为确保业务系统安全稳定可靠运行最有力手段。
XX企业关键有一栋N层办公环境，现阶段对设备维护关键采取自主维护方法。
因为人力有限，建设任务繁重，中心技术人员在接手新项目及日常工作同时往往需要做大量维护工作，不少技术人员长久处于满负荷，严重影响了工作效率。
在目前有限人力物力资源下，为了保障和提升IT服务质量，XX企业有必需将计算机、外设及网络运行维护进行外包，派驻2名工程师进行维护，以处理目前IT服务个方面日益增加需求和有限提供能力之间矛盾，提升XX企业办公区域内软、硬件、业务应用软件运行维护效率，确保信息系统正常运行。
1.2项目目标
结合XX企业业务工作及信息化建设实际，完善运维管理体系建设，加强信息系统正常运行保障，“以步骤为导向，以服务为关键”提升服务质量水平、转变服务理念、拓宽服务范围、提升服务效率、提升用户服务满意度。
1.3需求分析
此次项目XX企业需求关键包含两个部分，
1、运维管理体系建设要求；
2、信息系统正常运行保障服务。
其中运维管理体系建设应完善服务内控制度即服务质量管理，逐步建立起一套符合XX企业本身实际运维管理标准及应用制度；建设IT运行维护管理平台，采取标准IT运维管理步骤，提供正确、详尽、专业汇报制度，经过客观分析运维过中出现多种障碍及问题，为XX企业信息化建设提供决议依据。
信息系统正常运行保障涵盖了
1、通常信息化设备及软件运维管理；
2、、防病毒服务；
3、办公区域内设备及软件巡检普查；
4、提供符合XX企业实际服务响应水平及质量保障；
5、信息化资产管理
第2章运维服务管理体系建设
现今，伴随计算机技术，尤其是网络技术飞速发展，对于很多行政单位，很多企业而言，IT技术越来越深入到关键业务，影响策略制订和企业发展。
从而对IT环境可靠性，可用性和快速适应性提出了越来越高要求，和此同时，IT环境（包含软/硬件及相关技术）却变得越来越复杂。
所以，对于一个单位而言：
Ø怎样把有限IT资源最有效作用于关键业务发展
Ø怎样最快地获取专业支持能力
Ø怎样实现对系统完善管理，提升系统可靠性和可用性
Ø怎样提升用户工作效率，增加最终用户满意度
Ø怎样跟上IT技术发展，立即更新相关技术
Ø怎样提升对IT系统利用灵活性
Ø怎样愈加好地管理IT运行成本
Ø以提升服务能力，将会是单位可能面临问题。
IT服务管理（ITSM）是一套帮助企业对IT系统计划、研发、实施和运行进行有效管理方法，是一套指导IT服务方法论。
ITIL是英国国家电脑局（CCTA）于八十年代开发一套IT业界服务管理标准库，它把业界在IT管理方面最好方法归纳起来，形成规范，意在为企业IT部门提供一套从计划、研发、实施到运维标准方法。
它一经提出，便被欧洲各大企业纷纷采纳，随即在澳洲，美洲和亚洲流行开来，现在已成为IT服务管理实际上标准。
经过参考这些标准，我们能够充足借鉴国际化标准IT服务管理最好经验，使我们“站在巨人肩膀上”来设计、计划及运维IT服务，尽可能少走弯路，有效提升IT服务质量。
ITIL框架图
ITIL是基于步骤方法论。
IT部门可用其检验是否用一个可控和可训练有素方法为最终用户交付所需IT服务。
ITIL合并了一套最好实践通例，可适适用于几乎全部IT组织，不管其规模大小，或采取何种技术。
ITIL对IT服务管理实践中包含很多关键问题进行了系统分析，包含全方面检验清单、任务、程序、责任等和任何IT服务组织亲密相关问题。
这些概念定义也涵盖了大多数IT服务组织关键行为。
IT服务组织能够借助ITIL指导建立和拓展自己IT服务步骤。
运维务管理最关键是“服务支持”（ServiceSupport）和“服务提供”（ServiceDelivery）两个模块。
各步骤相互贯穿和作用，形成有机整体，共同建立一个健全服务管理体系。
以下图所表示：
2.2.1服务支持
服务支持内容描述了一个用户怎样访问合适服务，以支持其业务。
服务支持包含以下内容：
2.2.1.1服务台
我们为企业建设服务台，提供统一报障电话，统一报障、统一维修接口，越秀工商能够经过统一报障电话申请服务、查询服务处理进程，监控服务质量。
服务台（ServiceDesk）是IT服务组织和用户相互联络接入点。
服务台曾经被称为帮助台（HelpDesk）。
HelpDesk关键任务是统计，分解和监控提出问题。
一个服务台能够含有更宽范角色，如接收变更请求（RFC），而且能够支撑多个步骤中操作。
服务台是服务提供者和用户之间日常工作单一联络点。
它也是汇报突发事件和提交服务请求焦点。
正因为如此，服务台职责是保持将服务相关信息，行为和契机通知用户，并追踪了解用户每日行为。
比如，服务台可能饰演用户提交变更请求联络点，基于变更管理步骤传达变更实施计划，并保持将变更实施进程通知用户。
变更管理应该确保服务台随时保持对变更行为情况掌握。
在任何对SLA产生影响事件面前，服务台处于第一线，并维护高速信息流通道。
围绕突发事件，服务台有可能在其权限范围被授权实施变更。
这类变更范围可能被预先定义。
当全部相关变更发生时，变更管理步骤将被通知。
基础上，当对任何CI规范做出修改之前，变更步骤全部需要对其进行预先审批。
2.2.1.2突发事件管理
突发事件管理步骤致力于处理突发事件，并快速恢复服务供给。
突发事件被统计下来，而且事件统计质量决定了相关其它步骤效力。
服务台靠近于突发事件管理步骤和问题管理步骤，并处于它们之间。
假如没有合适控制，变更有可能引入新突发事件。
所以需要建立有效路径对变更进行跟踪。
这是为何提议连续不停地将突发事件统计在同一个CMDB中，并分类为“问题”，“已知错误”，“变更统计”等信息，以促进服务台界面信息沟通能力，简化事件调查和汇报。
突发事件优先权及其升级需要作为服务等级管理步骤中一部分进行协商，并在SLA中立案。
突发事件管理目标：
突发事件管理目标是尽可能快速地依据SLA中定义一般服务等级作出反应，使产生问题后对业务行为及组织和用户影响最小。
突发事件管理也应该保留对事件有效统计，方便于衡量和改善步骤，并向其它步骤汇报。
突发事件步骤以下图所表示：
2.2.1.3问题管理
对于突发事件有两种处理方法，一个是对其做出服务快速响应，立即恢复其正常运行，另一个是判别和处理问题根源。
这两种方法之间存在微妙区分，而且常常被相互混淆。
对其做好区分含相关键意义。
假如问题被怀疑存在于IT架构内部，问题管理步骤将会瞄准其潜在根源。
一个问题可能是被突发事件暴露出来，不过显然，问题管理目标是处理问题根源，预防其可能产生干扰，而不是快速恢复系统运行。
当问题被识别后（被识别问题通常称之为已知错误），通常需要进行一个业务决议，决定是否采取永久性方法改善系统架构，以预防再次发生新突发事件。
假如需要，提交一个变更请求来实现改善。
为了有效和高效地识别突发事件背后问题根源及其发展趋势，问题管理步骤需要正确全方面突发事件统计。
问题管理步骤一样需要和可用性管理步骤亲密联络，以确定这些趋势并明确补救方法关键性。
步骤：
2.2.1.4配置管理
配置管理致力于控制一个改变中IT架构（标准化和状态监控），判别配置项目（清册，相互关联，审核和注册），搜集和管理相关IT架构文档，为全部其它步骤提供IT架构相关信息。
配置管理是全部其它服务管理步骤不可分割一部分。
拥有目前架构中全部部件最新，正确，全方面和具体信息，并管理其变更，使这些信息有效而高效地支持其它步骤运行。
变更管理能够和配置管理集成。
最少，提议在配置管理系统中控制变更登录和实施，并自在配置管理系统帮助下对变更影响做出评定。
所以全部变更请求应该被输入配置管理数据库（CMDB），并伴随变更请求进展随时更新统计，直至其实施。
配置管理系统识别一个变更项目和架构中其它部件关系，将这些部件全部些人召集到影响评定步骤中来。
不管一个变更是否在架构中实施，相互关联配置管理统计应该在CMDB中得到更新。
最好在变更发生时，使用集成工具自动地更新统计。
CMDB应该开放给整个服务支持组，使全部些人了解部件失效可能原因，从而使突发事件和问题能够被更轻易地处理。
CMDB还应该被用来把突发事件及问题统计和其它统计联络起来，比如失效配置项目（ConfigurationItem-CI）和用户之间联络。
假如缺乏了配置管理步骤集成，公布管理将难以实现，并可能错误连连。
服务交付步骤一样依靠于CMDB中数据。
比如：
服务等级管理需要识别相互结合在一起部件，并在此基础上设置支持协议，交付服务。
IT财务管理需要知道每个业务部门使用IT架构部件，尤其是对于收费项目。
IT服务连续性和可用性管理需要识别部件，用于问题风险分析和部件失效影响分析。
下图显示了配置管理和其它服务管理步骤之间关系：
图：
能力管理，变更管理，配置管理和公布管理之间关系
2.2.1.5变更管理
变更管理专注于对IT架构实施可控变更。
此步骤目标是确定所需变更，并决定这些变更怎样在对IT服务产生最小不利影响范围内得以实施。
同时确保其变更是可追溯，而且是经过整个组织内部有效地磋商和协调。
在用户组织提交变更请求后，由配置管理步骤监控其状态，和问题管理和若干其它步骤进行协调。
变更实施推行一特定路径，包含定义，计划，建立，测试，接收，实施，和评定。
变更管理步骤依靠于配置数据正确性，以确保获知全部实施
变更造成影响。
所以变更管理和配置管理之间有亲密联络。
变更步骤具体内容应在SLA中存档，确保用户知道提交变更申请程序，项目目标立即间，和实施变更造成影响。
变更具体内容需要通知服务台。
即使变更经过了全方面测试，仍然很有可能存在实施变更过程中发生多种困难，这些困难可能缘于变更没有按需求或预期运行，或对变更对功效造成影响产生质疑。
变更咨询会议（ChangeAdvisoryBoard-CAB）由可向变更管理小组提供教授意见人员组成。
这个会议很可能由来自于全部领域IT及业务单位人参与。
2.2.1.6公布管理
公布是指一组配置项目（ConfigurationItems–CI）经过测试被引入处于活动状态环境中。
公布管理关键目标是确保公布信息被成功地公布，包含归纳综合，测试和存档。
公布管理确保只有经过测试和正确授权软硬件版本才能提供给IT运行环境。
公布管理和配置管理和变更管理行为亲密相关。
真实变更实施常常经过公布管理行为得以落实。
变更结果可能常常来自于新硬件，新版本软件，和新文档（自行建立，或购置而来）等。
对它们进行控制，并打包和颁发。
相关存档安全和公布程序应该和变更管理和配置管理步骤紧密集成。
公布程序也可能作为突发事件管理和问题管理步骤中不可分割一部分，同时还和CMDB亲密相连，以维护立即更新统计。
2.2.2服务提供
服务提供关键包含：
服务等级管理、IT服务财务管理、能力管理、连续连续管理、可用性管理等。
2.2.2.1服务等级管理
服务等级管理目标是缕清和用户之间相关IT服务协议，并付诸实施。
所以，服务等级管理需要搜集用户需求，IT服务组织可提供设施，和可用财务资源。
服务等级管理针对提供给用户服务（聚焦用户）。
所以是基于用户需求建立服务（需求拉动），而非单纯基于现有技术所及（供给驱动），从而使IT服务组织提升用户满意度。
服务等级管理叙述内容有：
●怎样在服务等级协议（ServiceLevelAgreement–SLA）中清楚地定义条款，使其可优化IT服务成本，并为用户所接收。
●怎样监控和讨论所提供服务。
●怎样管理IT服务组织供给商及其下包协议。
服务等级管理（ServiceLevelManagement－SLM）步骤是用来确保服务等级协议，并支持运行等级协议及其它协议，确保全部对服务质量影响降低到最小。
此步骤在服务质量和SLA基础上评定多种变更造成影响，包含预期变更前影响，也包含评定实施变更后影响。
SLA中一些最关键目标和服务可用性、和在许可周期内对突发事件形成决议相关。
SLM是服务支持和服务交付关键。
因为它依靠于其它步骤存在性，有效性及运行效率，它不可孤立存在。
一个缺乏基础支持步骤SLA是没有意义，缺乏支持SLA就失去了认可其内容基础。
2.2.2.2IT服务财务管理
财务管理针对于IT服务谨慎从事。
比如，当所提供IT服务在进行中时，财务管理将提供其造成成本信息。
这么使考虑IT架构或IT服务改变时，能够合理地考虑成本和利益（价格和性能）之间关系。
财务管理中对成本判别、分配、估计和监控使成本成为可知原因，降低成本和预算差距。
关键结合IT服务组织赢利，IT服务财务管理描述了多个支付方法，包含设置支付和定价目标，和预算计划。
财务管理负责对成本及IT服务投资回报会计核实，并管理任何来自于用户成本。
财务管理需要和能力管理（CapacityManagement），配置管理（ConfigurationManagement，包含资产数据），和SLM良好接口，来确定服务真实成本。
在IT组织预算谈判阶段和用户IT花费核实阶段，财务管理很可能和业务关系管理（BusinessRelationshipManagement）及IT组织亲密相关。
2.2.2.3能力管理
能力管理是优化成本，取得时间，和开发IT资源步骤，来支持和用户签署服务条款。
能力管理针对资源管理，性能管理，需求管理，建模，能力计划，负载管理，和应用软件能力推测。
能力管理强调用计划来确保所签署服务等级能够被推行和成长。
能力管理负责确保在全部时间含有足够可用能力，以满足业务需求。
能力管理不是简单地和系统部件性能相关，而是直接和业务需求相关。
在那些和能力问题相关困难面前，能力管理在突发事件决议和问题判别过程中被引入。
能力管理提交变更请求以确保得到合适可用能力。
这些RFC被提交给变更管理步骤，其实施可能影响若干CI，包含硬件，软件和文档，并需要提供有效版本管理。
能力管理应该在评定全部变更时被引入，用来确定变更造成在能力和性能上影响。
这种影响在变更实施前后全部有可能出现。
能力管理应该尤其关注变更在一定周期后引发累积性改变。
轻易被忽略单个变更往往在经过累积后，引发响应时间衰减，文件存放问题，和对处理能力过分需求。
2.2.2.4IT服务连续性管理
此步骤在业务中止时对IT服务进行灾难恢复方法准备和计划。
业务连续性管理为用户组织碰到灾难时准备好紧急预案，依据此预案采取和IT服务相关预防灾难发生方法。
IT服务连续性管理步骤对技术，财务和管理资源需求做好计划和协调，确保灾难发生后可连续提供服务，并就其内容达成用户同意。
IT服务连续性管理和一个组织在业务中止后在某个可许可范围内继续运作能力亲密相关。
最少要确保最基础业务运行所需要IT服务，预先对其服务等级作出要求，并和用户达成一致。
有效IT服务连续性需要一个平衡风险缩减方法，比如有弹性系统和备份恢复设施。
配置管理步骤中数据被用来辅助其计划和预防方法。
需要对架构和业务变更对连续性计划造成潜在影响进行评定。
相关IT和业务计划应该提交变更管理程序。
在连续性管理步骤中，服务台负担着关键角色。
2.2.2.5可用性管理
可用性管理是确保资源，方法和技术得以合适拓展步骤，以支持和用户签署IT服务条款。
可用性管理针对所碰到问题，如优化维护等，而且设计测量指标，最大程度降低意外突发事件数量。
可用性管理和IT服务设计，实施，测量和管理相关，确保要求业务需求中相关可用性内容被落实。
可用性管理需要了解IT服务失效发生原因和恢复服务所需事件。
突发事件管理和问题管理提供了关键输入
SLA中描述可用性目标在可用性管理步骤中被监控，并包含在其报表中。
另外，在支持服务核查制度所提供测量和报表中，可用性管理对服务等级管理（SLM）步骤提供了支持。
2.3运维服务管理计划
2.3.1第一阶段：
服务磨合阶段
第一阶段，又称为运维服务磨合阶段，工作目标关键是经过服务管理，将用户现有无序救火式突发事件服务有序化，实现突发事件管理，全部突发事件将利用技术、管理和步骤相结合方法，做到统一管理，统一任务分发，安排适宜人员处理适宜事件。
全部突发事件全过程可控制、跟踪、即时回馈，让每一个用户能够随时查询到事件处理过程，不会出现焦虑、服务要求长时间无人响应或服务要求根本无人响应情况，从而提升用户满意度，提升运行维护效率，提升用户使用业务信息系统效率，从而做到提升总体生产力。
现今用户大全部没有真正意义上配置管理系统。
配置管理系统，顾名思义，含有业务信息系统及终端设备具体清单，配置情况，针对于业务信息系统操作系统服务运行情况，终端运行软件情况，使用软件资产情况等，和每一次配置改变统计，做到配置改变全部有迹可查，将软硬件资产系统化管理起来。
用一句话概括我们上述两项服务：
将无序突发事件有序化，将纸制配置管理信息化。
就是我们突发事件管理和配置管理目标。
ITSM所定义处理突发事件工作目标是规避和立即恢复。
运维服务目标不是尽可能多，尽可能快完成服务，而应该是尽可能避免事件发生，当然，这不是一步能够到位，所以，在第一阶段，我们需要做到立即恢复用户正常使用，故：
在处理突发事件时，我们不分析事件发生原因，只搜集有价值事件/故障信息，并在最短时间内将用户设备恢复到正常使用状态。
针对于反复/频繁发生突发事件，我们需要转问题管理步骤，给予处理。
问题管理，也就是事件原因分析和根除此事件处理方法管理，我们需要对突发事件发生原因，使用专业方法给予分析，如使用国际QA标准，使用鱼骨图，使用柏拉图等方法来分析出可能原因，并对原因给予检测和测试，提出根本处理事件方案。
鱼骨图分析法
柏拉图分析法
问题管理，仅提出处理问题之道，也就是根除某突发事件方案，具体处理步骤，交由实施管理来实施。
实施管理，又叫做公布管理，因根除故障尤其是信息系统缺点时，需要严格处理过程，避免在线运行业务受到不可估计影响。
我们在公布过程中全部会估计到部分可能影响，如更改交换机配置可能造成部分终端无法使用网络；修改某一个数据库字段可能造成数据混乱；修改某段代码可能造成整个程序陷入死循环等。
所以实施管理必需能有效并切实分析大部分存在或隐含风险。
试想我们在更改交换机配置前经历过充足测试，将中止网络时间缩短为五分钟而且通知到全部/大部分可能受影响用户；修改数据库字段或代码前在虚拟测试平台或访真数据库中反复测试，以后给予公布；将公布时间定在非使用高峰期。
这么，能够规避大量风险，确保问题处理安全可靠。
越维风险控制模型
凡包含四处理问题，肯定关联到变更。
变更管理作用，是确保每一步配置更改，全部有迹可查，有些人可寻。
在工作中是否碰到过有些人修改了系统代码，您却不知道是谁改动了哪些地方？
验收后提供系统原代码不知道是否和在线系统原代码相符？
有哪些地方不一样？
是哪些人修改？
您设备是否和刚采购时候配置情况相同？
保修情况一直保持不变？
变更后资产是否已经更新配置库？
变更管理将为您解答上述问题。
第一阶段服务，就涵盖上述五个方面服务内容，总结描述：
将无序突发事件有序化，将纸制配置管理信息化，问题管理科学化，实施管理风险可控制化，和变更管理统计化。
2.3.2第二阶段：
主动服务阶段
关键是在改良前一阶段服务基础上，将前一阶段大量响应式服务，部分主动式服务，转换为主动服务为主导，科学规避故障发生，做到故障可控制化。
所以，第二阶段服务内容，关键包含：
实施&测试、安全管理、IT服务计划，和规模管理、可用性管理、服务等级管理和成本管理。
实施&测试：
前面我们讲实施管理，包含有上线前充足测试等工作，那这一个实施&测试是否反复呢？
此处实施&测试，是和业务信息系统开发质量管理相关实施管理和测试管理工作。
伴随业务信息化需求不停提升，业务系统升级也随之产生。
是Down掉原有系统建设新，还是在原有系统基础上进行修改？
是用新服务器替换掉原有服务器，还是在原有服务器上升级？
这些处理，全部面临一个必不可少阶段：
切换。
用户往往不愿意更换已经使用习惯了系统，除非系统已经不能满足她实际工作需求，但老系统总是存在大量缺点，且运行效率低下，造成业务部门工作效率也随之下降。
那么，为何用户不愿意更换系统？
原因是不熟悉。
已经开顺手车不会轻易出事故，已经用顺手手机能够方便找到每一个联络电话，而新系统培训，是否进行得完善？
新业务步骤讲解，是否让每一个业务部门人员熟悉了？
新系统是否有这么那样缺点而造成更低下效率？
新系统是否能够承载足够多用户访问？
新采购硬件是否能够确保质量？
业务系统能够经过分析代码来找寻缺点，不过需要时间过长，能够在测试平台上对每一个功效进行测试，不过无法满足压力测试，只有将多个测试手段有机结合起来，才能保障新系统质量，如使用Winruner给予界面测试，使用Loadruner进行压力测试，并管理好开发商培训工作，将给实施和测试工作带来实质性效果。
另外，选择适宜公布时间，做好公布计划，也是实施管理工作关键。
安全管理，指服务过程安全类服务、风险控制和和用户数据安全协议。
安全类服务如网络病毒防治，网络反黑，入侵检测等技术类服务，风险控制如服务过程中多种风险分析、规避等管理。
技术类工作能够经过软件等工具来实现，如系统补丁分发，防病毒软件升级及策略优化，网络安全性优化，增加入侵检测系统（IDS）等，这些服务也能够在第一阶段中开始，而风险控制和用户数据安全性协议，则完全经过人员管理、步骤管理来实现。
标准ITSM步骤是能够做到0风险，但在实际处理过程中却往往不可能做到0风险。
毕竟步骤是靠人来运转，而人员是否能够完全遵照步骤指导来实施，就是管理方法问题了。
运维被称为PeopleBusiness，就证实人员管理犹在步骤管理之上。
所以，运维人员素质是一个至关关键条件。
越维人员稳定，且大全部经历过保密培训，这些全部是实现安全管理必需条件。
另外，我们在项目开启前将和用户签定保密协议，确保用户数据安全。
IT服务计划：
此时我们对用户情况已经有所了解，且积累部分维护服务数据，假如进行了业务系统维护，更应该对用户业务步骤有了一定了解，此时能够针对用户现在使用信息系统或设备提出服务计划，包含怎样建立和推广运维服务系统平台，怎样和多方监控软件整合形成集中管理，怎样将运维部门由产出部门转换为产入部门等。
规模管理：
用户除本部外，还设有系列分部，分布地理位置比较靠近，在第一期项目中即能够组成2级服务结构，使用集中式服务台（ServiceDesk）统一报障和任务分发，这在资源充足利用上有很大意义。
如越维某用户单位正在策划将越维设置在总部统一故障受理平台（ServiceDesk）服务范围扩充到涵盖全市范围内全市各区分局及所辖下属单位集中式运维服务管理平台。
一样，规模扩充将不限于服务台，整体运维服务也能够在全市服务环境建立基础上发挥其集中管理覆盖面广特色。
可用性管理：
经过对用户系统环境了解和熟悉，和在磨合阶段系统改良，我们此时充足依据用户实际需求，做出符适用户成本，尽可能高可用性管理承诺。
可用性管理目标是合理调配有限资源，采取应急预案等手段保障关键系统正常运行，可用性承诺是服务方对用户方系统情况熟悉度结合本身技术承载能力所做出质量确保。
现在，越维对某用户做出系统可用性承诺高达98%。
服务等级管理：
同可用性管理，服务等级管理目标是确保服务提供根据服务等级协议（SLA）约
升级会员 