不灭的焱

下面按 Combodo iTop：开源 ITSM + CMDB 运维管理平台 来讲。它适合用来做 IT 服务台、资产/配置管理、服务目录、SLA、事故、请求、问题、变更、通知和自动化。iTop 官方说明它是面向 IT 日常运维的开源 Web 应用，核心是 CMDB，并以 ITIL 最佳实践为设计理念，但不会强制你照搬某一种流程。(iTop Hub)

1. iTop 可以解决什么问题

iTop 可以理解为“IT 运维门户”。它不是单纯的报修系统，而是把 人、部门、设备、应用、服务器、合同、服务、SLA、工单、变更 关联在一起管理。官方 iTop Hub 对它的定位是：在同一平台中管理配置项及关系、用户请求、事故、问题、变更和服务目录。(iTop Hub)

常见用途如下：

用途	解决的问题	例子
CMDB 配置管理	资产和应用关系不清楚	服务器、虚拟机、数据库、应用、网络设备、人员、地点统一建档
服务台 Helpdesk	报修分散在微信、电话、邮件	用户从门户提交“电脑无法开机”“申请邮箱账号”
事故管理 Incident	系统故障没人跟进、影响范围不清	ERP 宕机后关联受影响的服务器、数据库、业务部门
服务请求 Request	标准化申请流程	新电脑、VPN、软件安装、权限申请
问题管理 Problem	反复故障找不到根因	多次 VPN 断线，建立问题单分析根因
变更管理 Change	修改系统没有审批和回溯	防火墙策略变更、系统补丁、数据库升级
SLA 管理	响应和解决时间不可衡量	高优先级故障 15 分钟响应、4 小时恢复
通知自动化	工单状态没人知道	分派、升级、解决时自动发邮件或 webhook

2. iTop 核心概念先理解

2.1 组织、人员、团队

这是所有流程的基础。

例如：

对象	示例
Organization 组织	总公司、上海分公司、客户 A、供应商 B
Person 人员	张三、李四、王经理
Team 团队	一线服务台、网络组、系统组、数据库组
Location 地点	上海办公室、北京机房、A 栋 3 楼

实施时不要一上来就建工单，应该先建组织、人员、团队、地点。iTop 实施文档也建议先加载组织、地点、联系人、团队和人员，再开始填充 CMDB。(iTop Hub)

2.2 CMDB：配置项数据库

CMDB 是 iTop 的核心。它用来记录 IT 环境中的对象和关系。官方数据模型说明，iTop 的配置管理模块可以管理 PC、服务器、打印机、网络设备、电话、虚拟机、应用方案、业务流程、软件实例、许可证、组织、地点、人员和团队等。(iTop Hub)

例子：

业务服务：电商网站
  ├─ 应用：商城前台
  │   ├─ 服务器：web01、web02
  │   └─ 数据库：mysql-prod
  ├─ 网络设备：核心交换机 sw-core-01
  └─ 联系人：电商业务负责人、系统管理员、DBA

这样当 mysql-prod 出故障时，你可以知道哪些应用、业务、部门和联系人受影响。

2.3 服务目录 Service Catalog

服务目录是用户能申请或报修的内容。官方服务管理模块包括 Service、Service Subcategory、SLA、SLT、Customer Contract、Provider Contract 等对象，并且服务管理会和工单管理集成，用于决定客户可选哪些服务、工单截止时间如何计算。(iTop Hub)

一个实用结构：

服务族：办公支持
  ├─ 服务：电脑与外设
  │   ├─ 子类：电脑故障报修
  │   ├─ 子类：申请新电脑
  │   └─ 子类：打印机问题
  └─ 服务：账号与权限
      ├─ 子类：申请邮箱账号
      ├─ 子类：申请 VPN
      └─ 子类：重置密码

注意：如果使用增强门户，官方文档说明 Service Family、Service、Service Subcategory 三层必须定义，否则门户用户可能看不到可提交的服务。(iTop Hub)

2.4 SLA、TTO、TTR

在 iTop 里，SLA 通常由 SLT 组成。官方说明 SLT 默认有两类指标：TTO 和 TTR。TTO 是从工单创建到被接手或分派给处理人的时间；TTR 是从工单创建到被解决的时间。(iTop Hub)

例子：

优先级	TTO 响应时间	TTR 解决时间
Critical	15 分钟	4 小时
High	30 分钟	8 小时
Medium	4 小时	2 个工作日
Low	1 个工作日	5 个工作日

iTop 的 Helpdesk 模块会根据客户合同、SLA、优先级和请求类型计算 TTO/TTR 截止时间；如果配置了工作时间/假期窗口，还可以按工作时间计算。(iTop Hub)

3. 安装教程概览

生产环境建议先确认版本和依赖。官方最新硬件/软件要求页面建议使用 Debian 12 或 Ubuntu 24.04 LTS；小规模场景可以 all-in-one，大一些的场景建议 Web 和 MySQL 分开部署。例如每月少于 200 张工单、少于 20 个控制台用户、少于 5 万个 CI 时，官方给出的推荐是 2 vCPU、4GB 内存、MySQL 10GB 磁盘的单服务器；规模更大时建议 Web + MySQL 两台服务器。(iTop Hub)

3.1 准备环境

典型组件：

Web Server：Apache / IIS / NGINX
PHP：按 iTop 版本要求选择
DB：MariaDB 或 MySQL
浏览器：Chrome 或 Firefox

官方兼容性表显示，iTop 3.2.x 支持 PHP 8.1 到 8.3、MySQL 5.7+、MariaDB 10.6 到 11.8；iTop 3.3.x 支持 PHP 8.2 到 8.4、MySQL 5.7+、MariaDB 10.6 到 11.8。官方也提示 MySQL 8 虽然自 iTop 2.7 起支持，但不推荐用于大型数据库，因为 MySQL 8 移除了 query cache，可能导致性能问题。(iTop Hub)

3.2 安装步骤

官方安装向导流程大致如下：

1. 准备好 Apache/PHP 或 IIS/PHP 环境。

2. 将 iTop 包中 web 目录的内容解压到 Web 目录，比如 Linux 的 /var/www/html/itop 或 Windows/IIS 的 C:\inetpub\wwwroot\itop。

3. 设置目录权限。

4. 浏览器访问对应地址，例如 http://localhost/itop。

5. 按安装向导检查环境、选择全新安装或升级、接受许可、填写数据库连接、创建管理员账号、设置默认语言和访问 URL。

6. 选择 CMDB、服务管理、工单管理、变更管理等模块。

7. 确认后点击安装。(iTop Hub)

安装向导第一步会检查配置一致性、Web 服务器用户权限、MySQL/PHP 及可选 PHP 扩展；数据库步骤需要提供有足够权限的账号，因为安装过程中可能要创建表、触发器、视图，升级时也可能要删除视图。(iTop Hub)

3.3 安装后必须做的事

安装完成不代表可以直接上线，至少要补齐这些：

项目	为什么重要
配置后台任务 cron.php	SLA 升级、异步邮件、自动备份、扩展任务都依赖它
配置邮件通知	分派、解决、超时、用户回复时通知相关人员
创建组织/人员/团队	没有团队就无法合理分派工单
建服务目录和客户合同	没有服务目录，门户用户可能无法提交请求
建 SLA/SLT	没有 SLA 就无法自动算响应/解决期限
建 CMDB	事故、变更、影响分析都依赖 CI 关系
配置权限	不同部门、客户、供应商看到的数据应隔离

官方背景任务文档说明，iTop 的维护任务和异步任务集中由 webservices/cron.php 处理，包括 TTO/TTR 阈值通知、SLA 检查、自动备份、清理无用附件、异步邮件和很多扩展任务；官方建议按分钟级定时运行，并且不要用 root 用户执行，而应使用运行 iTop 的 Web 服务器用户。(iTop Hub)

4. 日常使用教程：从 0 到能跑起来

第一步：建立组织和人员

示例：

组织：
- 本公司 IT 部
- 财务部
- 销售部
- 供应商：网络运营商 A

人员：
- 王经理，财务部，普通用户
- 李工，IT 部，一线支持
- 赵工，IT 部，网络组
- 陈工，IT 部，系统组

团队：
- Helpdesk 一线
- Network 网络组
- System 系统组
- DBA 数据库组

组织还影响访问权限。iTop 实施文档说明，iTop 对对象的读取权限是按 Organization 维度控制的，用户账号会被授予可访问的组织范围。(iTop Hub)

第二步：建立 CMDB

从最关键的资产开始，不要一次性追求全量。

建议顺序：

1. 机房、办公室、地点
2. 服务器、网络设备、PC、打印机
3. 虚拟机、数据库、中间件
4. 应用系统
5. 应用和服务器、数据库、网络设备的依赖关系
6. 业务联系人、技术联系人

例子：

CI 类型	名称	关联
Server	app-prod-01	运行“OA 应用”
Database	mysql-oa-prod	被“OA 应用”依赖
Application Solution	OA 系统	服务“办公自动化”
Network Device	firewall-core-01	影响 OA、ERP、VPN
Contact	OA 业务负责人	事故通知联系人

第三步：建立服务目录

示例：

Service Family：办公 IT 服务

Service：账号与权限
  - Service Subcategory：申请邮箱账号，类型：service request
  - Service Subcategory：重置密码，类型：service request
  - Service Subcategory：账号无法登录，类型：incident

Service：网络服务
  - Service Subcategory：申请 VPN，类型：service request
  - Service Subcategory：VPN 无法连接，类型：incident

Service：业务系统
  - Service Subcategory：OA 系统故障，类型：incident
  - Service Subcategory：ERP 权限申请，类型：service request

Service Subcategory 很关键，因为它可以把工单细分到“事故”或“服务请求”。官方文档说明，服务子类用于更精确地定义服务，并且会关联请求类型，用来自动化用户请求或事故的分类。(iTop Hub)

第四步：建立交付模型 Delivery Model

Delivery Model 决定一个客户或组织的工单可以分派给哪些团队。官方实施文档说明，每个客户组织必须分配一个且只能一个 Delivery Model；它定义哪些团队为哪些客户提供支持。(iTop Hub)

例子：

Delivery Model：内部 IT 支持模型
包含团队：
- Helpdesk 一线
- Network 网络组
- System 系统组
- DBA 数据库组

如果用户提交“VPN 无法连接”，工单可以先分给 Helpdesk，确认后转给 Network 网络组。

第五步：建立客户合同、SLA、SLT

内部 IT 场景也可以把“公司内部部门”当作客户。

例子：

Customer Contract：总部办公 IT 服务合同
Customer：总部
Provider：IT 部
Services：
- 账号与权限
- 网络服务
- 业务系统

SLA：总部标准 SLA
SLT：
- Critical / Incident / TTO = 15 分钟
- Critical / Incident / TTR = 4 小时
- High / Incident / TTO = 30 分钟
- High / Incident / TTR = 8 小时

官方实施文档提醒，SLA/SLT 不是创建工单的强制条件，但如果没有它们，iTop 就不能计算工单处理期限，也不能自动升级工单。(iTop Hub)

第六步：创建工单并处理

用户请求可以从门户创建，也可以由支持人员在后台创建。官方用户请求管理文档说明，用户请求可以通过客户门户或直接在 iTop 中创建；支持人员可以通过 Public log 与客户沟通，通过 Private log 与内部团队沟通，门户用户只能看到 Public log。(iTop Hub)

一个基本处理流程：

用户提交请求
  ↓
一线查看和补充信息
  ↓
分派团队和处理人
  ↓
处理人记录处理过程
  ↓
需要等待用户时设为 Pending
  ↓
问题解决后填写 Solution
  ↓
用户确认或到期后关闭

5. 应用场景详细举例

场景 1：用户报修——“VPN 无法连接”

背景

销售部用户王经理在外出差，无法连接公司 VPN，影响访问 CRM。

配置方式

服务目录：

Service Family：办公 IT 服务
Service：网络服务
Service Subcategory：VPN 无法连接
Request Type：incident

团队：

Helpdesk 一线：先接单
Network 网络组：处理 VPN、防火墙、线路问题

SLA：

High 优先级：
TTO = 30 分钟
TTR = 8 小时

工单字段示例

字段	示例
Caller	王经理
Organization	销售部
Service	网络服务
Service Subcategory	VPN 无法连接
Impact	A person
Urgency	high
Priority	high
Origin	portal
Description	出差酒店网络下 VPN 客户端提示认证失败

处理流程

1. 王经理从门户提交工单。

2. iTop 根据服务目录和合同计算 TTO/TTR。

3. Helpdesk 一线接单，Public log 回复：“请提供 VPN 客户端截图。”

4. 用户上传截图。

5. Helpdesk 判断可能是账号锁定，在 Private log 中备注内部分析。

6. 若账号正常，则分派给 Network 网络组。

7. Network 检查 VPN 网关日志，发现用户账号被多次错误密码锁定。

8. 解锁账号，要求用户重试。

9. 用户确认恢复，工单填入解决方案：“重置 VPN 登录失败计数并指导用户更新密码。”

10. 关闭工单。

价值

这个场景的价值不只是“记录一张报修单”，而是沉淀：

谁报修
哪个服务出问题
哪个团队处理
用了多久响应
用了多久解决
是否违反 SLA
类似问题是否重复发生

如果未来大量 VPN 工单重复出现，就可以升级为 Problem 问题管理。

场景 2：事故管理——“ERP 系统无法访问”

背景

上午 9 点，财务部多人反馈 ERP 无法访问。这个不是单个用户问题，而是影响业务系统的事故。

iTop 的事故管理模块用于跟踪 IT 技术问题，例如系统宕机、网络问题、应用失败；事故可以关联到 Problem 或 Change。(iTop Hub)

CMDB 关系

Application Solution：ERP 系统
  ├─ Server：erp-app-01
  ├─ Database：erp-db-prod
  ├─ Network Device：core-switch-01
  └─ Contact：财务系统负责人、ERP 运维负责人

工单字段示例

字段	示例
Type	Incident
Title	ERP 系统无法访问
Impact	A service
Urgency	critical
Priority	critical
Service	业务系统
Service Subcategory	ERP 系统故障
CI	ERP 系统、erp-app-01、erp-db-prod

处理流程

1. Helpdesk 创建 Incident，选择受影响 CI：ERP 系统。

2. iTop 通过影响分析把关联的 CI 和联系人带出来。用户请求管理文档说明，当保存工单时，影响分析引擎会自动把受原始 CI 影响的其他 CI 和联系人加入列表，并标记为 Computed。(iTop Hub)

3. 系统组检查 erp-app-01，发现应用进程正常。

4. DBA 检查 erp-db-prod，发现数据库连接池耗尽。

5. 临时扩容连接池并重启应用服务。

6. Public log 通知业务方：“ERP 已恢复，根因分析继续。”

7. 工单先 Resolved，后续如果确认稳定再 Closed。

8. 若同类问题近期多次出现，建立 Problem 单做根因分析。

价值

这个场景中 CMDB 的作用非常明显：

没有 CMDB：只能问“ERP 谁负责？跑在哪台机器？”
有 CMDB：直接看到 ERP 依赖的服务器、数据库、联系人、相关合同和受影响服务。

场景 3：服务请求——“申请新虚拟机”

背景

研发部门需要一台新测试虚拟机，要求 4 CPU、16GB RAM、Ubuntu、开放 SSH。

服务目录设计

Service Family：基础设施服务
Service：服务器与虚拟化
Service Subcategory：申请新虚拟机
Request Type：service request

表单字段建议

普通描述框容易漏信息，所以建议使用自定义表单字段：

字段	示例
CPU	4
Memory	16GB
OS	Ubuntu 24.04
Disk	200GB
用途	测试环境
申请到期日	2026-12-31
是否需要公网	否

iTop 的 Customized request forms 扩展可以按服务/服务子类动态添加额外字段。例如官方文档举例：当用户申请“新虚拟机”时，可以要求填写 CPU 数量、RAM、OS 类型，而不是希望用户自己写在 Description 里。(iTop Hub)

流程示例

用户提交申请
  ↓
直属经理审批
  ↓
系统组创建 VM
  ↓
网络组配置 VLAN / 防火墙
  ↓
安全组检查基线
  ↓
交付账号和 IP
  ↓
关闭工单

价值

通过结构化字段，后续可以统计：

一个月申请了多少台 VM
哪些部门资源消耗最多
哪些 VM 有到期日
哪些 VM 没有关联负责人

场景 4：员工入职流程

背景

HR 提交新员工入职，需要 IT、行政、权限管理员、邮箱管理员协同处理。

服务目录设计

Service Family：人员生命周期
Service：员工入职
Service Subcategory：标准员工入职
Request Type：service request

入职申请字段

字段	示例
新员工姓名	陈小明
入职日期	2026-06-10
部门	销售部
岗位	销售经理
直属主管	王经理
是否需要电脑	是
是否需要邮箱	是
是否需要 VPN	是
是否需要 CRM 权限	是

任务拆分

Helpdesk：确认申请信息
资产管理员：分配笔记本电脑
账号管理员：创建 AD / 邮箱账号
网络组：开通 VPN
应用管理员：开通 CRM 权限
行政：发放门禁卡

如果每类入职都需要同样的一组任务，可以使用流程/工单自动拆分。iTop 的 Procedure Catalog 扩展可按服务子类定义一组 Procedure，并在 User Request 或 Incident 第一次分派时自动创建 Work Orders；它也支持按顺序执行，未关闭工作任务时默认不允许解决主工单。(iTop Hub)

对于更复杂的入职/离职流程，iTop 的 Global requests management 扩展支持用一个主请求自动生成多个子请求，官方文档就把 onboarding/offboarding 作为典型复杂流程例子。不过该扩展页面标注为 Combodo 客户使用。(iTop Hub)

价值

入职流程非常适合 iTop，因为它解决的是跨团队协同问题：

传统方式：
HR 发邮件 → IT 忘记 VPN → 新员工第一天不能办公

iTop 方式：
一个主请求 → 自动拆任务 → 每个团队有明确待办 → 主请求看到整体进度

场景 5：变更管理——“周末数据库升级”

背景

DBA 计划周六晚上升级生产数据库版本。这个动作可能影响 ERP、CRM、报表系统，需要审批、通知和回滚方案。

iTop 变更管理模块用于记录计划中的 IT 修改，例如补丁安装、系统配置变更、OS 更新、软件安装；文档化变更有助于在事故发生时追踪最近做过哪些修改，并且该模块可分析变更对基础设施和应用方案的影响。(iTop Hub)

变更单字段示例

字段	示例
Title	生产数据库版本升级
Category	system / software
Description	将 ERP 生产数据库从版本 A 升级到版本 B
Planned start	周六 22:00
Planned end	周日 02:00
Impacted CIs	erp-db-prod、ERP 系统
Backout plan	升级失败则恢复快照和备份
Change manager	运维经理
Implementor	DBA 张工

流程示例

新建变更
  ↓
填写影响范围、实施计划、回退计划
  ↓
关联受影响 CI
  ↓
变更经理审批
  ↓
通知业务负责人
  ↓
周末实施
  ↓
验证 ERP / CRM / 报表系统
  ↓
关闭变更

价值

当周一有人反馈 ERP 慢，你可以直接查到：

这个周末是否有数据库变更？
谁批准？
谁执行？
影响了哪些系统？
是否有回退方案？
是否有关联事故单？

场景 6：问题管理 + 已知错误库——“打印机反复卡纸”

背景

同一台打印机一个月内出现 12 次卡纸报修。每次单独处理都能恢复，但没有彻底解决。

处理方式

1. 将多张 Incident 关联到一个 Problem。

2. 建立问题单：财务部打印机 HP-01 反复卡纸。

3. 分析根因：纸张规格不匹配、搓纸轮老化。

4. 在 Known Error 中记录临时解决办法。

5. 采购备件或更换打印机。

6. 问题关闭后，后续类似事故可快速引用解决方案。

iTop 已知错误库用于记录尚未完全修复的问题和临时解决办法，以提升事故处理效率；已知错误还能关联 CI，当工单关联某个 CI 时，相关已知错误会自动显示。(iTop Hub)

Known Error 示例

字段	内容
Name	HP-01 打印机反复卡纸
Domain	Desktop
Symptom	打印 20 页以上时高概率卡纸
Root Cause	搓纸轮磨损
Workaround	每次打印不超过 10 页；临时使用备用打印机
Solution	更换搓纸轮或整机替换
Related CI	HP-01 打印机

价值

Helpdesk 不再重复摸索：

看到 HP-01 相关工单
  ↓
系统提示已有 Known Error
  ↓
一线按 workaround 临时恢复
  ↓
二线按 Problem 计划彻底修复

场景 7：邮件转工单

背景

很多用户习惯发邮件到 it-helpdesk@company.com，不愿意登录门户。

iTop 的 Mail to ticket automation 扩展可以扫描指定邮箱，根据邮件内容创建或更新工单；创建工单时可以填入描述、调用人、客户、附件、联系人等，回复邮件时也可以更新工单 Public Log。(iTop Hub)

配置思路

邮箱：it-helpdesk@company.com
行为：Create or Update
默认工单类型：User Request
未知发件人策略：拒绝或自动创建 Person
附件策略：允许图片、PDF，禁止危险类型
标题匹配：根据邮件头或标题中的工单号更新原工单

流程示例

1. 用户发邮件：“电脑蓝屏，附件是照片。”

2. iTop 自动创建 User Request。

3. 邮件正文进入 Description。

4. 附件照片进入工单附件。

5. 用户后续回复邮件，内容进入 Public Log。

6. 工单解决时，通知邮件自动发送给用户。

价值

这个场景适合服务台过渡期：既保留邮件入口，又把处理流程统一沉淀到 iTop。

场景 8：合同、许可证和到期提醒

背景

公司有网络线路合同、硬件维保合同、软件许可证。如果没有系统提醒，经常过期后才发现。

iTop 建模方式

Provider Contract：运营商专线合同
Provider：运营商 A
Covered CI：核心路由器、互联网出口
Start date：2026-01-01
End date：2026-12-31

Software License：Office 许可证
数量：300
到期日：2026-11-30
关联用户/设备：PC 清单

iTop 服务管理中 Customer Contract 可定义客户购买或请求了哪些服务以及对应 SLA；Provider Contract 则用于记录支撑服务的供应商合同。(iTop Hub)

价值

你可以做：

提前 60 天提醒合同续约
统计哪些合同即将到期
查看某个服务依赖哪些供应商合同
某个供应商故障时判断影响哪些业务

6. 通知和自动化配置教程

iTop 的通知系统由 Trigger 触发器 和 Action 动作 组成。触发器决定什么时候通知，例如工单进入 assigned 状态；动作决定做什么，例如发邮件、发内部 News、调用 webhook。官方文档还列出 webhook 动作可用于 Slack、Rocket.Chat、Google Chat、Microsoft Teams 等。(iTop Hub)

示例：工单分派给处理人时发邮件

配置思路：

Trigger：
- 类型：对象进入某状态
- 对象：User Request
- 状态：assigned

Email Action：
- 收件人：当前工单 Agent
- 主题：你有新的工单 $this->ref$
- 内容：标题、用户、服务、优先级、链接

官方的通知示例流程也是：进入 Admin tools / Notifications，先创建 Trigger，再创建 Email Action，最后把 Trigger 关联到 Email Action。(iTop Hub)

推荐通知规则

场景	通知对象
工单创建	Helpdesk 队列
工单分派	处理人
工单进入 Pending	用户
用户追加回复	当前处理人
工单解决	用户
TTO/TTR 即将超时	处理人、团队负责人
TTO/TTR 已超时	运维经理
变更审批通过	实施人、业务联系人
变更即将开始	受影响联系人

7. 推荐上线顺序

不要一次性把所有模块都上线。比较稳妥的顺序是：

第 1 阶段：服务台最小可用

目标：先让报修流程跑起来。

组织
人员
团队
服务目录
用户请求
邮件通知
基础 SLA

适合周期：1 到 3 周。

第 2 阶段：CMDB 和影响分析

目标：让事故和资产有关联。

服务器
网络设备
应用系统
数据库
业务联系人
CI 关系

适合周期：2 到 6 周。

第 3 阶段：事故、问题、变更

目标：从“接单系统”升级为“ITSM 流程平台”。

Incident
Problem
Known Error
Change
审批
回退计划

适合周期：1 到 3 个月。

第 4 阶段：自动化和集成

目标：减少人工录入和重复操作。

邮件转工单
监控告警转工单
资产扫描同步
API 集成
Webhook 通知
报表和看板

iTop 官方功能页说明，iTop 支持 REST API、Webhooks、与外部工具交换工单、数据同步引擎和 Collector，例如可与 OCS Inventory、VMware、Microsoft Graph、Azure、vSphere、Ansible 等集成。(iTop)

8. 一个完整落地案例：中小企业 IT 服务台

公司背景

人数：500 人
IT 团队：8 人
地点：上海总部 + 北京办公室
核心系统：ERP、OA、CRM、邮件、VPN、文件服务器
目标：统一报修、资产可查、SLA 可统计、变更可追溯

iTop 配置方案

组织

本公司
  ├─ 上海总部
  ├─ 北京办公室
  ├─ 财务部
  ├─ 销售部
  └─ 研发部

团队

Helpdesk 一线
系统组
网络组
应用组
DBA

服务目录

办公支持
  ├─ 电脑故障
  ├─ 打印机故障
  ├─ 软件安装
  └─ 申请新电脑

账号与权限
  ├─ 重置密码
  ├─ 申请邮箱
  ├─ 申请 VPN
  └─ 申请系统权限

业务系统
  ├─ ERP 故障
  ├─ OA 故障
  └─ CRM 故障

SLA

Critical：15 分钟响应，4 小时解决
High：30 分钟响应，8 小时解决
Medium：4 小时响应，2 天解决
Low：1 天响应，5 天解决

CMDB

ERP 系统
  ├─ erp-app-01
  ├─ erp-db-prod
  └─ core-switch-01

OA 系统
  ├─ oa-app-01
  ├─ oa-db-prod
  └─ file-storage-01

VPN 服务
  ├─ vpn-gateway-01
  └─ firewall-core-01

运行效果

指标	上线前	上线后
报修入口	电话、微信、邮件混杂	门户 + 邮件统一进 iTop
工单状态	用户需要反复追问	用户可看 Public log 和状态
SLA	靠人工记忆	自动计算 TTO/TTR
事故影响范围	临时问人	通过 CMDB 关系查看
变更记录	零散 Excel	变更单统一审批和追踪
知识沉淀	靠老员工经验	FAQ、Known Error、Solution 可复用

9. 常见坑和建议

常见问题	原因	建议
用户门户看不到服务	服务族/服务/服务子类/合同没建完整	先检查 Service Family、Service、Service Subcategory、Customer Contract
工单不能分派给某团队	Delivery Model 没包含该团队	更新对应客户组织的 Delivery Model
SLA 不计算	没有 SLA/SLT 或合同未关联服务	先建 SLT，再建 SLA，再关联 Customer Contract
邮件通知不发	SMTP、触发器、动作、cron 配置不完整	先测试邮件，再检查 Trigger 和 Action
超时不升级	cron.php 没跑	配置后台任务，使用 Web 服务用户执行
CMDB 很快变脏	缺少维护责任人	每类 CI 指定 owner，定期审计
一开始建模太复杂	想一次覆盖所有资产和流程	先跑 Helpdesk，再逐步补 CMDB、变更、问题

10. 最小可行配置清单

第一次上线可以按这个清单做：

1. 创建组织：公司、部门、供应商
2. 创建人员：用户、支持人员、经理
3. 创建团队：Helpdesk、系统组、网络组
4. 创建 Delivery Model，并把团队加入
5. 创建服务族、服务、服务子类
6. 创建 Customer Contract，并关联服务
7. 创建 SLT：TTO/TTR
8. 创建 SLA，并关联 SLT
9. 把 SLA 关联到 Customer Contract
10. 创建几类核心 CI：服务器、应用、网络设备
11. 配置通知：创建、分派、解决、超时
12. 配置 cron.php
13. 用 5 个典型工单做测试
14. 再开放给用户使用

一个很实用的原则是：先让工单流转顺畅，再逐步提高 CMDB 精度；先规范最常见的 20% 服务，再扩展到复杂流程。

 

 

---

 

上面提到的 CI 是什么的缩写？

在上面的 iTop / ITSM / CMDB 语境里，CI 是 Configuration Item 的缩写，中文通常叫：

配置项

它指的是 IT 环境中需要被管理、记录、追踪、关联的对象。

例如在 iTop 里，下面这些都可以是 CI：

CI 类型	示例
服务器	erp-app-01、web-prod-02
数据库	mysql-prod、oracle-erp-db
应用系统	ERP 系统、OA 系统、CRM 系统
网络设备	防火墙、交换机、路由器、VPN 网关
虚拟机	VM、云主机
终端设备	PC、笔记本、打印机
软件实例	Nginx、Tomcat、MySQL 实例
业务服务	邮件服务、VPN 服务、ERP 服务

在 iTop 中，CI 最重要的作用不是单独记录资产，而是建立关系。例如：

ERP 系统
  ├─ 运行在服务器 erp-app-01 上
  ├─ 依赖数据库 erp-db-prod
  ├─ 经过防火墙 firewall-core-01
  └─ 服务财务部用户

所以当 erp-db-prod 出故障时，iTop 可以帮助你判断：

哪个系统受影响？
哪些用户或部门受影响？
谁是负责人？
有没有相关事故单、变更单或合同？

注意：在软件开发领域，CI 也常指 Continuous Integration，持续集成。但在 iTop、CMDB、ITSM 里，CI 基本就是 Configuration Item，配置项。