客户挑战
客户是新加坡持牌保险公司，核心业务系统跑在 AWS EKS 上，配套 消息队列、EFS、S3 等 AWS 原生服务。业务健康时一切顺畅，但 MAS 与内部审计要求：
- 一旦 AWS 区域出现问题，业务能在本地机房恢复
- 恢复过程能被演练、可被观察、可以出审计报告
- 恢复流程不能停留在”纸面预案” —— 必须能被真正操作
客户原有的 DR 方案是”备份 + 文档” —— 出事再靠人肉一步步来。这在 MAS 视角下已经不够。
我们的方案
TWO TWO 用 Jumborca SupDRC + SupKube 搭建 AWS 到本地机房的跨云、跨环境容灾架构：
1. Kubernetes 层：EKS ↔ 本地 K8s
- 通过 SupKube 把 AWS EKS 上的工作负载（Deployment / StatefulSet / Service / ConfigMap / Secret）结构性同步到本地机房的 Kubernetes 集群
- 本地 K8s 集群按客户流量画像预留容量，随时可承接生产切换
2. 数据层：EFS / S3 → 本地存储
- EFS 文件数据 同步到本地对应的分布式文件系统
- S3 对象存储 通过 SupDRC 的对象同步机制复制到本地对象存储
- 消息队列（保险业务的核心事件流）同步策略确保切换时消息不丢
3. 编排层：SupDRC runbook
- SupDRC 提供 runbook 脚本引擎，把”发现故障 → 检查状态 → 停写 AWS → 拉起本地 K8s → 切换 DNS/入口 → 通知业务团队”整个流程编码成可执行脚本
- 一键容灾切换 —— 从操作台发起，几个关键 checkpoint 自动完成，不再靠人肉记忆
- 演练可被定期跑，出结构化审计报告
4. 7×24 本地运维
TWO TWO 本地值班团队负责跨云同步状态监控、演练支持、故障响应；客户 IT 团队参与关键决策，日常运营由我们承担。
客户成果
- 跨云容灾架构真正可执行 —— AWS EKS ↔ 本地 K8s 结构性一致，业务能在本地恢复
- 一键切换 —— 通过 SupDRC runbook，从”纸面预案”变成”操作台按钮”
- 可演练 —— 定期演练，出审计报告，MAS 视角下有说服力
- 本地运维 —— 7×24 有人值守，客户 IT 团队不再是恢复流程的单点
完整案例受 NDA 约束。如需了解架构设计、交付时间线与运维模式，欢迎联系我们做一次私密沟通。