GLPI 项目解读：开源 IT 资产管理与 ITSM 服务台平台

GLPI 项目解读：开源 IT 资产管理与 ITSM 服务台平台

项目地址：https://github.com/glpi-project/glpi

GitHub Stars：截至 2026 年 8 月约 6200

当前稳定版本：GLPI 11.0.8

关键词：GLPI、IT 资产管理、ITSM、CMDB、ITIL、工单系统、软件许可证、资产盘点、知识库、服务目录、开源运维

一、为什么企业需要统一的 IT 资产与服务管理平台

企业 IT 环境中的设备、软件、用户、机房、网络、合同和服务请求，通常分散在不同的表格、邮件、即时通信记录和管理工具中。

当环境规模较小时，人工台账和临时工单还可以勉强维持。随着设备数量、部门数量和服务请求增加，运维人员往往会遇到以下问题：

• 无法准确知道企业当前拥有多少台计算机、服务器、打印机和网络设备
• 设备使用人、所属部门、所在位置和当前状态没有统一记录
• 软件安装情况和许可证数量难以核对
• 用户通过电话、邮件或即时通信提出请求，问题容易遗漏和重复处理
• 工单缺少统一的优先级、负责人、处理过程和关闭标准
• 资产故障历史、维修记录和更换记录无法和设备关联
• 供应商、合同、保修期限和采购信息分散在不同文件中
• 发生故障时，运维人员无法快速判断受影响的设备、服务和业务范围

IT 运维真正需要的不只是一个资产列表或一个工单页面，而是一套可以把"人、设备、软件、服务、请求和处理过程"关联起来的管理系统。

GLPI 的价值就在于将 IT 资产管理、配置管理、服务台、软件许可证、合同和知识库等能力放在同一个平台中，使运维团队能够围绕统一的数据模型开展日常工作。

二、GLPI 是什么

GLPI 的全称是 Gestionnaire Libre de Parc Informatique，可以理解为自由、开源的 IT 设备资产管理平台。官方项目将其定位为资产与 IT 管理软件，并提供 ITIL Service Desk、许可证跟踪和软件审计等能力。

GLPI 不只是一个记录电脑序列号的资产台账，也不只是一个提交故障申请的工单系统。它将以下几类对象和流程集中到一个 Web 平台中：

• IT 资产和配置项
• 用户、群组、部门、组织实体和位置
• 计算机、服务器、网络设备、打印机、显示器和外设
• 操作系统、软件、版本和许可证
• 工单、问题、变更和服务请求
• 知识库、FAQ 和服务目录
• 供应商、合同、采购订单、保修和财务信息
• 机房、机柜、网络端口和数据中心基础设施
• 项目、任务、计划和现场干预

GLPI 的核心思路，是把资产数据和 IT 服务流程放在同一套关系模型中。运维人员可以从一张设备记录进入关联的用户、位置、软件、合同、工单和历史操作，也可以从一个工单反向查看相关资产和配置关系。

项目采用 GPL-3.0-or-later 许可证。GLPI 11.0.8 的官方发布说明显示，该版本属于安全修复版本，生产环境部署时应关注正式版本、漏洞公告和升级策略。

三、GLPI 的整体工作模型

GLPI 采用典型的 Web 应用模式。管理员、服务台人员和普通用户通过浏览器访问系统，GLPI 应用负责处理资产、工单、用户、权限和业务流程，数据库负责保存核心业务数据。

一个简化的工作模型如下：

普通用户 / 服务台 / 管理员
            |
            | 浏览器访问
            v
      Web Server
      Apache / Nginx / IIS
            |
            v
        GLPI 应用
            |
   +--------+--------+
   |                 |
   v                 v
数据库            文件存储
资产、用户、      文档、附件、
工单、配置        缓存和日志

GLPI 还可以接收来自其他系统和客户端的数据：

GLPI Agent / API / 邮件收集 / 插件
                 |
                 v
           GLPI 数据模型
                 |
        +--------+--------+
        |                 |
        v                 v
   资产与配置          工单与服务流程
        |                 |
        +--------+--------+
                 v
       报表、通知、审计和决策

在这个模型中，GLPI 的重点不是单个功能页面，而是让不同来源的数据最终进入统一的资产、用户、服务和流程体系。

四、GLPI 的核心模块与职责

GLPI 的功能模块比较多，可以按照"资产数据、服务流程、管理支撑"三个方向理解。

模块	主要职责	典型管理对象
资产与配置管理	维护 IT 设备、配置项和关联关系	计算机、服务器、网络设备、打印机、外设
工单与服务台	受理、分派和跟踪用户请求	事件、服务请求、问题、工单任务
软件与许可证	管理软件安装情况、版本和授权	软件、版本、许可证、授权数量
用户与组织实体	管理人员、部门和数据隔离范围	用户、群组、实体、位置
知识库	沉淀故障处理经验和标准答案	知识条目、FAQ、分类
服务目录与 SLA	描述服务内容和响应要求	服务目录、SLA、时间规则
合同与供应商	记录采购、保修和供应商关系	供应商、合同、联系人、文件
数据中心管理	管理机房、机柜和基础设施关系	数据中心、机柜、设备、网络端口
项目与任务	规划项目和现场干预工作	项目、任务、计划、干预
插件与市场	扩展平台能力和行业场景	插件、扩展模块、自动化集成

这些模块并不是相互独立的菜单。设备、用户、位置、合同和工单之间的关联，才是 GLPI 作为 IT 管理平台的核心价值。

五、IT 资产与配置管理

1. 统一管理硬件资产

GLPI 可以记录计算机、服务器、显示器、打印机、网络设备、电话、存储设备和其他 IT 资产。每类资产通常包含名称、序列号、型号、制造商、位置、状态、使用人和所属实体等信息。

通过统一的资产记录，运维人员可以回答一些基础但重要的问题：

• 一台设备属于哪个部门
• 当前由谁使用
• 设备位于哪个办公室、机房或分支机构
• 设备是否在保修期内
• 设备安装了哪些软件
• 设备最近关联过哪些故障工单
• 设备是否已经报废、借出、维修或闲置

2. 管理设备之间的关联

IT 设备通常不是孤立存在的。计算机可能连接显示器、打印机和网络端口，服务器可能属于某个机柜、数据中心和业务服务，网络设备又可能连接到不同的设备和网段。

GLPI 可以将这些关系记录在资产和配置对象中，使运维人员在处理故障或变更时能够看到更完整的上下文。

一个典型的资产关系可以表示为：

组织实体
   |
   +-- 部门
   |     |
   |     +-- 用户
   |
   +-- 位置
         |
         +-- 机房 / 办公区
                |
                +-- 服务器 / 网络设备 / 计算机
                         |
                         +-- 软件 / 外设 / 网络端口
                         |
                         +-- 合同 / 保修 / 工单历史

3. 管理实体和权限边界

对于集团、分支机构、学校、医院或多事业部组织，所有资产放在一个平面中管理并不一定合适。GLPI 提供 Entity Separation，可以按照组织实体划分数据和管理范围。

不同实体可以拥有各自的资产、用户、规则和服务管理范围，同时由上级管理员进行统一管理。这样可以在共享平台的同时，减少不同组织单元之间的数据混淆。

六、GLPI 如何支持 ITIL 服务管理

GLPI 的服务台能力围绕工单、问题、变更、知识和服务目录展开，可以用于建立较为完整的 IT 服务流程。

1. 工单受理

用户可以通过 Web 界面、邮件或其他集成方式提交请求。工单可以记录问题描述、请求人、关联资产、优先级、分类、附件和期望处理时间。

2. 工单分派

服务台可以根据实体、类别、来源、资产类型或其他规则，将工单分派给对应的技术团队或处理人员。

3. 处理和协作

处理人员可以在工单中添加跟进记录、任务、内部说明、解决方案和附件。工单的处理过程可以保留在同一条记录中，避免关键信息散落在聊天记录和个人邮件中。

4. 解决和关闭

问题解决后，可以记录解决方案并通知请求人。根据组织流程，工单还可以经过请求人确认、服务台审核或自动规则处理后关闭。

5. 问题与变更管理

重复发生的事件可以进一步归纳为问题，分析根因并制定预防措施。涉及生产环境、网络架构或关键配置的操作，则可以纳入变更流程，记录影响范围、计划、审批和实施结果。

一个典型的服务流程可以表示为：

用户提交请求
       |
       v
工单分类与优先级判断
       |
       v
分派给服务台或技术团队
       |
       v
处理、协作、记录操作过程
       |
       +-- 需要长期治理 --> 问题管理
       |
       +-- 涉及环境变更 --> 变更管理
       |
       v
记录解决方案并通知用户
       |
       v
确认、统计和关闭

GLPI 的 ITIL 能力不只是将工单状态从"打开"改成"关闭"，而是通过工单、问题、变更、知识和服务水平之间的关联，逐步形成可复用、可审计的服务流程。

七、GLPI Agent 与自动化资产发现

资产台账如果完全依靠人工维护，很快就会出现设备遗漏、软件信息过期和资产状态不准确的问题。GLPI Agent 可以安装在受管理的计算机或服务器上，用于收集设备硬件、操作系统、软件和网络等库存信息，并将结果发送到 GLPI。

从 GLPI 10 开始，项目支持原生动态库存管理。结合 Agent 后，可以减少以下重复工作：

• 手工录入计算机硬件信息
• 手工统计操作系统和软件版本
• 手工更新内存、磁盘、网卡和处理器信息
• 设备变更后重新维护资产台账
• 通过多个表格汇总资产盘点结果

一个典型的资产发现链路如下：

安装 GLPI Agent 的设备
          |
          | 采集硬件、系统、软件和网络信息
          v
      GLPI Agent
          |
          | 定期或按任务提交库存
          v
       GLPI 服务端
          |
          +-- 匹配已有资产
          |
          +-- 创建新资产
          |
          +-- 更新配置和软件信息
          v
       资产与配置数据库

Agent 的价值不仅是"自动创建电脑记录"，还可以让资产信息持续变化。设备更换内存、升级系统、安装新软件或改变网络配置后，GLPI 中的记录可以根据新的库存结果进行更新。

实际部署时需要提前规划 Agent 的分发、升级、通信地址、认证方式、代理服务器和设备退役流程。自动盘点并不等于资产治理已经完成，仍然需要处理重复资产、异常设备、离线设备和不再使用的记录。

八、软件、许可证与配置合规

软件管理是 IT 资产管理中比较容易被忽视的一部分。只记录硬件而不记录软件，会导致授权数量、软件版本和安全风险难以判断。

GLPI 可以围绕软件、版本和许可证建立管理关系：

• 记录组织使用的软件产品和版本
• 统计设备上的软件安装情况
• 记录许可证数量、类型、采购信息和有效期
• 将许可证分配给实体、设备或使用范围
• 通过库存信息发现软件安装和授权记录之间的差异
• 为软件升级、下线和授权续期提供数据依据

软件管理可以和工单、合同、供应商及财务信息关联。例如，一款业务软件发生授权即将到期时，管理员可以查看对应的供应商、合同、采购记录和使用设备，再决定续费、扩容或清理未使用授权。

需要注意的是，GLPI 的软件管理依赖库存数据、资产归属和许可证维护质量。如果 Agent 没有覆盖全部设备，或者软件名称没有经过统一规范化，统计结果仍然可能存在偏差。

九、知识库、服务目录与通知体系

1. 知识库和 FAQ

服务台每天都会重复处理密码、打印机、网络接入、客户端安装和常见软件故障。如果每次都重新排查，技术人员的时间会被大量消耗。

GLPI 的知识库可以将常见问题、处理步骤、配置说明和操作规范沉淀下来。知识条目可以按照分类、实体和可见范围进行管理，也可以作为工单处理和用户自助服务的依据。

2. 服务目录

服务目录可以将"IT 能提供什么服务"以更清晰的方式展示出来，例如账号申请、软件安装、设备借用、网络接入、服务器资源申请和权限变更等。

服务目录的价值在于将模糊的"找 IT 帮忙"转换成结构化的服务请求，使请求内容、审批人、处理团队和响应要求更加明确。

3. SLA 和通知

对于不同级别的服务请求，可以定义响应时间、解决时间、工作时间和升级规则。GLPI 还可以通过邮件通知用户、处理人员和管理人员，使工单状态、分派结果、处理进展和解决方案能够及时传达。

通知体系需要和组织的邮件服务器、值班制度和升级流程配合。只配置自动通知而没有明确责任人和升级规则，通常不能真正提升服务质量。

十、合同、供应商与数据中心管理

1. 合同和供应商信息

IT 资产往往和采购、保修、维保及供应商服务绑定在一起。GLPI 可以关联供应商、联系人、合同、采购订单、资产、保修期限和相关文档。

在设备故障或合同续期时，运维人员可以从资产记录快速定位供应商和保修信息，减少翻找纸质合同或个人文件的时间。

2. 数据中心基础设施

GLPI 提供数据中心基础设施管理能力，可以记录数据中心、机房、机柜、设备位置和网络端口等信息。

对于服务器数量较多的环境，机柜、机架位置、电源和网络连接关系能够帮助运维人员理解设备的物理布局，并辅助处理搬迁、扩容、维修和变更任务。

3. 资产生命周期

资产管理不应只关注"设备现在在哪里"，还应覆盖采购、入库、分配、使用、维修、借出、闲置、报废和回收等阶段。

GLPI 可以通过资产状态、历史记录、合同和工单关联来记录这些变化。这样既有助于日常运维，也可以为预算编制、设备更新和审计提供基础数据。

十一、插件、REST API 与自动化扩展

GLPI 的核心功能覆盖范围较广，但不同组织的流程、认证、报表和业务集成需求并不完全相同。插件机制是 GLPI 生态的重要组成部分。

插件可以用于扩展：

• 身份认证和目录服务集成
• 额外的资产类型或行业对象
• 表单、服务目录和审批流程
• 报表、仪表板和通知方式
• 外部监控、采购、财务或协作系统集成
• 数据导入、同步和批量处理

GLPI 还提供 REST API，可以通过应用令牌、用户令牌和会话令牌访问资源。外部系统可以使用 API 查询资产、创建或更新工单、读取用户和实体信息，或者将 GLPI 纳入更大的自动化流程。

一个典型的自动化链路如下：

监控、采购或身份系统
          |
          | API / 插件 / 文件导入
          v
        GLPI
          |
          +-- 创建或更新资产
          |
          +-- 创建工单或添加跟进
          |
          +-- 触发通知和审批流程
          v
       服务台和运维团队

使用插件和 API 时，需要明确数据归属、认证方式、访问权限、失败重试、重复数据和接口审计。扩展数量增加后，GLPI 的升级兼容性和插件维护也需要纳入版本管理。

十二、GLPI 部署方式与基础要求

GLPI 是 PHP Web 应用，官方仓库提供了源代码、依赖管理文件和 Docker 开发环境。生产环境可以根据组织习惯选择传统 Web 服务器部署、容器部署或官方发布包部署。

根据 GLPI 官方 README，当前版本的基础要求包括：

• Web 服务器，例如 Apache、Nginx 或 IIS
• PHP 8.2 或更高版本
• MariaDB 10.6 或更高版本，或 MySQL 8.0 或更高版本
• mysqli、curl、gd、intl、mbstring、openssl、xml、zlib 等 PHP 扩展
• 支持的现代浏览器，例如 Edge、Firefox 和 Chrome
• 如果使用 LDAP、压缩包、图片处理或其他高级能力，需要额外启用对应扩展

源代码部署还需要 Composer 和 npm，用于安装 PHP 和前端依赖。官方安装文档建议按照 GLPI Administrator 文档执行安装和升级，不应只复制源代码后直接暴露到生产环境。

生产部署时可以按照以下层次规划：

公网或内网访问入口
          |
          v
    反向代理 / Web Server
          |
          v
       GLPI 应用
          |
   +------+------+
   |             |
   v             v
数据库       files 目录
              |
              +-- 文档、附件、缓存、日志和会话

服务端部署完成后，还需要配置数据库备份、文件目录备份、邮件发送、计划任务、日志保留、访问控制、TLS 证书和升级回滚方案。

十三、使用 GLPI 时需要关注的问题

1. 资产数据质量

GLPI 可以提供统一的数据模型，但不会自动保证数据准确。需要制定资产命名、序列号、位置、部门、用户、状态和报废记录的维护规范。

2. Agent 覆盖率和数据重复

如果只有部分设备安装 Agent，资产库存就无法反映完整环境。Agent 重装、主机名变化、序列号缺失或导入规则不一致，也可能产生重复资产，需要建立识别和清理机制。

3. 权限和实体设计

实体、用户、群组、角色和资产范围需要在上线前规划。权限过宽会导致不同部门看到不应访问的数据，权限过窄又会影响跨部门协作和故障处理。

4. 工单流程不能只停留在录入

如果所有请求都进入同一个队列，没有分类、优先级、负责人、SLA 和升级规则，GLPI 只能成为一个新的"问题收集箱"。上线时应先梳理常见服务目录和处理流程，再配置系统字段和规则。

5. 邮件、计划任务和通知可靠性

邮件收集、自动通知、库存同步和部分后台任务依赖服务器计划任务和外部服务。需要监控任务是否执行、邮件是否投递、库存是否更新，以及失败后是否产生可追踪日志。

6. 插件兼容性

插件会扩展 GLPI 能力，但也可能影响升级和安全维护。正式环境应记录插件来源、版本、维护状态和依赖关系，并在升级前完成兼容性验证。

7. 备份与敏感数据保护

GLPI 中可能保存用户信息、设备信息、网络地址、合同、附件、账号关联和工单内容。数据库、files 目录、配置文件和备份介质都需要按照组织的数据安全要求进行保护。

8. 生产版本与安全升级

GLPI 官方仓库的 main 或开发相关分支不一定适合直接用于生产环境。生产环境应优先使用正式发布版本，并关注安全版本、漏洞修复、插件兼容性和升级回滚方案。

十四、GLPI 的能力边界

GLPI 适合承担 IT 资产管理和 IT 服务管理平台的职责，但不应被理解成可以自动替代所有运维系统的万能平台。

它可以管理资产、配置、工单、服务目录、知识、许可证、合同和相关流程，但以下能力通常仍需要结合其他系统或插件完成：

• 实时网络流量监控和完整的性能监控
• 终端检测响应、病毒防护和安全运营
• 操作系统补丁的完整生命周期管理
• 移动设备管理和复杂的终端合规控制
• 企业级财务、采购和 ERP 全流程
• 面向所有业务系统的配置自动发现和依赖分析
• 大规模自动化编排、发布和持续交付

GLPI 的正确定位是 IT 管理数据和服务流程的统一平台。它可以成为运维体系的重要入口，但实际效果取决于资产数据质量、流程设计、权限规划、Agent 覆盖率和周边系统集成。

十五、GLPI 适合哪些组织

比较适合的情况

• 需要统一管理计算机、服务器、网络设备和软件资产
• 希望将资产信息和工单服务流程关联起来
• 需要建设 IT 服务台、知识库和服务目录
• 需要跟踪软件许可证、合同、保修和供应商关系
• 组织包含多个部门、分支机构或实体，需要分层管理数据
• 希望通过 Agent 自动收集硬件、软件和网络库存
• 需要通过 API、插件或邮件把 GLPI 接入现有运维流程
• 有人员负责资产治理、服务流程和系统维护

需要谨慎评估的情况

• 组织没有明确的资产责任人和数据维护流程
• 只想临时记录几台设备，不需要完整的服务管理体系
• 需要的是实时监控、EDR、补丁或完整配置自动化，而不是 ITSM 平台
• 计划安装大量插件，但没有验证版本兼容性和安全维护能力
• 组织规模和工单量较大，却没有规划数据库、文件存储、备份和升级方案

十六、总结

GLPI 的核心价值，可以概括为以下几点：

• 统一管理计算机、服务器、网络设备、打印机和其他 IT 资产
• 记录用户、部门、位置、软件、许可证、合同和供应商关系
• 通过资产与配置关联，为故障处理和变更分析提供上下文
• 通过工单、问题、变更、知识库和服务目录支持 ITIL 服务流程
• 通过 GLPI Agent 自动收集硬件、系统、软件和网络库存
• 通过实体、角色、群组和权限控制不同组织单元的数据范围
• 通过插件、REST API 和 Marketplace 扩展平台能力
• 支持传统 Web 服务器、数据库和容器等多种部署方式

GLPI 更适合被理解为一套开源的 IT 资产与服务管理平台，而不是简单的设备登记工具或单一工单系统。它将"资产是什么、由谁使用、属于哪个组织、关联哪些服务、出现过什么问题、需要执行什么流程"放在同一个管理体系中。

真正落地 GLPI 时，最重要的工作并不是把所有模块一次性打开，而是先确定资产分类、实体结构、用户权限、工单流程和数据维护责任，再根据实际需要逐步启用 Agent、知识库、服务目录、许可证、合同、API 和插件能力。

参考资料

1. GLPI GitHub 主项目
2. GLPI 官方网站
3. GLPI Administrator Documentation
4. GLPI User Documentation
5. GLPI Developer Documentation
6. GLPI Agent Documentation
7. GLPI 插件文档
8. GLPI REST API 文档
9. GLPI 11.0.8 Release
10. GLPI LICENSE

本文用于项目认知和应用方向分析。具体部署时，需要结合组织规模、资产数量、身份体系、Agent 覆盖范围、数据库性能、插件兼容性、数据保护要求和 IT 服务流程进行验证。