自研脚本 + 对象存储的长期成本 | Ftrans B2B
脚本没有错，它只是没有被设计成要活五年、被十个人接手。
本页目录：一句话结论 ｜ 三点速览 ｜ 脚本是对的选择 ｜ 成本落在哪四个地方 ｜ 完整对照表 ｜ 各自的适用场景 ｜ 对象存储不用换掉 ｜ 常见问题
一句话结论
自研脚本加对象存储在起步阶段几乎总是正确的选择——它快、可控、没有采购流程。它的成本不在写的时候，而在写完之后：每加一家伙伴要改一次代码、安全检查没有位置放、写脚本的人调岗之后无人敢动、出问题时查不到过程。
三点速览
- 变更成本随伙伴数量线性增长。 每一家客户的服务器、协议、目录规则、命名规范、时间窗都不一样。第一家是写代码，第十家还是写代码。
- 安全检查在脚本里没有自然的位置。 病毒检查、敏感内容检查、审批不是脚本的职责，硬加进去意味着这套脚本要开始承担安全系统的责任。
- 人是最大的单点。 一段跑了三年的脚本，写它的人调岗之后，通常不是”没人会改”，而是”没人敢改”——因为没有人确切知道它现在还在为哪几条业务服务。
脚本是对的选择
这一页不打算贬低自研。多数技术负责人自己就是那个写脚本的人，这条路径的每一个决策在当时都是合理的：
- 需求来得急，采购走不完流程；
- 逻辑不复杂——定时去某个目录取文件、改个名、传到对象存储、通知一下；
- 用现成的 SDK 和调度器，一天能跑通；
- 出了问题自己就能改，不用等厂商。
它的问题不是设计错误，而是它从来没有被设计成要活五年、被十个人接手、承担合规责任。 一个原本三十行的定时任务，五年后可能有八百行、七个分支、三处硬编码的凭据，以及一份写在某个人脑子里的运维知识。
成本落在哪四个地方
每加一家伙伴，改一次代码
对端各不相同，适配成本全部由本方承担。同时对接多家客户时，每一家的服务器、协议、目录规则、命名规范、时间窗都不一样。
在脚本里，这些差异表现为分支、配置常量与特例处理。加一家客户是一次代码改动，跟着就是一次测试与一次上线。做过五次之后，这套脚本里会有一半的代码是在处理”这家不一样”。
平台把这些差异挪到配置里：每家客户建立为一个合作伙伴，其外部账号与密钥由平台统一托管，各家的 FTP/SFTP 或对象存储纳管为该伙伴的伙伴库目录，收发策略按伙伴与方向配置。加一家伙伴是加一份档案与一组策略，不是改一次代码。
安全检查没有位置放
外来文件是否查过毒、外发文件是否含敏感内容，在脚本路径里取决于写脚本的人当时有没有想到，以及后来有没有人维护那部分逻辑。
更本质的问题是顺序。出向的内容检查与审批必须在加密之前完成，因为加密之后不再具备明文内容检查能力；入向的加密来件必须先解密再杀毒，因为密文阶段的检测能力有限。这个顺序在脚本里是可以写反的，而且写反了不会报错——它只会安静地失效。
产品把这一顺序固化在流程中：出向依次是受控入库、内容识别、敏感内容检查、人工审批、加密封装；入向依次是受控隔离、外层预检、解密验签、威胁检测。两个方向都设放行闸，未通过的文件停留在隔离区，不进入内部目标，也不发往外部伙伴。
凭据在配置文件里，也在人手上
脚本要访问外部端点，就必须持有凭据。它们通常落在配置文件、环境变量或某个人的本地文件里，并且随着脚本被复制到新环境而复制。
伙伴的 FTP/SFTP 账号、对象存储访问密钥、加密密钥散在若干处，人员变动后凭据是否失效无人确认——这不是脚本写得好不好的问题，是这条路径本身没有凭据管理的位置。
平台把这类外部凭据统一保管与使用，业务侧提交任务与查看结果，全程不接触凭据；人员变动时不必逐个回收账号，轮换在平台一处完成。
出问题时查不到过程
脚本通常会打日志，但日志的形态是为排障设计的，不是为追责设计的。客户来问”上周三那批图纸你们什么时候发的、谁触发的、我们那边为什么没收到”，能拿出来的往往是一段文本日志，缺少可查询、可导出、可归集的结构。
平台记录访问会话、文件操作、文件传输、系统管理、身份管理、身份认证、安全检测七类日志，支持条件查询、详情查看与导出，保留时长与归档策略可配置。还有一件事脚本很难覆盖：上传完成不等于对方已经收到并处理。 文件包提取会回传提取回执，协议直连的交换由接收方回送响应，经验签与哈希校验通过后才标记为已送达。
完整对照表
| 维度 | 自研脚本 + 对象存储 | Ftrans B2B |
|---|---|---|
| 起步速度 | 快，一天能跑通 | 需要一次建档与配置 |
| 新增一家伙伴 | 改代码 → 测试 → 上线 | 建一份伙伴档案 + 一组收发策略 |
| 对端变更（换地址、换协议、换目录规则） | 改代码 | 改配置项 |
| 凭据存放 | 配置文件、环境变量或个人手中 | 平台托管，业务侧不接触 |
| 外发前的内容检查与审批 | 需要自行实现并维护 | 交换的固有环节，按伙伴与方向配置 |
| 出入向的处理顺序 | 靠写的人记得 | 固化在流程中，设放行闸 |
| 对端零部署的收发 | 需要另做一套页面与链接机制 | 文件包链接与收集链接，对端只需浏览器 |
| 交换记录 | 文本日志，为排障设计 | 七类日志 + 收发记录，可查询可导出 |
| 对方取没取 | 通常不知道 | 提取回执 / 协议回执 |
| 人员变动 | 无人敢改 | 配置在平台上，与人解绑 |
| 既有对象存储 | 继续用 | 同样继续用——纳管为伙伴库目录 |
| 作业编排与调度 | 脚本自己做 | 产品不含通用调度引擎，由既有调度平台承担，通过开放接口协同 |
最后一行是主动划出的边界：产品不包含通用的工作流编排与任务调度引擎。 如果企业已有成熟的调度平台，它继续承担编排，产品通过 OpenAPI、事件订阅与异步回调与其协同。
→ 与既有业务系统协同
各自的适用场景
自研脚本不会因为上了平台就全部下线，也不该全部下线。分界大致是这样的：
| 场景 | 建议 |
|---|---|
| 内部系统之间的文件搬运，不出企业边界 | 继续用脚本。这不是企业间交换 |
| 一次性的数据迁移、批量导入导出 | 继续用脚本。为一次性任务上平台不划算 |
| 只有一两个对端、规则长期不变、内容不敏感 | 继续用脚本。成本还没到临界点 |
| 作业编排、任务调度、依赖关系与重试策略 | 继续用既有调度平台。产品不做这件事 |
| 对端数量在增长，且每家规则不同 | 交给平台。变更成本会持续上升 |
| 交换内容涉及图纸、源代码、财务或个人信息 | 交给平台。需要外发前的检查与审批 |
| 需要向客户或审计说清每一次交付的过程 | 交给平台 |
| 脚本里硬编码了外部凭据 | 交给平台。这是最该优先处理的一类 |
| 写脚本的人已经调岗或即将离开 | 交给平台。这类脚本通常撑不过下一次对端变更 |
一个实用的判断：如果这套脚本挂了，你需要多久才能知道、以及知道之后由谁来修——这两个问题的答案，就是它真实的成本。
对象存储不用换掉
需要说清楚的一点：这一页说的是脚本那部分，不是对象存储那部分。
企业已有的对象存储、FTP 服务器与 NAS 都可以原位保留，纳管为伙伴库目录使用。可纳管的存储类型包括 FTP/FTPS/SFTP、SMB、Amazon S3（全球区域 / 中国区域）、阿里云 OSS、七牛云、深信服存储对象，以及兼容 S3 协议的存储服务。
数据不迁移、位置不变，对端不改配置，只把访问凭据收口到平台。 落地也不要求一次到位——可以先让平台接管一条新增的或风险较高的业务流，原路径保留作为回退，验证稳定后再停止人工操作与旧脚本。
→ 第三方存储资源纳管 · 零迁移纳管既有传输资源
→ 凭据托管的安全设计与评审配合见 外部凭据托管的安全设计与评审配合
→ 行业里的典型交换结构见 集成电路与半导体的内外部文件交换
常见问题
Q：我们自己写脚本对接就够了，为什么要上平台？
A：起步阶段脚本通常是对的选择。值得重新评估的信号有四个：对端数量在增长且每家规则不同、交换内容涉及敏感文件、需要向客户或审计说清交付过程、以及写脚本的人即将离开。出现两条以上时，长期维护成本通常已经超过一次性的建设成本。
Q：上了平台，现有的对象存储和 FTP 服务器要换掉吗？
A：不需要。既有的 FTP/FTPS/SFTP、SMB、S3/OSS 等存储资源可纳管为伙伴库目录，数据不迁移、位置不变，对端不改配置。要替换的只是脚本承担的那部分工作。
Q：我们已经有调度平台，两者会不会冲突？
A：不会，而且这是产品主动划定的边界——产品不包含通用的工作流编排与任务调度引擎。作业编排由企业既有的调度平台承担，产品通过 OpenAPI、事件订阅与异步回调与其协同。
Q：脚本能不能保留一部分？
A：可以，建议这样过渡。先让平台接管一条新增的或风险较高的业务流，原路径与旧脚本保留作为回退，验证稳定后再逐步停止。内部系统之间不出企业边界的搬运，本来就不需要挪。
Q：脚本里硬编码的凭据怎么处理？
A：这类通常应优先处理。做法是把外部企业建立为合作伙伴，其账号与密钥登记到该伙伴档案由平台保管，业务侧提交任务与查看结果、不接触凭据；平台侧跑通之后，再把脚本里与个人手中的旧凭据统一作废或轮换一次。