1.1.运维架构设计基于ITIL的运维管理体系的建立是企业在发展路程的一个阶段。

而一个良好的运维管理系统，需要有一个清晰的运维流程来支撑。

建设运维管理平台是一个长期的、持续的过程。

基于ITIL的运维服务体系建设应包含运维服务制度、流程、组织、队伍、技术和对象等方面的内容。

同时结合业务特色，整合运维服务资源，规范运维行为，确保服务质效，形成统一管理、集约高效的一体化运维体系，从而保障数据集中条件下网络和应用系统安全、稳定、高效、持续运行。

1.1.1.基于ITIL运维服务管理机制基于ITIL建立运维服务管理体系的过程分为以下7个步骤：理念导入、评估现状、确定目标及范围、流程设计、工具实施、上线试运行、持续改进。

理念导入理念导入是ITSM项目实施的第一步，也是决定项目能够成功实施的关键一步。

理念导入主要是学习、研讨、灌输基于ITIL最佳实践运维管理体系框架，包括ITIL的基本知识和实施理念，有共同的语言和目标，并明确运维服务管理的愿景，在组织内进行宣导。

培训课程可以采用提问和研讨的方式，让运维人员成为主角。

评估现状完成理念导入并建立愿景后，需要评估组织当前的服务管理流程成熟度及运维服务管理的现状，并查找分析差距，进一步明确目标和范围。

现状评估就是要通过定性和定量的分析、恰当的研究方法（包括调查问卷和现场访谈、观摩等）全面了解组织的运维服务状况，及其与理想状态之间的差距，并撰写评估报告。

这是后面确定运维管理范围、工具实施的基础。

确定目标、范围根据现状评估结果，制定近期运维服务管理的目标与范围。

在不同评估现状下，制定的目标也不同，随着体系的不断改进完善，目标也在不断提升，迭代式地实现已制定的愿景。

梳理并固化服务流程，优化服务模式，通过系统实施和推广优化逐步提升运维服务管理能力，防范运维管理的风险，基于ITIL 构建初步的运维服务管理体系。

包括：（1）基于ITIL思想梳理并固化运维服务管理流程；（2）实现统一的运维服务台，建立集中的运维知识库；（3）完成事件、问题、配置和变更发布流程的实施；（4）构建统一的配置数据库，为运维服务提供精确化的数据支持。

流程设计有了目标与范围，就需要制定和实施运维服务管理方案，主要包括管理体系的梳理、流程设计的选型等环节。

流程设计可以遵从先事件、服务台、问题、知识、服务级别后变更、发布、配置管理等顺序。

流程设计包括流程研讨、流程详细设计、评审确认3个环节。

其要点是保证运维人员、管理层的参与度，由咨询顾问带领企业人员共同设计，关键点是要做好评审确认，让运维人员和管理层尽可能达成一致。

评审确认会一般有两轮或多轮才能完成。

工具实施管理体系的设计、流程的制定、流程中相关指标的确立，都需要结合选择的工具以辅助体系实施，从而提高实施的效率。

为了更好地符合企业自身的特点，本文采用在某成熟供应商的成熟产品基础上定制化开发，实现功能相对简单且能满足使用要求的运维服务管理平台。

运维服务管理平台共包含事件管理、自助服务管理、服务请求管理、问题管理、知识管理、变更管理、发布管理、配置资产管理、计划作业（含任务管理）、服务水平管理、报表管理等11个功能模块，其逻辑框架图。

本文重点阐述已实施的事件管理、自助服务管理、变更管理、配置及资产管理等模块。

（1）事件管理事件管理又称故障管理（Incident Management），其主要目标是尽可能快地恢复到正常的服务运营，将事故对业务运营的负面影响减小到最低，并确保可以维持服务质量和可用性的最高水平。

事故管理的关键环节是：事件检测与记录、事件分类与初步支持、事件调查与诊断、事件解决与恢复、事件关闭、事件跟踪回顾等环节。

事件管理流程实施得好坏直接关系到项目的成败。

主要考虑如下几点：①事件的分类。

进行前期的梳理，事件按照类别、子类和条目进行分类。

一级分类包括桌面、网络、系统、信息安全、机房环境和应用。

②确定事件的优先级。

事件的优先级由事件的影响度和紧急度来确定。

影响度通常是考虑受影响的数量、部门，某种意义上将影响度往往等同于系统或设备的重要性。

紧急度一般等同于事件的严重程度，对于业务系统或核心设备，宕机的紧急度大于性能下降的紧急度，性能下降的紧急度又大于单个非核心功能不可用的紧急度。

③谁负责关闭事件。

事件应由服务台和用户进行确认并关闭，也可以允许用户在自助服务系统中确认并关闭。

④转派规则的设计。

同组可以转派，跨组需要回退到服务台才可以转派，或者特定角色的人才可以跨组转派（如事件经理）。

⑤各个环节如何通知相关的角色和责任人。

一般是通知受理人即可，但重大事件要第一时间通知事件经理、部门经理等主管领导。

对于事件补单的情形，也要通知事件经理。

整个事件处理的环节中事件的分派、等待、解决和关闭环节要及时通知用户。

⑥事件是否可以过期自动关闭。

事件一般由服务台或者用户自助关闭，对于超过10天未关闭的，系统可以自动实现关闭，并且默认为已经解决。

但是对于重大事件，必须由服务台进行关闭。

⑦事件满意度的获得。

事件的满意度是ITIL中一个重要的考核指标，高满意度是IT部门的一个主要追求。

项目中实现了基于系统的自动发送满意度征询邮件，用户可以通过邮件或自助服务模块反馈满意度及意见，对于超期未反馈的，邮件再次提醒，三天之内仍然未反馈的由服务台进行回访。

但对于重大事件，事件解决后，服务台第一时间回访满意度。

⑧告警升级规则的涉及。

服务级别协议（SLA）是指对于供应方在需求方要求下应当完成的活动的清晰描述，一个SLA总是以某种详细程度描述何时、何处以及如何完成这些活动[4]。

由于单位的IT发展还比较弱，信息中心还没有与业务部门签署SLA协议，在这种情况下进行讨论，以一套“预期的”并向业务部门公布作为警告的SLA，并基于此进行升级和告警。

表1所示为基于解决时间的事件警告升级规则。

其中，首次升级时间指事件的解决时限，即事件从创建开始到当前时间或解决时间，在该时间尚未解决即要升级告警的时间；升级告警对象是升级告警时，从行政或者管理角度的升级告警，即向何种角色或领导升级、告警，以引起重视。

（2）自助服务管理自助服务管理即“员工自助服务管理”，主要包含在线申报事件、服务请求、查询工单、访问知识库、对工单解决进行评价、授权与委托等。

主要功能是：按服务目录提交服务请求、在线申报事件、查询用户的历史工单、访问知识库、对工单解决进行满意度评价。

有效地实施自助服务，增加了业务部门和IT部门的渠道沟通，依靠有效的知识库，简单问题还能由用户自助解决，不但提高了业务部门用户IT技能和知识，也减轻了信息中心的工作量。

（3）变更管理变更管理流程通过可控的方法及步骤来管理所有针对IT生产环境的变更，从而消除或最小化变更对IT服务质量的影响，同时提高日常的运维效率。

通过对所有变更的正确评估，可以维护IT 环境的完整性；变更和变更实施得到正确记录，并提供审计记录。

在变更流程的实施中重点关注两个问题：一是变更类型的定义及审批流程。

变更的核心是审批、授权，及其在变更流程中对变更风险的评估。

二是变更时如何与配置管理数据库（CMDB）衔接，发挥CMDB的价值。

要求所有的变更都要关联CMDB，这样既可以精细化定义变更流程，也可以经过长时间的数据记录，从CMDB的维度查看一个配置项曾经有过的变更请求，有利于提高运维效率，在出现事故时更快地查找原因。

另外，在变更完成后，要求在变更流程中强化CMDB的同步更新和维护。

（4）配置及资产管理配置管理的目标是定义IT服务和基础设施的部件，维护与IT 部件及利用这些部件提供IT服务有关的记录，并确保这些记录的可靠性；提供准确的信息和文档以支持其他服务的管理过程[5]。

配置管理控制的范围包括硬件、软件、流程、人员以及相关文档，并在CMDB中集中管理。

其逻辑模型图。

其中记录包含配置对象的详细配置信息、变更历史信息、生命周期信息、配置之间的关联关系信息以及与事件、问题、变更管理的关联关系信息。

CMDB的建设至关重要，主要有以下几点需要重点考虑：①CMDB配置模型的设计、管理的范围和颗粒度的选择。

管理的类别，比如主机、网络、存储、应用系统、数据库实例、中间件实例等；管理的层次属性，可以业务系统为视角加以考虑，哪些业务系统及其支撑业务系统的主机、存储、数据库、中间件要纳入CMDB管理的范畴，一般是先实施核心系统后实施外围系统；管理范围的关系，配置项的关联有很多种：连接、依赖、运行、安装部署、父子、主备、等同等，不同类型的配置项之间可能有一种或多种关系。

②要高度重视配置项数据的收集和梳理。

配置项数据的收集是一项费力费时的工作，但方法恰当，可以事半功倍。

建议除网络设备、机房设备（配线架、空调、UPS等）外，以应用系统为维度考虑：应用系统、主机、存储、数据库、中间件等类别的配置项，先应用系统后主机，然后数据库实例、中间件实例、应用实例，最后考虑网络设备、机房设备等。

③在收集完配置项属性和关系数据并规格化后导入CMDB，并建立基线。

④构建CMDB的目的和价值在于运用。

在事件、问题等工单的记录中要关联CMDB的配置项，在变更发起和变更计划时要关联CMDB，并基于CMDB评估变更风险和影响。

⑤为了保证CMDB的数据的完整性和准确性，在有效实施变更流程的同时，定期对CMDB做“盘点”，即定期审计，主要是看配置项的属性和关系是否与生产环境一致，如果不一致要查明原因，并审查流程和制度规范。

⑥要考核配置管理数据库如何应用，比如是否有必要和监控系统整合；与事件、问题、变更、发布等流程的关联关系；与资产管理的关系等。

既不要高估配置管理的短期价值，但也不要低估配置管理长期的价值。

（5）报表基于ITIL的核心KPI考虑，包括事件总数、事件关闭的数量、事件成功关闭的数量/比率、规定时间内解决的事件数量/百分比、超时未解决的事件数量、规定时间内响应的事件数量/百分比、平均解决时间、一次成功解决率、问题总数、已找到根本原因的问题数量、趋势分析问题所占比率、通过变通办法解决的问题数量、问题成功解决率等。

上线推广在完成工具实施后，要进行上线测试、试运行和推广。

在系统正式上线前，需要组织好相关人员参加培训，掌握流程、制度和工具。

由于项目不仅仅涉及到信息部门，自助服务还涉及到业务部门的培训和使用，所以项目中对信息部门先做培训，在应用推广等相对稳定和成熟后，再向业务部门推广自助服务模块。

持续改进根据戴明质量环所倡导的PDCA的管理思想，流程设计应该是一个持续优化和改进的过程。

业务在发展、技术在进步、成熟度在提升，运维流程也要不断优化和完善。

项目结束后，主要是由流程经理或流程负责人定期或不定期地组织会议、研讨、总结、修订、完善运维流程。

1.1.2.运维服务岗位及职责设置运维服务组织岗位设置如下：图 1 运维服务组织岗位结构图1.1.3.基于ITIL运维服务体系建设原则运维服务体系建设的原则有以下几个方面。