- 官网地址：https://combodo.com
- GitHub地址：https://github.com/Combodo/iTop
我会按“是什么、核心能力、模块结构、适用场景、优缺点、落地建议”来讲，并顺带说明它和工单系统/CMDB/ITSM之间的关系。
下面给你一份 iTop 系统详解，偏 IT 运维落地视角。
1. iTop 是什么？
iTop 全称通常理解为 IT Operations Portal，是 Combodo 维护的一套开源、Web 化的 ITSM + CMDB 平台。它不是单纯的工单系统，而是一个围绕 IT 服务管理、配置管理、事件处理、变更管理、服务目录、SLA、组织人员、资产配置项关系等内容建立的综合运维管理平台。官方介绍中，iTop 定位为开源 ITSM 和 CMDB 解决方案，可管理用户请求、事件、问题、变更和服务目录。
简单说：
osTicket 更像“工单系统”；iTop 更像“IT 运维服务管理平台”。
它的核心价值是：
把人、组织、设备、系统、服务、合同、工单、故障、变更、SLA 这些运维对象关联起来管理。
2. iTop 的核心定位
iTop 主要围绕 3 个核心能力：
1）CMDB 配置管理数据库
这是 iTop 的核心。CMDB 用来记录 IT 环境中的各种配置项，例如：
| 类型 | 示例 |
|---|---|
| 组织 | 公司、部门、客户、供应商 |
| 人员 | 员工、联系人、技术团队 |
| 设备 | 服务器、PC、打印机、网络设备、电话 |
| 软件 | 应用系统、数据库、中间件、软件许可证 |
| 位置 | 办公室、机房、仓库、区域 |
| 服务 | 邮箱服务、网络服务、ERP、WMS、VPN |
| 关系 | 某业务系统依赖哪台服务器、哪套数据库、哪个网络设备 |
官方文档说明，iTop 的配置管理模块是必选模块，包含组织、联系人、服务器、网络设备、软件元素以及这些对象之间的关系。
这点非常关键。很多工单系统只记录“谁提交了什么问题”，但 iTop 可以进一步知道：
这个问题影响哪个服务？
这个服务依赖哪些服务器？
这些服务器归哪个团队维护？
哪些用户或部门会受影响？
2）ITSM 服务管理
iTop 是面向 ITIL/ITSM 思路设计的系统，支持用户请求、事件、问题、变更、服务目录等流程。官方说明它是 ITIL oriented，可以管理 user requests、incidents、problems、changes 和 service catalog。
常见模块包括：
| 模块 | 作用 |
|---|---|
| 用户请求管理 | 员工提交 IT 服务请求，例如开账号、装软件、申请权限 |
| 事件管理 | 处理故障，例如网络中断、系统异常、电脑蓝屏 |
| 问题管理 | 对重复故障做根因分析 |
| 变更管理 | 管理系统发布、配置变更、网络调整、权限变更 |
| 服务目录 | 定义 IT 能提供哪些服务 |
| SLA 管理 | 管理响应时间、解决时间、超时规则 |
| 通知管理 | 邮件通知、状态变更提醒 |
| 知识/文档管理 | 记录 SOP、处理方案、制度文档入口 |
3）工单流转与运维协同
iTop 也有 Helpdesk 能力，可以作为员工报障和 IT 处理工单的平台。它支持：
| 能力 | 说明 |
|---|---|
| 工单创建 | 用户提交请求或故障 |
| 工单分派 | 分派给具体团队或工程师 |
| 状态流转 | 新建、处理中、等待、解决、关闭 |
| 优先级 | 按影响范围、紧急程度划分 |
| SLA | 自动计算响应和解决时间 |
| 通知 | 状态变化邮件通知 |
| 关联配置项 | 工单可以关联电脑、服务器、系统、网络设备 |
| 关联服务 | 工单可以关联具体 IT 服务 |
| 历史记录 | 保留处理过程、沟通记录、操作日志 |
这也是它比简单工单系统更适合“规范化运维”的地方。
3. iTop 主要功能模块详解
3.1 组织与人员管理
iTop 可以管理：
| 对象 | 示例 |
|---|---|
| 组织 | 总公司、子公司、客户公司、供应商 |
| 部门 | 财务部、仓库部、客服部、IT 部 |
| 人员 | 员工、外包人员、供应商联系人 |
| 团队 | 桌面运维组、云运维组、网络运维组 |
| 联系方式 | 邮箱、电话、职位、所属组织 |
对你们 IT 运维来说，可以这样设计：
| 角色 | 用法 |
|---|---|
| 普通员工 | 提交工单 |
| 桌面运维 | 处理电脑、打印机、办公网络问题 |
| 云运维 | 处理服务器、云资源、发布、监控 |
| 网络运维 | 处理机房、交换机、防火墙、专线 |
| IT 主管 | 查看统计、审核变更、管理 SLA |
| 供应商 | 参与外包系统问题处理 |
3.2 CMDB 配置项管理
这是 iTop 最有价值的部分。
可以管理的配置项包括：
| 大类 | 小类 |
|---|---|
| 终端设备 | 台式机、笔记本、打印机、扫描枪、PDA |
| 网络设备 | 交换机、路由器、防火墙、AP、专线 |
| 服务器 | 物理服务器、虚拟机、云服务器 |
| 存储 | NAS、云盘、对象存储 |
| 软件系统 | ERP、WMS、OMS、OA、邮箱、VPN |
| 数据库 | MySQL、SQL Server、Redis、MongoDB |
| 机房资源 | 机柜、UPS、电源、链路 |
| 业务服务 | 邮箱服务、仓库网络服务、办公网络服务、打印服务 |
| 合同 | 维保合同、供应商合同、云服务合同 |
它的重点不是“资产数量统计”，而是“关系管理”。
例如：
WMS系统
├── 依赖：云服务器 A
├── 依赖：MySQL 数据库 B
├── 依赖：Redis C
├── 依赖：仓库网络
├── 负责人：云运维工程师
├── 供应商：某外包公司
└── 影响部门：仓库、客服、财务
这样一旦 WMS 出问题，iTop 可以帮助 IT 快速判断影响范围。
3.3 用户请求管理
用户请求偏“服务申请”，不是故障。
常见例子：
| 请求类型 | 示例 |
|---|---|
| 账号类 | 新员工开通邮箱、ERP、VPN、OA 账号 |
| 权限类 | 申请系统菜单权限、数据库只读权限 |
| 软件类 | 安装 Office、Foxmail、浏览器、远程工具 |
| 设备类 | 申请电脑、鼠标、显示器、打印机 |
| 网络类 | 申请 Wi-Fi、VPN、外网访问 |
| 资料类 | 申请共享盘权限、文档访问权限 |
适合设计成服务目录：
服务目录
├── 账号权限服务
├── 电脑外设服务
├── 打印服务
├── 网络服务
├── 邮箱服务
├── 业务系统支持
└── 云资源服务
员工提交工单时，直接选服务目录，不需要自己写太复杂。
3.4 事件管理
事件是“异常、故障、影响服务的问题”。
例如：
| 事件类型 | 示例 |
|---|---|
| 桌面故障 | 电脑蓝屏、开不了机、软件打不开 |
| 打印故障 | 无法打印、卡纸、驱动异常 |
| 网络故障 | 无法上网、Wi-Fi 掉线、仓库网络中断 |
| 系统故障 | ERP 登录失败、WMS 页面报错 |
| 邮箱故障 | Foxmail 收不到邮件、邮箱登录异常 |
| 云服务故障 | 服务器 CPU 高、磁盘满、服务宕机 |
事件管理适合用于“恢复服务”。
目标是：
尽快恢复正常，而不是一开始就深挖根因。
3.5 问题管理
问题管理偏“根因分析”。
例如：
| 现象 | 问题管理动作 |
|---|---|
| 某打印机一周故障 5 次 | 分析是否设备老化、网络不稳、驱动异常 |
| 某系统频繁超时 | 分析数据库、代码、服务器性能 |
| 仓库网络每月高峰期掉线 | 分析 AP 覆盖、交换机负载、线路质量 |
| 员工邮箱频繁重复收信 | 分析客户端配置、协议、迁移问题 |
事件管理解决“当下故障”；问题管理解决“为什么老是发生”。
3.6 变更管理
变更管理适合管这些事情：
| 变更类型 | 示例 |
|---|---|
| 系统发版 | ERP/WMS/OMS 新版本上线 |
| 数据库变更 | 表结构调整、索引优化、数据修复 |
| 网络变更 | 防火墙策略、端口开放、交换机配置 |
| 账号权限变更 | 管理员权限、数据库权限、后台权限 |
| 云资源变更 | 扩容、迁移、重启、配置调整 |
| 机房变更 | 设备上架、线路调整、UPS 切换 |
iTop 的变更管理对你们很有用，尤其是你之前提到的：
外包系统发版、数据库权限开放、端口开放、后台管理员权限开放、生产系统操作边界。
这些都可以纳入 iTop 的变更流程。
建议流程：
提交变更申请
→ 说明变更内容、影响范围、回滚方案
→ IT主管/业务负责人审批
→ 安排实施窗口
→ 执行变更
→ 验证结果
→ 关闭变更
3.7 服务目录与 SLA
iTop 可以把 IT 服务标准化。
例如：
| 服务 | 响应时间 | 解决时间 |
|---|---|---|
| 普通电脑故障 | 4 小时 | 2 个工作日 |
| 高优先级网络故障 | 30 分钟 | 4 小时 |
| 系统无法登录 | 1 小时 | 1 个工作日 |
| 新员工账号开通 | 1 个工作日 | 2 个工作日 |
| 生产系统故障 | 15 分钟 | 2 小时 |
这有利于 IT 运维从“人情式响应”变成“标准化服务”。
3.8 通知与自动化
iTop 支持流程状态、工单变更、分派、超时等通知。官方也强调 iTop 支持自动化、低代码定制、数据模型定制、角色权限、SSO 等能力。
可以实现：
| 场景 | 自动动作 |
|---|---|
| 工单提交 | 通知对应团队 |
| 工单分派 | 通知工程师 |
| 工单超时 | 通知负责人或主管 |
| 变更审批 | 通知审批人 |
| 工单关闭 | 通知用户确认 |
| 重大事件 | 通知相关业务部门 |
4. iTop 技术架构
iTop 是典型 Web 应用，官方旧版文档说明它基于 PHP 和 MySQL，需要 Web Server，例如 Apache、IIS 或其他支持 PHP 的 Web 服务器。
当前官方硬件建议中，小规模场景，例如每月少于 200 张工单、少于 20 个控制台用户、CMDB 配置项少于 5 万，可以使用一台 2vCPU、4GB 内存、10GB MySQL 磁盘的 all-in-one 服务器；更大规模则建议 Web 和 MySQL 分离部署。
典型部署结构：
用户浏览器
↓
Nginx / Apache / IIS
↓
PHP Runtime
↓
iTop 应用
↓
MySQL / MariaDB
常见部署方式：
| 方式 | 说明 |
|---|---|
| 单机部署 | 适合小团队试用 |
| Web + DB 分离 | 适合正式生产 |
| Docker 部署 | 适合测试或快速搭建 |
| Linux 部署 | 推荐用于生产 |
| Windows + IIS | 可以，但运维复杂度可能更高 |
5. iTop 适合哪些场景？
非常适合
| 场景 | 原因 |
|---|---|
| IT 部门想建立标准化运维体系 | iTop 有 ITSM、CMDB、SLA、变更管理 |
| 有服务器、网络、系统、供应商多方协作 | 能记录配置项关系和责任边界 |
| 需要管理业务系统发版和变更 | 变更流程比普通工单系统更完整 |
| 想做资产与服务关联 | CMDB 能表达依赖关系 |
| 桌面运维 + 网络运维 + 云运维统一管理 | 一个系统覆盖多个运维角色 |
| 公司未来要做 ITIL/ITSM 规范化 | iTop 思路更贴近 ITSM |
不太适合
| 场景 | 原因 |
|---|---|
| 只想要一个简单报修系统 | iTop 配置成本偏高 |
| IT 人员很少，流程很轻 | 可能显得复杂 |
| 没有人维护 CMDB 数据 | iTop 的核心价值发挥不出来 |
| 只关注客服式工单 | osTicket、Zammad 可能更轻 |
| 不想做流程设计 | iTop 需要先设计服务目录、分类、状态、角色 |
6. iTop 和 osTicket 的区别
| 对比项 | iTop | osTicket |
|---|---|---|
| 定位 | ITSM + CMDB 平台 | 工单系统 |
| 核心能力 | 服务管理、配置管理、变更管理 | 工单收集、分派、回复 |
| CMDB | 强 | 基本没有 |
| 变更管理 | 有 | 弱 |
| 问题管理 | 有 | 弱 |
| 服务目录 | 有 | 较简单 |
| SLA | 有 | 有 |
| 资产关系 | 强 | 弱 |
| 上手难度 | 中高 | 低 |
| 适合对象 | IT 运维体系建设 | 快速搭建服务台 |
| 二次配置 | 强 | 中等 |
| 适合桌面报修 | 可以，但需简化 | 非常适合 |
| 适合云/网络/系统运维 | 更适合 | 一般 |
一句话总结：
osTicket 适合“先把工单跑起来”；iTop 适合“把 IT 运维体系管起来”。
7. 对你们 IT 运维部门的建议
结合你之前描述的场景：桌面运维、网络机房、云运维、外包系统发版、权限开放、数据库变更、IT 体系建设，我建议：
如果你们只是先做桌面报修
可以先用：
osTicket / Zammad / 简化版工单系统
原因是轻、快、员工容易接受。
如果你们想建立完整 IT 运维管理体系
更建议用：
iTop
因为它更适合管理：
| 你们的工作 | iTop 对应能力 |
|---|---|
| 桌面运维工单 | 用户请求、事件管理 |
| 网络机房维护 | CMDB、事件、变更 |
| 云服务器运维 | CMDB、监控关联、变更 |
| 业务系统发版 | 变更管理 |
| 数据库权限开放 | 变更/请求审批 |
| 供应商处理问题 | 组织、联系人、工单协作 |
| SOP 文档 | 文档管理/知识库 |
| 服务响应考核 | SLA |
| 运维看板 | 查询、报表、统计 |
8. 推荐落地方式
不要一上来就把 iTop 所有功能都启用，否则会太复杂。
建议分 4 个阶段：
第一阶段：先做工单
目标：让员工能提交问题，IT 能处理。
先配置：
| 内容 | 示例 |
|---|---|
| 用户 | 员工、IT 工程师 |
| 团队 | 桌面运维、云运维、网络运维 |
| 服务分类 | 电脑、打印机、网络、邮箱、业务系统 |
| 工单状态 | 新建、处理中、等待用户、已解决、已关闭 |
| SLA | 普通、高、中、低 |
第二阶段：补 CMDB
目标：把关键资产和系统录进去。
优先录：
| 优先级 | 配置项 |
|---|---|
| 高 | 业务系统、服务器、数据库、网络设备 |
| 中 | 打印机、办公网络、仓库网络 |
| 低 | 普通员工电脑、外设 |
你们可以不要一开始就把所有员工电脑录进去。
建议先管关键对象：
业务系统 > 服务器 > 数据库 > 网络设备 > 打印机 > 电脑
第三阶段：上变更管理
目标：规范生产系统操作。
纳入 iTop 的变更类型：
| 类型 | 是否建议纳入 |
|---|---|
| 系统发版 | 必须 |
| 数据库变更 | 必须 |
| 防火墙端口开放 | 必须 |
| 管理员权限开放 | 必须 |
| 云服务器扩容 | 必须 |
| 普通软件安装 | 可不纳入变更，用请求工单即可 |
第四阶段：做报表和考核
目标：让 IT 管理可视化。
常看指标：
| 指标 | 作用 |
|---|---|
| 每月工单量 | 看工作负载 |
| 各分类工单数量 | 看问题集中在哪 |
| 平均响应时间 | 看服务效率 |
| 平均解决时间 | 看处理能力 |
| SLA 达成率 | 看服务质量 |
| 重复故障排行 | 推动问题管理 |
| 变更成功率 | 控制生产风险 |
| 供应商响应情况 | 管理外包质量 |
9. iTop 的优点
| 优点 | 说明 |
|---|---|
| 开源 | 可自行部署 |
| ITSM 思路完整 | 支持请求、事件、问题、变更 |
| CMDB 强 | 能管理配置项和依赖关系 |
| 可扩展 | 数据模型、字段、流程可定制 |
| 适合规范化 | 适合建设 IT 运维体系 |
| 支持权限控制 | 可按角色、组织隔离数据 |
| 支持集成 | 可通过 Web Service/API 与其他系统对接 |
| 适合多团队 | 桌面、网络、云、供应商都能参与 |
10. iTop 的缺点
| 缺点 | 说明 |
|---|---|
| 上手门槛较高 | 概念比普通工单系统多 |
| 配置成本高 | 要设计服务、分类、角色、CMDB |
| 界面不算特别现代 | 相比一些新系统，UI 偏传统 |
| CMDB 维护成本高 | 数据不维护就会失去价值 |
| 需要流程意识 | 没有流程设计，系统会变复杂 |
| 中文资料相对少 | 官方资料以英文为主 |
| 轻量报修可能显重 | 小团队可能用不到那么多功能 |
11. iTop 最适合你们怎么用？
结合你们 IT 运维部门的实际，我建议把 iTop 定位为：
IT 运维统一管理平台，而不是单纯报修平台。
建议分成 5 条主线：
1. 工单管理
- 桌面故障
- 打印机故障
- 网络故障
- 邮箱问题
- 业务系统问题
2. 服务请求
- 账号开通
- 权限申请
- 软件安装
- VPN 申请
- 共享盘权限
3. CMDB
- 业务系统
- 云服务器
- 数据库
- 网络设备
- 打印机
- 关键终端
4. 变更管理
- 系统发版
- 数据库操作
- 端口开放
- 管理员权限
- 云资源调整
5. 报表看板
- 工单量
- SLA
- 故障排行
- 变更记录
- 工程师工作量
12. 最终结论
iTop 是一套适合中小型到中大型 IT 团队建设 ITSM 运维体系的开源平台。
它最核心的价值不是“提交工单”，而是：
工单 + 服务 + 人员 + 组织 + 资产 + 系统 + 网络 + 供应商 + 变更 + SLA
全部关联起来。
如果你们现在只是想解决“员工报修、IT 接单、处理、关闭”，osTicket 更简单。
但如果你们想把：
桌面运维
网络运维
机房运维
云运维
业务系统运维
供应商协作
发版变更
权限开放
SOP文档
SLA考核
统一纳入一个平台管理，那么 iTop 比 osTicket 更适合做长期 IT 运维管理平台。