简介：iTop是一款基于CMDB与ITIL最佳实践的开源IT服务管理工具，面向企业IT运维人员、系统管理员及希望搭建服务台与资产管理体系的团队，帮助解决IT资产分散、服务流程不规范、变更与问题跟踪困难等问题。资源包共约2000个文件，以2128个php源码、313个png图片、256个js脚本、115个xml配置、82个css样式及twig模板、json、yml等为主，另有install安装说明、license许可文件与web前端目录，整体约11.44MB，结构完整便于部署与二次开发。目前已有1974人学习下载。内容覆盖CMDB关系建模、服务请求与问题变更管理、自动化工作流、报表分析、角色权限与API集成等模块，读者可据此搭建服务台、梳理资产依赖关系、定制字段视图与流程规则，并参考安装指南与开源许可快速完成环境配置，适合作为ITSM入门实践与定制开发的参考素材。
1. 从一张工单的流转说起：为什么我盯上了 iTop 这个 ITSM 开源工具
去年帮一个朋友处理他们内部运维流程混乱的问题，事情本身不复杂——服务器告警、用户报障、变更审批全散在聊天记录和邮件里，出了事没人说得清是谁在什么时候动了什么。他问我有没有能自己部署、不绑云服务、还能按自己流程改的工单系统。我翻了一圈，最后落在了 iTop 上。这玩意儿是开源 ITSM 工具里少有的把「配置管理数据库（CMDB）+ 工单 + 变更 + 服务目录」全塞进一套 PHP 应用里的方案，部署完就是一个完整的运维服务台，不是那种只给你一个表单引擎的半成品。它适合谁？适合中小团队里那个既要管服务器又要管流程、还不想被 SaaS 按人头收费的运维负责人，也适合想拿一套真实 ITSM 系统练手二次开发的 PHP 开发者。下面我按自己拆源码和部署的路径，把 iTop 从跑起来到改起来讲一遍。
2. 环境准备与部署：把 iTop 从压缩包跑到登录页
2.1 运行环境与依赖清单
iTop 是典型的 LAMP 栈应用，官方推荐的环境组合在源码包的 README 和安装向导里写得很清楚。我实际部署时用的配置如下，这套组合在社区里验证过很多次，踩坑概率最低：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| PHP | 7.4 / 8.0 / 8.1 | 8.2 部分扩展兼容性需确认 |
| MySQL / MariaDB | 5.7+ / 10.3+ | 需要 InnoDB 和 utf8mb4 |
| Apache / Nginx | 2.4+ / 1.18+ | 需开启 rewrite |
| 扩展 | mysqli、gd、ldap、soap、zip、json、mbstring | 缺一个安装向导就卡住 |
PHP 的memory_limit建议不低于 256M，max_execution_time给到 120 秒以上，因为安装阶段要建表和导入初始数据，超时中断会留下半拉子数据库，后面重装很麻烦。
2.2 数据库与目录权限配置
先把数据库建好，字符集必须是 utf8mb4，否则中文工单标题会变问号：
CREATE DATABASE itop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'itop'@'localhost' IDENTIFIED BY '你的密码'; GRANT ALL PRIVILEGES ON itop.* TO 'itop'@'localhost'; FLUSH PRIVILEGES;然后把源码包解压到 Web 根目录，比如/var/www/html/itop。iTop 运行时会往conf/和log/目录写配置和日志，这两个目录必须对 Web 用户可写：
chown -R www-data:www-data /var/www/html/itop/conf chown -R www-data:www-data /var/www/html/itop/log chmod -R 775 /var/www/html/itop/conf /var/www/html/itop/log这里有个容易忽略的点：conf/目录在安装前是空的，安装向导会生成production配置文件。如果你用 Nginx，记得把conf/和log/目录 deny 掉，别让外部直接访问到数据库密码。
2.3 安装向导与初始配置
浏览器打开http://你的域名/itop，会进入安装向导。几个关键步骤我按顺序说：
第一步是环境检查，PHP 扩展缺哪个它会红字标出来，照着装就行。第二步填数据库连接信息，就是上面建的那个库。第三步是选择安装类型，iTop 提供「简易」和「专家」两种模式，简易模式会装一套默认的数据模型，包含 Incident、Change、Service 等标准 ITSM 对象；专家模式让你勾选要装哪些模块。我建议第一次跑用简易模式，先把系统跑通，后面再通过扩展机制加模块。
安装完成后，默认管理员账号是admin，密码在安装最后一步会让你设。登录进去看到的是 iTop 的欢迎页和顶部菜单栏，左侧是导航，中间是仪表盘。到这一步，一套能用的 ITSM 系统就算落地了。
提示：安装完成后第一件事是改掉 admin 密码，并在「用户管理」里建一个自己的管理员账号，别一直用默认账号。
3. 核心模块拆解：工单、CMDB 与变更流程怎么串起来
3.1 数据模型：iTop 的「类」与「对象」体系
iTop 最核心的设计是它的元模型（Meta Model）。整个系统里所有东西——工单、服务器、联系人、合同——都是「对象」，每个对象属于一个「类」，类之间通过继承和关联组成一张网。这套模型定义在datamodels/2.x/目录下的 XML 文件里，安装时被解析并写入数据库的元数据表。
我拿 Incident（事件工单）举例，它的类定义大致长这样：
<class id="Incident" _delta="define"> <parent>Ticket</parent> <properties> <category>business</category> <abstract>false</abstract> </properties> <fields> <field id="impact" xsi:type="AttributeEnum"> <values> <value id="1">部门</value> <value id="2">公司</value> <value id="3">多公司</value> </values> </field> </fields> </class>这段 XML 的意思是：Incident 继承自 Ticket 类，多了一个impact枚举字段。iTop 启动时会读这些定义，动态生成数据库表和 PHP 对象类。你改 XML 就等于改数据模型，不用手写 SQL 建表。这种「模型驱动」的做法在开源 ITSM 里不多见，好处是扩展性强，坏处是第一次看会觉得绕——你得先理解它的编译流程：XML → 元数据表 → 运行时对象。
3.2 工单生命周期：从创建到关闭的状态机
iTop 的工单不是简单的「新建-处理-关闭」，它内置了一套状态机。以 Incident 为例，状态包括new、assigned、in_progress、pending、resolved、closed。状态之间的流转由lifecycle定义控制，写在同一个 XML 里：
<lifecycle> <states> <state id="new"> <transitions> <transition id="ev_assign"> <target>assigned</target> <action>assign</action> </transition> </transitions> </state> </states> </lifecycle>这段定义说的是：在new状态下，触发ev_assign事件会跳到assigned状态，并执行assign动作。实际运行时，用户在界面上点「分配」按钮，iTop 会检查当前状态是否允许这个事件，允许才执行跳转。这套机制的好处是流程可配置，你可以在 XML 里加状态、改流转条件，不用动 PHP 代码。
我踩过的一个坑是：直接改数据库里的状态字段，绕过状态机。结果工单卡在一个非法状态，界面按钮全灰了。后来才知道 iTop 的状态流转必须走ApplyTransition方法，直接 UPDATE 数据库是「翻车」操作。
3.3 CMDB 与工单的关联：CI 怎么挂到 Incident 上
CMDB 是 iTop 的另一个核心。所有服务器、网络设备、应用系统都是「配置项（CI）」，存在FunctionalCI类及其子类里。工单和 CI 之间通过关联表连接，比如 Incident 可以关联多个 CI，表示「这个故障影响了哪几台机器」。
关联关系定义在 XML 的<relations>标签里：
<relation id="impacts"> <source_class>Incident</source_class> <target_class>FunctionalCI</target_class> <type>many_to_many</type> </relation>运行时，iTop 会为这个关联生成一张中间表。你在工单详情页看到的「受影响 CI」列表，就是查这张表出来的。我实际用的时候，把服务器资产导入 CMDB 后，工单创建时可以直接选关联的 CI，排查故障时一眼能看到这台机器最近出过几次问题。这个联动是 iTop 比普通工单系统值钱的地方。
3.4 扩展机制：不改核心代码加功能
iTop 的扩展走的是「扩展包」机制。你可以在extensions/目录下建自己的模块，每个模块一个文件夹，里面放module.xml和对应的 PHP 类。安装时 iTop 会扫描这个目录，把模块注册进去。
一个最简单的扩展包结构：
extensions/ my-module/ module.my-module.php datamodels/ 2.x/ my-module.xmlmodule.my-module.php里声明模块信息，my-module.xml里定义新增的类或字段。这种设计让你升级 iTop 核心时，自己的定制不会被覆盖。我一般会把客户特定的字段和流程都放在扩展包里，核心目录保持干净，后面升级省心。
4. 避坑与排查：部署 iTop 时我遇到的那些坑
4.1 安装向导卡在「数据库连接失败」
现象：填完数据库信息点下一步，页面转圈然后报连接失败，但用命令行mysql -u itop -p能正常登录。
原因：iTop 安装向导用的是 PHP 的 mysqli 扩展连接数据库，如果 PHP 没装 mysqli 或者mysqli.default_socket指向的 socket 路径和 MySQL 实际路径不一致，就会连不上。命令行能连是因为用的是 mysql 客户端自己的配置。
解决：先php -m | grep mysqli确认扩展装了。如果装了还连不上，在 php.ini 里显式指定mysqli.default_socket = /var/run/mysqld/mysqld.sock（路径按实际改），重启 PHP-FPM 再试。
4.2 中文乱码：工单标题变问号
现象：安装时选了 utf8 而不是 utf8mb4，或者数据库建库时字符集不对，导致中文工单标题存进去变成???。
原因：MySQL 的 utf8 字符集每个字符最多 3 字节，存不下 emoji 和部分生僻字；iTop 内部用的是 utf8mb4，两边不一致就乱码。
解决：建库时必须用CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。如果已经装好了才发现，改数据库字符集后还要检查conf/production/config-itop.php里的db_charset参数，确保是 utf8mb4。
4.3 页面 500：conf 目录不可写
现象：安装完能登录，但点任何菜单都报 500，Apache 错误日志里写Permission denied往conf/或log/写文件。
原因：iTop 运行时需要往conf/写缓存配置，往log/写运行日志。如果 Web 用户没有这两个目录的写权限，就会 500。
解决：chown -R www-data:www-data conf log，权限给 775。注意别给 777，生产环境不安全。
4.4 升级后自定义字段消失
现象：从旧版本升级到新版本，之前手动在核心 XML 里加的字段全没了。
原因：iTop 升级会覆盖datamodels/2.x/下的核心文件，你直接改核心 XML 的定制就被冲掉了。
解决：所有定制走扩展包机制，放在extensions/目录下。升级前备份数据库和extensions/目录，升级后重新安装扩展包即可。这个坑我踩过一次，后来所有客户定制都强制走扩展包，再没丢过。
4.5 工单状态卡死无法流转
现象：工单停在某个状态，所有操作按钮都是灰的，管理员也点不动。
原因：有人直接改数据库状态字段，或者扩展包里的状态机定义有冲突，导致当前状态不在合法状态列表里。
解决：先查priv_internal表看状态机的定义，确认当前状态是否在<states>里。如果是数据问题，用 iTop 自带的ApplyTransition接口重新触发一次合法流转，别直接 UPDATE。如果是扩展包冲突，禁用最近加的扩展包再试。
5. 二次开发上手：从改一个字段到写一个扩展模块
5.1 最小改造：给工单加一个自定义字段
假设你要给 Incident 加一个「故障等级」字段，取值是 P1 到 P4。正确做法是建一个扩展包，而不是改核心 XML。
在extensions/下建目录fault-level/，里面放module.fault-level.php：
<?php // 声明模块基本信息 SetupWebPage::AddModule( __FILE__, 'fault-level/1.0.0', array( 'label' => '故障等级扩展', 'dependencies' => array('itop-itsm' => '3.0.0'), ) );然后在datamodels/2.x/fault-level.xml里定义字段：
<delta> <class id="Incident"> <fields> <field id="fault_level" xsi:type="AttributeEnum"> <values> <value id="p1">P1-紧急</value> <value id="p2">P2-高</value> <value id="p3">P3-中</value> <value id="p4">P4-低</value> </values> <default_value>p3</default_value> </field> </fields> </class> </delta>装完扩展后，Incident 的编辑页就会多出这个下拉框。字段值存在incident表的fault_level列里，iTop 自动帮你建列。
5.2 改流程：自定义状态流转规则
如果你想在工单关闭前强制要求填写解决方案，可以改状态机的closed状态定义，加一个mandatory条件。在扩展包的 XML 里覆盖：
<delta> <class id="Incident"> <lifecycle> <states> <state id="resolved"> <transitions> <transition id="ev_close"> <target>closed</target> <action>close</action> <condition>solution IS NOT NULL</condition> </transition> </transitions> </state> </states> </lifecycle> </class> </delta>condition里写的是 OQL（Object Query Language），iTop 自己的查询语法。这样用户点「关闭」时，如果解决方案为空，会被拦下来。这种改造不用动 PHP，纯配置就能实现。
5.3 验证改造是否生效
改完扩展包后，需要重新安装扩展让 iTop 重新编译元模型。命令行方式：
php /var/www/html/itop/webservices/run_query.php --update-schema或者在界面里进「管理工具」→「扩展包」→「刷新」。刷新后清一下缓存，再打开工单页面看新字段和流程是否生效。如果没生效，先看log/下的错误日志，多半是 XML 语法写错了或者依赖没声明对。
5.4 一个我常用的调试习惯
iTop 的报错有时候只给一个白屏，什么信息都没有。我一般会先把conf/production/config-itop.php里的debug打开：
'debug' => true,打开后页面底部会输出 SQL 和调试信息，定位问题快很多。但记得上线前关掉，不然性能和安全都有影响。从那以后我每次改完扩展包，都强制走一遍「刷新元模型 → 清缓存 → 开 debug 看日志」的流程，再没出现过改完不知道哪里错了的情况。希望帮到你。
本文还有配套的精品资源，点击获取
