服务挂过一次，要不要花钱做双活

先把结论摆在这儿：你要买的东西不是"不挂"，是"挂了之后多久回来、回来时数据是不是完整的"。 双活只是买到这样东西的四五种方式里最贵的那一种，而且很多情况下你花的钱大部分买的是心理安慰。

挂过一次之后谈这个决定，时机其实最好——你有真实数字了。怕的是把那次故障直接翻译成"上双活"，中间那一步算账省掉了，钱花完，下次故障恢复时间没变短。

先分清三个词，它们的价格差一个数量级

备份：数据在，服务不在。机房着火了你能从对象存储里把库捞回来，但要重搭环境、改配置、灌数据，恢复时间按小时甚至按天算。绝大多数说"我们有备份"的系统，实际买的就是这一档。

冷备 / 温备：多养一套不接流量的环境。真出事时靠人切过去——改域名、起服务、把库指向新主。它的成本是"多一套资源 + 一次切换要有人在场"，收益是把恢复时间从"重搭"缩到"切换"。这一档最容易坏在细节上：备用环境是三个月前建的，这三个月里线上加了两个字段、换了一版中间件，切过去起不来。

同城双活：两套都在接流量，任何一套挂掉，另一套自动承接，用户理论上无感。成本是前两者的总和再加一大截，而且加的那一截不是机器。

这三档的可用性数字看着只差几个 9，价格却是台阶式往上跳的。多数讨论坏在第一步：把"我们要不要做高可用"当成一个是非题，而不是先说清要买哪一档。

双活真正贵的三处，机器钱是最小的一块

第一处：冗余资源。 这是唯一算得清、也最容易被当成全部成本的那一块。同城两套都在接流量，正常时各自承担约一半峰值，所以资源量不是 2 倍而是 2 倍再多留一点冗余系数（一套全挂时另一套要能扛住全量峰值）。按量计费的云资源、双份的带宽、双份的监控与日志接入，都在这一格里。

这笔钱有个特点：它是一次性摊开、年年重复的固定支出，谈预算时最醒目，所以老板看到的"双活很贵"通常就是指它。但它往往只占双活总成本的三分之一不到。

第二处：数据一致性改造。 这才是大头，而且它贵得很隐蔽。

单活时你的数据库、缓存、消息队列都默认"只有一个地方在写"。这个假设写进了你系统的每一层：靠自增主键生成的单号、靠数据库唯一约束兜底的去重、靠"先更新库再删缓存"这种顺序假设的缓存逻辑、靠事务保证的跨表一致性。

一旦两地都能写，这些假设全部失效：同一个单号可能在两边各自生成、同一条记录可能在两边被改成不同值、消息可能被两边各消费一次。要修，就得把写路径逐条过一遍——幂等键、冲突合并规则、时序依赖、跨区延迟下的读己之写。这是一次范围覆盖全部业务写入的改造，不是运维能自己完成的，需要每个业务模块动手。

反过来，如果你的数据本来就能切开——按租户、按地域、按业务线，让每份数据只有一个"主写区"，两边各写各的，那一致性代价会掉一大截。这是判断双活贵不贵的第一道分水岭：能分区的才是便宜的双活，不能分区的双活买的是数据库团队的排期。

第三处：长期演练与人力。 双活不是上线那天成立，是每一次变更之后仍然成立。

真实故障里最常见的画面是这样的：切换脚本上一次被完整跑通是两年前；DNS 的 TTL 设成了 600 秒，等于切换至少要等十分钟生效；连接池配置里写死了某个内网地址；证书轮换后两边不一致。这些都不会在评审 PPT 上出现，只会在凌晨三点出现。

要维持双活，你得定期把它真的切一次（白天没人敢切，半夜切就得有人值班），要有人对切换结果负责。这一格是永续的人力成本，通常比资源费更让财务意外，因为它不出现在采购单上。

停机一小时到底赔多少钱：先把这个数字写下来

值不值，取决于这一句。三类系统口径完全不同，别混着算。

收入直连型（下单、支付、结算、对外 API 计费）：挂一小时约等于少收一小时的钱，再叠加转化流失——用户在你这儿下不了单，他不会等你，他去对手那儿了，这部分人不会回来。这类系统算出来的数字最有说服力，也最容易撑住双活的预算。

效率型（内部系统、后台、报表、审批流）：挂一小时的损失 = 受影响人数 × 一小时人力成本 × 无法绕过的比例。注意最后那个系数：如果销售可以回手写单子、财务可以第二天补录，真实损失比"全员停摆"小得多。这类系统上双活，账常常算不过来——不是双活不好，是你买的东西比需要的贵。

合规型（数据不能丢、要留痕、有上报义务）：这一类的关键不是"挂多久"，是"丢不丢"。挂四小时但数据一条不少，可能完全没事；反过来一次数据丢失就是罚则和客户信任。这类系统该把钱花在备份可恢复性和恢复演练上，双活对"数据不丢"的贡献远小于它对"服务不断"的贡献——很多人把这两件事当成一件，钱就花错方向了。

算法很简单：年预期停机小时 × 每小时损失，对比双活年成本 + 一致性改造的一次性投入 + 每年演练人力。前者小于后者，双活就不该是这一轮的答案；前者明显大于后者，再往下走。

这里有个坑要提醒：别拿"行业平均可用性"或者供应商 PPT 里的"99.99%"当代入值。你手上那次故障就是真实数据——它挂了多久、影响了多少人、赔了什么。一次样本也比没有样本强。

比双活便宜得多、又确实管用的那一档

多数中小规模的系统，真正该做的不是把可用性堆高，而是把恢复时间压下来。下面四件事的成本都在双活的一个零头以内，收益当天可见。

第一件：把数据库做成能自动切换的高可用。 整套系统里最致命的单点通常不是应用——应用挂了重启、替换、扩容都很便宜；数据库挂了，写不进去、读不出来，恢复还牵涉数据完整性。主从加自动故障转移，比双活便宜一个量级，却正好打在那个最疼的点上。

第二件：先跨可用区，再谈跨城。 同一个地域内的多个可用区之间延迟只有毫秒级，你的数据一致性假设基本不用改；而跨城就是另一个物理世界，几十毫秒的往返会把前面说的一致性改造成本全部激活。对绝大多数业务，跨可用区已经消灭了"整个机房没了"这一类风险，剩下的"整个城市出问题"概率低到不值得为它重构写路径。

第三件：让应用层无状态、能快速扩出一份。 会话、文件、临时状态只要落在应用实例本地，恢复就得靠"那台机器回来"。把它们挪到外部存储之后，恢复动作从"修一台机器"变成"再起十台"，后者是云厂商最擅长的事。

第四件：写一份切换预案，并且每季度真的演练一次。 这一件几乎不花钱，但它决定前三件在真实故障里到底生不生效。预案要写到"谁在什么条件下点哪个按钮"这个颗粒度，而不是"由运维团队负责处理"。演练的判据也很实在：从故障发生到服务恢复，秒表量一次，看时间花在哪一步——通常是等人、等权限、等一个没写在预案里的确认。

确实该上双活的四个条件

• 停机直接等于收入损失，而且每小时损失 × 年预期停机小时明显大于双活的年总成本；
• 合同或监管层面对可用性有承诺，罚则是明确的、可执行的；
• 用户分布在多个地域，单一地域故障的影响面大到不可接受；
• 数据能分区，每份数据只有一个主写区，不需要处理跨区写冲突。

四条里最后一条是前提。前三条决定"值不值"，最后一条决定"做不做得起"。如果数据切不开，同城双活的项目排期会从"运维配个环境"变成"所有业务模块改一轮"，报价单上那一行数字只是开始。

三个自查问题

• 你上一次故障，从发生到恢复具体是多久？这段时间里，有多少是技术恢复时间、多少是"找到能拍板的人 + 拿到权限 + 决定切不切"？如果后者占一半以上，你现在最该买的不是双活，是一份预案。
• 你的系统里，去掉应用之后还剩几个单点？把它们列出来，通常只剩三个：数据库、消息或队列、外部依赖（第三方接口、证书、DNS）。双活是一次性把三个都解决，但多数预算只够解决第一个。
• 如果明天整个机房消失，你多久能重新有一套能对外服务的系统？答不出具体小时数，说明备份的可恢复性从来没被验证过——这一格比双活便宜得多，也危险得多。

读完能做什么决定

• 先分清你要买哪一档：备份、冷备、双活，价格台阶式上涨，收益不是线性的。
• 双活的成本大头不是那两份机器，是数据一致性改造（覆盖全部写路径）和永续的演练人力；判断贵不贵先看数据能不能分区。
• 把"停机一小时赔多少钱"写成一个财务口径的数字，分收入直连、效率、合规三类算，再和双活年成本对比。
• 多数非收入直连的系统，这一轮的答案应该是那四件便宜事：数据库高可用、跨可用区、应用无状态化、写下来并季度演练的预案。
• 四个条件都满足再上双活，尤其别跳过最后一条：数据切不开的双活，做的是数据库团队的排期，不是可用性。