一步一步实施itop（手册）-服务台的使用

 3.1一线服务台人员操作指南

一线人员应该是使用itop平台最频繁的人，使用的次数和时间都是最长的。工作台大概就是这样的。

左边主菜单，右边是主要数据展示。
我们常用的有这样一些菜单（如图标记）：

• 新建一个工单（当用户的请求不是自助通过Portal来的时候,比如电话、邮件）的菜单
• 查看分配给自己的工单，或者分配给自己团队的工单
• 自己处理过的工单
  其他的相对来说使用会少一点。

右边的区域主要是数据展示，经常操作的应该是最近工单状态，不必做过多解释，点击对应的数字就可以查看到想关列表,关于列表的操作请查看基本操作章节。

我理解的一线的主要操作包括，工单创建、分派，指配、关闭、调查评价，跟踪工单状态。
而关于工单的CI关联，处理具体问题，其他操作，基本属于二线、三线的工作，但是很多公司一线会充当部分三线的工作。这里暂时不提。

所以接下来我会先说一线，然后说二三线的工作。

3.2创建工单

工单的创建有几种场景

1. 用户从服务台自助创建（这种情况无需服务台干预）
2. 用户通过其他方式（电话、邮件等）提起需求或者报告事件
3. 由于其他工单派生的子单

3.2.1 创建工单入口

我们现在说后两种，前面已经说了，工单其实分为两种，一种是UserRequest服务请求，另一种是Incident事件报告。严格的说我们要分别对待，但是在有些公司，并没有严格区分

这里我讲会同时覆盖两种情况

• 如果是服务请求，那么到helpdesk下面创建
  
• 如果是事件，就到incident Managment下面创建
  

3.2.2新建工单页面介绍

创建工单的界面和安装的插件有一定关系，如果你安装了dispatch插件，那么应该类似这样样子

 填写完成相关信息后可以直接Dispatch到一个团队，或者直接Assign给具体的人员。

如果你选择的服务启用了approval，那么标题会多出wait for approval

• 创建一个incident的界面几乎一样，就不重复介绍，现在说一下 new UserRequest的一些项说明
• organization：是指这caller所在的主要组织，这个要和服务发布对应，不一定是最小的组织，通常来说会是比较上层的一直组织，看公司业务分布情况和服务经理的设计。
• caller：此处可以直接搜索，或者点击后面的搜索框开始搜索，正式环境基本不会有新建联系人的可能，所以请不要自己新建，配置管理员会把人员都设置好的，搜索小技巧，一个字一个字的输入，如果当前结果小于5就会出现在备选框了
• impact & urgency：这个一定要选择合理，这个影响SLA以及以后做数据分析，影响的范围和紧急度是很重要的一个判断。
• relations：关系部分是指当前工单是由某一个工单所派生（引起）的，这个也是重要的数据分析一句

进阶： 上面的tab有两项值得关注，attachment、contacts；附件和想要关注的人，这个在创建的时候就可能会录入，当然这些也可能在后续l2、l3处理的时候添加。CIs基本也是后续处理分析问题的时候添加，当然了，incident可能会在第一阶段就添加。

3.2.3 log的记录

在这个界面，会有两个log，一个叫做 Private log ，一个 public log一般来说，创建阶段填写private log 的几率会大一点，主要记录什么呢？ 前期沟通调查、对工单的理解，方便后续自己、同事查看处理等，这个log前端portal用户是看不到的，只有后台agent查看。
public log 后面说，主要是用于交互的。

3.3工单的指派

其实这里我们要说的指派是广义的，翻译成中文还真不好说指配和分派，原文是Assign和Dispatch，意思是指定给某一个具体的agent进行跟踪处理和分派到某个团队进行负责。两个动作都是可以重复执行的，就是常说的转交单
在说明工单指派的具体操作之前有必要说明一下工单的基本流程

3.3.1 工单的基本流程

这是一张工单生命周期的图，可能有点小，但是没关系，解释一下基本流程
创建后状态new，不管是前台创建还是后台创建，当然了后台创建可以同时走下一个步骤。
下一个步骤如果有审批就走审批，没有就是分派或者指配，这里要注意，工单创建后就开始计算TTO，直到超时或者Assigned，如果出现工单需要变更给到另外的agent或者team在这个状态都是可以操作的
一旦Assigned，就意味着需要处理，此时开始计算TTR，这个状态到下一个状态可能是重新指派、解决、超时关闭，期间可能出发TTR动作。解释以下两个指标

• TTO: Time To Own，从新建立到指派到具体的angent的时间，可能是手工指派也可能是自动升级派单，重新派单不重置时间
• TTR: Tiem To Resolved，从第一次指派Assigned开始，到解决问题resolved的时间，重新分派不重置时间，pending暂停。

3.3.2 工单的常用操作

在工单的处理中，每个状态看到的可能不一样，但是常用的Action有这么几种

• Assign：很容易理解，很简单，我们在OtherActions或者新建的时候标题按钮下面就会有，不用解释就是指派给某人处理。
  
• Dispatch to a team：也很简单，给到某个后端团队，通常是L2/L3的人，经过分析后，确定这个工单要该团队来处理，就dispatch给他们。
  对于已经Assigned的工单可能会有这样一些操作
  

  请注意：任何地方的Actions都和权限有关、状态有关

• Pending：表示工单由于一些原因暂时不能处理或者无需现在处理，需要等待时机，那么可以有理由的进行暂停
• Mark as resolved：表示工单已经处理完毕，发起人认可后可以关闭
• Re-assign：需要转交给其他人进行处理
• Close：一个工单完成以后，须用户确认并关闭，这才算一个完结，一般来说，关闭后需要用户做一个评价，本次服务评分会对服务台的考核做参考依据。

3.4.1事件管理

有的人会把helpdesk和事件管理分开，但实际运作过程中，他们是一体的，UserRequest和incident密不可分。前面已经提到了，不过事件和请求还是有一定区别的，先看下生命周期

事件一般都是需要直接处理的，服务台确认事件后会尽快分配到处理人进行处理。

• 事件对紧急度更为关注
• 事件可以升级为问题（不能马上解决）
• 事件的关联性极高，一个事件可能会引发多个事件
• 事件对CI的关注度比较高，注重影响范围

事件的创建和流转都和服务器请求一样，所以其他的就不用说了。
附事件管理流程图：

3.4.2 服务管理

服务管理是服务台最重要的部分，服务的配置决定了服务台是否可以正常运作，服务分类是否合理，是否覆盖业务需要。所以服务管理这块的工作基本是交有服务经理或者专职主管团队来负责配置的，相对来说也比较复杂，对IT服务要有一定的认识，对ITIL等有所了解。不过就算你不知道也没太大关系，只想用这个软件的话，我来告诉你。

3.4.3 服务的分类和设计

这里要了解一个概念，在itop里面有三层架构

1. 第一层，Service family 服务族：这是最大的分类，一般来说表示一个方向性的，或者一种服务合同范围，比如：桌面服务、销售渠道服务
2. 第二层，Service，服务：这个是代表一套服务，比如：企业邮箱服务、crm系统售后服务，可以直接明确的让人看懂这个服务是做什么，或者负责什么范围
3. 第三层， Service subcategorie：这个是什么呢，这其实才是我们传统说的具体服务项，指一个具体的可操作项目，比如，开通企业邮箱、crm帐号被锁问题，这个必须是唯一有针对性的，用户选择到这个服务项后会很肯定的知道自己就是要做这件事情。

我上面说的分类方式不一定适合所有环境，在设计这个服务三层架构的时候一定要想好，我们现在提供什么服务，以后还可能提供什么服务，会不会冲突或者无法分辨。而且你要考虑到合同，因为合同是和服务签订的，不是服务项，也不是服务族，换句话说，服务是人群针对性的，虽然可以签两份合同给到两个人群，但请你想清楚怎么样才是最合理的。
 比如我这里的分类，其实并不太好，服务族分类软件和服务请求，其实软件里面部分也属于服务，用户直接看到的肯定是服务，对服务族没体现到价值。

3.4.4 合同和交互模式

这里默认指用户合同customer contract，对于供应商合同我们用得不是很多，交互模式其实一种关系设定，这个在前面服务台原理的时候简单介绍过，这里再稍微详细一点说明一下。

首先是合同：创建一个customer contract 有几个重要的属性需要说明

• Customer：当前创建的合同是针对谁的，向谁提供服务的，这是一个organization对象，只有在这个组织下的人员才能享受这个合同包含的服务。
• Service：服务，每个合同必须包含有最少一个服务，注意，是服务Service不是服务项，也不是服务族
• Provider：提供方，也是organization，表示提供本合同涉及的所有服务的组织 别小看了这个，如果不正确设置，到时候服务团队可能无法设置，通常来说这是一个部门，比如IT部门。

有了这三大件，就不影响功能使用了，还有一个不影响使用但很重要的东西SLA,针对每一个服务，都需要一个SLA对应。这也是ITIL最基本的要求，关于SLA的计算后面单独说

接下来是交互模式，其实交互模式非常简单，就两个重要列表

• contacts 联系人：这里的联系人其实是指负责人，也就是交互模式对应到合同后的处理问题的人，在itop里面很多地方联系人都可以理解为当前实体的负责人。当然了，针对交互模式这里通常是负责处理问题的服务团队，一线、二线、三线工程师，你可以给他们定义角色
• customers 客户，顾名思义，这里是指向谁提供服务，具体是我们的用户，很容易理解。

有了这两个其属性，交互模式也就明白了,我们的合同和交互模式配置好，基本就可以发布服务出去了。

3.5.1 SLA是什么

service level agreement 服务级别协议在itop里面是由若干个SLT组成的，用于定义服务提供者和客户之间针对具体服务的处理时间的定义。

那么SLT就是什么呢？

service level target指定义一个服务的响应时间目标，在itop里面有两个衡量标准
TTO,TTR,这个在第三节 工单的指派和处理 3.3.1之中有解释过
SLT需要定义类型（服务请求、事件）、度量单位，数值，优先级
所以，一个SLA通常有多个SLT组成，这个要看服务的设置量
如果看不懂怎么设置的可以参考 官方wiki的详细说明怎么创建

### 3.5.2 SLA的计算体系
这个其实有点深了，不过，作为服务管理人员还是有必要了解的。

这里用到了一个插件：SLA with Coverage Windows
这个插件可以定义工作时间、计算当前工单状态，配合cron触发tto/ttr的状态，我们从数据模型里面就可以看出这两个时间都有几个状态：
Columns: ttr_timespent: INT(11) UNSIGNED, ttr_started: DATETIME, ttr_laststart: DATETIME, ttr_stopped: DATETIME, ttr_75_deadline: DATETIME, ttr_75_passed: TINYINT(1) UNSIGNED, ttr_75_triggered: TINYINT(1), ttr_75_overrun: INT(11) UNSIGNED, ttr_100_deadline: DATETIME, ttr_100_passed: TINYINT(1) UNSIGNED, ttr_100_triggered: TINYINT(1), ttr_100_overrun: INT(11) UNSIGNED, Default: "0", Null Allowed

开始、结束、75%状态、100%状态，对于警告和过期状态，所以我们通常可以在UserRequest列表看到有标红的颜色
当一个单创建的时候就会进入tto计时，
根据定义的优先级、重要程度，选取不同的SLT 进行计算,当每次执行cron的时候，计算达到了对应标识的值就对工单进行标志更新操作，直到超时升级或者进入Assigned状态
当一个工单一旦 Assigned就会立即进入ttr计时，
和tto一样会根据优先级和重要程度读取SLT配置进行计算，直到发生resolved或者pendding或者超时关闭。

注意：redispatch不影响计时。

要很好的理解SLA其实需要对ITIL有所了解，知道IT服务是什么，在这里就不做过多阐述了。
到这里，服务台的几本使用和配置应该差不多了。