付款回收管道和操作手册 (Payment Recovery Pipeline And Runbooks)

在上一节中，我们了解了付款 ID、步骤事件日志和延迟完成指标的相关性如何为操作提供支持。本节着眼于建立在这种可见性基础上的恢复管道：当支付陷入困境时，系统首先可以自行做什么，以及人类何时介入？

良好的恢复管道的原则很简单：自动化第一。协调工作者、卡住的观察者、重试工作者——这些无需人工干预即可清除大多数漂移。只有当自动化遇到独特性或模棱两可的证据时，人类操作手册才会发挥作用。```text Ödeme takıldı → otomatik: reconciliation scan → otomatik: retry with backoff → otomatik: PSP status query → insan: uniqueness wall / ambiguous evidence

## 第一次提到的概念```text
📦 Recovery Pipeline
Takılan veya tutarsız ödemeleri otomatik olarak teşhis edip düzeltmeye çalışan ardışık işlem hattı.

📦 Uniqueness Wall
Veritabanı benzersizlik kısıtının, güvenli replay veya heal girişimini engellediği durum.

📦 Evidence-Driven Runbook
Her adımın hangi kanıta (step log, PSP sorgusu, audit) dayandığını tanımlayan operasyon kılavuzu.

📦 Manual Review Queue
Otomasyonun çözemediği kayıtların biriktiği, görünür bekleme alanı.
```Runbook 回答了“做什么”的问题；以证据为导向的操作手册回答了“没有证据就不能做什么？”的问题。

## 自动化之前：恢复管道层

恢复管道不是单个工作人员，而是相互补充的各层。每一层都解决前一层无法解决的问题；任何一方都不应该尝试做下一个的工作。```text
Katman 1: Retry worker
  → transient hataları backoff ile tekrar dener

Katman 2: Stuck watcher
  → lease süresi dolmuş, Processing'de kalan kayıtları sıfırlar

Katman 3: Reconciliation sweeper
  → aged FinalizePending / Expired kayıtları PSP ile karşılaştırır

Katman 4: Manual review queue
  → otomasyonun çözemediği kayıtlar
```1-3 级是全自动的，足以满足一天中的大部分时间。第 4 层不是管道的故障，而是其边界的可见性。

## 独特墙：自动化停止的地方

协调工作人员从 PSP 中看到“成功”，并尝试创建本地记录 `Captured` — 但数据库中已经存在具有相同幂等键的行 `Captured`。插入或更新失败；自动化停止。```text
Reconciliation: payment #5521 → PSP says Captured
  → local UPDATE attempt
  → UNIQUE constraint violation on idempotency_key
  → otomasyon durur
  → manual review queue'ya yaz
```这不是一个错误，而是一种保护机制。唯一性墙可以防止双重最终确定，但它也可以防止自动化说“我解决了问题”。这就是基于证据的操作手册发挥作用的地方。

## 基于证据的操作手册：程序，而不是反射

当需要人工干预时，操作手册遵循以下顺序：```text
1. Step event log'u oku (payment id ile)
2. PSP status query yap (provider gateway üzerinden)
3. Local kayıtları karşılaştır (payment, order, idempotency)
4. Kanıt tablosunu doldur
5. Karar: heal / refund / no-action
6. Audit kaydı yaz
```运行手册中的每个决策点都需要证明。 “PSP 说已捕获但本地已过期”→ 治疗候选者。 “未找到 PSP，本地处理”→ 不适合退款、等待或升级。 ‘两条捕获的行，不同的幂等键’→双倍收费，退还一条。

## 手动审核队列：可见等待

自动化无法解决的记录不应悄然消失。手动审核队列是一个可见区域，这些记录在此累积、老化并确定优先级。

|面积 |目的|
| --- | --- |
|付款ID |相关性|
|卡住原因 | UniquenessWall / 模糊证据 / PSPUnknown |
|证据总结 |步骤日志+PSP查询汇总|
|同上|他等了多久了|
|优先|金额、客户投诉、SLA |

队列中的每条记录必须与 Runbook 步骤匹配；操作员应该能够从队列中读取“做什么”的问题。

## Runbook 示例：独特性墙之后```text
Durum: reconciliation Captured yazamadı — idempotency_key conflict

Kanıt toplama:
  □ Step log: FinalizeAttempted iki kez mi?
  □ Mevcut Captured satırı hangi webhook'tan geldi?
  □ PSP query: kaç charge var bu correlation id ile?

Karar ağacı:
  → Tek PSP charge, local çift satır → eski satırı audit ile kapat
  → İki PSP charge → birini refund et (runbook: duplicate charge)
  → PSP charge yok → local Captured yanlış → escalate

经常混淆的区别```text

❌ Manual review queue = otomasyon başarısız oldu ✓ Manual review queue = otomasyonun sınırı görünür ve güvenli

❌ Runbook = deneyimli mühendisin sezgisi ✓ Runbook = kanıt tabanlı, tekrarlanabilir prosedür

❌ Uniqueness wall kaldırılmalı ✓ Uniqueness wall korunmalı; runbook duvarın ötesini yönetir

|状态 |自动化|人类操作手册|
| --- | --- | --- |
|瞬时超时 |重试工作人员 |没有必要|
|老化最终确定待定 |和解|没有必要|
|幂等性冲突 |他停下来写信给队列 |收集证据，做出决定 |
| PSP 回应模棱两可 |他停下来写信给队列 |升级或等待 |

## 恢复管道清单

1. 重试、卡住的观察者和协调层是否单独且按顺序工作？
2. 唯一性约束违规是否会自动写入手动审核队列？
3. 运行手册的每个步骤是否明确定义了它需要哪些证据？
4. 手动审核队列中的记录是否按年龄和优先级排序？
5. 人工干预后是否必须进行审核记录和步骤事件日志输入？
6. 是否以度量方式跟踪自动化解决率（automation_resolution_rate）？

## 本文中您应该记住的内容

1、恢复管道分层，自动化优先原则；人是最后的手段。
2. 独特性墙阻止自动化——这种保护不是一个错误。
3. 操作手册应以证据为基础；反射动作是危险的。
4. 手动审核队列可防止未解决的记录悄然消失。

> 良好的恢复流程并不试图将人为干预减少到零，而是将人为干预限制在正确的时刻、正确的证据和正确的程序。

在下一节中，我们将深入到消息传递层：exactly-once 是一个谎言；如何做到纵深防御、一次见效？