香港服务器要不要做异地容灾？从Threema“被殃及”说起

8月14日，瑞士加密通讯商Threema发了一篇复盘博客，把上周那次故障讲清楚了：8月11日周二晚上，服务整整瘫了四个小时（当地时间19:30到23:30），周三上午又断断续续，直到中午12点23分才恢复正常。原因是一连串大规模DDoS攻击。

DDoS本身不稀奇，天天都有。这篇复盘值得多看两眼的，是三个细节。

第一，挨打的不只是Threema。攻击同时打向了它的机房托管商——苏黎世的Nine。Threema自己也承认，说不清这波攻击到底是冲着自己来的，还是同时打了多个目标。换句话说，它很可能只是"被殃及"的那一个。

第二，Threema走的是colocation托管模式：硬件是自己的，放在Nine的机房里。这次机器本身没出任何问题，坏的是机房的网络。这一点对所有托管用户都很扎心——机柜、电力、上联带宽都是"房东"的，房东的上联被打满，你的机器再健康也出不了流量。

第三，用Threema OnPrem私有化部署的企业客户全程没受影响，因为服务跑在客户自己的基础设施上。同一家厂商、同一套软件，那几天的可用性完全取决于服务落在谁的篮子里。

还有个小插曲：故障期间Threema的状态页恰好也出了问题——官方说明是和攻击无关的技术故障——对外通报一度只能靠社交媒体顶着。事后他们补的功课包括：加了一层上游DDoS清洗，把攻击流量挡在自家基础设施之前；状态页则要扩展出事件历史和RSS订阅。

对用香港服务器跑业务的人来说，这件事的映射关系相当直接。

一台机器扛所有：三种故障，只躲得过一种

很多业务的架构是一台香港服务器打天下：网站、数据库、文件、定时任务全在一台机器上。平时相安无事，出了问题才发现，故障其实不止一种。

最常见的是机器级故障：硬盘坏、内存报错、系统起不来。这类最好处理，服务商换硬件，你从备份恢复，几个小时能解决——前提是你真有备份，而且备份没和数据放在同一块盘上。

再往上是机房和线路级故障，Threema这次就是典型：你什么都没做错，机器也没坏，但托管商的网络被打了，业务照样不可用，而且什么时候恢复完全不由你掌控。放到香港的场景里，对应的是海缆中断、上游线路拥塞、同机房其他租户被大流量攻击波及。前几年几次海缆事故期间，部分香港机房出现过国际方向延迟飙升、临时调整路由的情况，性质是一样的。

最上面一层是区域级的极端情况，比如台风导致的断电和大面积网络调整。概率低，但真发生时，放在同城的"备份机"会和主力机一起失联。

单台机器加本机备份，只能覆盖第一层。第二、三层，要靠异地。

中小业务要的不是双活，是一条保命线

一说异地容灾，很多人第一反应是双活——太贵、太复杂，小业务不配。其实中小业务需要的从来不是双活，而是一条保命线：主节点挂掉时，能在可接受的时间里，把核心功能在另一个地方拉起来。这条线可以做得很省。

数据是底线。在另一个故障域放一台低配备援机（比如香港主力搭一台美国机器，或者反过来），数据库做异步主从复制，静态文件和配置用rsync或对象存储定期同步。备援机不需要和主力同配置，第一步只保证一件事：数据在别处还有一份，而且够新。

切换靠DNS。把域名解析的TTL降到300秒以内，平时流量全部指向主节点；主节点出事时，手动或由监控触发，把解析切到备援节点。生效时间大致等于TTL，几分钟内全球用户会陆续切过去。这套方案不追求秒级切换，追求的是"确定能切"。

备援跑降级版。低配机扛不住全量业务很正常，提前准备一个只保核心功能的版本，再挂一条公告：电商保住下单和查订单，社区保住登录和浏览。用户对"功能变少但能用"的容忍度，远高于"完全打不开"。

最后是演练。Threema的状态页在故障期间掉链子这件事说明：没真正切过的方案，都只是一份文档。每季度挑个低峰期，真实走一遍"主节点断网—DNS切换—备援接管"的全流程，顺手把切换手册改到最新。演练还有个附带收获——你会提前知道，自己的对外通报渠道（状态页、群公告、客服话术）在主节点挂掉时还能不能用。

主备节点怎么选

原则只有一条：不共享故障域。不同机房、不同上游线路，最好不同地区。

香港主力加美国备援是常见搭配：香港节点保住内地和亚太用户的访问体验，美国节点带宽单价低、扛流量能力强，平时还能兼做备份存储、跑离线任务，不至于纯闲置。预算再紧一点，备援用一台按月付费的云服务器也够——出事之前，它只需要安静地保持数据同步；真出事了，再临时升配顶上。

Threema的上游清洗和新版状态页，都是挨打之后补的课。托管用户能做的，是把这堂课上在前面：一台备援机，加一套真演练过的切换流程，成本不高。但下次机房"被殃及"的时候，它决定的是你的业务停摆四个小时，还是只慢了五分钟。