企业官网建设流程全解析

1. RPA 中断恢复到底在解决什么问题

做过 RPA 的人都有一个共识：流程跑通不难，难的是跑稳。一个自动化流程在开发机上跑一百遍都顺顺利利，一上生产环境，各种幺蛾子就来了——目标系统响应超时、页面元素加载慢了一拍、弹窗突然冒出来挡住按钮、网络抖了一下、甚至机器被人误碰重启了。这些意外一旦发生，传统 RPA 脚本的行为非常"脆"：要么直接抛异常终止，要么卡在某个等待条件上死等，要么带着错误状态继续往下跑，把脏数据写进业务系统。

中断恢复要解决的核心问题就一句话：当流程因为任何原因偏离了预期执行路径时，如何让它以最小的代价回到正轨，或者至少干净地停下来，而不是留下一地鸡毛。

这件事听起来简单，做起来极其复杂。因为"中断"这个词背后藏着至少七八种截然不同的情况：进程崩溃、节点宕机、外部系统不可用、业务规则校验失败、人工干预打断、超时、资源竞争、数据不一致。每一种的恢复策略都不一样，用一套逻辑去兜底所有场景，必然会在某个角落翻车。

我在实际项目里踩过最典型的一个坑：一个财务对账流程，跑到一半目标系统维护重启了，脚本重试了三次都失败，然后按照"失败即终止"的配置直接退出。问题是它退出前已经提交了前半部分的对账结果，后半部分没跑，导致账目对不上，财务同事排查了一整天才定位到是自动化流程留下的半成品。这就是典型的缺少事务边界和恢复语义导致的灾难。

所以这篇文章我想系统性地聊一聊 RPA 中断恢复这件事。我会给出一个我自己在多个生产项目中沉淀下来的七层框架，从最底层的进程守护一直讲到最上层的业务补偿，然后重点讲清楚 AI 在这个框架里能增强哪些环节、怎么增强、以及哪些环节 AI 其实帮不上忙。内容会涉及 Saga 补偿模式、租约机制、检查点设计、幂等性保障这些偏工程的东西，也会给出可以直接抄的配置和代码片段。适合已经写过一些 RPA 流程、正在被稳定性问题折磨的工程师，也适合正在做 RPA 平台架构设计的技术负责人。

2. 七层框架的整体设计与分层逻辑

2.1 为什么是七层而不是三层

很多人第一反应是：中断恢复不就是"重试 + 补偿"吗，搞七层是不是过度设计？我一开始也这么想，直到在一个跨五个系统的采购流程里被现实教育了。

三层模型（检测、重试、补偿）的问题在于，它把不同粒度、不同时间尺度、不同责任主体的恢复动作混在一起。进程崩了和业务校验失败，恢复手段完全不同，但三层模型里它们都叫"异常"。结果就是代码里到处是 if-else，重试逻辑和业务补偿逻辑纠缠在一起，维护成本爆炸。

七层框架的本质是按恢复的粒度和责任边界做切分。每一层只关心自己这一层能处理的中断，处理不了就往上抛，由上层决定是重试、补偿还是终止。这样每一层的逻辑都足够简单，组合起来又能覆盖全部场景。

2.2 七层框架的分层说明

我把这七层从下到上列出来，每一层用一个关键词概括它的核心职责：

这七层不是必须全部实现才能用。小项目可能只需要 L1 到 L4，跨系统的大流程才需要把 L5 到 L7 补齐。但你要清楚每一层解决的是什么问题，缺了哪一层会在什么场景下出问题。

2.3 分层之间的协作关系

层与层之间是向上抛异常、向下要能力的关系。举个具体例子：L3 步骤重试层在重试三次后仍然失败，它不会自己去做业务补偿，而是把"这一步彻底失败了"这个事实抛给 L4。L4 检查点层看到这个失败，会判断当前检查点是否完整，如果不完整就标记流程为"需要恢复"，然后由 L5 事务补偿层决定是回滚已完成的步骤还是从检查点续跑。

这里有个关键设计原则：下层永远不知道上层的存在，上层通过下层的接口来编排。L3 只管重试，它不知道什么叫 Saga；L5 只管补偿，它不关心底层是重试了三次还是三十次。这种解耦让每一层都可以独立测试、独立替换。

注意：分层不等于分层部署。这七层逻辑上分层，物理上完全可以跑在同一个进程里。不要为了"架构清晰"强行拆成七个微服务，那是另一种形式的过度设计。

3. 核心层级的实现细节与实操要点

3.1 L1 进程守护层：让执行器死而复生

进程守护层要解决的是最粗暴的中断：执行器进程本身挂了。原因可能是内存溢出、未捕获异常、操作系统杀进程、机器重启。

实现方式有两种。第一种是用操作系统的守护机制，Linux 下用 systemd 的Restart=always，Windows 下用服务管理器配置自动重启。这种方式简单可靠，但粒度粗，进程一挂就整个重启，正在执行的流程状态全丢。

第二种是在 RPA 框架内部实现心跳和自愈。执行器定期往一个共享存储写心跳时间戳，守护进程扫描心跳，发现超时就拉起新的执行器实例。这种方式可以配合 L4 检查点层，实现"进程重启后从检查点续跑"。

我一般两个都用：systemd 兜底保证进程一定活着，框架内部的心跳机制负责优雅恢复。配置大概长这样：

# /etc/systemd/system/rpa-worker.service [Unit] Description=RPA Worker After=network.target [Service] Type=simple ExecStart=/opt/rpa/worker --config /etc/rpa/worker.yaml Restart=always RestartSec=5 StartLimitBurst=10 StartLimitIntervalSec=300 [Install] WantedBy=multi-user.target

RestartSec=5表示崩溃后等 5 秒再拉起，避免疯狂重启打爆日志。StartLimitBurst=10配合StartLimitIntervalSec=300表示 5 分钟内最多重启 10 次，超过就停止，防止一个必然崩溃的配置无限循环。

3.2 L2 会话保持层：连接断了要能自己接回来

RPA 经常要跟浏览器、数据库、API 打交道，这些连接都可能断。会话保持层要做的是：检测连接失效、重建连接、把重建后的会话上下文恢复到可用状态。

浏览器自动化的会话恢复最麻烦。比如用 Playwright 或 Selenium 控制浏览器，如果浏览器进程崩了，重建一个容易，但页面状态、登录态、已填表单全没了。这时候要么重新走一遍登录和导航，要么用持久化的浏览器上下文（storage state）来恢复登录态。

我的做法是：关键登录态定期持久化，会话重建时优先加载持久化状态，加载失败才走完整登录流程。Playwright 里可以这样操作：

# 保存登录态 context.storage_state(path="auth_state.json") # 重建时加载 context = browser.new_context(storage_state="auth_state.json")

数据库连接用连接池 + 健康检查。连接池配置里有个关键参数叫validationQuery（或者连接池对应的健康检查语句），每次从池里取连接时先 ping 一下，失效的就丢弃重建。这个参数不配的话，池里可能全是已经断掉的死连接，取出来用就报错。

实操心得：会话重建一定要有次数上限和退避。我见过一个流程，目标系统挂了，脚本疯狂重建连接，一秒几十次，把目标系统的日志刷爆了，运维直接找上门。重建间隔至少 1 秒起步，失败次数超过阈值就上报，别硬刚。

3.3 L3 步骤重试层：区分"值得重试"和"重试也没用"

重试是最容易被滥用的恢复手段。很多人一看到异常就加重试，结果把本来应该快速失败的问题拖成了长时间挂起。

重试的前提是：这个故障是瞬时的、可自愈的。网络抖动、目标系统短暂过载、锁竞争，这些重试有意义。但如果是参数错误、权限不足、业务规则校验失败，重试一万次结果都一样，纯属浪费资源。

所以 L3 的第一件事是异常分类。我通常把异常分成三类：

• 可重试异常：超时、连接拒绝、5xx 错误、元素暂时不可见
• 不可重试异常：4xx 错误、参数校验失败、权限拒绝
• 未知异常：默认按不可重试处理，记录详细上下文供人工分析

分类之后是重试策略。指数退避是标配，但参数要调。我的经验值是：初始间隔 1 秒，退避倍数 2，最大间隔 30 秒，最多重试 5 次。这样总耗时大约是 1+2+4+8+16=31 秒，对于大多数瞬时故障足够了。如果 31 秒还恢复不了，那大概率不是瞬时问题，继续重试也没用。

import time import random def retry_with_backoff(func, max_retries=5, base_delay=1, max_delay=30): for attempt in range(max_retries): try: return func() except RetryableError as e: if attempt == max_retries - 1: raise delay = min(base_delay * (2 ** attempt), max_delay) # 加抖动，避免多个实例同时重试造成惊群 delay = delay * (0.5 + random.random()) time.sleep(delay) except NonRetryableError: raise

注意那个抖动（jitter）。如果多个 RPA 实例同时遇到目标系统过载，它们会几乎同时重试，形成新的冲击波。加个 0.5 到 1.5 倍的随机因子，把重试时间打散，能显著降低二次冲击。

3.4 L4 检查点层：断点续跑的基础设施

检查点层是整个恢复框架的地基。没有检查点，进程一挂就只能从头再来；有了检查点，才能实现"从上次成功的地方继续"。

检查点的设计有三个关键决策：存什么、存哪里、什么时候存。

存什么？最小集合是：当前执行到哪个步骤、已完成步骤的输出结果、流程级的上下文变量。不要存整个内存快照，那样太重，而且恢复时很多状态已经失效了。

存哪里？本地文件最简单，但多实例场景下不行。生产环境我一般用 Redis 或者数据库。Redis 快，适合高频写入；数据库持久，适合关键流程。折中方案是 Redis 做热存储、定期落库做冷备份。

什么时候存？每个"业务上有意义的步骤"完成后存一次。什么叫有意义？就是这一步的结果会影响后续步骤的执行。比如"登录成功"是个检查点，"点击了一个按钮"可能不是，除非这个点击改变了业务状态。

检查点还要配合幂等键使用。恢复时从检查点续跑，可能会重复执行检查点之后的步骤。如果这些步骤不是幂等的，就会产生重复数据。幂等键的作用是让重复执行变成无害操作。

# 检查点结构示例 checkpoint = { "flow_id": "purchase_20240115_001", "current_step": "submit_order", "completed_steps": ["login", "select_product", "fill_address"], "context": { "order_id": "ORD123456", "idempotency_key": "purchase_20240115_001_submit" }, "timestamp": "2024-01-15T10:30:00Z" }

注意：检查点写入必须是原子的。我见过用普通文件写入做检查点的，写到一半进程挂了，恢复时读到一个损坏的 JSON，直接解析失败。用 Redis 的 SET 或者数据库事务，或者写临时文件再 rename，保证要么完整要么不存在。

3.5 L5 事务补偿层：Saga 模式在 RPA 里的落地

跨多个系统的 RPA 流程，本质上就是一个分布式事务。传统两阶段提交在 RPA 场景下不现实，因为很多目标系统根本不支持事务接口。这时候就要用Saga 模式。

Saga 的核心思想是：把一个大事务拆成一串本地事务，每个本地事务都有一个对应的补偿操作。如果某一步失败，就反向执行前面已成功步骤的补偿操作，把系统恢复到一致状态。

在 RPA 里，Saga 的落地方式是这样的：

class SagaStep: def __init__(self, name, action, compensation): self.name = name self.action = action # 正向操作 self.compensation = compensation # 补偿操作 class SagaOrchestrator: def __init__(self): self.steps = [] self.completed = [] def add_step(self, step): self.steps.append(step) def execute(self): for step in self.steps: try: step.action() self.completed.append(step) except Exception as e: self.compensate() raise def compensate(self): # 反向补偿 for step in reversed(self.completed): try: step.compensation() except Exception as e: # 补偿失败要告警，人工介入 log_critical(f"补偿失败: {step.name}", e)

举个实际例子。一个采购流程：创建采购单 → 扣减库存 → 生成付款单 → 通知供应商。如果"生成付款单"失败，补偿操作就是：恢复库存 → 取消采购单。注意补偿顺序是反的，先恢复库存再取消采购单，因为采购单取消后可能不允许再操作库存。

补偿操作有两个难点。第一是补偿本身也可能失败，这时候不能无限重试，要记录到"待人工处理"队列，同时告警。第二是有些操作不可补偿，比如已经发出去的邮件、已经通知的供应商。对于不可补偿的操作，要么把它放到流程最后，要么设计成"可撤销"的形式（比如发一封更正邮件）。

3.6 L6 租约协调层：多实例并发下的接管机制

当 RPA 流程需要多实例并发执行时，中断恢复就多了一个维度：一个实例挂了，它的任务谁来接管？

答案是租约（Lease）。每个实例在执行任务时，先申请一个带过期时间的租约。执行过程中定期续约。如果实例挂了，租约到期自动释放，其他实例可以申请这个租约并接管任务。

租约的关键参数是过期时间和续约间隔。过期时间太短，实例稍微卡一下租约就丢了，导致任务被重复执行；过期时间太长，实例挂了之后要等很久才能被接管。我的经验值是：续约间隔 10 秒，过期时间 30 秒，也就是允许连续两次续约失败。

class LeaseManager: def __init__(self, redis_client, lease_ttl=30): self.redis = redis_client self.ttl = lease_ttl def acquire(self, task_id, worker_id): # SET NX 保证原子性 key = f"lease:{task_id}" acquired = self.redis.set(key, worker_id, nx=True, ex=self.ttl) return bool(acquired) def renew(self, task_id, worker_id): key = f"lease:{task_id}" # Lua 脚本保证"检查持有者 + 续约"的原子性 lua = """ if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('expire', KEYS[1], ARGV[2]) else return 0 end """ return self.redis.eval(lua, 1, key, worker_id, self.ttl)

续约必须用 Lua 脚本保证原子性，否则会出现"检查时还是自己持有，续约前被别人抢走"的竞态。这个坑我在早期项目里踩过，表现为任务偶尔被两个实例同时执行，排查了很久才发现是续约的竞态问题。

接管任务时，接管的实例要先读检查点，从检查点续跑，而不是从头开始。这就是 L4 和 L6 的配合。

3.7 L7 业务语义层：让恢复决策理解业务

前面六层解决的都是"技术上的中断恢复"。但有些中断，技术上流程没断，业务上已经错了。比如：目标系统返回了一个"成功"状态，但实际业务规则要求这个操作不应该成功；或者流程跑完了，但结果不符合业务预期。

L7 要做的是在恢复决策中引入业务语义。最简单的形式是规则引擎：定义一组业务规则，流程执行到关键节点时校验规则，不满足就触发特定的恢复动作。

AI 在这一层能发挥的空间最大。传统规则引擎只能处理预定义的规则，遇到没见过的情况就抓瞎。而大模型可以基于流程上下文做推理，判断"当前这个异常状态，最可能的恢复动作是什么"。

比如一个订单处理流程，某一步返回了"库存不足"。规则引擎只能告诉你"库存不足，流程终止"。但大模型可以结合上下文推理：这个订单是 VIP 客户的，历史上有过缺货先发后补的记录，建议走"缺货登记 + 优先补发"的补偿路径。这种判断传统规则很难覆盖。

不过 L7 的 AI 增强要非常谨慎。AI 的建议必须经过人工确认或者严格的规则校验才能执行，不能让大模型直接决定补偿动作。原因很简单：补偿操作往往涉及资金、库存、客户关系，错了代价很大。AI 适合做"建议者"，不适合做"决策者"。

4. AI 增强路径：哪些环节值得用 AI，怎么用

4.1 AI 增强的边界：先搞清楚 AI 不擅长什么

在聊 AI 能做什么之前，我想先泼盆冷水。中断恢复的核心是确定性和可靠性，而大模型天生是不确定的。同一个输入，大模型两次调用可能给出不同答案。这在恢复决策场景里是危险的。

所以 AI 增强的第一原则是：AI 只用在"决策辅助"和"模式识别"环节，不用在"执行"环节。执行环节必须是确定性的代码，AI 的输出要经过校验才能转化为执行动作。

具体来说，AI 不适合做这些事：直接执行补偿操作、直接修改检查点、直接决定是否重试。AI 适合做这些事：异常根因分析、恢复策略建议、日志模式识别、测试用例生成。

4.2 用 AI 做异常根因分析

RPA 流程失败时，日志里往往有一大堆信息：异常堆栈、截图、页面 HTML、网络请求记录。人工分析这些信息很耗时，尤其是当失败原因很隐蔽时。

大模型可以吃下这些上下文，给出根因假设。我实际用下来的效果是：对于常见异常（元素找不到、超时、登录失效），大模型的判断准确率相当高；对于复杂的业务逻辑异常，大模型能给出一两个有价值的排查方向，但需要人工验证。

实现方式是把异常上下文组装成 prompt，让模型输出结构化的分析结果：

def analyze_failure(context): prompt = f""" 以下是一个 RPA 流程失败时的上下文信息： 异常类型：{context['exception_type']} 异常信息：{context['exception_message']} 当前步骤：{context['current_step']} 页面 URL：{context['page_url']} 页面截图描述：{context['screenshot_desc']} 最近的操作序列：{context['recent_actions']} 请分析： 1. 最可能的根因是什么 2. 这个异常是否可重试 3. 建议的恢复动作 以 JSON 格式输出，字段为 root_cause, retryable, suggested_action。 """ response = llm_client.chat(prompt) return parse_json(response)

关键是输出结构化。不要让模型自由发挥写一大段分析，那样没法程序化处理。用 JSON schema 约束输出，解析失败就降级到默认策略。

4.3 用 AI 做恢复策略推荐

比根因分析更进一步的是恢复策略推荐。当流程在某个检查点失败时，AI 可以基于历史成功恢复案例，推荐最可能有效的恢复路径。

这需要先积累一个"恢复案例库"：每次人工处理完一个中断，把"异常特征 → 采取的恢复动作 → 结果"记录下来。积累到一定量之后，用这些案例做 few-shot 提示，让模型推荐恢复动作。

def recommend_recovery(failure_context, case_library): similar_cases = retrieve_similar(failure_context, case_library, top_k=3) prompt = f""" 当前失败上下文： {failure_context} 历史上相似的失败案例及处理方式： {format_cases(similar_cases)} 请推荐最可能的恢复动作，并说明理由。 可选动作：retry, skip_step, rollback, restart_from_checkpoint, manual_intervention """ return llm_client.chat(prompt)

这里的retrieve_similar可以用向量检索，把异常特征向量化后找最相似的案例。这个方案我在一个电商订单流程里试过，恢复动作推荐的命中率大概在 70% 左右，剩下 30% 需要人工判断。虽然不完美，但已经能显著减少人工介入的频率。

4.4 用 AI 做日志模式识别和告警降噪

RPA 流程多了之后，告警会爆炸。同一个根因可能触发几十条告警，运维根本看不过来。AI 可以做告警聚类：把语义相似的告警归为一组，只推送一条代表性告警。

实现思路是把告警文本向量化，做聚类，每个簇选一条代表。这个用传统 NLP 也能做，但大模型对语义的理解更好，尤其是当告警文本包含大量业务术语时。

另一个用法是异常模式发现。大模型可以分析历史失败日志，发现人类没注意到的模式。比如"每周一早上 9 点的失败率明显高于其他时段"，可能指向目标系统周一早上的批处理任务导致的资源竞争。这种洞察对优化流程很有价值。

4.5 AI 增强的工程化注意事项

把 AI 引入恢复框架，有几个工程上的坑必须注意。

第一是延迟。大模型调用通常要几百毫秒到几秒，如果放在关键路径上会拖慢恢复速度。我的做法是：AI 分析异步进行，不阻塞主恢复流程。主流程先用默认策略恢复，AI 分析结果出来后再决定是否需要调整。

第二是成本。每次失败都调大模型，token 消耗很快。要设置采样率，比如只对"未知异常"和"高频失败"调用 AI，常见异常直接用规则处理。

第三是降级。大模型服务可能不可用，必须有降级路径。AI 调用失败时，回退到规则引擎或者默认策略，不能因为 AI 挂了导致整个恢复流程卡住。

第四是审计。AI 给出的每个建议、最终采取的动作、结果，都要记录。这既是为了排查问题，也是为了积累训练数据。

实操心得：AI 增强不要一上来就全量铺开。先在一个非关键流程上试点，积累案例库，验证效果，再逐步推广。我见过团队一上来就把 AI 决策接进核心资金流程，结果模型幻觉导致一次错误补偿，损失不小。AI 是增强，不是替代，这个定位要摆正。

5. 常见问题与排查技巧实录

5.1 恢复后重复执行导致数据重复

这是最高频的问题。流程从检查点续跑，检查点之后的步骤被重复执行，如果这些步骤不幂等，就会产生重复数据。

排查思路：先确认检查点记录的位置是否准确。常见错误是检查点记录在"步骤开始前"而不是"步骤完成后"，导致恢复时这一步被重跑。检查点必须在步骤成功完成后写入。

解决方法是给每个写操作加幂等键。幂等键的生成规则要保证：同一个业务操作，无论执行多少次，幂等键都一样。通常用"流程ID + 步骤名 + 业务主键"组合。

5.2 租约续约失败导致任务被重复接管

表现是同一个任务被两个实例执行。根因通常是续约的竞态，或者续约间隔设置不合理。

排查时先看租约的续约日志，确认续约是否按时发生。如果续约正常但任务还是被接管，检查续约操作是否原子。用 Redis 的话，GET+EXPIRE两步操作不是原子的，必须用 Lua 脚本或者SET XX配合EXPIRE。

另一个常见原因是时钟漂移。如果多个实例的时钟不一致，租约的过期判断会出错。生产环境要保证所有实例的时钟同步。

5.3 补偿操作本身失败

补偿失败是最棘手的情况，因为系统已经处于不一致状态，而自动恢复手段又失效了。

处理原则是：补偿失败必须告警，并且记录到待人工处理队列。不要试图无限重试补偿，那只会让情况更糟。同时，补偿操作要尽量设计得简单可靠，避免补偿逻辑本身很复杂。

我的一般做法是给补偿操作也加重试，但重试次数比正向操作少（比如 2 次），失败后立即告警。告警信息要包含：流程ID、失败的补偿步骤、当前系统状态、建议的人工处理方式。

5.4 检查点数据损坏

前面提过，检查点写入不是原子的话，进程崩溃时可能留下损坏的数据。恢复时读到损坏数据，解析失败，流程无法续跑。

排查方法是检查检查点的写入方式。如果是文件写入，确认是否用了"写临时文件 + rename"的原子模式。如果是 Redis，确认是否用了单条命令写入（SET是原子的，HSET多条字段不是）。

预防措施是给检查点加版本号和校验和。恢复时先校验，校验失败就降级到上一个有效检查点，或者从头开始。

5.5 AI 分析结果不可用

AI 返回的结果解析失败、格式不对、或者内容明显不合理，这些都会发生。

处理方式是永远不要假设 AI 输出一定可用。解析失败就降级到规则策略，同时记录这次失败用于后续优化 prompt。内容不合理的话，加一层校验：比如 AI 建议的恢复动作必须在允许的动作列表里，不在列表里就丢弃。

下面这张表汇总了常见问题和排查方向，可以当作速查表用：

5.6 几个容易被忽略的细节

日志要带流程ID和检查点ID。排查恢复问题时，没有这两个 ID 基本没法定位。每条日志都要带上，包括 AI 分析的日志。

恢复动作要可观测。每次恢复触发了什么动作、结果如何，要有独立的指标。这样才能知道恢复框架本身是否健康。我一般会监控：恢复触发次数、恢复成功率、补偿失败率、AI 建议采纳率。

定期演练恢复流程。恢复逻辑平时不跑，真出问题时才发现有 bug，那就晚了。我建议每个月做一次故障注入演练，手动杀掉执行器进程，验证恢复流程是否正常工作。

6. 从框架到落地：我的实施建议

七层框架听起来完整，但落地要分阶段。我的建议是先做 L1 到 L4，把基础打牢，再考虑 L5 到 L7。

L1 到 L4 是恢复能力的地基。没有进程守护，进程挂了就全完；没有检查点，恢复就只能从头再来；没有重试，瞬时故障就会导致流程失败。这四层做完，流程的稳定性会有质的提升，投入产出比最高。

L5 事务补偿层在跨系统流程里是必须的，但如果你的流程只操作一个系统，而且这个系统本身支持事务，那可以先不做。判断标准是：流程失败时，会不会留下不一致的中间状态。会，就需要补偿；不会，可以先跳过。

L6 租约协调层只在多实例并发场景下需要。单实例跑的话，用不上。但要注意，即使现在单实例，如果未来可能扩展，租约的接口可以先预留。

L7 业务语义层和 AI 增强是锦上添花。先把前六层做扎实，再考虑用 AI 优化。AI 能提升恢复的智能化程度，但替代不了确定性的恢复机制。

最后分享一个我在多个项目里验证过的经验：恢复框架的复杂度要和流程的业务价值匹配。一个每天跑一次、失败了人工重跑就行的流程，不需要七层框架。一个每分钟跑一次、失败会影响资金安全的流程，七层都不一定够。先评估流程的中断代价，再决定投入多少做恢复。这个判断做对了，后面的技术选型才不会跑偏。