《独立开发者的商业指南·合同、应收与风险》10.3 备选方案与迁移成本

以下情境为教学假设，人物与数字不代表经核实的真实案例。

10.1 算的是依赖断了损失多少，这一节算的是“提前准备备选方案要花多少”。两者是一笔对冲：备选方案的固定成本是确定的，中断损失是不确定的。只有当“期望年损失”大于“年冗余成本”，并且一次性投入能在可接受年限内回本，备选方案才在财务上成立；否则它只是让团队感觉安全。

三种常见备选方案的成本结构不同。多云防的是云区域或云供应商中断，双支付防的是单通道故障或封号，自建分发防的是平台下架或分成变化。三者的共同点是：固定成本先付，收益是“少发生的损失”。共同点的另一面是：如果中断概率很低，固定成本会一直付下去，而收益永远不会出现在账上。

三种备选方案的成本结构

先看三种方案各自要付什么。下表的金额是教学假设，不是供应商报价；一次性成本包括接入、迁移和改造，年成本包括维护、对账和额外运维。

多云的一次性成本最高。它不只是“再开一个云账号”，而是要把数据复制、流量切换、权限和备份都做成两套；年成本是双份的运维和监控。双支付的一次性成本低一些，主要是接第二个支付通道、重做对账和退款路径；年成本是维护两套集成和每月对账。自建分发的一次性成本包括商店页、下载、更新、支付和客服；年成本是托管、支付费和客服工时。

Nord Studio 的备选方案不是云或支付，而是获客渠道：转介绍占 55%，备选是内容与主动销售。它的冗余成本是时间，不是账单；平衡点按“新增渠道带来的收入能否覆盖投入的工时”算。服务型业务的备选方案通常更便宜，但也更慢，因为渠道不会在一个月内建成。

冗余成本与中断损失的平衡点

先把三个量写清楚：

期望年损失 = 单次中断损失 × 年中断概率 × 年中断次数

年净收益 = 期望年损失 − 年冗余成本

回本年数 = 一次性成本 ÷ 年净收益

平衡概率 = 年冗余成本 ÷ 单次中断损失

平衡概率回答“中断概率要到多少，年冗余成本才刚好被覆盖”。回本年数回答“覆盖之后，一次性投入还要多久赚回来”。两个都要看：一个方案可能覆盖年成本，但一次性投入十年才回本；也可能回本很快，但中断概率低于平衡点。

LedgerLite 的双支付方案：一次性成本 16,000 美元（接入 4,000 + 迁移 120 小时 × 100 美元 = 12,000），年成本 2,400 美元；单次支付中断损失 15,000 美元（3 天月末故障，含退款、客服和流失），年概率 30%，每年按 1 次算。

期望年损失 = 15,000 × 30% = 4,500 美元

年净收益 = 4,500 − 2,400 = 2,100 美元

回本年数 = 16,000 ÷ 2,100 = 7.62 年

平衡概率 = 2,400 ÷ 15,000 = 16.0%

30% 的年概率高于 16.0% 的平衡概率，所以双支付在“年成本”这一层是划算的：期望每年省 4,500 美元，减去 2,400 美元维护费，净省 2,100 美元。但一次性投入 16,000 美元要 7.62 年才回本。如果 LedgerLite 计划三年内出售或转型，双支付在财务上不回本；它的理由只能是企业客户要求“至少两个支付通道”，或者单次中断损失远高于 15,000 美元。

敏感性可以直接算出来：

第一行说明：如果单次中断只损失 5,000 美元、年概率 10%，期望年损失 500 美元，连 2,400 美元的年维护费都覆盖不了，平衡概率要 48.0% 才够，实际概率远低于它。第三行说明：如果单次损失 40,000 美元、年概率 50%，期望年损失 20,000 美元，一次性投入 0.91 年就回本，双支付明显值得。同一个方案，结论完全取决于“单次损失”和“年概率”两个假设。

多云方案用同一套公式：一次性 60,000 美元，年成本 12,000 美元；单次云中断损失 50,000 美元，年概率 20%。

期望年损失 = 50,000 × 20% = 10,000 美元

年净收益 = 10,000 − 12,000 = −2,000 美元

平衡概率 = 12,000 ÷ 50,000 = 24.0%

20% 的年概率低于 24.0% 的平衡概率，年净收益是 −2,000 美元，回本年数不存在。多云在这个假设下不是“贵一点”，而是“每年确定亏 2,000 美元，换一个 20% 概率的 50,000 美元损失”。如果云中断的后果是永久失去客户，50,000 美元可能低估；如果只是几小时不可用，50,000 美元可能高估。平衡概率把争论变成“你认为年概率高于 24% 吗”，而不是“多云是不是更安全”。

这张表还可以用来比较方案。双支付的平衡概率是 16.0%，多云是 24.0%；双支付的一次性成本 16,000 美元，多云 60,000 美元。双支付在两项上都更便宜，但它防的是支付中断，不是云中断，两者不能互相替代。备选方案要先按“防什么”分组，再在同组内比较成本；跨组比较只会得出“便宜的方案更好”这种没有意义的结论。

Tidecast 自建分发的销量门槛

Tidecast 的备选方案不是“再上一个平台”，而是“把 Steam 的销量搬到自有渠道”。它的一次性成本约 26,000 美元（商店与下载 8,000 + 迁移 200 小时 × 80 美元 = 16,000 + 一次性工具 2,000），年成本约 6,000 美元（托管、支付、客服）。这些是教学假设，不是实际报价。

当前结构：Steam 7,680 份，净得 103,167 美元，每份净得约 13.43 美元；官网 1,920 份，净得 35,004 美元，每份净得约 18.23 美元；合计净得 138,171 美元。自有渠道每份多留约 4.80 美元，因为不用付 30% 平台分成，只付 5% 支付费。

如果迁移后能保留 100% 的 Steam 销量，自有渠道总销量是 9,600 份：

9,600 × 18.23 − 6,000 = 169,008 美元

比当前 138,171 美元多 30,837 美元。但 100% 保留几乎不可能：Steam 的愿望单、评价、推荐位和退款记录不能原样搬走，迁移后销量会下降。真正的问题是“下降多少还能不亏”。

设迁移后的销量保留率为 r，则自有渠道净得为：

(1,920 + 7,680 × r) × 18.23 − 6,000

令它等于当前净得 138,171 美元，解得 r = 78.0%。也就是说，从 Steam 迁移到自有渠道，至少要保留 78.0% 的 Steam 销量，收入才和现在持平；低于 78.0%，迁移是亏的。

这张表说明，自建分发的成败不在成本，而在销量保留率。一次性成本 26,000 美元和年成本 6,000 美元是确定的；销量保留率是不确定的，而且很难在迁移前准确估计。70% 保留率下，每年少 11,165 美元；80% 保留率下，每年多 2,836 美元。78.0% 的门槛正好落在两个常见情景之间，所以“要不要自建”不是一个拍脑袋的决定，而是一个“你有多大把握留住八成销量”的判断。

平台条款不可谈，进一步放大了这个门槛。Steam 的 30% 分成、4% 退款、评价和推荐机制都是标准条款，独立开发者没有谈判空间；能改的只有销量从哪来。如果自建渠道能把 Steam 的 80% 依赖降到 50%，但保留率只有 70%，收入反而下降。依赖度下降不等于收入上升，这两个目标经常冲突。

自建分发还有一个隐性成本：客服和退款。Steam 处理退款、支付争议和部分客服；自建渠道要自己处理，年成本 6,000 美元里已经包含一部分，但如果退款率从 4% 上升，或者支付争议增多，实际成本会更高。表里的 6,000 美元是下限，不是上限。

把平衡点写成代码

下面的 migration-cost.ts 把冗余方案写成 redundancyCase：oneTimeCostCents 是接入加迁移工时，expectedAnnualLossCents 是单次损失 × 年概率 × 年次数，annualNetBenefitCents 是期望损失减年成本，breakEvenProbabilityBps 是年成本刚好被覆盖的概率，breakEvenYears 是一次性成本的回本年数。isProbabilityReachable 用来判断平衡概率是否超过 100%。

// file: src/contract/migration-cost.ts
// tier: L1
// verify: node --test test/contract/migration-cost.test.ts

import { type Cents } from "../core/money.ts";
import { type Bps, divide } from "../core/rate.ts";
import { type Result, fail, ok } from "../core/result.ts";

export type RedundancyInput = {
  setupCostCents: Cents;
  annualCostCents: Cents;
  migrationHours: number;
  hourlyRateCents: Cents;
  outageLossCents: Cents;
  outageProbabilityBps: Bps;
  eventsPerYear: number;
};

export type RedundancyCase = {
  oneTimeCostCents: Cents;
  firstYearCostCents: Cents;
  expectedAnnualLossCents: Cents;
  annualNetBenefitCents: Cents;
  breakEvenProbabilityBps: Bps | null;
  breakEvenYears: number | null;
};

function checkAmount(value: Cents, label: string): string | null {
  if (!Number.isInteger(value) || value < 0) {
    return `${label} must be a non-negative integer amount in cents`;
  }
  return null;
}

function checkBps(value: Bps, label: string): string | null {
  if (!Number.isInteger(value) || value < 0 || value > 10000) {
    return `${label} must be between 0 and 10000 bps`;
  }
  return null;
}

/**
 * Redundancy is a fixed cost paid every year to reduce a low-probability loss.
 * The break-even probability is the outage probability at which the expected
 * annual loss equals the annual redundancy cost. The payback period also has to
 * recover the one-time setup and migration labor, which is why a redundancy can
 * clear its annual cost and still take years to pay back.
 */
export function redundancyCase(
  input: RedundancyInput,
): Result<RedundancyCase> {
  for (const [value, label] of [
    [input.setupCostCents, "setup cost"],
    [input.annualCostCents, "annual cost"],
    [input.hourlyRateCents, "hourly rate"],
    [input.outageLossCents, "outage loss"],
  ] as Array<[Cents, string]>) {
    const error = checkAmount(value, label);
    if (error) {
      return fail(error);
    }
  }
  if (!Number.isFinite(input.migrationHours) || input.migrationHours < 0) {
    return fail("migration hours must be a non-negative number");
  }
  const probabilityError = checkBps(
    input.outageProbabilityBps,
    "outage probability",
  );
  if (probabilityError) {
    return fail(probabilityError);
  }
  if (!Number.isFinite(input.eventsPerYear) || input.eventsPerYear <= 0) {
    return fail("events per year must be a positive number");
  }

  const migrationCostCents = Math.round(
    input.migrationHours * input.hourlyRateCents,
  );
  const oneTimeCostCents = input.setupCostCents + migrationCostCents;
  const firstYearCostCents = oneTimeCostCents + input.annualCostCents;
  const expectedAnnualLossCents = Math.round(
    (input.outageLossCents *
      input.eventsPerYear *
      input.outageProbabilityBps) /
      10000,
  );
  const annualNetBenefitCents =
    expectedAnnualLossCents - input.annualCostCents;
  const annualLossPerEventCents = Math.round(
    input.outageLossCents * input.eventsPerYear,
  );
  const breakEvenProbabilityBps =
    annualLossPerEventCents === 0
      ? null
      : divide(input.annualCostCents, annualLossPerEventCents);

  return ok({
    oneTimeCostCents,
    firstYearCostCents,
    expectedAnnualLossCents,
    annualNetBenefitCents,
    breakEvenProbabilityBps,
    breakEvenYears:
      annualNetBenefitCents <= 0
        ? null
        : Math.round((oneTimeCostCents / annualNetBenefitCents) * 100) / 100,
  });
}

/**
 * A break-even probability above 10000 bps means even a certain outage every
 * year would not cover the annual redundancy cost. The helper keeps that case
 * explicit instead of forcing the caller to compare against a sentinel value.
 */
export function isProbabilityReachable(breakEvenProbabilityBps: Bps): boolean {
  return breakEvenProbabilityBps <= 10000;
}

把 LedgerLite 双支付代入：一次性 400,000 美分接入 + 120 小时 × 10,000 美分 = 1,600,000 美分；首年 1,840,000 美分；期望年损失 450,000 美分；年净收益 210,000 美分；平衡概率 1,600 基点；回本 7.62 年。低损失情景（单次 500,000 美分、概率 1,000 基点）返回期望损失 50,000 美分、年净收益 −190,000 美分、平衡概率 4,800 基点、回本 null；高损失情景（单次 4,000,000 美分、概率 5,000 基点）返回期望损失 2,000,000 美分、年净收益 1,760,000 美分、平衡概率 600 基点、回本 0.91 年。多云（一次性 6,000,000 美分、年成本 1,200,000 美分、单次损失 5,000,000 美分、概率 2,000 基点）返回期望损失 1,000,000 美分、年净收益 −200,000 美分、平衡概率 2,400 基点、回本 null。

代码里有三个刻意的限制。第一，breakEvenProbabilityBps 用年成本除以单次损失，不含一次性投入；一次性投入的回本由 breakEvenYears 单独回答。第二，breakEvenYears 不含资金时间价值，也没有折现；对三年内的决策够用，对十年期的决策会高估收益。第三，代码只算冗余与中断，不算 Tidecast 的销量保留率；后者是单位经济，不是概率模型，所以放在正文表格里单独算。

备选方案的决策顺序应该是：先按“防什么”分组，再在同组内算平衡概率和回本年数，最后看一次性投入是否在持有期内回本。跳过任何一步，都会把“有备选”当成“更安全”。备选方案的价值不在于它存在，而在于它在你的持有期内能回本。

小结

• 备选方案是一笔固定成本换一笔低概率损失；固定成本确定，收益不确定，只有期望年损失大于年冗余成本才成立。
• 双支付的平衡概率是 16.0%，年净收益 2,100 美元，但一次性投入 16,000 美元要 7.62 年回本；三年内出售或转型时不回本。
• 双支付的结论对假设极敏感：单次损失 5,000 美元、概率 10% 时不回本；单次损失 40,000 美元、概率 50% 时 0.91 年回本。
• 多云的平衡概率是 24.0%，年净收益 −2,000 美元；20% 的年概率下，多云每年确定亏 2,000 美元。
• 双支付比多云便宜，但防的不是同一种中断；备选方案要先按“防什么”分组，再比较成本。
• Tidecast 自建分发的一次性成本约 26,000 美元、年成本约 6,000 美元；销量保留率 78.0% 是收入持平的门槛。
• 70% 保留率下自建分发每年少 11,165 美元，80% 保留率下每年多 2,836 美元；门槛正好落在两个常见情景之间。
• 平台条款不可谈，依赖度下降不等于收入上升；自建分发要先回答“能不能留住八成销量”，再回答“要不要建”。

阅读导航：上一节：10.2 供应商合同与退出条款 · 下一节：11.1 DPA、SCC 与跨境传输 。

常见错误与边界

1. 把“有备选”当成“更安全”。 备选方案的固定成本每年都付，收益只在中断时出现；期望年损失低于年成本时，备选方案是净亏损。
2. 只算一次性成本，不算年成本。 双支付一次性 16,000 美元，年成本 2,400 美元；年成本决定平衡概率，一次性成本决定回本年数，两者不能合并。
3. 只算回本年数，不算平衡概率。 一个方案可能年净收益为正，但中断概率低于平衡点；也可能回本很快，但概率假设不成立。
4. 用单次损失代替期望损失。 15,000 美元的单次损失乘 30% 才是 4,500 美元；直接拿 15,000 美元和 2,400 美元比，会高估收益 3 倍多。
5. 忽略概率的不确定性。 30% 是教学假设，不是统计值；概率从 10% 变到 50%，回本年数从“不回本”变到 0.91 年。
6. 跨组比较备选方案。 双支付比多云便宜，但双支付防不了云中断；先按“防什么”分组，再比成本。
7. 把多云当成“再开一个账号”。 多云的一次性成本包括数据复制、流量切换、权限和备份；年成本是双份运维，不是双份订阅费。
8. 假设自建分发能保留 100% 销量。 Steam 的愿望单、评价和推荐位不能原样搬走；78.0% 是收入持平的门槛，不是保守估计。
9. 只看依赖度下降，不看收入变化。 把 Steam 的 80% 依赖降到 50%，如果保留率只有 70%，收入反而每年少 11,165 美元。
10. 把年成本当日成本上限。 自建分发的 6,000 美元年成本含托管、支付和部分客服；退款率上升或支付争议增多时，实际成本更高。

本节的边界是“单次中断、年度概率、线性损失”的静态模型。它假设中断损失和概率已知、冗余方案一次建成、年成本不变，不含资金时间价值、不含多事件叠加、不含冗余方案自身的故障率、不含迁移期间的收入下降。它足够回答“双支付和多云在什么概率下回本、Tidecast 自建分发要留住多少销量”，但不足以回答“多云架构本身出故障时怎么办”。后者要把备选方案放进业务连续性计划，见 10.1 云、支付、平台的关键依赖 ；渠道退出的合同侧见 9.3 渠道合同与退出 。本节不构成法律意见，具体条款请由律师审阅。