跨产品
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 健康页巡检、授权关停倒计时预警
- Gotham 定时备份 cron 可在运维页直接改,配置持久在 DB、重启不丢(非法表达式 400 并回滚原配置)
- 培训 + 交接文档 + 轻交付撤场:业务骨干自己查数、看报表、管权限
⛔ 这套交付流程做不了
- Git 仓库是本地目录模拟,真实 GitHub / GitLab / Gitea 对接规划中;同步需手动 / Webhook / cron 触发
- 演示 Poller 只拉取 / 上报,不真实拉起进程(ProcManager 未挂载时仅巡检)
- 跨产品语义层未打通:Foundry 建的对象不会自动同步给 AIP,两边演示数据各自独立
- 告警只覆盖部署 / 配置侧:Apollo 有告警汇总 / 自愈 / 通知渠道,但漂移 / 授权事件仍以落库 + 审计为主,"业务指标 + 跨产品主动推送"要等后续版本
- Swift 为仿真域 PoC(模拟数据非真实在轨),不能进入任何真实投产承诺
- 重人工驻场模式不在本项目定位内:复杂场景靠远程支持 + 迭代交付,不做半年常驻
适用角色
本主题按"一次客户交付"的参与方切分视角,四类人分别对应进场、定制、运维、交接四段工作:
- FDE 前沿部署工程师:进场部署五产品、接入客户数据、定制本体、培训交接——交付全程的操盘手,也是本主题的主角。
- 客户现场 IT:配合拷包进场、开网段、登记仓库、跑备份恢复,是部署落地的把关人。
- 客户业务骨干:确认指标口径、学习查数 / 报表 / 权限管理,是撤场后的日常使用者。
- 客户情报 / 结算人员:在 Gotham 与 Swift 上的具体业务用户,参与现场定制与验证。
每个故事都可单独阅读,建议按顺序看一遍建立"进场 → 定制 → 现场 → 运维 → 交接"的完整交付观。
能力速览(FDE 交付五板斧)
声明式进场
期望状态 YAML 放进本地 Git 目录,登记同步目标即落库,Spoke 出向拉取对齐;五产品 bat 脚本一键启动,端口互不冲突。
语义定制
Foundry 数据源接入 + 导入元数据 + 建本体,YAML 导入导出让对象定义可评审、可迁移;指标口径、同义词、PII 标记钉在属性上。
现场专属
Gotham 多源融合 + 实体解析把散名单汇成图;Swift 仿真流水线 + 授权自检,星地场景可演示、可验收。
运维自愈
漂移检测 / reconcile / auto_fix、失败自动回滚、/ops 健康页巡检、授权到期优雅关停,异常可发现、可收敛、可回退;Gotham 定时备份 cron 页面可配、重启不丢。
轻交付撤场
培训业务骨干自助查数 / 看报表 / 管权限,交接文档 + 制品清单后撤场;与 Palantir 重人工驻场形成对比,产品驱动增长。
界面操作指引(不写代码怎么用)
下面按「打开哪个页面 → 点哪里 → 填什么 → 看到什么」的顺序把一次客户现场交付完整走一遍,业务用户照做即可。每步末尾的「API 等价」是给工程师对照用的,可以忽略。
1
进场:确认五产品在隔离内网都起来了
顶部导航「运维状态」(/ops)→ 服务健康卡
- 怎么做:拷包进场后按端口分别启动 AIP(18080)/ Foundry(18081)/ Apollo(18082)/ Gotham(18083)/ Swift(18084);登录任一产品后点顶部导航「运维状态」(/ops),看五张服务健康卡,点「立即检测」可手动刷新。
- 会看到:卡片状态徽章为「正常」;AIP 卡额外展开 database / vector / llm_gateway / disk_space 依赖级明细;某个产品没起来时对应卡片变红并给出失败原因。
API 等价:GET /health
2
声明式交付:把期望状态 YAML 交给 Apollo
Apollo 控制台(18082)→ Git 仓库 → 同步目标
- 怎么做:用 admin / admin1 登录 Apollo,把期望状态 YAML 放进本地 Git 目录;在「Git 仓库」(/apollo/git-repos)新建仓库(URL 填本地目录路径)→「测试连接」→ 在下方「同步目标」新建一条 auto 目标 → 点「同步」。
- 会看到:提示「同步目标 #id 同步成功:commit …」,期望状态徽章变「已激活」,并出现在「部署与漂移」页「发起部署」的期望状态下拉里。
API 等价:POST /api/v1/projects/1/git-repos、POST /api/v1/git-repos/:id/test-connection、POST /api/v1/projects/1/sync-targets、POST /api/v1/sync-targets/:id/sync
3
隔离网段:注册 Spoke Agent 出向拉取
Apollo「环境管理」→ 某环境「Agents」管理弹窗;Apollo「Spoke Agent」页
- 怎么做:在「环境管理」(/apollo/environments)对目标环境点「Agents」打开管理弹窗,填 Agent 名称(如 prod-zone3-node01)后注册;把 Agent 放到隔离网段目标机,回「Spoke Agent」(/apollo/agents)页点「模拟 Pull」,再用两个上报输入框提交状态。
- 会看到:在线列表出现该 Agent,状态 online,展示调和状态与心跳时间,可点「查看快照」;「模拟 Pull」返回期望状态与校验摘要。
API 等价:POST /api/v1/projects/1/environments/:id/agents、GET /api/v1/agent/pull、POST /api/v1/agent/report
4
数据接入:把客户 Excel / 旧库变成可查的表
Foundry 控制台(18081)→ 数据源
- 怎么做:先把 Excel 另存为 CSV,登录 Foundry 进「数据源」(/foundry/datasources)新建数据源并保存;点「导入元数据」;如果之前导过,勾选清理残留列 / 表再导。AIP 侧同类源在「数据源管理」(/datasources)里维护。
- 会看到:返回导入的表 / 字段数量,数据源卡片显示已导入元数据,可被本体建模引用;重复导入前先清理可避免残留表名误导查询。
API 等价:POST /api/v1/datasources、POST /api/v1/datasources/:id/import-metadata
5
语义定制:建本体对象与指标,导出 YAML 评审
Foundry「本体工作台」/「指标管理」/「YAML 导入导出」
- 怎么做:在「本体工作台」(/foundry)新建 customer / order / product 对象、映射属性、配主键;到「指标管理」(/foundry/metrics)定义 total_gmv / aov 并钉住口径;在「YAML 导入导出」(/foundry/yaml)把对象定义导出成 YAML 进本地 Git 评审,评审后再导入。
- 会看到:对象创建返回 version 1;指标列表出现新指标、查询返回数值;YAML 导入回显成功条数,指标口径可被语义检索命中。
API 等价:POST /api/v1/ontology/objects、POST /api/v1/metrics、POST /api/v1/ontology/objects/import
6
现场专属:Gotham 多源融合 + 实体解析
Gotham 控制台(18083)→ 多源接入 / 实体解析
- 怎么做:进「多源接入」(/gotham/ingestion)新建 file_csv 源、配映射后点「运行 Ingest」;到「实体解析」(/gotham/resolution)建作业 res-persons 并运行,人工审 0.70~0.90 的待审对,逐条点确认或拒绝。
- 会看到:接入返回节点 / 边数量与批次号;解析作业统计出现候选数、匹配对与聚类数;确认后同名跨源记录归并成一个实体。
API 等价:POST /api/v1/ingestion/sources、POST /api/v1/ingestion/sources/:id/run、POST /api/v1/resolution/jobs/:id/run、POST /api/v1/resolution/reviews/:id/confirm
7
运维与交接:看授权倒计时,把日常交给客户
「运维状态」(/ops)→ 授权信息卡;Gotham「运维监控」定时备份卡
- 怎么做:在「运维状态」页看底部「授权信息」卡的机器码 / 有效期 / AUTH_KEY 是否已设置;到 Gotham「运维监控」(/gotham/ops)的「定时备份」卡确认 cron 状态、按需改期或启停;最后把「查数 / 看报表 / 管权限」教给业务骨干,整理交接文档后撤场。
- 会看到:未注册授权时授权状态显示「未授权」并有倒计时提示;备份卡改期后提示保存成功、重启不丢,非法 cron 表达式被 400 拒绝并保留原配置。
API 等价:GET /api/v1/license/info
提示:五产品端口固定(AIP 18080 / Foundry 18081 / Apollo 18082 / Gotham 18083 / Swift 18084),各自独立登录、默认账号均为 admin / admin1;控制平面 Apollo 永不反向连入被管环境,隔离网段只靠 Spoke Agent 出向拉取,这是信创离线场景能过安全评审的关键。以上是一条真实客户交付链路,每段单独操作也可独立演示。
调整指南(怎么调整)
- 改部署方式:被管环境零入向端口就加 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,跨产品联动是设计契约但尚未落地。
- 告警只覆盖部署侧:Apollo 有告警汇总 / 自愈 / 通知渠道,但只针对部署与配置健康;漂移 / 授权事件仍以落库 + 审计为主,异常要靠人进 /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 与关停倒计时,提前续期
- 到 Gotham 运维页「定时备份」卡片确认 cron 状态,改期 / 启停即时落库、重启不丢
- 系统响应
- 漂移检测与调和返回:
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 不自动应用);Apollo 告警只覆盖部署 / 配置健康,业务指标与跨产品主动推送仍待后续版本;Gotham「定时备份」只持久化调度配置(cron / 启停)到平台库,不负责异地容灾;/metrics 与告警联动、Windows 服务注册属后续版本。
故事 5
培训交接与撤场:轻交付,产品驱动增长
场景:培训交接
角色:FDE + 客户业务骨干
耗时:两周培训 + 撤场
- 背景
- 交付第四周,阿凯要撤场了。他的目标是把"查数、看报表、管权限"这三件日常完整交给客户:林经理在 AIP 用一句话查数、在 Foundry 看指标口径;周警官在 Gotham 出简报;唐工在 Apollo 管部署与授权。撤场之后,客户自己运转,阿凯只在远程支持群里待命。
- 传统做法对比
- Palantir 的 FDE 常驻客户现场 6~12 个月,靠重人工定制撑起交付,成本高、依赖深;本项目的轻交付定位是"产品驱动增长":一套 YAML + GitOps 一周装完、两周培训,日常操作交给业务骨干,FDE 撤场后客户自运转,后续需求靠迭代交付而非常驻。
- 角色
- 阿凯(FDE,组织培训与交接);林经理(客户业务骨干,学习查数 / 报表 / 权限);唐工(客户现场 IT,接管运维);周警官 / 小沙(客户业务用户,验证专属场景)。
- 操作步骤
-
- 第一周培训:AIP 一句话查数 + 指标口径核对;Foundry 对象查询自助取数
- 第二周培训:Gotham 出简报;Apollo 看部署 / 漂移 / 回滚;权限与账号管理实操
- 整理交接文档:产品端口、默认账号、边界与限制清单、备份恢复脚本用法、Gotham 定时备份 cron 的改期方法
- 用 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 制品库,并把 Gotham 定时备份的改期 / 启停方法写进运维手册。相关阅读:角色视角、限制综述、迁移指南。
- 动手试一试
- 场景:让业务骨干自己走一遍——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 不真实部署、语义层未打通、告警只覆盖部署侧、Swift 为仿真域。