IT外包运维服务方案详细完整版.docx
《IT外包运维服务方案详细完整版.docx》由会员分享，可在线阅读，更多相关《IT外包运维服务方案详细完整版.docx（63页珍藏版）》请在冰豆网上搜索。
IT外包运维服务方案详细完整版
IT外包运维服务方案详细完整版
IT外包服务方案
[键入文档副标题]
DADA
2020-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）统一报
升级会员 