跨产品
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 + 客户现场 IT
耗时:约一周
- 背景
- FDE 阿凯第一次进场。客户机房是三区隔离内网,只能出、不能进,信创评审要求"控制平面不得向被管环境建立任何入向连接",还明确没有外网。他要在一周内把 AIP(18080)、Foundry(18081)、Apollo(18082)、Gotham(18083)、Swift(18084)五产品装进客户现场,并让 Apollo 用出向拉取方式把应用部署到隔离网段。
- 传统做法对比
- 对标 Palantir 的重驻场模式:一个 FDE 常驻客户现场 6~12 个月,逐台服务器手工拷包、写脚本、改配置,光安全评审就来回拉扯几周;现在五产品是单机二进制,期望状态写成 YAML 放进本地 Git 目录,登记同步目标即可交付,隔离网段靠 Spoke 出向拉取,一周装完。
- 角色
- 阿凯(FDE 前沿部署工程师,负责进场部署与配置);唐工(客户现场 IT,负责拷包进场、网段与端口协调)。
- 操作步骤
-
- 经审批把五产品二进制与启动脚本拷包进场(ISO / U 盘,无外网)
- 按端口规划启动服务:AIP=18080、Foundry=18081、Apollo=18082、Gotham=18083、Swift=18084,确认日志"listening"
- Apollo 登记本地目录模拟的 Git 仓库与 auto 同步目标,把期望状态 YAML 落库并激活
- 在隔离网段目标机放 Spoke Agent(AgentName=prod-zone3-node01),出向拉取期望状态
- 打开各产品 /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、旧库两天变成本体与指标
场景:数据接入与本体定制
角色:FDE + 客户业务骨干
耗时:约两天
- 背景
- 进场第二天,阿凯面对客户的真实数据:销售明细在 Excel 里、客户主数据在旧 Oracle 库里、渠道字典是 CSV。业务骨干林经理的诉求很简单:"让业务同事以后能自己查'客单价',别再来找 IT。"阿凯要用 Foundry 把客户的业务词汇变成平台对象和指标。
- 传统做法对比
- 以前要数据团队出建模文档、画 ER 图、排接口排期 3~7 天,口径还常对不上;现在数据源接入 + 导入元数据 + 建本体,两天内对象、指标、口径全部落地,YAML 导出进 Git 评审,跨环境可迁移。
- 角色
- 阿凯(FDE,数据源接入与本体建模);林经理(客户业务骨干,确认"客单价""大区"等口径叫法)。
- 操作步骤
-
- 把 Excel / 旧库数据落成 CSV,经 Foundry 数据源页注册连接并导入元数据(或复用 AIP 的 /datasources 体系)
- 导入前先清理旧 columns / tables,防止残留表名误导 RAG 与查询
- 本体工作台建 customer / order / product 对象,映射属性、配主键与约束
- 定义 sales 实体与 total_gmv / aov 指标,让"客单价"有明确口径
- 导出对象 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 授权自检
场景:现场定制
角色:FDE + 情报分析员 + 结算值班
耗时:约半天
- 背景
- 这次客户是两家单位:一家要情报研判,一家要看星地结算仿真。阿凯在 Gotham 上把几份 CSV / JSON 名单接入、跑实体解析把"同一个人在不同源里的记录"归并成图上单点;又在 Swift 上完成部署,并给客户演示"授权到期自动优雅关停"——五产品装进现场之后,两个专属场景都能现场验证。
- 传统做法对比
- 以前情报名单靠手工录入 Excel、逐条比对同名记录,一份 3000 行名单折腾大半天;授权到期全靠人工盯日历,忘了续期服务就裸奔或崩溃。现在多源融合 + 实体解析自动消解,Swift 授权周期自检、到期优雅关停本产品,不影响其它产品。
- 角色
- 阿凯(FDE,配置数据源与解析作业、Swift 部署);周警官(客户情报分析员,消费融合实体与解析结果);小沙(客户结算值班,看 Swift 授权自检)。
- 操作步骤
-
- Gotham 数据接入页新建 file_csv 源,配 mapping_config(node_type=person、id_field、property_fields)并运行导入
- 创建实体解析作业 res-persons(entity_type=person、source_ids 指定多源),运行并查看 clusters / pairs
- 人工审核阈值带 0.70~0.90 的待审对,确认合并落 EntityMergeLog
- Swift 部署完成后打开 /license/info,看机器码、有效期与关停档位
- 演示"授权不满足 → 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
上线后运维:漂移收敛、失败回滚、授权到期预警
场景:上线运维
角色:FDE + 客户现场 IT
耗时:连续一周盯守
- 背景
- 五产品上线第一周,阿凯和唐工轮流盯守。现场发生三件事:有同事手改了服务器配置产生漂移;一次发布组件就绪超时触发了自动回滚;Swift 授权快到期,/license/info 显示关停倒计时。阿凯要给唐工演示"漂移检测 → 收敛"、"失败自动回滚"和"授权到期预警"三条自愈链路。
- 传统做法对比
- 以前服务器配置被手改只能等"下次出事才发现",一次巡检 6 台机器 40 分钟;发布失败凌晨爬起来手工回滚,回滚还靠记忆;授权到期靠人盯日历。现在漂移检测秒级出 diff、reconcile 收敛、失败自动回滚、授权关停倒计时一目了然,运维从"人肉巡检"变成"看板处置"。
- 角色
- 阿凯(FDE,演示自愈链路并教运维);唐工(客户现场 IT,接管日常巡检与处置)。
- 操作步骤
-
- 对 demo-app 执行漂移检测,查看 JSON Patch diff(如 web 端口 8080 → 9090)
- 把 pid / restart_count 动态字段配进 ignore_paths,避免噪音误报
- 修正实际状态后执行 reconcile,确认 has_drift=false、部署回到 synced
- 演示失败发布:组件就绪超时触发自动回滚,看 deployment_records 的 kind=auto-rollback
- 打开 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
培训交接与撤场:轻交付,产品驱动增长
场景:培训交接
角色:FDE + 客户业务骨干
耗时:两周培训 + 撤场
- 背景
- 交付第四周,阿凯要撤场了。他的目标是把"查数、看报表、管权限"这三件日常完整交给客户:林经理在 AIP 用一句话查数、在 Foundry 看指标口径;周警官在 Gotham 出简报;唐工在 Apollo 管部署与授权。撤场之后,客户自己运转,阿凯只在远程支持群里待命。
- 传统做法对比
- Palantir 的 FDE 常驻客户现场 6~12 个月,靠重人工定制撑起交付,成本高、依赖深;本项目的轻交付定位是"产品驱动增长":一套 YAML + GitOps 一周装完、两周培训,日常操作交给业务骨干,FDE 撤场后客户自运转,后续需求靠迭代交付而非常驻。
- 角色
- 阿凯(FDE,组织培训与交接);林经理(客户业务骨干,学习查数 / 报表 / 权限);唐工(客户现场 IT,接管运维);周警官 / 小沙(客户业务用户,验证专属场景)。
- 操作步骤
-
- 第一周培训:AIP 一句话查数 + 指标口径核对;Foundry 对象查询自助取数
- 第二周培训:Gotham 出简报;Apollo 看部署 / 漂移 / 回滚;权限与账号管理实操
- 整理交接文档:产品端口、默认账号、边界与限制清单、备份恢复脚本用法
- 用 actionctl 把核心对象定义导出归档,确认制品可迁移、可重建
- 撤场:远程支持群待命,客户日常操作全部自理
- 系统响应
- 培训现场用 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 为仿真域。