为什么能源 SaaS 不应该从零写每家逆变器适配：3 年生产经验
初次成本、长期维护、API 改版事故、决策框架——基于 Zenergy Monitor 三年生产数据。
那是个普通的周二早上。standup 5 分钟,工程组组长把白板擦了。
「我们这个月又花了 3 周接第 4 家逆变器厂商。每家平均 5–7 周。算上之前 3 家,我们今年在『接入』这一件事上已经投了 5 个工程师月。」
「我们的产品是什么?监控看板。我们这个月给监控看板新增了什么客户能感知的功能?」白板上写了一个「0」。
那天我们决定:这种做法不能再延续下去。
三年后回头看,那个决定催生了 ZenovaConnect。这篇文章是当时那个决策推理的复盘——为什么对能源 SaaS 团队来说,从零写每家逆变器厂商的适配,几乎一定是个错的选择。
初次接入的真实成本
假设你的工程师每天 8 小时,扣除会议、code review、其它琐事,一周纯写代码大约 25 小时。下面这些数字是 Zenergy Monitor 三年里跨 15 家厂商的真实经验摘录。
接一家新厂商,要经过 4 个阶段:
- 账号申请:对接商务流程,签 NDA 或 API 协议,等凭据下发。耗时 1–6 周,但工程师实际投入约 1–3 天(等待时间不算工程量,但延误项目交付)
- 文档消化:阅读 API 文档、理清认证流程、找清楚字段含义。1–5 天(看文档质量)
- 字段映射:把厂商字段映射到你的统一 schema,处理单位、时区、采样频率。3–5 天
- 错误处理与测试:rate limit、重试、超时、单元测试、上线前观察。3–5 天
加起来,单家厂商初次接入 4–8 周(工程师纯投入时间,不含等待)。
但是有规律。下面是按厂商类型的拆解:
| 厂商类型 | 账号申请等待 | 文档消化 | 字段映射 | 错误处理 | 工程师合计 |
|---|---|---|---|---|---|
| 国内头部(华为/阳光/固德威级别) | 1–2 周 | 2–4 天 | 3–5 天 | 3–4 天 | 4–6 周 |
| 国内中型(锦浪/古瑞瓦特级别) | 1–3 周 | 1–3 天 | 3–5 天 | 3 天 | 5–7 周 |
| 国内小型 | 2–4 周(商务流程长) | 1–2 天 | 2–4 天 | 2 天 | 6–8 周 |
| 海外品牌(SMA / Fronius 级别) | 2–6 周(国际客服) | 2–5 天(英文文档) | 3–5 天 | 4–5 天 | 6–12 周 |
看清楚:国内小型厂商不见得比国内头部好接。头部厂商文档完整、字段命名规范、API 改版有 changelog;小型厂商往往文档过时,字段语义需要邮件确认,商务流程能拖一个月。
长期维护:真正的隐性成本
初次接入的成本相对可见——它是个一次性投入,你能在项目计划里看到。
真正贵的是长期维护。它不在项目计划里。它每个月、每个季度、每次厂商发版都重新发生一次。
维护成本按 4 类:
| 维护项 | 频率(每厂商) | 单次工时 | 年化工时/厂商 |
|---|---|---|---|
| API minor version 升级 | 每年 2–4 次 | 2–4 天 | 6–12 工程师日 |
| 字段语义变更追踪 | 不定期(平均年 5–8 次) | 0.5–2 天 | 4–8 工程师日 |
| 凭据 / 证书轮换 | 每 6–12 月 | 1–2 天 | 2–3 工程师日 |
| 新机型告警代码扩展 | 每新机型一次 | 1 天 | 3–5 工程师日 |
| 合计 | 15–28 工程师日/年/厂商 |
把这个数字放到你的盘子里:接 5 家厂商,长期维护投入约 75–140 工程师日/年,相当于 0.4–0.7 个全职工程师。
这还没算事故响应。事故是另外的故事——发生时优先级压一切,通常需要 24 小时 SLA 内响应。下一节说事故。
这里要强调的是:长期维护不是「项目完成之后的事」,它是「项目永远完不成」。 每家厂商都是一条永远在维护的产品线。你接得越多,维护团队越压不动。
三个真实事件:API 改版风险
不是「会不会改」,是「什么时候改」。三年里我们经历过的几个事件,匿名化处理:
事件 1:单位悄悄变了
某头部厂商的某型号逆变器,某天起 EDay(当日发电量)从 kWh 变成 kWh × 10。无 changelog。
发现是因为有客户在产品里看自己电站日发电量,某天起数字翻 10 倍。监控看板看起来「电站爆发」,工程师上去看才发现单位变了。
后续:重发 6 个月历史数据(单位换算);客户沟通(信任修复);监控规则加单位校验(防再次发生)。
工程量:2 周 + 客户关系修复。
事件 2:OAuth2 endpoint 静默迁移
某央企对接的某厂商在某次发布 v3 API 后,把旧 OAuth2 endpoint 静默 410'd。
发现是因为晚上 11 点客户告警群刷屏——所有该厂商的数据全停了。
处理:连夜申请新 endpoint 凭据,改采集管道认证逻辑,重启所有该厂商的采集任务。
工程量:8 小时停机 + 1 个工程师整夜响应。后续与厂商建立了改版预警机制(每月固定沟通)。
事件 3:海外厂商 rate limit 收紧
某海外厂商把 API rate limit 从 1000 req/min 收紧到 100 req/min。无预警。
发现是历史数据回补脚本全部 429 失败,历史数据回放卡住。
处理:重写采集策略——并发降 10 倍,增量请求改分片,加请求队列。
工程量:3 天工程师专注修复。
这三个事件共同点:不是技术上特别难,但每次发生都需要立即响应。如果你的工程团队同时维护 10 个厂商,每年大约会发生 15–20 次这种「需要立即响应」的事件。这是真正的隐性成本。
决策框架:什么时候应该自研,什么时候应该买
把上面的成本结构内化进决策,你应该:
自研 当:
- 你只接 1–2 家专属厂商,且这些厂商不再扩展
- 你的接入需求非常深(自定义协议、私有字段、特殊业务逻辑),通用接入层无法覆盖
- 你的数据合规要求极严,任何第三方都不能参与采集(注:Self-Hosted 部署的接入层依然可以满足这个,见下一篇)
买接入层 当:
- 你的产品需覆盖 5+ 厂商
- 你的客户会持续提出新厂商需求
- 你的工程师时间应该花在你自己的核心产品上(看板、AI 报告、调度优化)
- 你需要 SLA 保障与持续维护承诺
决策表:
| 你的场景 | 自研 | 买接入层 |
|---|---|---|
| 接入 1–2 家专属厂商 | ✅ | |
| 接入 5+ 家国内厂商 | ✅ | |
| 海外品牌覆盖需求 | ✅(海外凭据流程外包) | |
| 短期(<1 月)PoC 验证 | ✅ | |
| 数据完全不能出域 | ✅ 或 Self-Hosted 接入层 | ✅(Self-Hosted) |
| 长期 SLA 责任明确 | ✅(明确服务边界) |
注意「数据不出域」这一行——很多团队默认这就意味着自研,但 Self-Hosted 部署的接入层是另一个选项。下一篇文章讨论 Cloud vs Self-Hosted。
一句话总结
接入工作不构成你的产品差异化,但它会消耗你最值钱的工程资源。
把它外包给一个专门做这件事、有 3 年生产数据沉淀、支持 Cloud 与 Self-Hosted 两种部署的团队,是大多数能源 SaaS 在第 3 个厂商之后会做的判断。
我们当时做了这个判断。三年后这套能力变成了 ZenovaConnect。