IT运维管理服务专项方案.doc

第1章 项目概况 4
1.1 项目背景 4
1.2 项目目标 4
1.3 需求分析 4
第2章 运维服务管理体系建设 6
2.1 IT运维管理概述 6
2.2 运维管理步骤体系 7
2.2.1 服务支持 8
2.2.2 服务提供 14
2.3 运维服务管理计划 18
2.3.1 第一阶段：服务磨合阶段 18
2.3.2 第二阶段：主动服务阶段 21
2.3.3 第三阶段：战略计划阶段 24
2.4 运维服务质量管理 24
2.5 建立运维管理规范 26
2.5.1 运维管理规范概要 26
第3章 信息系统运行保障方案 28
3.1 统一服务台建设 28
3.2 建立文档管理制度 29
3.3 通常信息化设备及相关软件运维管理 33
3.3.1 通常信息化设备服务范围 33
3.3.2 通常信息化设备运维 33
3.3.3 例行维护步骤图 34
3.3.4 通常设备服务方案 35
3.4 防（杀）病毒服务 40
3.4.1 防病毒服务需求 40
3.4.2 制订合理防病毒策略和安全管理制度。 40
3.4.3 用户端防病毒升级软件 41
3.4.4 防毒组件立即更新 41
3.4.5 每七天防毒系统布署情况统计 42
3.4.6 每七天对产生病毒事件进行评定 42
3.5 信息资产巡检及普查服务 42
3.5.1 主动巡检 42
3.5.2 信息资产普查 43
3.6 其它相关说明及要求 43
第4章 运维服务计划方案 45
4.1 运维服务准备 45
4.1.1 签定必需协议和约定 45
4.1.2 人员准备 45
4.1.3 工具准备 45
4.2 项目人员组织 46
4.2.1 人员结构 46
4.2.2 人员职责和岗位要求 47
4.3 服务计划 48
4.3.1 服务时间 48
4.3.2 进场初始阶段 48
4.3.3 第一个服务阶段 49
4.3.4 第二个服务阶段 49
4.3.5 服务总结和延续阶段 50
第5章 应急服务方案 51
5.1 灾难应急方法 51
5.1.1 应急方法体制图和总则 51
5.1.2 大型灾难紧急行动方案 52
5.2 运行服务应急方案 55
5.2.1 开启应急步骤 55
5.2.2 成立应急小组 58
5.2.3 应急处理过程 58
5.2.4 应急处理结果评定 59
5.2.5 统计和汇报 59
第6章 服务水平质量承诺及服务管理 62
6.1 服务水平体系 62
6.1.1 汇报服务 62
6.1.2 管理类服务 62
6.1.3 主动式服务 63
6.1.4 响应式服务 63
6.2 服务承诺 64
6.2.1 服务等级承诺 64
6.2.2 服务质量承诺 65
6.3 服务管理 65
6.3.1 服务管理总则 65
6.3.2 服务步骤管理 66
6.3.3 服务台支持管理 67
6.3.4 事件管理 69
6.3.5 问题管理 70
6.3.6 知识库管理 71
6.3.7 服务统计管理 71

第1章 项目概况
1.1 项目背景
多年来为适应业务发展需求，XX企业进行了大规模电子商务建设，包含采购桌面PC约300台，打印机约100台，这些应用系统及硬件设备投入使用极大推进了XX企业信息化建设进程。伴随越秀工商局对整体IT系统（硬件、软件、网络通讯…）可用性要求日益提升，系统运行保障和维护管理就成为确保业务系统安全稳定可靠运行最有力手段。
XX企业关键有一栋N层办公环境，现阶段对设备维护关键采取自主维护方法。因为人力有限，建设任务繁重，中心技术人员在接手新项目及日常工作同时往往需要做大量维护工作，不少技术人员长久处于满负荷，严重影响了工作效率。在目前有限人力物力资源下，为了保障和提升IT服务质量，XX企业有必需将计算机、外设及网络运行维护进行外包，派驻2名工程师进行维护，以处理目前IT服务个方面日益增加需求和有限提供能力之间矛盾，提升XX企业办公区域内软、硬件、业务应用软件运行维护效率，确保信息系统正常运行。
1.2 项目目标
结合XX企业业务工作及信息化建设实际，完善运维管理体系建设，加强信息系统正常运行保障，“以步骤为导向，以服务为关键”提升服务质量水平、转变服务理念、拓宽服务范围、提升服务效率、提升用户服务满意度。
1.3 需求分析
此次项目XX企业需求关键包含两个部分，
1、IT运维管理体系建设要求；
2、信息系统正常运行保障服务。
其中运维管理体系建设应完善服务内控制度即服务质量管理，逐步建立起一套符合XX企业本身实际运维管理标准及应用制度；建设IT运行维护管理平台，采取标准IT运维管理步骤，提供正确、详尽、专业汇报制度，经过客观分析运维过中出现多种障碍及问题，为XX企业信息化建设提供决议依据。
信息系统正常运行保障涵盖了
1、 通常信息化设备及软件运维管理；
2、 、防病毒服务；
3、 办公区域内设备及软件巡检普查；
4、 提供符合XX企业实际服务响应水平及质量保障；
5、 信息化资产管理

第2章 运维服务管理体系建设

2.1 IT服务管理概述
现今，伴随计算机技术，尤其是网络技术飞速发展，对于很多行政单位，很多企业而言，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服务步骤。
2.2 运维服务管理步骤体系
运维务管理最关键是“服务支持”（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服务组织提升用户满意度。服务等级管理叙述内容有：
l 怎样在服务等级协议(Service Level Agreement – SLA)中清楚地定义条款， 使其可优化IT服务成本， 并为用户所接收。
l 怎样监控和讨论所提供服务。
l 怎样管理IT服务组织供给商及其下包协议。
服务等级管理(Service Level Management －SLM)步骤是用来确保服务等级协议，并支持运行等级协议及其它协议，确保全部对服务质量影响降低到最小。此步骤在服务质量和SLA基础上评定多种变更造成影响，包含预期变更前影响， 也包含评定实施变更后影响。SLA中一些最关键目标和服务可用性、和在许可周期内对突发事件形成决议相关。
SLM是服务支持和服务交付关键。因为它依靠于其它步骤存在性， 有效性及运行效率， 它不可孤立存在。一个缺乏基础支持步骤SLA是没有意义， 缺乏支持SLA就失去了认可其内容基础。
2.2.2.2 IT服务财务管理
财务管理针对于IT服务谨慎从事。比如，当所提供IT服务在进行中时，财务管理将提供其造成成本信息。这么使考虑IT架构或IT服务改变时，能够合理地考虑成本和利益(价格和性能)之间关系。财务管理中对成本判别、分配、估计和监控使成本成为可知原因，降低成本和预算差距。 关键结合IT服务组织赢利， IT服务财务管理描述了多个支付方法，包含设置支付和定价目标，和预算计划。
财务管理负责对成本及IT服务投资回报会计核实，并管理任何来自于用户成本。财务管理需要和能力管理(Capacity Management)，配置管理(Configuration Management，包含资产数据)，和SLM良好接口， 来确定服务真实成本。 在IT组织预算谈判阶段和用户IT花费核实阶段， 财务管理很可能和业务关系管理(Business Relationship Management)及IT组织亲密相关。
2.2.2.3 能力管理
能力管理是优化成本，取得时间，和开发IT资源步骤，来支持和用户签署服务条款。能力管理针对资源管理，性能管理，需求管理，建模，能力计划， 负载管理，和应用软件能力推测。能力管理强调用计划来确保所签署服务等级能够被推行和成长。
能力管理负责确保在全部时间含有足够可用能力，以满足业务需求。 能力管理不是简单地和系统部件性能相关， 而是直接和业务需求相关。 在那些和能力问题相关困难面前， 能力管理在突发事件决议和问题判别过程中被引入。
能力管理提交变更请求以确保得到合适可用能力。 这些RFC被提交给变更管理步骤， 其实施可能影响若干CI， 包含硬件， 软件和文档，并需要提供有效版本管理。
能力管理应该在评定全部变更时被引入， 用来确定变更造成在能力和性能上影响。 这种影响在变更实施前后全部有可能出现。 能力管理应该尤其关注变更在一定周期后引发累积性改变。 轻易被忽略单个变更往往在经过累积后， 引发响应时间衰减， 文件存放问题， 和对处理能力过分需求。
2.2.2.4 IT服务连续性管理
此步骤在业务中止时对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风险。毕竟步骤是靠人来运转，而人员是否能够完全遵照步骤指导来实施，就是管理方法问题了。运维被称为People Business，就证实人员管理犹在步骤管理之上。所以，运维人员素质是一个至关关键条件。越维人员稳定，且大全部经历过保密培训，这些全部是实现安全管理必需条件。另外，我们在项目开启前将和用户签定保密协议，确保用户数据安全。
IT服务计划：此时我们对用户情况已经有所了解，且积累部分维护服务数据，假如进行了业务系统维护，更应该对用户业务步骤有了一定了解，此时能够针对用户现在使用信息系统或设备提出服务计划，包含怎样建立和推广运维服务系统平台，怎样和多方监控软件整合形成集中管理，怎样将运维部门由产出部门转换为产入部门等。
规模管理：用户除本部外，还设有系列分部，分布地理位置比较靠近，在第一期项目中即能够组成2级服务结构，使用集中式服务台（Service Desk）统一报障和任务分发，这在资源充足利用上有很大意义。如越维某用户单位正在策划将越维设置在总部统一故障受理平台（Service Desk）服务范围扩充到涵盖全市范围内全市各区分局及所辖下属单位集中式运维服务管理平台。一样，规模扩充将不限于服务台，整体运维服务也能够在全市服务环境建立基础上发挥其集中管理覆盖面广特色。
可用性管理：经过对用户系统环境了解和熟悉，和在磨合阶段系统改良，我们此时充足依据用户实际需求，做出符适用户成本，尽可能高可用性管理承诺。可用性管理目标是合理调配有限资源，采取应急预案等手段保障关键系统正常运行，可用性承诺是服务方对用户方系统情况熟悉度结合本身技术承载能力所做出质量确保。现在，越维对某用户做出系统可用性承诺高达98%。
服务等级管理：同可用性管理，服务等级管理目标是确保服务提供根据服务等级协议（SLA）约定实施，如2小时响应4小时处理。通常在项目初始阶段会有一个初始服务等级（SLA）这是对服务商本身技术承载能力，服务初始资源安排和用户基础需求约定，不可能完全符适用户实际情况，那么在第二阶段，已经有充足时间分析用户实际需求，审阅本身技术承载能力，二者相结合做出真正符适用户实际服务等级承诺，并由服务等级调配相关资源。如越维和某用户一期项目服务等级为全部故障2小时响应4小时处理，而在二期7至9月中，越维平均故障恢复时间，仅为18分钟！
成本管理：前面提到了很多“资源”调配问题，伴随对用户系统环境熟悉，我们能够分析出用户更为实际需求。如关键业务不能发生故障，而某台不常被使用一般终端可能两天内修复也不会影响工作，所以不需要提供过多资源进行紧急维护，成本管理目标是在用户能够接收预算内尽可能高提升系统可用性。运维不是多做突发事件处理，而是降低突发事件发生率，所以善用工具，降低紧急事件，也能够有效控制成本；做好规模管理，有效合理使用整体资源，更是控制成本好方案。综上，成本管理意义，就在于资源合理，充足使用。
2.3.3 第三阶段：战略计划阶段
第三阶段，用户已经和服务商紧密结合为战略合作伙伴关系，能够为用户制订IT战略计划，能够对用户业务投资建设信息系统使用所发明业务价值给予计算和评定，并能够帮助业务部门对最终用户给予管理。
2.4 运维服务质量管理
和 “产品”不一样，“服务”提供贯穿于和用户互动中。 只有当服务被提供时，才能表现其存在和价值。 服务质量取决于服务提供者和其用户间互动过程中一些协议实现程度。 用户怎样感知服务优劣， 服务提供者怎样考虑所提供服务，二者全部很大程度上取决于她们经验和期望。
提供服务步骤是生产和使用一个组合方法，经过步骤使服务提供者和用户同时参与服务过程。用户对服务感知关键来自于服务供给过程。用户通常见以下问题评价服务质量：
l 所提供服务是否达成期望？(质量可衡量性)
l 能否在数次服务中得到一样质量？(质量稳定性)
l 服务所需成本是否合理？(质量和成本)
服务是否达成用户期望关键取决于用户在多大程度上赞同所交付服务内容， 而不是服务提供者提供了多“好”服务。 所以开展有效和连续用户对话机制极为关键。
服务质量取决于服务完成用户需求和期望程度。为了能够提供所需质量， 服务提供者应该连续评定服务经验， 了解用户对未来期望。不一样用户考虑内容和方法全部不尽相同。所以优质服务全部是为客“户量身定做”，这也是服务区分于产品关键特点。
ISO-8402对质量定义是：“质量是一个产品或服务就其含有能力满足确定或暗示需求总体特征。”质量“高”往往意味着产品或服务在某种程度上超出了用户期望。
在质量得以确保同时，成本也是用户同时考虑原因。或说在就其对服务期望达成协议以后紧接着步骤就是对成本达成协议。服务成本必需是合理 --- 对于服务提供者来说表现其实施成本和合理利润，对于用户来说是建立在对服务市场所理了解和选择之上。
用户对服务质量评定另一关键依据是服务一贯性。假如服务提供者偶然能够提供超出用户期望服务， 但在其它时间却常常让用户失望， 则显然不能称之为质量合格者。 “连续质量”是最为关键， 也常常是服务业最难以实现目标。
服务(或产品)提供是经过交付行为实现。 而其质量很大程度上取决于组织这些行为方法。 Deming质量轮提供了一个简单有效质量控制模型：

这一模型假设要实现有效质量控制， 必需反复推行以下步骤：
l 计划(Plan)： 应该做什么？什么时候做？谁去做？怎样做？借助什么去做？
l 实施(Do)： 实施计划行为。
l 检验(Check)： 确定实施行为是否提供了预期结果。
l 效果(Act)： 基于检验得到信息修正计划。
有效和适时地推进此轮旋转， 意味着服务行为被根据各自计划和检验机制分为各子步骤。 必需清楚谁在组织中负有责任， 她们被授权修改哪些计划和程序， 不仅为某一个行为， 而且为每一个步骤。
质量管理(Quality Management)是在提供服务组织中工作每一个人责任。 每一个职员必需明白她对组织作出结果怎样影响工作质量， 影响其它同事作出工作质量， 而且最终怎样影响整个组织提供服务质量。 质量管理同时意味着连续地寻求改善组织机会，实施能够改善质量行为。
质量确保(Quality Assurance)是组织内部关键政策，用来确保质量管理实施。 它集中表现了一整套质量衡量标准和推行程序，确保组织能够提供持久满足用户期望及相关协议服务。质量确保确保质量管理所实施结果处于可维护状态。
总而言之，此次越秀工商运维项目标服务质量管理，围绕质量系统服务步骤是确保服务质量持久延续有效方法。
2.5 建立运维管理规范
2.5.1 运维管理规范概要
我门和XX企业共同学习ITIL、ITSM、BS15000、ISO0和ISO9000等中国外优异标准，运维管理规范采取ISO9000模式编写，涵盖服务管理体系、服务等级管理、服务台管理步骤、突发事件管理、问题管理、变更管理、公布管理、配置管理等方面，以下图所表示：

如上图所表示，是一个金字塔结构。处于最高层，是《用户满意度指导》，一切服务均以“确保用户最大满意度”为前提展开。和之同级还有服务管理体系文件和总体文件，用以和服务管理体系相结合，而且维持服务管理规范改良性标准。处于中层，是ITIL关键11个标准步骤，均依据XX企业实际情况进行了修订和优化，以确保在XX企业实际工作中能够得到实际应用，运维管理规范是多种操作指南和巡检制度，包含日常管理制度等，确保提供给用户服务，是统一形象规范化标准服务。巡检制度建立，为XX企业信息系统“提升系统可用性、提升系统健壮性、提升各级人员技能素质”“三提升”目标奠定了坚实基础。

第3章 信息系统运行保障方案
3.1 统一服务台建设
提供统一报障电话，统一报障、统一维修接口，XX企业能够经过统一报障电话申请服务、查询服务处理进程，跟踪处理进度，确保服务时效、控服务质量、调查用户满意度。这个统一服务接口，在国际上有个标准称呼：服务台（Service Desk）。我们将为XX企业建立统一服务台，提供优质、专业报障受理、跟进服务；
服务台总体架构以下：

服务台（服务台）在服务支持中饰演着一个极其关键角色。完整意义上服务台能够了解为其它IT 部门和服务步骤“前台”，它能够在不需要联络特定技术人员情况下处理大量用户请求。对用户而言，服务台是她们和IT 部门唯一连接点，确保她们找到帮助其处理问题和请求相关人员。
服务台不仅负责处理事故、问题和用户问询，同时还为其它活动和步骤提供接口。
这些活动和步骤包含用户变更请求、维护协议、服务等级管理、配置管理、可用性管理和连续性管理等，服务台还负责事件快速响应，使用已知问题、已知事件知识库对终端用户突发事件给予快速恢复或规避事故发生。
3.2 建立文档管理制度
文档管理目标是经过对运维服务过程中使用文档进行统一管理，达成充足利用文档提升服务质量目标，确保运维资源符合运维服务要求。文档资源包含运维体系文档、项目（软硬件）文档资料、服务质量管理文档和服务汇报文档等。
双方职责为：XX企业：负责同意运维文档更改、删除和公布。XX企业运维部组织编写及更改运维文档；同意文档借阅申请。运维服务商负责更新文件目录清单；负责保管文档资料；负责备份文档资料；检验各类在用文件有效性，预防使用无效版本；负责定时提交服务质量管理文档和服务汇报文档等。
文档资源管理步骤图

文档资源管理工作程序
文档资源管理包含对以下五类文档进行管理：
l 运维文档：指运维体系文档，包含运维手册、程序文件、相关支持文件及表单格式等。
l 项目文档：指交付运维软硬件系统相关文档。
l 质量管理文档
l 服务汇报文档
l 其它文件资料：指文件、传真、外来资料等。
A、运维文档编码规则
文档分级
文档编号规则
说 明
示 例
一级文件
（总体）
A+两位一级文件序列号
两位一级文件序列号从01起次序递增
A01：术语表
A02：总纲
二级文件
（程序文件）
B+两位二级文件序列号
两位二级文件序列号从01起次序递增
B01：服务等级管理程序文件
B02：服务台管理程序文件
三级文件
（支持性文件）
C+二级文件序列号+两位三级文件序列号
三级文件均从某个二级文件产生，此处二级文件序列号是指和本文件对应二级文件序列号；两位三级文件序列号从01起递增
C0101：服务等级计划
C0102：服务目录
四级文件
（表单）
D+二级文件序列号+两位四级文件序列号
四