5.5 托管服务与自建的取舍
一句话
托管买的是 “把值班、升级、备份、打补丁的责任转移出去”，自建买的是 “控制权与成本拐点”；判断不看先不先进，而看责任边界落在谁身上、在你的规模上哪一边的总代价更小。
先画清那条线：共享责任模型
| 形态 | 你管 | 厂商管 | 你仍然躲不掉的三件事 |
|---|---|---|---|
| IaaS（VM / 块存储） | OS、中间件、数据、备份、补丁 | 硬件、虚拟化、机房 | 数据、容量、访问控制 |
| 托管数据库 | 表结构、索引、SQL、数据 | 安装、主从、备份、小版本补丁 | 容量规划、慢查询、数据正确性 |
| 托管 K8s | 工作负载、网络策略、RBAC | 控制面、升级、节点池运维 | 资源配额、镜像安全、容量 |
| FaaS | 函数代码、超时、并发上限 | 运行时、伸缩、扩缩容 | 冷启动预算、依赖安全 |
共同规律：托管只转移 “运维动作”，不转移 “数据责任与容量责任”。“上了托管数据库就不用管备份”——这句话在事故复盘里出现过太多次：备份是厂商做的，恢复演练是你的。
五个判据，按顺序问
| 维度 | 问什么 | 偏向托管 | 偏向自建 |
|---|---|---|---|
| ① 控制权 | 需要特定版本 / 参数 / 内核 / 插件吗？ | 用标准版就够 | 必须改参数或打补丁才能达标 |
| ② 总代价 | 含人力、工具、培训的年度总成本 | 规模小、人力贵 | 规模大到人力占比被摊薄 |
| ③ 合规 | 数据能不能出园区 / 出境；审计要谁签字 | 厂商有合规背书 | 必须私有化部署 |
| ④ 锁定与退出 | 换掉的成本多少、数据能否导出 | 标准协议（S3/PostgreSQL/K8s） | 已用厂商专有能力且深度耦合 |
| ⑤ 故障可操作性 | 厂商故障时能否降级或绕过 | 有跨可用区与官方 SLA | 需要自己掌控故障时的每一条命令 |
顺序不能换：控制权是硬约束（决定了有没有得选），总代价是经济性，合规是硬边界，锁定是长期风险，故障可操作性决定 “出事那天你手里有什么牌”。更一般的 Make / Buy / Reuse 判断框架见 4.4 Make / Buy / Reuse 决策，选型打分维度见 4.3 技术选型的评估维度。
成本拐点：把 “运维很贵” 算成钱
自建年成本 = 人力(FTE × 全成本) + 机器 + 存储 + 工具 + 培训 + 故障赔付风险
托管年成本 = 单价 × 用量 + 出口流量费 + 请求费 + 超量费 + 集成成本
一个可复算的例子（3 节点 PostgreSQL，8C32G）：
| 项 | 自建 | 托管 |
|---|---|---|
| 机器与存储 | 约 6 万/年 | — |
| 人力 | 0.5 FTE ≈ 30 万/年（全成本 60 万/年） | ≈ 1 万/年（只看慢查询与容量） |
| 服务费 | — | 约 5 万/年（含备份、监控） |
| 合计 | 约 36 万/年 | 约 6 万/年 |
规模变了，结论会反转：50 个节点、需要定制参数与专用扩展时，托管单价随规格线性上涨，而自建的人力近乎不变（还是那 1–2 个人），拐点大约出现在 “节省的人力 ≥ 专用机器与工具成本” 的位置。算不出的团队通常漏了两项：人力按 “顺手维护” 记 0，以及备份/演练/补丁的时间没有计入。
“总代价” 的口径与折现方法见 4.2 成本-收益分析；托管账单里的隐藏项见 5.6 云成本结构。
什么时候必须自建 / 必须托管
| 必须自建（或私有化） | 必须托管 |
|---|---|
| 数据主权 / 等保要求数据不出园区 | 团队 < 5 人，没人能承担 7×24 on-call |
| 必须改内核 / 参数才能达到指标（如特定 IO 调度、共享内存） | 非核心系统（内部工具、报表、日志） |
| 成本占比极高且用量稳定（如对象存储 > 1 PB） | 处于验证期，需要一周内上线 |
| 厂商无对应服务，或服务已停止演进 | 需要开箱即用的高可用与自动备份 |
| 极端延迟要求（同机进程内 < 100μs 级） | 需要合规背书（等保三级、行业认证） |
“必须” 是排他性判断：只要有一条成立，就不是权衡问题。多数团队的问题不是 “该不该自建”，而是把 “想掌控” 当成 “必须自建”，结果自建了一个没人值班的集群。
两张隐形账单
| 托管的隐形账单 | 自建的隐形账单 |
|---|---|
| 出口流量费（可能超过服务费本身） | on-call 排班与夜间唤醒 |
| 请求费 / API 调用费（日志、指标摄取常被忽略） | 升级窗口：大版本升级要停机与回滚预案 |
| 跨可用区流量（多 AZ 架构的固定税） | 备份 “做了但没恢复过” |
| 附加模块：审计、加密、跨区复制单独计费 | 安全补丁的响应时间（往往比厂商慢 1–4 周） |
| 闲置实例与自动扩缩容的峰值浪费 | 关键人离职 = 运维知识清零 |
决策表
| 你的情况 | 选择 |
|---|---|
| 5 人团队，做一个内部审批系统 | 托管数据库 + 托管 K8s，人力用在业务上 |
| 核心交易库，日订单 300 万 | 托管起步；成本占比超过阈值后评估自建或专用方案 |
| 数据不得出园区 | 私有化部署（IaaS 之上自建），并把补丁流程写成 runbook |
| 需要改内核参数压测达标 | 自建或选支持参数定制的托管形态（如专属实例） |
| 验证期项目，两周要上线 | 全托管，接受锁定，先活下来 |
| 已深度使用厂商专有 API | 先算退出成本（见 5.7 云厂商锁定与迁移），再决定是否继续加深 |
反模式
| 反模式 | 后果 |
|---|---|
| 为 “掌控感” 自建，却没有 on-call | 故障时无人可叫，可用性反而不如托管 |
| 把 “托管” 当 “不用管” | 备份没验、容量没算、慢查询没看 |
| 只比单价，不比出口费与请求费 | 账单超预算 2–3 倍，且找不到是哪个模块 |
| 核心账务系统托管却无法导出数据 | 换供应商时被迫接受涨价 |
| 人力按 0 计入自建成本 | 拐点算错，自建的决定从第一年就是亏的 |
| 小团队自建 K8s + 中间件全家桶 | 80% 精力在做 “别人已经做好的运维” |
| 用专有 API 换开发速度，却不记录锁定成本 | 三年后迁移预算没人认领 |
三条铁律
🔑 托管转移运维动作，不转移数据与容量责任；恢复演练永远是自己的。
🔑 人力必须按全成本计入自建（含招聘、on-call、离职风险），否则拐点永远算错。
🔑 先看有没有 “必须” 项（合规 / 参数 / 规模），再谈 “哪个更先进”。
自检
Q1 团队说 “托管数据库太贵，我们自己装一套更省”。你要他补哪三项成本？
▸ 答案：① 人力全成本（0.5–1 FTE 的值班、升级、故障处理，按市场价而非 “顺手”）；② 工具与演练成本（监控、备份存储、跨可用区副本、恢复演练占用的时间）；③ 风险成本（误删数据、主从切换失败的概率 × 损失）。三项补齐后，小规模场景通常反而是托管更便宜；只有规模足够大、人力被摊薄时才反转。
Q2 托管的 Kafka 出了 4 小时故障，业务方问 “我们能不能自己绕过去”。这说明选型时漏了什么判据？
▸ 答案：漏了 ⑤ 故障可操作性。选型时只比较了功能、价格、SLA，没有回答 “厂商故障时我们手里有什么牌”：能否双写到自建集群、能否切到备用供应商、能否降级为同步调用。缓解手段通常不是 “再买一家”，而是在关键链路上保留一条可切换的旁路，并把 “切过去的三条命令” 写进 runbook、每半年跑一次演练。
Q3 数据不得出园区，但团队只有 4 个人。怎么同时满足合规与人力？
▸ 答案：缩小自建的范围，而不是全自建：把 “必须留在园区” 的部分（核心库、敏感数据）用标准开源组件私有化部署，并买厂商的专属支持（远程运维 + 应急响应）；把非敏感、可脱敏的部分托管。关键是划清边界：哪些数据不出园区、哪些服务可以出、跨边界只走脱敏聚合结果。
Q4 为什么 “托管 = 省心” 是危险的简化？
▸ 答案：因为托管只转移 “运维动作”，不转移三类责任：数据正确性（慢查询、索引、误删恢复）、容量（配额、存储增长、连接数）、访问控制（谁能读、审计留痕）。这三类出问题时的第一责任人仍是业务团队。把托管当 “省心”，等于把这三件事从待办清单里删掉，直到事故发生。
Q5 一个 12 人团队要选消息队列：托管版单价是自建的 2.5 倍，怎么判断？
▸ 答案：把自建的真实成本补齐再比：自建需要 0.3–0.5 FTE 运维（约 18–30 万/年）+ 机器 + 监控 + 升级窗口 + 故障演练，且要接受 “关键人单点”。若托管年费 < 自建总成本，选托管；反之再看锁定与退出（消息格式是否标准、能否双跑）。只比单价时，2.5 倍看起来贵；补齐人力后，常见结论是托管便宜 30%–50%。
跨篇相关：服务模型决定责任边界切在哪一刀，见 5.1 服务模型：IaaS / PaaS / FaaS；部署形态与合规边界见 5.2 部署模型：公有 / 私有 / 混合；选型打分与权重见 4.3 技术选型的评估维度、通用 Make / Buy / Reuse 框架见 4.4 Make / Buy / Reuse 决策；TCO 与折现见 4.2 成本-收益分析；账单结构与出口费见 5.6 云成本结构；锁定成本与退出方案见 5.7 云厂商锁定与迁移。