实施方法

iTop 实施指南

该文档的目的是描述,如何一步一步地,为你的组织创建必要的iTop对象以实施iTop。例如,为了去创建用户请求单,你需要确保存在请求的发起人,并且至少有一个为客户定义的合同,合同定义了交付给客户的服务,等等。这个文档解释了在iTop中创建对象应该遵守的顺序。

为了创建一个干净的生产环境,最好从一个没有安装示例数据的实例开始。然而你也可以安装另外一个示例数据的实例去快速查看需要的基础数据,去创建一个完整的功能实例。

下面的图解概述了实施流程:

iTop on-boarding cheat sheet

本文没有关于如何使用iTop特性的细节描述。关于想更多地了解iTop使用详情,请参考“iTop用户手册”。

在iTop中创建新对象

在iTop中创建一个对象有多种方法,根据对象类型及是否想交互式创建,一个一个或者批量模式。通过菜单创建每个对象的步骤在数据模型文档中可以看到详细的解释,但是有两种其他的方法更方便系统管理员:

  • 通过CSV导入:如果想创建同类对象的许多实例,通常从一个存在的数据集中导入更容易些。CSV导入工具,在“数据管理”菜单下,是专门为此设计的。准备好CSV格式的数据:作为一个文本文件,每行一个对象并且值通过特定字符分割开(分号,逗号或制表位)。然后让CSV的导入向导指引你导入文件到iTop。

  • 通过通用搜索:创建一个任意类的新对象,使用在“管理工具”选项卡中的“全局搜索”菜单。执行一个类对象的查询,然后使用“操作/新建...”下拉菜单去创建一个类的新实例。

配置管理

Configuration Management on-boarding

创建组织

当计划做一个iTop部署时,首先要确定组织结构。在iTop中,组织通常有两个主要目的:一是描述客户和供应商实体,二是从安全的角度对数据隔离。几乎所有加载到iTop的对象都和组织有关系,因此在加载其他对象到iTop之前,创建一个适合的组织结构是很重要的。

理解客户和供应商

在iTop中,没有诸如“客户”或“供应商”,他们都仅仅是组织。就像在现实的生活中,一个组织是客户或供应商取决于观察的视角。例如组织“公司A”是“公司B”的一个客户,同时也是“公司C”的供应商。在iTop中客户/供应商关系是通过合同所体现的。如果有一份“公司B”作为供应商且“公司A”作为客户的客户合同的话,“公司A”就是“公司B”的一个客户。

客户合同和供应商合同之间的不同是什么?

供应商合同是客户合同的轻量级简化版本,有两个限制:

  • 供应商合同不和服务目录中的任何服务关联。服务目录中的任何服务同供应商合同是不相关的。

  • 在供应商合同中服务级别协议是作为自由文本域定义的,那么,因此在iTop中不会被自动计算。

供应商合同对于和第三方供应商(在ITIL术语中成为支撑合同)签订合同是有必要的,iTop中这类情况下不能跟踪工单。

你也可以使用客户合同去描述和第三方供应商的合同关系,但是这意味着你必须同时在iTop中定义供应商的服务目录。

组织和访问权限

在iTop中区分客户/供应商关系,创建一些组织的其他原因是对管理的数据区域做访问限制。

在iTop从数据库中“读”(或显示)权限是以组织为基础定义的。每个用户(在定义他/她的账号时)给定了对一些组织的集合的访问权限。

组织可以分层结构。这种情况下,访问权限从“父”组织被继承到“子”组织。例如,如果“公司A”有两个子组织:“公司A1”和“公司A2”,那么如果一个用户有访问“公司A”对象的权限,她/他将也允许访问“公司A1”和“公司A2”。另外一方面,一个仅允许访问“公司A1”的用户既不能访问“公司A”也不能访问“公司A2”的对象。

“写”(也就是创建,修改或者删除)对象的权限仅通过指定给账户的角色定义。例如角色“Support Agent”有创建或修改用户请求单(但并不能删除它们)的权限。

这意味着一个用户对所有允许访问的组织有相同的权限。

例如,在当前的iTop版本中,一个用户账户不能同时可以访问组织“公司A”和“公司B”,并且仅可以在“公司B”创建服务器。如果她/他被授予创建服务器的权限,将同时适用于“公司A”及“公司B”。

创建位置

位置对通过地理分组对象非常有用。当你在CMDB中创建一个配置项的时候,即使位置属性并不是一个必填项目,也是强烈推荐预先创建位置,并去追踪所有配置项的位置的。

需要仔细计划位置的创建。位置是难以辨认的(对于位置通常不接受唯一识别符),如果你的公司先前没有位置,为了避免在配置管理数据库中重复的位置,你可能想去定一个地点的命名规范

共享位置(Shared Locations)

在企业环境中,即使角色和职责的分离,有利于创建子组织,但是在一些定义为“协作位置”的组织中,尝尝需要去“共享”位置。在标准版本中iTop在组织间并不支持事实上“共享”对象的方法。然而,位置是可以从父组织以同样方式的访问权限“被继承”到子组织的。这意味着,属于“公司A2”的人,服务,网络设备可以被定位到属于“公司A”的位置。

创建人员

在iTop中,人员是作为定义所有的联系人和他们的职责是非常重要的。一个人员属于且仅属于一个组织。一个人是一个团队或多个团队的成员,所以应该在建立团队前创建。

同样,每一个用户记录被链接到一个人员对象。因此人员必须在导入用户账户至iTop前被创建。用户记录定义了访问权限(和识别方法),然而人员对象定义了关于联系人的信息:姓名,位置,邮箱地址,电话...

创建团队

团队被链接到一些类型的对象,像合同或工单,是为了定义职责。团队被用作分配工单的“工作组”。团队被用作分配工单必须保证至少有一个成员(指定工单分配的代理)。在团队和人员中链接的 “角色”属性不是强制的,所以你可以让它空着,但是在定义团队中人员的角色上是非常有用的(团队领导,管理者...)。

设备和软件配置项

一旦定义了组织结构,位置和联系人(团队和人员)被加载,你就能够开始填充配置管理数据库了。

因为软件实例依赖于定义在软件目录中的软件类型,并且作为安装在一个特定主机而被记录,你应该通过记录一下内容开始:

  • 物理基础设施:服务器,网络设备,个人电脑等

  • 软件目录,通过创建需要的“软件”对象类型

服务管理

在iTop中管理工单之前,必须定义服务目录交付模式还有合同

Service Management on-boarding

服务目录

“服务目录”是一个来自指定供应商组织的可用的服务列表。通过创建服务对象在iTop中记录服务目录,分配给给定的组织(被作为服务供应商)。服务被组织为两层,通过两个类对象:服务子服务。在加载子服务前创建顶级的服务。

第三层的操作“服务簇”将服务分组在一起,并且对于增强型门户是必须的。

一旦定义了服务目录(服务或子服务),就可以创建一份将每个“客户”组织链接到他的提供商的客户合同,这就需要为每一对提供商/客户间创建一份客户合同,并且将适当的服务链接到合同中。

交付模式

交付模式是作为为客户工作团队而定义的对象。你能用一个交付模式对象去把为一组给定服务的“支持团队”分组到一起,或者支持团队指定给一个特定的客户。每一个客户组织必须指定且唯一指定一个交付模式。

在标准的iTop2.0数据模型中,团队和服务间没有联系。当指派一个工单到团队唯一的限制是:团队必须属于分配的那个工单所在的客户组织的选择的交付模式。

例如,如果你有以下的团队:

  • 桌面支持团队:一个处理所有桌面支持请求/呼叫的团队
  • 微软办公支持团队:一个处理所有关于微软办公软件的支持请求的团队
  • 硬件支持团队:一个处理硬件呼叫(更换,新的新建订单)的团队
  • 网络支持团队:处理网络相关问题的团队
  • 客户B桌面支持团队:一个为客户B服务的桌面支持
  • 客户B硬件团队:一个为客户B处理硬件呼叫的团队

你可以建立两个不同的交付模式:

  • “交付模式1”包括:

    • 桌面支持团队
    • 微软办公支持团队
    • 网络支持团队
  • “交付模式2”包括:

    • 客户B桌面支持团队
    • 客户B硬件团队
    • 微软办公软件团队

“交付模式1”将被组织“客户A”、“客户A1”、“客户A2”及“客户C”使用;同时,“交付模式2”被“客户B”使用。

服务级别协议和目标

在iTop中,管理工单的服务级别协议(SLAs) 和服务级别目标(SLTs) 的定义不是强制的,但是没有他们iTop既不能计算处理工单的截止日期,也不能自动升级工单。

为了计算期望的服务级别协议是否被遵守,iTop引入了两种可能的度量类型,被称作SLTs(服务级别目标):

  • TTO (指派时间):工单创建到工单分配到代理的时间

  • TTR (解决事件):工单创建到解决(即当工单转换为“解决”状态的测量)的时间

SLT 定义的时间段有关于:

  • 一个度量:TTO or TTR

  • 工单类型(事件或用户请求)

  • 优先级 (因为高优先级的工单通常应该被更快地处理)

一个SLA是被作为一组SLTs(例如在“金牌”和“银牌”服务级别的区别)简单定义的。

在iTop中,SLAs/SLTs的定义有两个作用:

  • 通知触发条件可以定义为其中一个度量“临界值”的任意百分比(例如当达到解决时间的50%时,一个配置通知发送一个邮件给处理一个工单的代表,并且达到75%时通知团队领导)。

  • 当完全达到度量的时间,工单自动发送到一个特定的“升级”状态(在工单的生命周期中有两个特殊的状态定义:升级TTO和升级TTR)。转换到这种状态通常会触发一个特定的通知。

例如,以下的服务级别矩阵定义:

事件优先级 高事件优先级 中请求优先级 高请求优先级 中
分配时间:5分钟分配时间:30分钟分配时间:30分钟分配时间:4小时
解决时间:1小时解决时间:4小时解决时间:4小时解决时间:不限制

这个将创建4个SLTs,表格中每一列是一个。这4个SLTs能够被聚合在一个叫做“金牌服务级别”的SLA下。

最终SLAs能够被联系到一个客户合同中,定义了合同适配的度量。

你的iTop实例现在已经准备去运行了,你可以查看配置通知去设置工单的邮件通知。

原贴链接:https://www.itophub.io/wiki/page?id=2_7_0%3Aimplementation%3Astart


iTop implementation guide

The purpose of this document is to describe, step by step, which iTop objects have to be created to implement iTop for your organization. For instance, in order to create a User Request ticket, you need to make sure that the caller for this request exists, that there is at least one contract documented for this customer defining the services delivered to this customer, etc. This document explains the order to be followed for creating the objects in iTop.

For creating a clean production environment it is better to start from an iTop instance installed without the sample data. However you can also install another instance of iTop with the sample data to have a quick look at the basic data needed to produce a fully functional instance.

The following schema summarizes the on-boarding process:

iTop on-boarding cheat sheet

This document does not describe in details how to use all the features of iTop. For more details about the usage of iTop, refer to the “iTop User Manual”.

Creating new objects in iTop

There are several ways to create new objects in iTop, depending on the type of object and whether you want to create the objects interactively, one by one, or in bulk mode. The steps to create each class of object from the menu is explained in details in the Data Model Documentation, but there are two other ways that can be convenient for an administrator:

  • From CSV Import: if you wish to create many instances of the same class of objects, it is often easier to import them from an existing data set. The CSV Import tool, under the “Data Administration” menu, is designed for this. Prepare your data in CSV format: as a text file, with one object per line and values separated by a fixed character (semicolon, comma or tab). Then let the CSV import wizard guide you into loading the file into iTop.

  • From the Universal Search: to create a new object of any class, use the menu “Universal Search” in the “Admin Tools” section. Perform a search for objects of this class, then use the “Actions / New…” popup menu to create a new instance of the class.

Configuration Management

Configuration Management on-boarding

Creating organizations

When planning a deployment of iTop, the first decision to be made is about the structure of Organizations. In iTop, Organizations are used for two main purposes: the description of customers and providers entities and the partitioning of the data, from the security point of view. Almost all the objects loaded in iTop have a relation with an Organization, therefore it is important to create a proper structure of Organizations before loading other objects into iTop.

Understanding customers and providers

In iTop, there is nothing such as a “customer” or a “provider”, there are only Organizations. Like in real life, whether an Organization is a customer or provider depends on the point of view. For example the Organization “Company A” can be a customer of “Company B” and at the same time a provider for “Company C”. The customer/provider relations in iTop are represented using Contracts. “Company A” is a customer of “Company B” if there is a Customer Contract with “Company B” as the provider and “Company A” as the customer.

What is the difference between Customer Contracts and Provider Contracts?

A Provider Contract is a slightly simplified version of the Customer Contract, with two limitations:

  • A Provider Contract is not related to any Service from the service catalog.

  • The Service Level Agreement is documented as a free text field on Provider Contracts and therefore cannot be used for automated computations in iTop.

Provider Contracts are useful for documenting contracts with third party suppliers (called underpinning contracts in the ITIL terminology), for which no tickets will be tracked in iTop.

You can of course use Customer Contracts for describing the contractual relation with a third party supplier, but this means that you have to also document in iTop the service catalog of this supplier.

Organizations and access rights

Apart from the customer/provider relations, another reason to create several Organizations in iTop is to restrict access to some areas of the managed data.

In iTop the rights to “read” (or display) objects from the database is defined on a per Organization basis. Each user is given (in the definition of her/his account) the rights to access a set of Organizations.

Organizations can be structured as a hierarchy. When this is the case, the access rights are inherited from the “Parent” Organization to the “Child” Organizations. For example, if “Company A” has two child Organizations: “Company A1” and “Company A2”, then if a user has the rights to access the objects in “Company A”, she/he will also be allowed to access the objects in “Company A1” and “Company A2”. On the other hand, a user who is allowed to access only “Company A1” will be allowed to access neither the objects in “Company A” nor those in “Company A2”.

The rights to “write” (i.e. create, modify or delete) objects are defined only by the profile(s) assigned to the user account. For example the profile “Support Agent” gives the rights to create or modify User Request tickets (but not to delete them).

This means that a user has the same access rights over all Organizations that she/he is allowed to access.

For example, in the current version of iTop, a user cannot have the rights to access the data of the Organizations “Company A” and “Company B” and the rights to create Servers only in “Organisation B”. If she/he is given the rights to create Servers, this will apply to both “Company A” and “Company B”.

Creating Locations

The Locations are very useful for grouping object by geography. Even if the location attribute is not a mandatory field when you create a CI in the CMDB, it is strongly recommended to create Locations beforehand and then to track the locations of all CIs.

Carefully plan the creation of the Locations. Locations are difficult to identify (there is no commonly accepted unique identifier for a Location), if your company does not have one already, you may want to put in place anaming convention in order to avoid duplicate Locations in the CMDB.

Shared Locations

In Enterprise environments, even though the split of roles and responsabilities are in favor of creating several sub Organizations, it is often needed to have “shared” locations among several Organizations to document “co-locations”. iTop does not provide - in its standard version - a way to actually “share” objects between Organizations. However, the Locations are “inherited” from parent Organizations to child Organizations in the same manner as the access rights. This means that a Person, a Server or a Network Device belonging to “Company A2” can be located on a Location owned by “Company A”.

Creating Persons

The Persons are very important in iTop as they are used to define all the contacts and their responsibilities. A Person belongs to one and only one organization. A Person can be a member of one or more Team(s), and therefore should be created before trying to setup Teams.

Also, each user record is linked to a Person object. Therefore Persons must be created before loading user accounts into iTop. The user record defines the access rights (and identification method), whereas the Person object defines the information about the contact: name, location, email address, telephone…

Creating Teams

The teams are linked to several types of object, like contracts or tickets, in order to define responsibilities. Teams are also used as “workgroups” for assigning tickets. Teams used for assigning tickets must also have at least one member (the agent to assign the ticket to). The attribute “Role” on the link between a Team and a Person is not mandatory, so you can leave it empty, but it is useful to define the role of the Person in the Team (Team Leader, Manager…).

Devices and Software CIs

Once the structure of the Organizations, the Locations and the contacts (Teams and Persons) have been loaded, you can start to populate the CMDB.

Since the software instances depend on the software types defined in the software catalog and are documented as installed on a particular host, you should start by documenting:

  • The physical infrastructure: Servers, Network Devices, PCs, etc…

  • The Software catalog, by creating the needed type of “Software” objects

Service Management

Before managing tickets in iTop, the services catalog, the Delivery Models and the contracts must be defined.Service Management on-boarding

Services Catalog

The “Services Catalog” is the list of Services that are available from a given provider Organization. The Services Catalog is documented in iTop by creating Service objects, assigned to the given Organization (considered as the provider of the service). Services are organized in a two-level hierarchy, through the two classes of objects: Service and Service Subcategory. Create the top level Services before loading sub categories.

The third level “Service Family” is used to group Services together and is mandatory for the Enhanced Portal.

Once the service catalog (Services and Service Subcategories) is defined, create the Customer Contracts that will link each “customer” Organization to its “providers” by creating one Customer Contract per couple of provider/customer and linking the appropriate Services to the contract.

Delivery Model

The Delivery Model is the object that defines which Team works for which customer. You can use a Delivery Model object to group together all the “support teams” for a given set of Services, or the support Teams dedicated to a particular customer. Each customer Organization must be assigned one, and only one, Delivery Model.

In the standard iTop 2.0 data model, there is no link between Teams and Services. The only limitation when assigning a ticket to a Team is that the Team must be part of the Delivery Model assigned to the Organization which is the customer of the ticket.

For example, if you have the following Teams:

  • Helpdesk team: a Team that processes all helpdesk requests/calls.

  • MS Office Support Team: a Team that processes all support requests about MS Office.

  • Hardware Support Team: a Team that handles hardware calls (Replacements, new hardware orders)

  • Network Support Team: a Team that handles network related issues

  • Customer B Helpdesk Team: a helpdesk team dedicated to Customer B

  • Customer B Hardware Team: a Team handling hardware calls for Customer B

You can then build two different Delivery Models:

  • “Delivery Model 1” composed of:

    •  

    Helpdesk Team

    •  

    MS Office Support Team

    •  

    Network Support Team

  • “Delivery Model 2” composed of:

    •  

    Customer B Helpdesk Team

    •  

    Customer B Hardware Team

    •  

    MS Office Team

The “Delivery Model 1” will be used by the Organizations “Customer A”, “Customer A1”, “Customer A2” and “Customer C”; whereas “Delivery Model 2” will be used by “Customer B”.

Service Level Agreements and Targets

The definition of Service Level Agreements (SLAs) and Service Level Targets (SLTs) are not mandatory to manage tickets in iTop, but without them iTop can neither compute deadlines for processing a ticket, nor escalate the ticket automatically.

In order to compute whether or not the expected Service Level Agreements are respected, iTop introduces two possible types of metrics called SLTs (Service Level Targets):

  • TTO (Time To Own): the time between the creation of a ticket and its assignment to an Agent.

  • TTR (Time To Resolve): the time between the creation of a ticket and its resolution (i.e. measured when the ticket enters the state “resolved”)

A SLT defines a duration associated with:

  • metric: either TTO or TTR

  • type of ticket (incident or user request)

  • priority (since tickets with higher priority should generally be processed more quickly)

A SLA is simply defined as a named group of SLTs (for example to distinguish between “Gold” and “Silver” service levels).

The definition of SLAs/SLTs have two effects in iTop:

  • Notifications can be defined for any percentage of the “threshold” associated with one of the metrics (for example one can configure notifications to send an email to the agent working on a ticket when 50% of the Time To Resolve is reached and to the team leader when reaching 75%).

  • When 100% of a metric is reached, the ticket is automatically set to a special “escalation” state (there are two specific states defined in the tickets’ life-cycle: Escalation TTO and Escalation TTR). Entering such a state can also be used to trigger specific notifications.

For example, one can define the following service level matrix:

Incidents – Priority HighIncidents – Priority MediumRequests – Priority HighRequests – Priority Medium
Time To Own: 5 minTime To Own: 30 minTime To Own: 30 minTime To Own: 4 hours
Time To Resolve: 1 hourTime To Resolve: 4 hoursTime To Resolve: 4 hoursTime To Resolve: n/a

This would lead to creating 4 SLTs, one for each row of the table. These 4 SLTs can be grouped under one SLA named “Gold Service Level”.

Finally SLAs can be associated to Customer Contracts in order to define the applicable metrics for the contract.

Your iTop instance is now ready to run. You may have a look at the Configuration of Notifications to setup email notifications for the tickets.

 

标签:
由 superadmin 在 2020/08/27, 16:18 创建
    

需要帮助?

如果您需要有关XWiki的帮助,可以联系:

深圳市艾拓先锋企业管理咨询有限公司