服务管理建设下的几个重要ITSS流程介绍
本帖最后由 monicazhang 于 2015-9-2 10:56 编辑20150902 淡然续上
5.4.1流程5.4.1.1事件管理 n建立规范统一的服务台，使服务台成为中心和用户部门间的唯一接口目前大多数运维中心都已经建立起了186服务热线，由于功能局限部分业务客户一般会通过186需求帮助，一些业务的处理存在绕开帮助台直接联系后台IT员工的现象。通常会带来以下问题： ITSS考试 1．受理职责不明确，经常找不到人；2．增加客户事件申报的难度，申报前自己需要对问题有初步分析；3．对信息中心人员来讲，客户通过找熟人的方式解决问题不仅影响他们的工作效率，而且造成部门内部工作的分配不均，影响服务质量和工作情绪；4．事件处理无法跟踪，因为没有人有跟踪事件的职责，事件处理的拖延在所难免；5．事件记录可能不完全记录或不记录，为今后的知识共享与统计分析带来困难；6．因为缺少与客户交互的统一界面，客户得到的反馈不及时，或得不到反馈。通过建立统一规范的服务台可以解决上述问题。首先，统一的受理服务台可以使用户在遇到问题或事件时很清楚该打什么电话；对于用户申报的问题，用户可以随时向服务台咨询问题的处理情况，同时，服务台也可以主动向用户通报问题处理情况；另外，事件可以被完整地记录，同时事件可以被跟踪和控制，IT人员不会被用户的电话干扰，同时，也避免很多不必要的压力。
n增强服务台功能，使服务台成为内外部信息沟通的纽带目前多数运维中心的服务台的功能集中于事件的接收与分派，少部分业务由服务台人员进行处理。根据IT服务管理流程总体建设的需要，今后服务台机构将成为内外部信息，尤其是客户信息集中维护的载体，将为事件管理，变更管理、服务级别管理等其它管理流程提供集中、统一的参考数据信息。同时，知识管理的建设与维护今后也将成为服务台工作的一个重点，服务台也将越来越多的承担事件监控和处理的职能，成为二线力量的集中储备资源。n制定清晰的事件逻辑类别（Category）和分类（Classification）；
解决的问题：针对事件没有准确的分类。通常我们建议在服务台的热线（一线）人员能够尽可能的划分清楚事件的类别并进行解决，但热线人员的技术能力毕竟有限，所以简单明了的事件分类不但可以加快判断事件的原因，还有利于将不能处理的问题正确转交二线。
目标和意义：可以根据中心工程师的职能划分或和业务特点将事件做清晰的逻辑分类，一方面，有助于将事件单更清晰地分派给相应的工程师或工作组；另一方面，在对事件的分类统计时也相对准确，有利于分析出相应的事件规律。n定义严格的事件影响程度、优先级并和所需要的解决时限关联起来；
解决的问题：目前一些运维组织对于事件的优先级划分有一类故障/二类故障等，实际上是事后报告和评估的标准，这三类的划分在实际工作中很不适用，很难在操作过程中界定；
目标和意义：根据影响程度和类别信息重新规划优先级，使工程师在对事件的优先判断时更灵活和准确。准确的优先级一方面可以有效地协调资源，也可以帮助工程师合理分配工作任务。同时，能够将一些事件及时地反应给相关相关管理层，由相关管理层督促和协调解决，将事件的影响降低到最小。举例说明具体信息：
表格 5‑1 事件分类和优先级示意
运维部门
事件分类优先级最后期限影响描述受理台询问问题
系统维护中心
网络普通16个小时对业务没有影响，咨询、IP更换等事件；主要和事件类别（Category）相关，当受理台选择的事件类型是：申述、咨询时，该事件的影响程度可以根据实际情况确定；1，判断该事件属于服务请求或咨询；2，该事件是否影响业务？
低8个小时属于局域网络问题，而且该故障只是影响个人用户使用； 1，确定是网络问题；2，该故障影响业务吗？3，是不是只是个人受影响？
中4个小时属于局域网络问题，而且该故障只是影响信息中心对系统和平台的操作，对业务系统不会造成影响等；1，确定是网络问题；2，该故障影响业务吗？3，该业务是属于内部业务吗？（不会影响前台业务，不会直接影响最终用户；）
高2个小时属于局域网络问题，而且该故障与业务相关的故障，或重要用户的故障，影响面较广；1，确定是网络问题；2，该故障影响业务吗？
最高1个小时属于广域网络问题，而且该故障引起全局业务无法使用；4，确定是网络问题；5，该故障影响业务吗？6，影响整体业务吗？
n制定和事件管理流程兼容的重大/紧急事件处理流程；解决的问题：在日常的IT服务管理中，有重大/紧急事件发生时，大家都要放掉手头事务投入到事件处理过程中，往往因为沟通不够，导致相关管理层很紧张，责任工程师压力太大。
目标和意义：需要建立一个能够和事件管理相兼容的紧急事件处理流程，当紧急事件发生时，能够按照流程有序、及时地通知各层相关相关管理层，由各层相关管理层循序地进行资源调配完成紧急事件的处理。n完善事件升级机制，包括管理升级和技术升级；解决的问题：相关管理层会被卷入到日常处理事务中，分散相关管理层精力的同时，也会给相关工程师带来工作上的压力；对于有些事件，申报的时候可能是一般级别，但是可能随着时间的推移事件就会变得紧急起来，另外，还有一些工程师的工作习惯，更愿意自己解决问题，而不顾及时间成本；或者是担心‘打搅相关管理层’，所以尽可能不及时将一些事件通告给相关管理层，而贻误了业务和事件处理的机会等。
目标和意义：
通过清晰的事件升级机制，最好能够固化在技术上，通过技术自动实现。可以使只有必要的事件升级到相关管理层层，相关管理层能够及时掌握不同级别的事件处理情况，能够及时协调时间和资源处理相对影响度大和紧急的事件。同时，使很多事件能够及时地升级给资深的专家处理，解决。
n制定严格的流程政策和流程执行控制机制；解决的问题：流程在实施的时候都会碰到一些障碍，如，工作习惯，工作态度，工作素质等。所有的流程都不可能设计得尽善尽美，所以，流程有时还会被一些员工‘上有政策，下有对策’给消化掉，达不到流程执行的目的。
目标和意义：通过制定严格的流程政策和流程执行控制机制，可以弥补流程设计中一些无法顾及的部分，另外，也可以为流程的推广和执行提供可以参照的行政手段和依据。
5.4.1.2变更管理 变更管理的目标就是确保IT基础架构中所有的变更都能用有效和快速标准的方法和步骤来管理，其目的就是减少或防止变更对业务产生影响或将事件数减少，希望能在变更需求与变更所可能造成的影响两者之间取得平衡，同时，配合配置管理模块保证CMDB数据的准确性。总的看来，建立变更管理的主要意义：1)IT服务和业务之间更好的整合；2)改善变更的风险评估；3)减少由于变更所造成的对IT服务和服务级别协议的负面影响；4)可以更好的评估计划中的变更所需要的费用；5)减少失败的变更次数；6)提高问题管理和可用性管理的效率；7)提高IT服务的质量；8)与配置管理形成接口，保证CMDB数据的准确性。根据国家电网公司各地运维部门当前在变更管理上的现状，需要通过流程的建立解决以下问题： ITSS认证
n 根据配置管理的范围，识别变更管理目前的变更操作虽然有制度规范，但由于没有变更管理，操作人员不能清晰的识别哪些应该属于变更管理范畴，制度通常不能被有效执行。通过配置管理的实施，操作人员就可以了解到哪些行为是影响到配置项变化的，属于变更范畴。
n对变更划分清晰的类别和分类变更的类别通常代表不同种类的变更,如：标准变更、实施类变更、紧急变更等，根据变更的类别，操作人员能够清晰的了解到，哪些变更应该遵循什么变更流程；而变更的分类通常是专业性的划分，如网络、主机、数据库等，通过分类操作人员可以找到相应的CAB进行风险评估和核准。变更的类别和分类在对变更的统计分析时也起着关键作用。
n 巩固变更评估和审批制度目前各运维中心对变更的操作过程中对变更的风险评估意识普遍较强，变更的风险和必要性通常通常能很好的识别，今后需要通过加强CAB审核的制度对一些关键变更进行系统评估，同时，对在变更中受影响的业务或个人进行提前通知或实施一些规避措施。n 加强变更的实施和回顾在变更执行前，变更管理员应该对变更做出《变更实施计划》，其中包括测试、上线、回退等计划，需要变更经理审核；变更执行后变更管理员应该准备《变更检查报告》（Change Review），作为下次CAB讨论的主题。通常CAB会议的议程会包括失败或测试不成功的变更请求、新的需要审核的变更请求、变更请求执行成功后的后续追踪。一个成功的变更请求如果经过追踪成效良好，最后变更主管就可以结案该变更请求的整个过程。
5.4.1.3配置管理 n 建立配置元素的相应属性、状态等，以利于提供信息并产生相应的管理报表；解决的问题：在IT服务管理过程中，很多行为都和IT设备管理密不可分，好的IT事件管理必须要有配置管理作为支撑；
目标和意义：IT事件管理，尤其是运维管理中，如果能够清楚地了解发生事件的IT设备的配置、该设备和其它相关设备的关系、该设备的历史发生事件等配置信息，那么对排障是非常有帮助的。同时，建立配置管理还可以为其它相关的管理流程提供可靠的数据支撑，在将来进行IT成本核算时，对设备配置信息的掌握也是必不可少的。n 建立配置管理的相关流程，如新元素登录，信息更新，审计等；解决的问题：配置管理的核心是配置数据库，即CMDB（Configuration Management DataBase），对该数据库中数据的维护是配置管理需要解决的主要问题。
目标和意义：如果建立的CMDB不进行维护，很快该数据库中的数据就会过时，变得不可用。所以我们必须建立配置管理的相关流程，并且定期由配置经理主导进行配置管理数库的审计和核查工作。n 加强配置管理的管控与授权配置管理数据库中只能由指定的经过培训的相关人员进行增删改的操作，并且在进行这些操作时必须有正式的授权，这些授权可以通过变更或事件管理发出的配置修改指令作为执行依据。
5.4.1.4问题管理 n 建立被动和主动式的问题管理解决的问题：突发事件不能在事件管理周期内得到根本解决，相同或类似的事件频发，降低IT服务质量。
目标和意义：问题管理流程最终完成找到问题发生的根本原因，也只有找到原因，才能根本解决问题，避免同样的问题一而再，再而三的发生。建议将问题管理分成两个部分建设，一个是建设被动问题管理的部分——等事件通报变成了问题，再来分析问题，找出问题发生原因，加以诊断，再提出解决方法及步骤。另一个是建设主动问题管理的部分，分析事件发生趋势，事前先找出可能的潜在问题，主动提出解决方法及步骤，预防问题将来发生。在问题的被动管理方面，建议包含两个层面上的管理，问题管理（Problem Control）和错误管理（Error Control）。当事件通报到问题管理流层后，进入问题控制阶段，在这个阶段，我们主要诊断并分析问题，当找出问题发生原因时，它就转变成已知错误（Known Error）。找出问题发生的原因后，就可以找出问题的解决方法和方案，必要时提出变更需求（Request For Change），通过变更流程实现问题的最终解决。在问题的主动管理建设方面，透过事件的趋势分析及定期检查事件统计报表，找出未来可能发生的问题。另外产品提供厂商的报告或建议，也会建议一些措施以防范未来可能发生的问题。通过这些主动方法，便可在事件发生之前就找出可能潜在的问题，主动提出解决方法和方案。
5.4.1.5发布管理 发布管理从全局的角度来管理IT服务变更，通过协同考虑技术或非技术的发布内容的所有环节，确保只有经过测试和正确授权的软硬件版本才能提供给ＩＴ运行环境。发布管理的核心在于通过标准化的流程和检查来保护生产环境及其IT服务，确保发布信息被成功公布。n 建立发布策略发布策略是一份用来阐述发布管理职责的文档。其中定义了发布管理的范围，以及发布管理中的基本概念和分类。发布策略用来指导发布管理生命周期的制定，针对每一个系统，发布经理都应当制定一项发布策略来定义一项发布怎样以及在何时得以配置。发布策略需要每年进行定期回顾，以及根据具体的变更进行不定期的回顾。n 强化发布计划过程在每个发布实施前需要制定完整的发布计划，发布计划包括在将要使用的发布策略与过程上的协调一致、确定参与发布管理个人员或单位的角色与责任以及计划资源的使用情况等。在计划阶段成立发布管理小组是至关重要的。发布管理小组的责任包括制定发布的方针，协调发布版本的内容，规划与监督发布版本的构建、功能测试、验收测试、回退计划以及发布的日程安排等，确保所有正式发布的配置项都可以在CMDB中得到。n 规范发布的设计、构建与配置过程除注意开发的程序外，安装说明文档和配置发布的说明文档也应当视为发布的一部分，另外对一项发布的软件和硬件组件应当审慎的进行配置和记录，以便可以重复利用这种配置，另外测试样本数据也应该被妥善的保存，以便日后的改动和重复利用。n 与客户进行测试和发布验收不满意的变更和发布最常见的原因是缺乏足够的测试。为了防止这一点，在实施前，发布应该由用户代表对其进行功能测试并由IT管理人员进行操作测试，在测试过程中，IT管理人员还需考虑技术操作、功能、运营、绩效以及与基础设施其它部分集成等方面问题。n 不要忽略沟通与培训与客户进行沟通并对员工进行培训，这对发布管理的成功是非常重要的。首次运行过程中产生的问题和变更都需要及时传达给各方。
5.4.1.6可用性管理 可用性管理流程是确保所有设计的 IT 服务均能以连贯且符合成本效益原则的途径实现业务所需的可用性水平。它通过优化IT基础架构、服务以及组织的能力，从而提供最有效的、最稳定的服务可用性，来最大化的支持业务的正常运行，实现业务的相关目标。n 可用性需求的确定必须基于业务的实际需求根据新规划的IT服务或已有IT服务功能改进的内部设计说明需求，或为签订新的SLA或变更原有SLA，从业务的角度分析对可用性的需求，分析服务支撑架构，识别服务的可服务性、可靠性、弹性和可维护性。必须确定和文档化这些可用性需求，所有的可用性需求都必须与客户共同决定n IT组件的设计、实施，必须考虑可用性需求当IT系统或业务发生变化时，可用性管理流程必须介入，对服务所需的关键组件及组件间关系进行分析，设计/确定服务可用性模型，审核当前可用性监控能力，对新服务设计提出监控需求，或对原有监控提出改进措施，文档化系统架构和监控需求。n 主动性的风险及差距分析评估新服务或由于SLA的变更对业务带来的风险，对现有IT系统环境的影响，评估现有系统架构的可用性能力是否能满足需求，确定IT部门可以达到的可用性水平，有针对性的提出适当的解决方案和成本估算，提出自建或购买的建议。n 可用性指标必须有相关服务保障合同的支持，并得到可用性验证可用性需求必须被满足，同时必须以服务合同的形式签署。环境改变之后，必须重新审查相关服务合同，因此应与供应商保持良好的合作关系。如具备合适可用性需求验证环境，针对提出的可用性建议方案进行验证，根据验证结果更新建议方案。n 需要制定一个可持续的改进计划，来保证服务的可用性定期或不定期的进行服务可用性回顾，对过去一段时间内的运行情况进行分析、评估，找出运行当中的薄弱环节，提出改进建议，制定可用性改进计划，返回给服务级别管理流程。
5.4.1.7 服务级别管理 服务级别管理的主要活动是在预定的标准服务参数基础上定义、协商、监测、报告和控制面向客户的服务级别。n“定义” 是指将IT客户的服务需求转化成可量化的标准服务级别，并整合进 服务级别协议 n“协商” 是指与IT客户共同磋商服务级别协议，直到IT服务提供者和IT客户共同达成一致 n“监测”是指收集服务性能数据、并与服务级别协议、运行级别协议、外部服务支持合同等进行比较的过程。如果服务级别协议（SLA）需要，该流程还可以为客户创建定制服务，定制的内容要求记载在服务级别需求（SLR）中。服务级别协议是连接科技信息部和业务部门的纽带
n 定义服务级别需求服务级别经理对事件管理转来的服务请求进行判断，如果在SLA内，将服务请求单拒绝并交回事件管理继续处理；如果不在SLA内，则接受客户需求；服务级别经理和客户关系经理根据客户的服务需求和服务级别目标(SLO) 收集信息，如果不在服务级别管理范围内或变更流程拒绝审批，拒绝该请求。n 草拟SLA、协商和确认OLA服务级别经理根据已有的模板起草SLA，服务级别经理审核这个服务的支持OLA，判断是否可以满足这个客户的需求, 服务级别经理和服务负责人共同识别当前服务哪些部分可以转化为监控需求。如果已有的OLA不满足客户的需求，则起草新的OLA。 如果已有的OLA满足客户的需求，则转去审核、协商、确认UC来保证对这个服务的支持。服务级别经理根据OLA模板和需要内容支持的内容起草新的OLA。进行OLA协商，如果OLA协商完成，OLA可以被确认，否则反复磋商，直到完成
n 谈判和确认UC如果已有的UC服务内容，或服务级别不能充分满足客户的需求，则开始与外部供应商进行新的UC协商。服务级别经理和供应商管理者一起和外部供应商协商新的UC。洽谈的内容一方面是找到可以提供客户需要的服务，其次是确认是否可以提供需要的服务级别，然后进行价格磋商。如果和外部供应商协商的条款需要SLA有所调整，则重新起草SLA。如果UC谈判完成， 则去确认UC。 UC定稿并被确认。同供应商约定等SLA签订时一起签署n 定稿和签署SLA服务级别经理审核SLA初稿，保证初稿的完整性和容易被客户理解，服务级别经理给客户讲解SLA初稿，争取获得客户认可。服务级别经理和客户协商SLA条款，任何需要的修改将落实到最终的SLA中定稿。 ITSS培训
n 监测、报告SLA达标情况服务负责人被授权负责监控服务级别，服务级别的监控参数应被配置到监控系统中。服务负责人周期性地生成服务级别报告。服务级别达标报告展示在哪些地方服务水平符合、超过、或没有达到SLA中承诺的级别。报告结构和指标基于预先定义的模板或SLA协商时的共识。外部服务提供商也将负责定期根据UC提供服务级别报告。服务级别经理审核报告分析IT相对于SLA中的承诺交付情况，如发现有违例情况，及时协调资源进行解决。
待续http://ITIL-foundation.cn/thread-52384-1-1.html本帖关键字：ITSS
页:
[1]