企业为什么需要一个开源版 ServiceNow

云与数字化 | 开源 ITSM AI日志

企业不是不需要 ServiceNow 这样的产品。

而是需要一个更开放、更可控、更贴近本土流程的版本。

昨天发了《我为什么要做一个开源 ITSM 项目》。

阅读量不算大，但分享率很高。更重要的是，已经有人开始问一些很具体的问题：

有没有 APM 监控？

有没有 Prometheus、SkyWalking、Jaeger、ELK？

有没有 CI/CD、镜像仓库、Harbor 这类能力？

如果只是工单，那和普通 ITSM 有什么区别？

这些问题问得很准。

因为真正的企业级 ITSM，从来不只是工单系统。

如果只做工单，确实没有必要重新做一遍。

我想做的，是一个面向中国企业的开源版 ServiceNow。

不是简单复刻 ServiceNow 的界面，也不是照搬一套国外流程。

而是重新思考：在中国企业的数字化现场，什么样的平台能把流程、系统、资产、知识、协同工具和 AI 真正连接起来。

01

ServiceNow 的价值，不是工单，而是平台

谈 ITSM，绕不开 ServiceNow。

很多人对它的第一印象，是一个很强大的工单系统。

但如果只把它理解成工单系统，就低估了它真正的价值。

ServiceNow 厉害的地方，不是让企业多了一张工单表。

而是它把 IT 服务管理做成了一个平台：

有流程：事件、问题、变更、请求、审批、发布、复盘。

有数据模型：CMDB、服务目录、组织、角色、资产、配置项。

有自动化：规则、通知、升级、分派、脚本、工作流。

有集成能力：能和监控、日志、身份、开发、财务、人力系统连接。

有生态：应用、插件、连接器、合作伙伴和实施方法论。

所以它真正解决的问题，不是“怎么记录一个工单”。

而是企业怎么把碎片化的服务过程，变成可管理、可度量、可优化、可自动化的平台能力。

这件事，中国企业同样需要。

甚至更需要。

02

中国企业的现实，不适合只买一个封闭系统

国内企业的数字化现场，很复杂。

一个企业里可能同时存在 OA、ERP、CRM、WMS、MES、财务系统、监控系统、日志系统、低代码平台、飞书、企业微信、钉钉、内部自研系统。

这些系统往往不是同一年建设的，也不是同一个厂商交付的。

很多流程也不是标准教科书流程。

比如一个权限申请，可能先在飞书里沟通，再走 OA 审批，再由 IT 手工开通，再到微信群里反馈。

一个业务故障，可能先从 Prometheus 告警开始，然后查日志、看链路、找变更记录、问业务影响，最后才进入工单系统。

一个系统上线，可能涉及 GitLab、Jenkins、Harbor、Kubernetes、数据库变更、灰度发布、回滚预案和业务验收。

中国企业真正需要的，不是一个孤立的新系统。

而是一个能接入本地系统、适配内部流程、支持私有化和二次开发的平台。

这也是为什么我认为，开源很重要。

开源不是为了“免费”。

开源的核心价值，是让企业有机会看见系统怎么工作，有机会按自己的业务改造，有机会把自己的连接器、流程模板、行业经验沉淀进去。

03

开源版 ServiceNow，不是把所有功能都重做一遍

这里要说清楚一个边界。

我并不打算重新造一套 Prometheus。

也不打算重新造 SkyWalking、Jaeger、ELK、Harbor、Jenkins。

这些系统已经在各自领域做得很好。

问题在于，企业真正处理故障、变更和服务请求的时候，这些系统之间经常是断开的。

- Prometheus 能发现告警，但不知道业务影响；

- Jaeger 能看到链路，但不一定知道谁负责处理；

- ELK 能查日志，但日志不会自动变成复盘知识；

- Harbor 能管理镜像，但镜像发布和变更审批未必打通；

- Jenkins 能做流水线，但发布失败后的事件、回滚、复盘常常靠人工补；

- CMDB 有资产数据，但如果不进入故障和变更流程，就很难产生价值。

所以开源版 ServiceNow 的重点，不是替代所有工具。

重点是做连接器，把这些工具产生的事实，放进企业服务管理流程里。

告警应该进入事件管理。

链路和日志应该进入根因分析。

镜像和流水线应该进入变更和发布记录。

CMDB 应该进入影响分析。

故障处理过程应该进入知识库和复盘。

这才是企业级 ITSM 平台该做的事。

04

AI Native ITSM，不是给工单系统加一个聊天框

到了 AI 时代，很多系统都会说自己接入了 AI。

但如果只是给工单系统加一个聊天框，我认为意义不大。

企业里的 AI 真正要发挥作用，必须理解上下文。

什么上下文？

这个告警影响哪个业务服务？

这个服务依赖哪些应用、数据库、中间件和容器？

最近有没有变更？

历史上有没有类似故障？

知识库里有没有处理方案？

谁是负责人？谁有权限执行修复？

这个操作是否需要审批、审计和回滚？

这些信息，不在聊天框里。

它们分散在监控、日志、链路、CMDB、工单、知识库、代码仓库、流水线、协同工具里。

所以我理解的 AI Native ITSM，不是“AI 问答”。

而是让 AI 进入企业服务流程，基于真实上下文做判断、推荐、执行和复盘。

05

我准备怎么做

这个项目会分阶段推进。

第一阶段，先把 ITSM 主干打牢：工单、事件、问题、变更、SLA、CMDB、知识库、流程和权限。

第二阶段，做企业运行现场的连接器：Prometheus、Alertmanager、Grafana、SkyWalking、Jaeger、ELK/EFK、Harbor、GitLab/Jenkins、Kubernetes、飞书、企业微信、钉钉。

第三阶段，做 AI Native 能力：AI 分诊、影响分析、知识库 RAG、故障复盘、Runbook 推荐、连接器 Skill 市场。

第四阶段，面向企业和服务商做多租户、白标、私有化部署、插件市场和本地化交付。

我的判断很直接：

中国企业需要一个能自己掌控的企业服务管理底座。

它要能连接国内企业真实使用的系统。

它要能私有化、能扩展、能二次开发。

它还要从一开始就为 AI 进入企业流程做好准备。

这就是我说的，开源版 ServiceNow。

06

接下来我会继续写这几篇

这不是一篇文章能讲完的事。

后面我会继续把这个项目的产品逻辑和技术路线拆开写：

《CMDB 为什么难做？因为它不是一张资产表》

《AI Native ITSM 不是给工单系统加一个聊天框》

《连接器市场：企业 AI 落地绕不开的基础设施》

《企业数字化的深水区，其实是流程问题》

如果你也关注 ITSM、AIOps、CMDB、企业数字化、开源企业软件，欢迎继续关注这个系列。

项目地址：

https://github.com/heidsoft/itsm

我正在做一个开源 ITSM 项目，目标是对标 ServiceNow，构建面向国内企业的 AI Native ITSM 平台。

方向包括：ITIL v3、CMDB、流程引擎、连接器市场、插件市场、Skill 市场、企业 AI 自动化。