# FDE 是传统运维产品厂商的出路吗？ 很多传统运维产品厂商，已经不缺产品了。 从 ITSM、CMDB、监控、自动化，到 IAM、数据中心管理和各类大屏，一个成熟厂商往往都能拿出一张很完整的产品地图。销售材料上看，客户运维部门的日常工作几乎都被覆盖了。 但项目一落地，味道就变了。 产品越多，集成越重；模块越全，边界越模糊；客户越大，定制越深。到了后期，项目成功本身也会变成麻烦：现场改出来的东西回不到主干，配置越来越像黑箱，谁都不敢轻易升级。 这不只是产品经理或实施团队的问题。很多时候，是产品能力本身把厂商拖住了。 所以今天想讨论的问题是： > FDE 会不会是传统运维产品厂商的一条出路？ 这里说的 FDE，比普通驻场工程师更进一步。它更接近 Palantir 那种 Forward Deployed Engineer：深入客户现场，既懂业务，又懂产品和工程，把现场复杂性反向沉淀成可复用的平台能力。 ## 一、产品线越全，为什么交付反而越重？ 传统运维产品通常按模块生长。 ITSM 管流程，CMDB 管资产，监控管指标，日志管检索。链路管调用关系，自动化管脚本，IAM 管账号权限。数据中心管理管空间和容量，大屏负责展示。 这些模块单独看都合理。问题是，客户真正要解决的通常不是单模块问题。 比如一个核心业务系统连续告警，现场真正关心的是： ```text 告警出现 → 判断影响哪个业务 → 查最近有没有变更 → 找到关联主机、容器、数据库、中间件 → 判断责任团队和当前值班人 → 匹配历史故障和处置经验 → 决定是否创建工单 → 判断是否可以扩容、重启、切流、回滚 → 执行后写回工单、告警、CMDB 和审计 ``` 这个过程同时涉及监控、CMDB、ITSM、自动化、IAM、变更、知识库和审计。 模块之间如果只是并列存在，实施团队就只能在现场接接口、配规则、写脚本、改流程、做大屏、补字段。 管理层真正需要关心的，已经不只是“这个项目能不能验收”。更麻烦的问题是：每一个大客户是不是都在重新消耗一次交付能力？ 如果答案是肯定的，产品线越全，厂商反而越累。 ## 二、“内置最佳实践”为什么挡不住现场定制？ 很多厂商都说自己“内置最佳实践”，但项目现场又免不了大量定制。 这两件事不一定冲突，关键在颗粒度。 小颗粒度的最佳实践，本来就应该沉淀在产品底座里。比如字段校验、权限控制、审计记录、告警抑制、脚本参数校验、工单状态流转。客户不应该为这些东西一遍遍付实施费。 但大颗粒度的最佳实践更像方法论，比如集团级变更治理、金融核心系统故障处置、数据中心容量运营、跨部门事件指挥。它不可能开箱即用，必须结合客户的组织结构、系统边界、风险偏好和历史包袱做适配。 所以别再争“最佳实践有没有价值”。更该问的是：厂商能不能把大颗粒度方法论，翻译成小颗粒度、可执行、可复用、可审计的产品资产。 这也是客户、实施、产品、研发经常互相不理解的根源。 客户觉得厂商不懂业务。实施觉得研发不接地气。研发觉得现场需求不可复用。产品觉得每个客户都在破坏标准化。 这背后不是态度问题，而是机制问题。 ## 三、Palantir 值得借鉴的是复利机制 Palantir 的公开材料里，把 AIP、Foundry、Apollo 组合称为一种 Enterprise Operating System。 这几个名字可以先放一边。对传统运维产品厂商来说，更值得看的是它背后的复利机制。 简单说： * Foundry 负责数据集成、治理、管道和计算。 * Ontology 把数据映射成业务对象、关系、动作和权限。 * AIP 让 AI、Agent、应用和自动化在这个业务世界里工作。 * Apollo 负责持续交付、部署、升级和运行管理。 这套结构最有价值的地方，是把客户现场的差异沉淀为平台资产。 Ontology 可以理解为一套企业运营模型。它比知识图谱更靠近业务执行，也比传统 CMDB 覆盖面更大。 * 对象：运维里的实体，例如应用、主机、工单、告警。 * 关系：这些实体之间的依赖、归属和影响。 * 动作：派单、审批、变更、重启、回滚等可控操作。 * 治理：权限、规则、审计和版本追踪。 运维系统不能只回答“发生了什么”。它还要回答：影响什么？谁负责？能不能动？谁批准？怎么执行？失败怎么回退？做完如何留痕？ 这正是传统运维产品厂商缺的一层。 这里说的运维运行底座，不等于把所有产品塞进一个门户。重点是让这些产品围绕同一批对象、关系、动作、权限和审计工作。 ## 四、FDE 解决的是产品复利问题 FDE 经常被误解成高级驻场工程师。 如果只是派技术人员到客户现场写代码、改配置、接接口，那不叫 FDE，只是更贵的驻场外包。 FDE 真正要解决的是一个断层： ```text 客户现场的复杂业务 与 产品主干的可复用能力 之间的断层 ``` 传统实施团队离客户近，但离产品主干远。产品研发团队懂产品，但离现场远。售前知道方案，但通常不负责长期落地。客户成功知道关系，但不一定能做工程判断。 FDE 要同时具备三种能力：懂客户现场，懂产品底座，也懂工程实现。 更具体一点，他要知道哪些做法可以直接复用，哪些需要参数化，哪些必须结合客户组织和系统环境重新裁剪。 对传统运维产品厂商来说，FDE 的产出不应该只是项目交付物，而应该是一批可复用资产： * 客户流程差异，变成标准流程扩展点。 * CMDB 差异，变成对象模型和关系模型。 * 脚本需求，变成受控 Action。 * 告警配置，变成场景模板。 * 大屏需求，变成可复用视图。 * 项目经验，回到行业包和产品能力里。 FDE 的价值不止是“帮客户把活干完”。更重要的是，把客户现场的复杂性转化为产品进化能力。 ## 五、平台要从现场长出来 讲到这里，很容易产生一个问题：这不就是平台化、中台化吗？ 某种意义上，是。 Palantir 的演进过程，可以理解为一个平台/中台不断成长的过程。FDE 在客户现场解决真实问题，Foundry、Ontology、Apollo 把这些问题里可复用的部分沉淀为数据、语义、行动、治理和交付能力。 关键差异在于：Palantir 的平台并不是先在总部规划出来，再要求所有项目服从。它更像是在大量前线交付中长出来的。 传统平台化常见路径是： ```text 先规划统一平台 / 中台 → 定义通用能力 → 推给各项目使用 → 现场发现不适配 → 继续定制和打补丁 ``` 更健康的路径应该是： ```text 前线项目 → FDE 解决真实问题 → 抽象共性对象、Action、流程、权限和视图 → 沉淀为平台能力、产品包和行业模板 → 后续项目复用 → 新复杂性继续反哺平台 ``` 所以，FDE 和平台/中台要放在一起看。 平台/中台是能力沉淀的载体，FDE 是把现场复杂性转化为平台能力的人和机制。 没有平台，FDE 容易变成高端驻场外包：现场解决了很多问题，但沉淀不下来。没有 FDE，平台容易变成空中楼阁：功能很多，但不知道如何贴合客户真实运营。 平台当然重要。但平台能力必须从真实闭环里长出来。否则所谓中台，很容易变成统一门户、统一菜单、统一配置中心，表面完整，现场照样大量定制。 ## 六、如果这条路成立，现有产品线会被重新切分 如果传统运维产品厂商真的走向 FDE + Ontology 的模式，影响最大的不会是多一个 AI 助手。更大的变化会发生在产品生态内部。 过去产品边界按功能划分：监控是监控，ITSM 是 ITSM，CMDB 是 CMDB，自动化是自动化。 未来边界会更多围绕操作闭环。 客户不太关心这个能力属于哪个模块。他关心的是：异常能不能发现，根因能不能定位，影响能不能判断。再往后，是动作能不能安全执行，结果能不能复盘，经验能不能沉淀到下一次。 这会带来几个变化。 第一，有些产品会从独立产品变成底座能力。 CMDB 是最典型的例子。过去 CMDB 可以作为独立产品售卖：资产录入、字段扩展、关系维护、查询报表。 如果厂商建立了统一对象层，CMDB 的角色会变化。告警依赖它，工单依赖它，自动化依赖它，权限和审计也依赖它。 CMDB 不会消失，但形态会变化。它的重要性不再来自页面多少，而是来自全系统对资产、服务、责任和影响范围的共同理解。 第二，有些产品会被拆成 Action、Workflow 和 View。 ITSM、告警、自动化之间的边界会变模糊。 过去的链路是： ```text 监控发现告警 → 告警平台通知 → ITSM 创建工单 → 人工判断 → 自动化平台执行脚本 → 人工回填结果 ``` 更合理的链路应该是： ```text 事件对象触发 → 关联业务系统、拓扑、资产、责任人、近期变更 → 形成候选根因和影响范围 → 匹配处置 Action → 根据风险等级决定自动执行还是人工审批 → 执行后写回工单、告警、CMDB 和审计 ``` 这时，ITSM 会从流程表单变成动作链的一部分。告警也不只是通知系统，自动化也不只是脚本执行器。 它们会被拆成 Action、Workflow、Policy 和 View。也就是动作、编排、策略和视图。 第三，有些产品形态会慢慢失去意义。 一次性定制大屏会被冲击。大屏还会存在，但应该是对象和指标上的视图，而不是每个项目手工拼一套页面。 孤立报表会被冲击。报表还会存在，但大量项目级 SQL 报表，会被语义查询、指标对象和可复用分析模板替代。 脚本市场式自动化也会被冲击。脚本还会存在，但不应该直接暴露给人随便执行。更合理的方式，是把脚本包装成带参数校验、权限控制、审批、回滚和审计的 Action。 这比“做一个 AI 助手”难得多，也更接近产品战略问题。 ## 七、大模型让 Action 资产变得更值钱 传统运维产品厂商讨论 AI 时，很容易停在问答、摘要、告警压缩、知识库检索。 这些有用，但还不够。 运维场景里，AI 真正有想象力的地方，是改写传统自动化的演进路径。 过去，运维自动化大多沿着一条很清晰的路线走： ```text 手工操作 → 写成 SOP → 固化为脚本 → 编排成自动化动作 → 串成流水线 ``` 这条路线要求人先把故障模式理解清楚，再把处理步骤标准化，最后才能自动化。所以传统自动化擅长处理“已知问题”：磁盘满了清理目录，进程挂了重启服务，副本不足自动扩容，证书过期提前通知。 但真实运维里的大量问题，并不是一开始就这么清楚。 告警可能是多个系统共同作用的结果，根因可能和近期变更、容量趋势、依赖服务、历史故障、网络抖动都有关系。人要先观察、关联、判断，再决定执行哪个动作。 大模型可能改变的，正是这一步。 当平台已经有一批可靠的原子性 Action，大模型不一定要等人把整条流水线提前写好。 它可以在运行时完成感知、决策和意图编排：理解上下文，评估证据和风险，选择 Action，填写参数，申请执行，再观察结果。 传统流水线是“人提前把路径编好”。大模型参与后的平台，更像是在受控边界内动态选择下一步。 SOP 和自动化仍然重要。变化在于，自动化会从静态流水线推进到可演进的 Action 网络。 不过有一条底线：AI 不能直接操作生产系统。 AI 可以提出意图、选择候选动作、填写参数，但真正执行必须由 Action 平台完成。Action 平台要负责权限、审批、审计、回滚和补偿。 也就是说，FDE 沉淀下来的 Action 资产，会因为大模型变得更值钱。 没有这些 Action，大模型只能建议。 有了这些 Action，大模型才可能进入受控执行链。 ## 八、传统运维厂商可以怎么试？ 既然平台能力要从真实闭环里长出来，转型就不能从一张大而全的中台蓝图开始。 更现实的路径，是从一个高价值闭环开始，把大颗粒度方法论拆成一组小颗粒度资产，再逐步沉淀回产品底座。 第一步，选一个跨模块闭环。 不要先选一个模块。可以从告警到工单到自动化处置开始，也可以从重大故障指挥调度、变更风险评估、资产漏洞处置切入。 标准很简单：这个场景必须跨越至少三个模块，并且能形成“发现问题 → 判断影响 → 执行动作 → 留痕复盘”的闭环。 第二步，建立最小对象关系图。 不要试图一次重建完整 CMDB。先围绕一个闭环建立最小对象关系： ```text 业务系统 → 依赖 → 应用 → 部署于 → 主机 / 容器 / 集群 → 负责于 → 团队 / 人员 → 产生 → 告警 → 关联 → 工单 / 变更 / 事件 → 可执行 → 自动化动作 ``` 关键不是对象多，而是能回答几个问题：这个告警影响哪个业务，责任人是谁，最近有没有变更，是否允许自动处置，执行后写回哪里。 第三步，把脚本升级成 Action。 传统自动化平台关注脚本能不能执行。 Action 平台关注的是这个动作能不能被安全执行：谁发起，参数是否合法，当前状态是否允许，是否需要审批。它还要记录影响范围、写回结果和失败补偿。 只有把脚本包装成 Action，AI 才有可能安全参与运维处置。 第四步，把项目经验做成产品包。 每个项目结束时，不应该只留下验收文档和现场配置。至少要沉淀三类资产：行业对象模型、场景 Action 模板、操作视图模板。 这些资产越多，后续项目越轻，FDE 的价值才会从人力交付转向产品复利。 第五步，重构组织考核。 如果仍然只按项目验收、交付人天、回款节点考核，FDE 很容易退化成驻场外包。 新的考核要看几件事：多少现场需求沉淀为标准能力，多少客户配置进入版本管理，多少脚本变成可治理 Action，多少行业模型被后续客户复用。 FDE 模式能不能成立，取决于公司是否真的奖励“把现场经验产品化”。 ## 九、FDE 是出路，但不是所有厂商的出路 FDE 对传统运维产品厂商有吸引力，但它不是万能药。 如果客户只需要标准监控工具，不需要复杂定制，FDE 没必要。产品高度标准化、客户流程很轻时，FDE 反而会拉高成本。 如果公司没有产品化底座，FDE 会沦为驻场外包。如果客户采购目标只是“买交付物”，不是“建能力”，FDE 也很难发挥作用。 真正适合走这条路的厂商，通常有几个特征。 产品线已经较完整，但模块协同成本高。客户多为中大型企业、集团、金融、能源、制造、运营商、政企。项目中存在大量流程、资产、接口、告警、大屏、自动化定制。客户现场差异大，但差异背后有行业共性。 还有一个前提：公司愿意把交付经验产品化，而不是只按人天收费。 所以，FDE 是出路，但前提是厂商愿意从“卖模块”转向“经营运维运行底座”。 ## 十、结语：FDE 是把交付变成复利的机制 过去，传统运维产品厂商卖的是工具。 后来，卖的是平台。 下一阶段，真正有竞争力的厂商，卖的可能是一套持续适配客户运维体系的能力。 在这套系统里，CMDB 是统一对象层。监控提供事件和状态输入。ITSM 承接受控动作链。 自动化变成可治理 Action。大屏也从展示工程变成对象视图。 AI 也会从问答助手继续往前走，进入受控执行链，参与诊断、建议、申请执行和效果反馈。 我倾向于认为，FDE 不是传统运维产品厂商的万能药。但如果一家厂商已经被重交付、重定制、重集成拖住，它至少应该认真研究这条路。 因为继续堆产品模块，解决不了这个问题。简单加一个 AI 助手，也解决不了。 真正值得做的，是让每一次定制、每一次交付、每一次故障处置，都能沉淀、复用、升级，并最终反哺产品。 如果做不到，FDE 只是更贵的实施。 如果做得到，它可能会把传统运维产品厂商从项目泥潭里拉出来，开始真正积累产品复利。