影刀RPA店群自动化灾难恢复与业务连续性实战：备份、切换与数据丢失预防

影刀RPA店群自动化灾难恢复与业务连续性实战：备份、切换与数据丢失预防

店群自动化系统跑久了，你一定会被问一个问题：
“万一挂了，多久能恢复？”
我们曾经被这个问题问住过。因为真的没有认真想过。
直到有一次，机房光纤被挖断，整个主控中心失联6小时。虽然执行节点还在离线运行，但任务调度完全停摆，新任务无法创建，运营只

那次之后，我们花了三个月，建立了一套完整的灾难恢复与业务连续性体系。
这篇文章不讲脚本，也不讲调度。专门聊聊店群自动化系统的备份策略、故障切换、数据丢失预防和恢复演练。

适用场景：对可用性要求高的店群平台、SaaS服务商。

技术栈：跨区域备份、RTO/RPO设计、主备切换、故障演练。

一、先定义两个数字：RTO和RPO

任何灾备体系，都绕不开两个核心指标：

• RTO（恢复时间目标）：从故障发生到系统恢复服务，最多能容忍多久？
• • RPO（数据丢失容忍度）：故障发生时，最多能容忍丢失多长时间的数据？
    我们根据业务影响，给店群系统定了分级目标：
    | 组件 | RTO | RPO | 说明 |
    |------|-----|-----|------|
    | 调度器 | 5分钟 | 1分钟 | 短时间不可用，任务堆积但不会丢 |
    | 任务队列 | 2分钟 | 0 | 绝对不能丢任务 |
    | 配置中心 | 10分钟 | 5分钟 | 配置变更不频繁 |
    | 店铺数据 | 1小时 | 15分钟 | 可从平台重新同步 |
    | 操作日志 | 不要求快速恢复 | 24小时 | 非关键数据 |
    不同的组件，备份和恢复策略不同。核心是：任务队列不能丢，调度器要能快速切换。

二、任务队列的持久化与跨区域复制

任务队列是系统的命脉。我们使用Redis，但Redis默认的持久化（RDB/AOF）在灾难场景下不够用。
我们做了三层保护：

第一层：AOF持久化 + 每秒同步

appendonly yes appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb ``` **第二层：跨区域异步复制** 使用Redis主从，但跨区域部署。主Redis在区域A，从Redis在区域B。采用异步复制，网络延迟约50ms，数据丢失窗口小于1秒。 **第三层：双写消息队列 + 归档** 每个任务在进入Redis队列的同时，也写入一个“归档队列”（Kafka或Pulsar）。归档队列持久化到磁盘，保存7天。即使Redis全部丢失，也可以从归档重建任务。 ```python # task_archiver.py class TaskArchiver: def __init__(self, redis_client, kafka_producer): self.redis = redis_client self.kafka = kafka_producer def push_task(self, task): # 写入Redis队列 self.redis.lpush("task_queue", json.dumps(task)) # 同时写入Kafka归档 self.kafka.send("task_archive", value=task, headers=[("timestamp", str(time.time()))]) ``` 当Redis队列损坏需要恢复时，我们从Kafka中读取过去几小时的任务，重放到新的Redis。 --- ## 三、主控中心的跨区域热备 调度器是无状态的，难点在于状态存储（任务队列、分布式锁、配置）。我们采用了“主备双活 + 自动切换”模式。 **主区域**：香港（主Redis + 主调度器Pod） **备区域**：新加坡（备Redis + 备调度器Pod，待命） 正常情况下，所有流量走主区域。备区域不接收写请求，但实时同步数据。 切换逻辑使用**全局一致性健康检查**： ```python # failover_controller.py class FailoverController: def __init__(self): self.primary_region = "hk" self.backup_region = "sg" self.health_check_interval = 5 def check_primary_health(self): # 检查主区域调度器API try: resp = requests.get("http://scheduler.hk.internal/health", timeout=3) if resp.status_code == 200 and resp.json().get("status") == "ok": return True except: pass # 检查Redis连通性 try: redis_hk.ping() return True except: pass return False def switch_to_backup(self): # 1. 将DNS/负载均衡指向备区域 self.update_dns("scheduler.api", "sg") # 2. 将备Redis提升为主（如果复制中断） redis_sg.slaveof("no", "one") # 3. 启动备调度器（如果未运行） k8s.scale_deployment("scheduler-sg", replicas=3) # 4. 发送告警 alert("主区域故障，已切换至新加坡") ``` 切换需要人工确认吗？我们设计成**自动切换 + 人工确认回切**。自动切换的条件非常严格：主区域连续3次健康检查失败（15秒），且备区域健康。切换后，人工负责验证业务恢复，再决定何时切回。 **坑**：自动切换后，原主区域可能恢复（网络闪断）。这时需要防止“脑裂”——两个区域同时写。我们的方案：原主区域恢复后，自动转为备模式，拒绝写请求，等待人工介入。 --- ## 四、数据备份策略：全量+增量+跨区域 数据库和配置文件需要定期备份。我们采用： - **数据库**：每日全量备份（北京时间凌晨3点），每小时增量备份（WAL日志）。备份存储到同区域的对象存储，并异步复制到另一个区域。 - - **店铺Profile目录**：每6小时增量备份（只备份变更的文件）。Profile很大（每个几百MB），全量备份太占空间。 - - **脚本代码**：存在Git仓库，本身就是分布式备份。 备份保留策略： | 数据类 | 日备份保留 | 周备份保留 | 月备份保留 | |--------|-----------|-----------|-----------| | 数据库 | 7天 | 4周 | 12个月 | | Profile | 3天 | 2周 | 不保留月备份 | | 日志 | 30天 | 不保留 | 不保留 | 我们每月做一次恢复演练：从备份中恢复一个完整的测试环境，验证数据完整性。曾经发现备份脚本有问题，增量备份一直没有成功，全靠全量备份撑着。修复后增加了备份校验（每次备份后计算checksum，与上一次对比）。 --- ## 五、灾难场景分类与应对预案 我们把可能发生的灾难分成几类，每类有对应的预案。 **场景一：单节点故障** - 现象：某个执行节点宕机 - - 应对：调度器自动将任务分配给其他节点（已有负载感知机制） - - RTO：<10秒 - - 演练频率：每周（通过混沌实验） **场景二：整个可用区（AZ）故障** - 现象：云服务商的一个数据中心断电/网络中断 - - 应对：K8s集群跨AZ部署，Pod自动漂移到健康AZ - - RTO：<2分钟 - - 演练频率：每月 **场景三：整个区域（Region）故障** - 现象：香港区域全部不可用 - - 应对：执行跨区域切换，备区域接管 - - RTO：<5分钟 - - 演练频率：每季度 **场景四：数据损坏（误删除、bug覆盖）** - 现象：某个店铺数据被错误脚本删除 - - 应对：从备份中恢复该店铺的数据（按时间点恢复） - - RTO：<30分钟（视数据量） - - 演练频率：每半年 每个场景都有详细的SOP文档，并且定期演练。演练时记录实际RTO，与目标对比。如果差距过大，优化流程。 --- ## 六、数据丢失预防：删除保护与回收站 很多数据丢失不是灾难导致的，而是人为误操作。 我们设计了多层防护： **第一层：删除确认** API层面的删除操作，需要二次确认（传递`confirm=true`参数）。同时记录操作人、时间、原因。 **第二层：软删除** 所有关键数据（店铺、任务、脚本）不物理删除，只标记`deleted_at`。保留30天，30天后自动清理或归档。 ```sql ALTER TABLE shops ADD COLUMN deleted_at TIMESTAMP; CREATE INDEX idx_deleted_at ON shops(deleted_at); ``` **第三层：回收站** 对于“批量删除”操作，我们实现了一个回收站机制：删除的数据先移入回收站表，保留7天。7天内可以一键恢复。超过7天，才真正物理删除。 ```python def delete_shop(shop_id): # 将数据移入回收站 shop_data = db.query("SELECT * FROM shops WHERE id=%s", shop_id) db.insert("recycle_bin", { "original_table": "shops", "original_id": shop_id, "data": json.dumps(shop_data), "deleted_by": current_user, "deleted_at": datetime.now() }) db.update("shops", {"deleted_at": datetime.now()}, "id=%s", shop_id) ``` **第四层：操作审计与回滚** 对于批量更新操作（如批量改价），记录操作前后的快照。如果运营发现改错了，可以在后台一键回滚到操作前的状态。 --- ## 七、演练机制：每月一次“断网日” 光有预案不够，必须真刀真枪地练。 我们设立了每月的**断网日**：在周末低峰期，随机选择一个场景进行灾难模拟，记录真实恢复时间。 演练流程： 1. 提前通知所有团队（但不通知具体时间和场景） 2. 2. 混沌工程平台注入故障（如主控区域网络断连） 3. 3. 值班工程师按照SOP执行恢复 4. 4. 记录每个步骤的耗时 5. 5. 业务验证（使用测试店铺跑几个核心任务） 6. 6. 恢复原状，复盘 有一次演练，我们模拟数据库误删除。SOP要求从备份恢复，但备份恢复脚本因为权限问题失败了。复盘后修复了脚本，并增加了备份恢复的自动化测试。 连续演练一年后，团队的恢复能力大幅提升：跨区域切换从最初的15分钟缩短到2.5分钟。 --- ## 八、真实踩坑与教训 **坑1：跨区域切换时，任务队列里的任务状态不一致** 主Redis和备Redis之间是异步复制，切换时可能丢失最后几秒的任务。虽然备Redis有全部数据，但主Redis中有些任务可能已经出队但未完成，切换后这些任务丢失了。 解决：任务出队时不立即删除，而是放入“处理中”队列，并记录时间戳。切换后，新区域的主Redis会扫描“处理中”队列，对超过2倍预估执行时间的任务进行重试。 **坑2：切换后，店铺的Profile目录不匹配** 执行节点的profile目录是本地存储，跨区域切换后，新区域的节点没有这些profile，导致店铺需要重新登录。 解决：Profile目录使用云文件存储（EFS/NFS），跨区域共享（虽然延迟高，但只在切换时使用）。或者切换后，新节点从备份中拉取profile到本地缓存。 **坑3：备份恢复时，数据格式不兼容** 数据库备份是旧版本的Schema，恢复后应用代码已经升级，无法读取。 解决：每次数据库迁移时，同时生成降级脚本。备份文件也记录Schema版本号，恢复时根据版本号决定是否需要先降级。我们要求所有Schema变更必须向前兼容至少2个版本。 **坑4：演练时忘记通知客服团队，客户咨询暴涨** 有一次演练导致任务延迟，客户发现订单状态更新慢了，大量咨询涌入客服。客服团队完全不知情。 解决：演练前必须通知所有相关团队（客服、运营、销售），并在状态页（status.yourdomain.com）发布公告。 --- ## 九、状态页与故障通报自动化 灾难发生时，对内对外都需要及时通报。我们建立了一套自动化通报系统： - 系统检测到重大故障（如主区域不可用），自动在状态页创建“Incident”记录 - - 发送通知到企业微信、钉钉、Slack - - 每5分钟自动更新状态页的故障进展（根据自动化脚本收集的信息） - - 故障恢复后，自动生成RCA（根因分析）草稿，供人工补充 这个机制让客户的焦虑减少了，因为他们能实时看到我们正在处理。 --- ## 十、总结：灾备不是成本，是保险 很多创业团队觉得灾备“没必要”“等出问题再说”。但店群自动化系统一旦成为业务核心，故障的代价可能是几万、几十万的损失。 我们的经验：灾备系统的建设成本大约是主系统的15-20%，但它带来的好处远不止于“万一出事”。 - 定期的演练让团队对系统理解更深 - - 备份机制让你敢于做数据库变更（因为可以回滚） - - 高可用架构提升了日常运维的容错能力 如果你还没有灾备体系，可以从小处开始： 7. 先把数据库每日备份做起来 8. 2. 写一份简单的切换SOP 9. 3. 找个周末手动演练一次 10. 4. 逐步增加自动化程度 记住：**最好的灾备，是平时根本感觉不到，出事后才发现它一直在保护你。** --- 作者：林焱