业务故事站
跨产品

FDE 前沿部署工程师:把五产品装进客户现场

对标 Palantir 的 FDE 角色,本项目主打"轻交付":隔离内网里一次进场把五产品装好、把客户数据变成平台对象、教业务骨干自己查数,然后撤场。看完这 5 个故事,你就知道 FDE 的"最后一公里"是怎么从驻场半年压缩到一周的。

FDE 前沿部署工程师 客户现场 IT 客户业务骨干 隔离内网 声明式交付 培训交接 共 5 个故事

能 / 不能速览

✅ 这套交付流程能做
  • 隔离内网 / 信创离线环境一次进场装五产品:AIP(18080)/ Foundry(18081)/ Apollo(18082)/ Gotham(18083)/ Swift(18084)
  • Apollo 用 Spoke Agent 出向拉取式部署,控制平面永不反向连入客户环境,天然过安全评审
  • Foundry 数据源接入 + 元数据导入 + 本体 / 指标 / YAML 定制,把客户业务词汇变成平台对象
  • Gotham 多源融合 + 实体解析落地;Swift 授权自检到期自动优雅关停本产品
  • 上线后漂移检测收敛、失败自动回滚、/ops 健康页巡检、授权关停倒计时预警
  • 培训 + 交接文档 + 轻交付撤场:业务骨干自己查数、看报表、管权限
⛔ 这套交付流程做不了
  • Git 仓库是本地目录模拟,真实 GitHub / GitLab / Gitea 对接规划中;同步需手动 / Webhook / cron 触发
  • 演示 Poller 只拉取 / 上报,不真实拉起进程(ProcManager 未挂载时仅巡检)
  • 跨产品语义层未打通:Foundry 建的对象不会自动同步给 AIP,两边演示数据各自独立
  • 告警推送属 V2:漂移 / 授权事件只落库 + 审计,主动通知要等后续版本
  • Swift 为仿真域 PoC(模拟数据非真实在轨),不能进入任何真实投产承诺
  • 重人工驻场模式不在本项目定位内:复杂场景靠远程支持 + 迭代交付,不做半年常驻

适用角色

本主题按"一次客户交付"的参与方切分视角,四类人分别对应进场、定制、运维、交接四段工作:

  • FDE 前沿部署工程师:进场部署五产品、接入客户数据、定制本体、培训交接——交付全程的操盘手,也是本主题的主角。
  • 客户现场 IT:配合拷包进场、开网段、登记仓库、跑备份恢复,是部署落地的把关人。
  • 客户业务骨干:确认指标口径、学习查数 / 报表 / 权限管理,是撤场后的日常使用者。
  • 客户情报 / 结算人员:在 Gotham 与 Swift 上的具体业务用户,参与现场定制与验证。

每个故事都可单独阅读,建议按顺序看一遍建立"进场 → 定制 → 现场 → 运维 → 交接"的完整交付观。

能力速览(FDE 交付五板斧)

声明式进场

期望状态 YAML 放进本地 Git 目录,登记同步目标即落库,Spoke 出向拉取对齐;五产品 bat 脚本一键启动,端口互不冲突。

语义定制

Foundry 数据源接入 + 导入元数据 + 建本体,YAML 导入导出让对象定义可评审、可迁移;指标口径、同义词、PII 标记钉在属性上。

现场专属

Gotham 多源融合 + 实体解析把散名单汇成图;Swift 仿真流水线 + 授权自检,星地场景可演示、可验收。

运维自愈

漂移检测 / reconcile / auto_fix、失败自动回滚、/ops 健康页巡检、授权到期优雅关停,异常可发现、可收敛、可回退。

轻交付撤场

培训业务骨干自助查数 / 看报表 / 管权限,交接文档 + 制品清单后撤场;与 Palantir 重人工驻场形成对比,产品驱动增长。

调整指南(怎么调整)

  • 改部署方式:被管环境零入向端口就加 Spoke Agent 出向拉取;想自动收敛把同步目标 drift_policy 设为 auto_fix;演示要真实进程就挂 ProcManager。
  • 改数据接入:Excel / 旧库先落成 CSV 再建源;导入元数据前先按 table_schema_id 清理旧列,防残留表名误导 RAG。
  • 改本体口径:给 region 加同义词提升语义检索命中;给敏感字段打 PII 标记联动列级安全;指标口径争议到指标管理查定义。
  • 改进场脚本:.bat 必须 CRLF + GBK 编码中文;SQLite 目录先 ensureDir;端口被占改 cfg.Server.Port。
  • 改交接节奏:先培训查数与看报表,再交权限管理;交接文档列清楚"哪个产品 / 哪个账号 / 哪些边界"。

做得好的场景

FDE 交付最擅长"把产品装进隔离环境、把数据变成业务语言、把日常交给客户自己":
  • 信创 / 离线进场:单机二进制 + 本地 Git 目录 + 出向 Spoke,物理隔离也能完成部署与持续对齐。
  • 快速语义化:客户五花八门的数据十几分钟变成平台对象,替代以前 3~7 天的建模排期。
  • 运维可交代:漂移、回滚、健康页、授权关停倒计时都是"落库 + 留痕",安全合规有证据。
  • 轻交付闭环:一套 YAML + GitOps 一周交付、两周培训,撤场后客户自运转,与 Palantir 数月驻场形成对比。

限制与不足

以下是明确的边界,交付承诺前先知道:
  • Git 仓库为本地目录模拟:真实托管平台 clone / push 属规划中;轮询自动同步未接线,需手动 / Webhook / cron 触发。
  • 演示 Poller 不真实部署:Apollo 演示 Agent 只拉取 / 上报,真正拉起进程需挂载 ProcManager。
  • 语义层未打通:Foundry 对象 / 指标不会自动同步到 AIP,跨产品联动是设计契约但尚未落地。
  • 告警缺位:漂移 / 授权事件只落库 + 审计,主动告警推送属 V2,异常要靠人进 /ops 或各页面发现。
  • Swift 为仿真域:模拟数据非真实在轨,任何"真实投产"承诺都不可作出。

场景故事

故事 1 隔离内网进场:五产品一周装完,控制面零入向端口
背景
FDE 阿凯第一次进场。客户机房是三区隔离内网,只能出、不能进,信创评审要求"控制平面不得向被管环境建立任何入向连接",还明确没有外网。他要在一周内把 AIP(18080)、Foundry(18081)、Apollo(18082)、Gotham(18083)、Swift(18084)五产品装进客户现场,并让 Apollo 用出向拉取方式把应用部署到隔离网段。
传统做法对比
对标 Palantir 的重驻场模式:一个 FDE 常驻客户现场 6~12 个月,逐台服务器手工拷包、写脚本、改配置,光安全评审就来回拉扯几周;现在五产品是单机二进制,期望状态写成 YAML 放进本地 Git 目录,登记同步目标即可交付,隔离网段靠 Spoke 出向拉取,一周装完。
角色
阿凯(FDE 前沿部署工程师,负责进场部署与配置);唐工(客户现场 IT,负责拷包进场、网段与端口协调)。
操作步骤
  1. 经审批把五产品二进制与启动脚本拷包进场(ISO / U 盘,无外网)
  2. 按端口规划启动服务:AIP=18080、Foundry=18081、Apollo=18082、Gotham=18083、Swift=18084,确认日志"listening"
  3. Apollo 登记本地目录模拟的 Git 仓库与 auto 同步目标,把期望状态 YAML 落库并激活
  4. 在隔离网段目标机放 Spoke Agent(AgentName=prod-zone3-node01),出向拉取期望状态
  5. 打开各产品 /ops 运维健康页,确认四服务健康卡全部 OK
系统响应
Spoke 拉取端点返回期望状态与校验摘要:
GET /api/v1/agent/pull?agent=prod-zone3-node01
{ "desired_state": { "app": "demo-app", "version": "1.0.0",
  "components": [ {"name":"web","depends_on":["db"]}, {"name":"db"} ] },
  "bundle_digest": "sm3:...", "has_update": true }
同步历史返回 trigger_type=manual、status=success,期望状态徽章变为"已激活"。
结果洞察
三区一台入向端口都不开,Agent 自己出向拉取、自行校验后应用——这是信创离线场景的根本解法。五产品端口互不冲突、bat 一键启动,客户现场 IT 唐工两天就能独立启停。核心认知:Apollo 是控制面,演示 Poller 只拉取 / 上报,真要拉起进程需挂载 ProcManager,讲清楚这一点交付就不会被误导。
调整建议
轮询周期按业务紧迫度调(演示 60s,生产可加大);Agent 名按"环境-角色-序号"命名便于 /agents 视图区分;启动脚本必须 CRLF + GBK 编码中文,否则 cmd 解析错乱。相关阅读:GitOps 入门Spoke Agent
动手试一试
登录:Apollo http://127.0.0.1:18082(admin / admin1)。操作:登记一个本地目录 Git 仓库,创建 auto 同步目标并手动同步;再在 Agent 页启动一个 Poller(AgentName=prod-zone3-node01)。预期结果:期望状态变 active,/agents 出现该节点且 status=online。
限制提示
Git 仓库为本地目录模拟(真实 GitHub/GitLab/Gitee 对接规划中);fsnotify 轮询自动同步未接线,需手动 / Webhook / cron 触发;演示 Poller 未挂 ProcManager 时不真实部署进程;gRPC / mTLS 属设计,当前为 HTTP + 轮询。
故事 2 客户数据五花八门:Excel、旧库两天变成本体与指标
背景
进场第二天,阿凯面对客户的真实数据:销售明细在 Excel 里、客户主数据在旧 Oracle 库里、渠道字典是 CSV。业务骨干林经理的诉求很简单:"让业务同事以后能自己查'客单价',别再来找 IT。"阿凯要用 Foundry 把客户的业务词汇变成平台对象和指标。
传统做法对比
以前要数据团队出建模文档、画 ER 图、排接口排期 3~7 天,口径还常对不上;现在数据源接入 + 导入元数据 + 建本体,两天内对象、指标、口径全部落地,YAML 导出进 Git 评审,跨环境可迁移。
角色
阿凯(FDE,数据源接入与本体建模);林经理(客户业务骨干,确认"客单价""大区"等口径叫法)。
操作步骤
  1. 把 Excel / 旧库数据落成 CSV,经 Foundry 数据源页注册连接并导入元数据(或复用 AIP 的 /datasources 体系)
  2. 导入前先清理旧 columns / tables,防止残留表名误导 RAG 与查询
  3. 本体工作台建 customer / order / product 对象,映射属性、配主键与约束
  4. 定义 sales 实体与 total_gmv / aov 指标,让"客单价"有明确口径
  5. 导出对象 YAML 进本地 Git 仓库,评审后导入,形成"本体即代码"
系统响应
对象创建与指标查询返回:
POST /api/v1/ontology/objects
{ "api_name": "order", "base_table": "orders",
  "pk_column": "order_id", "version": 1 }

POST /api/v1/metrics/query   {"name":"total_gmv"}
{ "rows": [[6470.5]], "metric": { "name": "total_gmv",
  "formula": "SUM(amount)", "dimensions": ["created_at"] } }
语义检索输入"客单价"能命中 metric aov。
结果洞察
两天时间,客户的业务词汇变成平台对象:region 加了同义词"区域,大区",name 打了 PII 标记自动联动列级安全,total_gmv / aov 口径钉在指标定义上。林经理的诉求达成——业务同事在对象查询里自助取数,不再依赖 IT 手工导出。
调整建议
给属性加同义词提升语义检索命中率;给敏感字段打 PII 标记;对象定义走 YAML 版本管理,改口径先评审再合入。相关阅读:Foundry 入门本体建模YAML 导入导出
动手试一试
登录:Foundry http://127.0.0.1:18081(admin / admin1)。操作:数据源页确认 foundry_demo_warehouse 已导入元数据;本体工作台新建一个对象,指标管理看 total_gmv。预期结果:对象创建 version 1,指标查询返回 6470.5。
限制提示
Foundry 建的对象不会自动同步给 AIP——跨产品语义层当前未打通,两边演示数据各自独立;跨数据源管道未实现(单数据源 SQL 步骤);XLSX 上传暂以明确报错降级。
故事 3 情报 / 星地现场:Gotham 多源归一,Swift 授权自检
背景
这次客户是两家单位:一家要情报研判,一家要看星地结算仿真。阿凯在 Gotham 上把几份 CSV / JSON 名单接入、跑实体解析把"同一个人在不同源里的记录"归并成图上单点;又在 Swift 上完成部署,并给客户演示"授权到期自动优雅关停"——五产品装进现场之后,两个专属场景都能现场验证。
传统做法对比
以前情报名单靠手工录入 Excel、逐条比对同名记录,一份 3000 行名单折腾大半天;授权到期全靠人工盯日历,忘了续期服务就裸奔或崩溃。现在多源融合 + 实体解析自动消解,Swift 授权周期自检、到期优雅关停本产品,不影响其它产品。
角色
阿凯(FDE,配置数据源与解析作业、Swift 部署);周警官(客户情报分析员,消费融合实体与解析结果);小沙(客户结算值班,看 Swift 授权自检)。
操作步骤
  1. Gotham 数据接入页新建 file_csv 源,配 mapping_config(node_type=person、id_field、property_fields)并运行导入
  2. 创建实体解析作业 res-persons(entity_type=person、source_ids 指定多源),运行并查看 clusters / pairs
  3. 人工审核阈值带 0.70~0.90 的待审对,确认合并落 EntityMergeLog
  4. Swift 部署完成后打开 /license/info,看机器码、有效期与关停档位
  5. 演示"授权不满足 → shutdown_scheduled=true → 到点优雅退出本产品"
系统响应
实体解析作业与授权自检返回:
GET /api/v1/resolution/jobs/:id/stats
{ "total_candidates": 8, "matched_pairs": 2,
  "auto_merged": 1, "clusters": 6 }

GET /api/v1/license/info
{ "authorized": false, "auth_key_set": false,
  "shutdown_scheduled": true,
  "shutdown_tier": "hard",
  "shutdown_deadline": 1760000000,
  "shutdown_reason": "授权未注册,请配置 AUTH_KEY" }
同名"吴刚"跨源自动合并为 graph:person:wugang。
结果洞察
Gotham 把散名单汇成统一实体池:≥0.90 自动合并、0.70~0.90 待审、<0.70 拒绝,每条解析都有 Layer + Reason 可解释依据。Swift 授权自检每 30 分钟在线校验一次,未注册档位 hard(约 20 分钟倒计时关停)、已过期宽限档位 grace(6h+随机),配好 AUTH_KEY 后 authorized=true、调度自动取消——"授权约束落地"现场看得见。
调整建议
实体解析的 AI 灰区(L4,0.35~0.85)默认关闭,需要时由管理员配置 LLM 网关;AUTH_KEY 建议写进 DB system_settings 或环境变量,别只放 config.yaml;给 Swift 配一个测试授权 key 演练续期闭环。相关阅读:多源融合实体解析Swift 架构
动手试一试
登录:Gotham http://127.0.0.1:18083、Swift http://127.0.0.1:18084(admin / admin1)。操作:新建 file_csv 源导入一份名单并跑 res-persons 作业;打开 Swift /license/info。预期结果:解析作业 stats 出现 matched_pairs ≥1;/license/info 展示 shutdown_scheduled 与倒计时。
限制提示
Swift 为仿真域 PoC,模拟数据非真实在轨,不得作任何真实投产承诺;fusion 只产候选不做合并,归并交给实体解析作业;数据库源走 connector 工厂 allow-list,默认仅放行 MYSQL / SQLSERVER / POSTGRESQL。
故事 4 上线后运维:漂移收敛、失败回滚、授权到期预警
背景
五产品上线第一周,阿凯和唐工轮流盯守。现场发生三件事:有同事手改了服务器配置产生漂移;一次发布组件就绪超时触发了自动回滚;Swift 授权快到期,/license/info 显示关停倒计时。阿凯要给唐工演示"漂移检测 → 收敛"、"失败自动回滚"和"授权到期预警"三条自愈链路。
传统做法对比
以前服务器配置被手改只能等"下次出事才发现",一次巡检 6 台机器 40 分钟;发布失败凌晨爬起来手工回滚,回滚还靠记忆;授权到期靠人盯日历。现在漂移检测秒级出 diff、reconcile 收敛、失败自动回滚、授权关停倒计时一目了然,运维从"人肉巡检"变成"看板处置"。
角色
阿凯(FDE,演示自愈链路并教运维);唐工(客户现场 IT,接管日常巡检与处置)。
操作步骤
  1. 对 demo-app 执行漂移检测,查看 JSON Patch diff(如 web 端口 8080 → 9090)
  2. 把 pid / restart_count 动态字段配进 ignore_paths,避免噪音误报
  3. 修正实际状态后执行 reconcile,确认 has_drift=false、部署回到 synced
  4. 演示失败发布:组件就绪超时触发自动回滚,看 deployment_records 的 kind=auto-rollback
  5. 打开 Swift /license/info,看 shutdown_scheduled 与关停倒计时,提前续期
系统响应
漂移检测与调和返回:
POST /api/v1/drift/check
{ "has_drift": true, "diff": [ { "op": "replace",
  "path": "/components/0/probes/readiness/url",
  "expected": "127.0.0.1:8080", "actual": "127.0.0.1:9090" } ] }

POST /api/v1/drift/1/reconcile
{ "has_drift": false, "reconciling": false }
自动回滚在部署策略 readiness_timeout_sec 超时后触发,生成 kind=auto-rollback 的新部署记录。
结果洞察
三条自愈链路各有兜底:漂移靠 diff + ignore_paths + reconcile(配 auto_fix 还能自动调和,但有 3 轮 / 5 分钟防循环上限);发布失败靠 auto_rollback 回上一稳定成功版本(防循环:自动回滚产生的版本不再触发自动回滚);授权到期靠 WatchPeriodic 每 30 分钟校验 + 调度器幂等评估,grace / hard 两档倒计时。异常全部落库 + 审计,唐工交接无压力。
调整建议
漂移忽略规则优先配 ignore_paths 而非直接改期望状态;发布窗口期用部署策略里的 auto_rollback 兜底;授权预警提前 2 周在管理端处理,别等到 hard 档倒计时。相关阅读:漂移检测回滚监控与告警
动手试一试
登录:Apollo http://127.0.0.1:18082(admin / admin1)。操作:对 demo-app 跑一次漂移检测(把 web 探针端口改成 9090)再调和。预期结果:diff 精确指向被改字段,调和后部署回到 synced;再发起一次部署触发就绪超时,观察 auto-rollback 记录。
限制提示
漂移 reconcile / auto_fix 只判定与记录,真正应用需 Spoke Agent 重拉取(演示 Poller 不自动应用);告警推送属 V2,事件只落库 + 审计,无主动通知;/metrics 与告警联动、Windows 服务注册属后续版本。
故事 5 培训交接与撤场:轻交付,产品驱动增长
背景
交付第四周,阿凯要撤场了。他的目标是把"查数、看报表、管权限"这三件日常完整交给客户:林经理在 AIP 用一句话查数、在 Foundry 看指标口径;周警官在 Gotham 出简报;唐工在 Apollo 管部署与授权。撤场之后,客户自己运转,阿凯只在远程支持群里待命。
传统做法对比
Palantir 的 FDE 常驻客户现场 6~12 个月,靠重人工定制撑起交付,成本高、依赖深;本项目的轻交付定位是"产品驱动增长":一套 YAML + GitOps 一周装完、两周培训,日常操作交给业务骨干,FDE 撤场后客户自运转,后续需求靠迭代交付而非常驻。
角色
阿凯(FDE,组织培训与交接);林经理(客户业务骨干,学习查数 / 报表 / 权限);唐工(客户现场 IT,接管运维);周警官 / 小沙(客户业务用户,验证专属场景)。
操作步骤
  1. 第一周培训:AIP 一句话查数 + 指标口径核对;Foundry 对象查询自助取数
  2. 第二周培训:Gotham 出简报;Apollo 看部署 / 漂移 / 回滚;权限与账号管理实操
  3. 整理交接文档:产品端口、默认账号、边界与限制清单、备份恢复脚本用法
  4. 用 actionctl 把核心对象定义导出归档,确认制品可迁移、可重建
  5. 撤场:远程支持群待命,客户日常操作全部自理
系统响应
培训现场用 actionctl 演示"本体即代码"的交接物:
actionctl login --base http://127.0.0.1:18081 \
  --username admin --password admin1
actionctl ont export order --format yaml -o order.yaml
{ "ok": true, "base": "http://127.0.0.1:18081",
  "username": "admin", "token": "<JWT>",
  "stored_to": "C:\\Users\\pan\\.actionctl" }
林经理在 AIP /chat 输入"查询本月各区域订单销售额"即出表格与图表。
结果洞察
撤场后的一周,林经理每天自己查数、看报表,唐工在 /ops 巡检、在 Apollo 看漂移与授权倒计时——没有任何一个问题需要阿凯进场。轻交付的量化对比:Palantir 式驻场半年起步、数百万美元成本;本项目一周交付 + 两周培训,客户按需订阅迭代能力,产品驱动增长。
调整建议
交接文档务必写清"哪些不能承诺"(Swift 仿真、告警缺位、语义层未打通);把常用问题沉淀成团队模板;给客户留一份可重建的 YAML 制品库,灾难恢复不用等厂商。相关阅读:角色视角限制综述迁移指南
动手试一试
场景:让业务骨干自己走一遍——AIP 一句话查数、Foundry 对象查询自助取数、Gotham 出一页简报、Apollo 看一次部署状态。预期结果:全程不需要 IT 或 FDE 介入,日常操作在 30 分钟内完成。
限制提示
撤场后复杂定制(新数据源建模、跨产品联动)仍需远程支持或迭代交付;各产品独立登录、用户库不互通,权限管理要在每个产品分别做;演示数据重启重建,生产接真实数据源需绕过 demo seed 逻辑。

常见问题

隔离内网没有外网,授权在线校验怎么做?

授权在线校验依赖授权服务器(https://zyinfo.pro:19999/auth),纯隔离环境需要运维把授权域名放进出口白名单,或按授权服务器部署方案内网化;校验失败走 grace 宽限档(6h+随机)不会立即关停,给运维留处理窗口。

Apollo 演示 Poller 到底会不会部署进程?

取决于是否配置 ProcManager。演示 Poller 未配置时只做"拉取 + 上报",不实际拉起进程;配置了进程管理(仅 process 运行时)后 Reconciler 才会按 start / stop / restart 真实管理子进程。交付演示环境前一定要跟客户讲清楚,避免误导。

Foundry 建的对象会自动出现在 AIP 里吗?

不会。当前两套演示数据各自独立(foundry_demo_warehouse 与 aip_demo_warehouse),跨产品语义层联动(Foundry 对象 / 指标 → AIP)是设计契约但尚未落地。FDE 需要分别准备两边的元数据,交接文档里要写明这个边界。

FDE 撤场后客户出问题找谁?

轻交付模式下,日常操作(查数、看报表、部署巡检、授权续期)由客户自理;复杂问题走远程支持群或迭代交付单。交接文档 + YAML 制品库 + 可重建脚本就是"自我服务"的底子,客户不是离开厂商就黑屏。

五个产品端口会不会冲突?

不会。端口分工固定:AIP=18080、Foundry=18081、Apollo=18082、Gotham=18083、Swift=18084、Web 网关=80。被占时改对应 cfg.Server.Port(8080 常被系统 httpd.exe 占用,勿用)。

主题小结

一句话:FDE 前沿部署工程师 = 一次进场装五产品(声明式 + 出向 Spoke)+ 把客户数据变成平台对象(数据源 / 本体 / 指标 / YAML)+ 现场验证专属场景(Gotham 解析 / Swift 授权自检)+ 上线运维自愈(漂移 / 回滚 / 健康页 / 授权预警)+ 培训交接撤场。记住边界:本地 Git 目录模拟、演示 Poller 不真实部署、语义层未打通、告警属 V2、Swift 为仿真域。