开源 ITSM 不是做 Demo：企业级系统真正难在产品化

heidsoft

发布于 2026-07-06 18:17:28

MANAGEMENT REVIEW · OPEN ITSM

云与数字化 | 一个 AI Native ITSM 项目的建设笔记

做一个能演示的 ITSM 系统并不难，真正难的是让它在企业环境里长期可信地运行。

开源 ITSM 的挑战，不只是补功能，而是把部署、权限、流程、审计、数据质量、升级边界这些“看不见的工程”做扎实。

最近公众号后台的数据给了我一个很明确的信号：《我为什么要做一个开源 ITSM 项目》和《企业为什么需要一个开源版 ServiceNow》这两篇文章，阅读和转发都明显高于普通技术文章。读者真正关心的，不只是某个功能怎么实现，而是这件事为什么值得做、为什么现在做、以及它能不能走成一个长期项目。

这也让我意识到，后面不能只写概念。开源 ITSM 如果只是喊“对标 ServiceNow”，很容易变成一句空话。真正需要持续公开的是：一个早期开源项目，如何从功能 Demo 走向企业级产品化。

这里我先把边界说清楚。当前这个开源 AI Native ITSM 项目还处在早期阶段，GitHub 上是 40+ Star，不是成熟商业产品，也不是 ServiceNow 的完整替代品。项目已经有 ITIL 核心流程、BPMN 工作流、CMDB v1、知识库、SLA、RBAC、多租户、AI 分诊、摘要和 RAG 等基础能力，但连接器市场、插件市场、Skill 市场、CMDB 数据质量治理和更完整的企业集成仍在持续建设。

正因为还早，才更适合把建设过程写清楚。企业级系统不是靠一两次发布做出来的，它靠持续处理那些不够显眼、但决定能不能进入生产环境的问题。

Demo 解决的是“看起来能用”，产品化解决的是“出了问题怎么办”

Demo 的目标通常很明确：页面能打开，流程能走通，按钮点下去有结果。对早期项目来说，Demo 很重要，因为它帮助团队确认方向，也让外部用户快速理解产品。

但企业软件不能停在 Demo。企业真正上线一个 ITSM 系统时，会问很多更具体的问题：干净机器能不能部署？管理员密码怎么初始化？数据库迁移失败怎么办？多租户数据会不会串？权限是否能控制到菜单和动作？AI 输出有没有审计？连接器密钥放在哪里？版本升级会不会破坏客户定制？

这些问题在演示视频里并不显眼，却决定系统能不能进入生产。

一个企业级系统的成熟度，不取决于“有没有这个页面”，而取决于“这个页面背后的状态、权限、数据、审计和异常处理是否闭环”。

功能存在只是第一步，可信运行才是产品化。

我在做这个项目时，越来越能感受到这一点。工单、事件、问题、变更、服务请求、CMDB、SLA、知识库这些模块，单独做出页面并不算完成。真正复杂的是它们之间要联动：工单要触发 SLA，变更要关联 CMDB，服务请求要进入审批，AI 建议要被人确认，连接器动作要留下审计。

开源项目最容易低估的，是“可信部署”

很多开源项目的 README 写得很漂亮，但用户第一次部署时，往往会遇到各种细节问题：环境变量不完整、镜像构建慢、数据库初始化不一致、默认账号不可用、前后端地址配置混乱、升级脚本没有说明。

对于个人项目，这些问题可以靠作者手把手解释；对于企业级开源项目，这样不行。企业用户需要一条可复现路径：从克隆代码、配置环境、启动服务、登录系统、执行核心流程，到健康检查和日志排查，都应该能按文档完成。

当前项目已经把 Docker Compose、GHCR 镜像、初始化任务、健康检查、GA readiness、API smoke 放进交付体系里。它们听起来不像“亮点功能”，但它们是企业级开源项目的地基。

可信部署至少要回答这些问题：

服务能否一键启动，并且每个依赖都能健康检查？

数据库迁移和初始化是否幂等？

默认账号、JWT、数据库密码、Redis 密码是否有生产安全提醒？

后端 API、前端构建、核心 smoke 是否能作为版本门禁？

失败时，用户能否通过日志和文档定位问题？

这些工作不会让文章标题更性感，但它们决定开源项目能不能被外部用户认真试用。一个企业级开源项目的第一批用户，往往不是被功能打动，而是被“它真的能跑起来，而且问题能定位”留下来的。

企业级 ITSM 的核心，不是模块数量，而是流程闭环

ITSM 很容易被做成模块堆叠：工单管理、事件管理、问题管理、变更管理、服务目录、知识库、CMDB、SLA、报表，每个模块都有页面，看起来覆盖面很全。

但企业使用时，真正关心的是流程是否闭环。一个事件能不能从告警进入工单？能不能升级？能不能关联问题？问题能不能沉淀为知识？变更能不能做风险评估和审批？服务请求能不能走目录、表单、审批、交付任务和状态追踪？SLA 能不能贯穿整个过程？

如果这些链路断开，模块再多也只是页面集合。企业数字化的深水区，常常不是缺系统，而是系统之间缺少可执行、可追踪、可治理的流程。

ITSM 产品化的一个判断标准：

每个核心对象都要有状态机，每个关键动作都要有权限，每个跨模块流程都要有真实数据，每个失败路径都要有明确反馈。

这也是为什么最近项目里大量工作不是新增页面，而是修 API 契约、补兼容端点、清理 mock、补状态字段、统一 DTO、修前后端字段命名、跑 smoke。外部看起来像“琐碎修复”，但对产品化来说，这是必经之路。

权限、租户、审计，比新增功能更早进入优先级

很多产品早期会把权限、租户、审计放到后面做，理由是先把功能跑通。但企业级系统里，这三件事不能太晚。

ITSM 系统天然会进入企业组织结构：谁可以看哪些工单，谁可以处理哪个部门的事件，谁可以审批变更，谁可以配置 SLA，谁可以管理连接器，谁可以查看 AI 审计。这些不是 UI 权限的小问题，而是组织治理问题。

多租户也一样。如果未来要支持私有化、SaaS、MSP 这些部署模式，租户边界必须从早期进入数据模型和中间件。等系统已经大量写死单租户逻辑，再去补多租户，成本会高很多。

审计则决定系统能不能承载 AI 和连接器。AI 分诊建议、摘要生成、RAG 检索、连接器调用、插件安装、流程审批，这些都应该能留下记录。企业不是不愿意用 AI，而是不愿意使用不可追溯、不可解释、不可治理的 AI。

企业级系统的顺序感很重要：

先把权限、租户、审计、状态、异常、部署这些底座做稳，再让功能继续增长。否则功能越多，治理成本越高。

这也是我不希望把开源 ITSM 做成“功能堆叠项目”的原因。真正长期可用的系统，必须有治理结构。

CMDB 是最能检验产品化深度的模块之一

CMDB 很容易被误解成资产表。只要能录服务器、数据库、应用、负责人、IP 地址，就好像有了 CMDB。但企业真正需要的是配置管理底座：类模型、关系、识别规则、数据质量、服务映射、影响分析。

当前项目已经有 CI、CI Type、CI Relationship、拓扑、影响分析、云资源发现基础能力，也开始补属性定义校验、默认值、必填、唯一性等治理能力。但距离 ServiceNow 风格的 CMDB，还需要继续做类模型、IRE、CSDM 分层、数据质量评分和多源对账。

这里不能夸大。CMDB 模块已经跨过从 0 到 1 的阶段，但还没有到“企业级 CMDB 治理中心”的成熟度。下一阶段要做的不是再多加几张表，而是让数据更可信，让关系更有业务语义，让变更、事件、服务目录和 CMDB 真正联动。

CMDB 产品化要看四件事：

是否有稳定的类模型，而不是只有类型标签。

是否有识别与对账规则，而不是简单覆盖数据。

是否有数据质量治理，而不是只负责存储。

是否能服务事件、变更、SLA 和影响分析，而不是孤立存在。

CMDB 难做，恰恰说明企业级 ITSM 的复杂度不在表面。它考验的是数据治理、流程联动和组织协同。

AI Native 不是更炫，而是更需要工程约束

AI Native ITSM 不能理解成“给工单系统加一个聊天框”。如果 AI 只是在页面上回答问题，它对企业流程的改变很有限。真正有价值的 AI，要进入分诊、摘要、知识推荐、影响分析、流程建议和工具调用。

但 AI 一旦进入流程，就必须被约束。它要有模型配置、prompt 版本、输入摘要、输出记录、置信度、人工确认、降级策略、审计日志和回归评估。否则 AI 越深入，风险越大。

这也是项目路线图里持续强调 Guidance-Harness-Skill、AI evaluator、AI audit、Skill registry 的原因。企业 AI 不是靠一次效果演示就能进入生产，它需要可测、可控、可追溯。

AI Native 的真正门槛，不是接入大模型，而是把大模型变成企业流程里可治理的一部分。

AI 可以建议，但高风险动作必须有人审或策略授权；AI 可以调用工具，但不能绕过权限和流程。

从这个角度看，AI Native ITSM 和插件市场、连接器市场、Skill 市场其实是一件事。连接器提供受控工具，插件提供扩展边界，Skill 提供可复用 AI 能力，流程和审计负责约束它们。

插件市场，是避免“每个客户都改核心代码”的产品化能力

企业软件一定会有差异化。不同企业有不同流程、字段、审批、连接器、页面和管理制度。如果每个差异都通过改核心代码解决，开源项目很快会走向分叉：企业改了自己的版本，社区版本升级困难，安全补丁合不上，功能演进也无法共享。

插件市场要解决的不是“让页面上多几个插件卡片”，而是建立扩展契约。插件应该声明版本、权限、菜单、API、流程模板、连接器依赖、Skill 依赖、审计要求和卸载策略。平台根据契约安装、启用、禁用、升级和治理插件。

这和 ServiceNow 的 Spoke 机制给我的启发是一致的：企业级扩展不能靠散落的脚本和临时接口，而要变成可安装、可复用、可治理的能力单元。

开源 ITSM 的长期竞争力，不只是核心功能做得多，而是能不能让外部能力在不破坏核心的前提下持续生长。

这就是插件市场、连接器市场和 Skill 市场要一起设计的原因。

下一阶段，我更关心这些“不显眼”的工作

如果只追求外部观感，下一阶段最容易做的是继续加页面、加图表、加 AI 按钮。但从产品化角度看，我更关心几类基础工作。

第一，继续提升测试和验收基线。

后端测试、前端构建、API smoke、核心流程 E2E，要逐步成为每次发布的默认门禁。

第二，继续清理 mock、stub 和假成功。

开源用户最怕页面提示成功，但数据没有真实落库。产品化必须优先消灭这类信任损耗。

第三，推进连接器生命周期。

飞书、企业微信、钉钉、Webhook 不只是通知通道，而是未来企业 AI 工具层的第一批基础设施。

第四，设计插件 Manifest 和能力包。

让企业可以扩展流程、页面、连接器和 Skill，而不是直接改核心代码。

第五，继续补 CMDB 数据治理。

类模型、识别规则、对账、质量评分和服务映射，是 CMDB 从资产表走向配置管理底座的关键。

这些工作短期看不一定带来爆发式传播，但它们决定项目能不能从“能演示”走向“能被企业认真评估”。

为什么要持续写这些建设过程？

开源项目早期最缺的往往不是代码，而是信任。外部用户看到一个仓库，会先判断几件事：作者是不是持续投入，项目是不是有清晰方向，问题是不是被认真处理，文档是不是跟代码一致，路线图是不是现实，已经完成和计划中的能力有没有区分。

公众号文章可以承担一部分信任建设。它不只是宣传渠道，更像是一份公开的产品日志：为什么做这个功能，为什么先修这个问题，为什么某个能力暂时不夸大，为什么连接器、插件、Skill、CMDB 要按这个顺序演进。

这对企业读者也有价值。很多 CIO、IT 负责人、架构师并不需要马上下载代码，但他们会关心一个判断：这个项目是否理解企业软件真正的难点。如果文章只讲“我们有 AI”“我们能替代谁”，信任很难建立；如果文章能持续讲清楚流程、权限、租户、审计、连接器、插件、数据治理这些基础问题，读者会知道这是一个认真对待企业场景的项目。

对一个早期开源项目来说，内容不是包装，而是产品建设的一部分。

文章把判断公开，代码把判断落地，数据再反过来验证哪些判断被读者关心。这三件事循环起来，项目才会逐步形成自己的方向感。

从最近公众号数据看，读者确实更愿意阅读带有明确建设逻辑的文章。下一阶段我会更系统地把项目开发、架构设计和企业数字化问题结合起来写，而不是把文章做成单纯的功能发布说明。