[it计算机]itil运维管理技术建议方案_非常不错的资料

[it计算机]itil运维管理技术建议方案_非常不错的资料内容摘要：

管理者：  IT 从规划到实施到运维更加有效，降低成本的同时获得更高的 IT 服务水平  确保 IT 流程支持业务流程，提高企业整体业务运营的质量  推进 IT 部门和业务部门的沟通，降低沟通成本  减少冗余和重复的工作，提高 IT 运维人员和业务人员的生产 效率 IT部门经理：  了解业界领先的 IT 服务管理模式，熟悉业界领先的 IT 管理最佳实践  通过自动化 IT 运维模式，使 IT 部门的管理更加有效、方便  使用知识库与 FAQ 等方法，全面记录规范化的解决方案，为 IT 部门快速解决问题提供坚实基础  通过明确的角色定义与职责划分，提高 IT 部门人员的生产效率、士气和工作满意度  加强个人的 IT 服务管理工作技能，成为 IT 界的 MBA，向管理型的 IT 人才发展 XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 10 IT部门的运维操作人员：  了解业界领先的 IT 服务管理模式，熟悉业界领先的 IT 管理最佳实践  通过知识库与 FAQ 等，加强个人 的工作技能，提高工作表现，获得更多的专业知识  通过自动化与可视化流程大大提高个人工作效率  加强个人的 IT 服务管理工作技能，成为 IT 界的 MBA 从而获得更好的发展机会 企业的 IT 资源用户：  使用 IT 资源时遇到的故障与问题将被快速解决  通过满意度评估等手段，切实推进 IT 服务水平，从而获得更佳的用户体验 关联同类故障处理方式，规范事故处理阶段 在 IT 资源越来越多的前提下，很可能存在多个 IT 资源同时出现故障的情况，近年来 XX客户 的 IT 部门也在不断的增加技术人员，原因就在于在以往的运维模式中是将 IT 部门的人员作为 解决问题的核心，事故的解决效果完全依赖于个人的能力和水平 ，因此，本阶段的建设重点在于，建立一种以事故处理经验为核心的事故分析模式，减少对个人能力的依赖，同时可以帮助技术人员快速的进行问题定位和问题分析。 故障点关联裙带的展现 影响运维效果的最重要一个原因还可能在于，当解决了一个故障后，引起了另外一个新的故障出现，这种被称之为拆东墙补西墙的故障处理方式是比较常见的，也就造成了 IT 部门人员在不断的解决问题的状况，所以，本阶段的建设重点就是，建立一种故障点关联裙带的展现机制，最大程度的帮助技术人员进行故障关联裙 带的分析，避免这种解决老问题带来新问题的现象。 度量运维效率，降低服务风险 作为运维整体的掌控上来讲，运维效率是一定需要保证的，而这就要求需要有一套保障 及时快速的响应用户请求的机制，比如可以通过设定硬件类的故障一线解决时间在 2 小时以内，同时对 VIP 用户提出的问题需要醒目的标示等等，因此，在本阶段的建设重点就是， 通过 SLM的设定来对运维效率进行约束，同时可以评审报告的形式对周期内的运维效率进行有效的统计XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 11 和计算，用来辅助管理决策。 拓展 IT 服务途径 以往 XX 客户 接受用户请求的方式只是通过电话，这种方式用户已 经很习惯，但经过统计之后会发现， IT 技术人员每天的工作量有至少 30%会放在帮助用户解决一些 简单问题上，比如打印机不能打印之类，如果可以有一个用户自助式的服务台，可以把这些简单问题的处理方式直接呈现给用户， 用户自己根据这样的方式解决的话，对 IT 部门来说，也就意味着，对用户的服务渠道又多了一个，而内部技术人员的工作量也会相应减少，因此，本阶段的建设重点在于，通过拓展 IT 服务途径的方式，来同步降低 IT 部门的工作量，实现一箭双雕的效果。 建立分类统计报告机制 对运维情况的了解， 比如如何可以得到 IT 部门一段时间内支 持了多少个用户的请求，其中多少是硬件类的，多少是简易问题等等， 都需要反映的报表或对应的 KPI 中，提供给 IT 部门决策者，因此，在本阶段的建设重点在于，完善且全面的报表和 KPI 建设。 XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 12 4 XX 客户 ITIL 运维系统 实施建议方案详述 借以 ITIL 的运维阶段概述 摩卡软件将 ITIL 先进的设计理念加以十年运维管理经验，形成一套完整的切实可行的 ITIL实施依据，在摩卡 ITOM 中将整个的 ITIL 分为四大实施阶段，各个阶段的特点如下：  计划 阶段 阶段描述 阶段负责人 计划（ Plan ） IT 高层管理者或 IT 部门经理 根据业务部门的需求制定相应的 IT 服务策略与目标，在评估实现这些目标所需的服务水平与成本等因素后，产生详细的实施计划。 IT 高层管理者 IT 部门经理  实施 阶段 阶段描述 阶段负责人 实施（ Do ） IT 服务经理执行计划（ Plan）阶段产生的实施计划，对流程、表单、报表、 KPI 等做出修正，使之更加符合实际业务的需要，同时收集相关运行数据以度量它的绩效。 IT 服务经理  检查 阶段 阶段描述 阶段负责人 检查（ Check ） 在成功实施了新的计划后， IT 服务经理检查实施的效果，发现 IT 运维中出现的新的问题与瓶颈，并通过分析相关运行数据找到问题与瓶颈的根本原因，并汇报给 IT 高层管理者。 IT 服务经理  改进 阶段 阶段描述 阶段负责人 改进（ Improve ） IT 高层管理者或 IT 部门经理根据检查（ Check）阶段的检查结果决定需要采取的进一步行动，例IT 高层管理者 IT 部门经理 XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 13 如，修正流程缺陷、进一步标准化流程等，以提高 IT 运维管理的效率。 强化运维管理流程关键点详述 将整个运维流程分为事故管理、问题管理、变更管理、发布管理四大阶段，可实现事故或问题或故障在不 同流程阶段中的切换，方便进行跟踪管理。 服务台 amp。 事故管理 事故管理的目的是记录、解决及跟踪 IT 服务运作过程中发生的事故，并使用户可以尽快恢复自己的正常工作，避免业务中断，将事故对业务运营的影响降至最低。 服务台即连接用户与IT 部门以处理上述事故的连接点。 于是，服务台与事故管理相结合就构成了从事故发生到得到解决的首要流程，同时，服务台记录下事故以及事故解决方案的有效信息，以备其他流程（例如问题管理）参考。 XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 14 输入和输出 服务台 amp。 事故管理的输入主要有以下三个方面： 监控系统自动发现的请求； 用户热线电话反馈的请求； 用户通过自动服务台反馈的请求。 XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 15 服务台 amp。 事故管理的输出主要有以下： 请求的应急措施或最终解决方案。 受理请求 请求按照三类不同的来源流入请求池中，进入请求的“未受理”状态。 请求池中的请求会按照设置的请求分发策略分派请求：  自动分发：请求池中的请求按照已定义好的资源类型对应关系自动分派给相应的一线支持人员；服务台值班长也可以手动分派一些未自动分派出去的请求；  手动分派：由服务台值班长分派给相应的一线支持人员，进入请求的“已受理”状态；  主动获取：一线支持 人员主动获取能够处理的请求，服务台值班长也可以手动分派一些未自动分派出去的请求； 处理请求 一线支持人员直接关闭请求，处理结果为：①彻底解决请求；②确定无法解决，直接关闭；③错误的请求时，将请求转为“已关闭”状态。 一线支持人员由于工作量超负荷时可升级给服务台值班长，申请重新分派请求给其他的一线支持人员。 一线支持人员升级至对应的二线支持人员处理请求。 二线支持人员处理路径有三种：  提供处理意见，置请求状态为“待验证”，提交一线支持人员进行请求处理方案验证，验证通过，一线人员 提供最终解决方案并置“已关闭”状态。  可以提供应急措施，但不能彻底解决请求，需要申请变更流程或转入问题流程以解决请求，同时发出邮件通知请求提出人，请求进入“转入问题”或“变更中”状态。  无法解决请求，需升级三线支持人员处理请求。 三线支持人员处理请求路径与二线支持人员大致相同。 有如下三种处理路径：  提供处理意见，置请求状态为“待验证”，提交一线支持人员进行请求处理方案验证，验证通过，一线支持人员提供最终解决方案置“已关闭”状态。  可以提供应急措施，但不能彻底解决请求，申请变更流程或问题流程以解决请求 ，同时发出邮件通知请求提出人，请求进入“转入问题”或“变更中”状态。  根据服务台实际 N 线流程，无法解决请求，需升级 N 线支持人员处理请求。 XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 16 问题 管理 问题管理是负责解决 IT 服务管理中遇到的所有潜在的和已经发生的问题的流程，目的是找到这些问题的根本原因，并提供临时措施与根本解决方案，防止问题再次发生或减少问题的数量。 问题管理调查基础设施和所有可用信息，例如监控系统事件记录等，以确定引起事件发生的真正的潜在原因以及提供的服务中可能存在的问题。 在定位问题的根本原因后，产生相应的应急措施以及最终解决方案。 对于那些由于成本、技术等原因，暂时不予消除的问题，可以置为已知错误，留待日后解决。 输入和输出 问题管理的输入主要有以下两个方面： 由服务台 amp。 事故管理转入的问题； 问题管理员主动发现并新起草的问题； 问题管理的输出 ： 已知错误； XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 17 问题的应急措施或最终解决方案； 处理问题 对于不同来 源的问题，处理问题权限如下：  对于由服务台 amp。 事故转入的问题，则任意问题管理员均可抢先处理。  对于问题管理员自己起草的问题，只有起草人有权限处理问题。 关闭问题 如果问题不需要解决，问题管理员可以直接处理，则可以点击“关闭”按钮直接结束文档的处理，问题进入“已关闭”状态。 申请变更 如果需要申请变更以消除问题，问题管理员可以点击“提交”按钮申请变更，问题进入“变更中”状态。 已知错误 如果暂时还没有找到问题的最终解决方案或由于成本、技术等原因暂时不解决当前问题，则问题管理员提供一个可接受的应急措施后， 将问题转为已知错误。 一旦找到了最终解决方案或成本、技术已允许解决该问题，就可以通过对已知错误继续处理来消除这些已知错误。 点击“提交”按钮，选择“已知错误”路径，问题进入“已知错误”状态。 若要消除已知错误，在页面“已知错误”模块找到当前错误，并重新启动流程。 重复问题 如果问题是一个重复问题，问题管理员可以直接在表单中输入重复问题编号，再点击“提交”按钮选择“重复问题”路径，问题进入“已关闭”状态。 确认变更结果 如果问题触发了变更，当变更处理后，会给问题管理员一个反馈，问题管理员可以对变更后的效果进行审 核，如果问题已解决，则可以点击“关闭”按钮直接结束文档的处理，问题进入“已关闭”状态。 如果问题没解决，则问题管理员可以点击“关闭”按钮直接结束文档的处XX客户 ITIL运维系统 技术建议方案 客户 质量 团结 创新 . 18 理，也可以点击“提交”按钮，再一次申请变更。 变更 管理 业务需要通过变更改善自己的服务，但是，经验显示影响业务的 IT 事件往往与变更有关。 造成这些事件的原因很多：可能是由于一时疏忽，资源匮乏，准备不充分，较差的影响度分析，测试不够或者一些暂时的问题。 如果与变更有关的事件无法控制， IT 服务提。