भुगतान पुनर्प्राप्ति पाइपलाइन और रनबुक (Payment Recovery Pipeline And Runbooks)

पिछले अनुभाग में, हमने देखा कि भुगतान आईडी, चरण ईवेंट लॉग और स्थगित अंतिम मेट्रिक्स के साथ सहसंबंध कैसे ऑपरेशन को फ़ीड करता है। यह अनुभाग पुनर्प्राप्ति पाइपलाइन को देखता है जो उस दृश्यता पर आधारित है: जब कोई भुगतान फंस जाता है तो सिस्टम पहले स्वयं क्या कर सकता है, और मानव कब हस्तक्षेप करता है?

एक अच्छी पुनर्प्राप्ति पाइपलाइन का सिद्धांत सरल है: स्वचालन पहले। सुलह कार्यकर्ता, अटका हुआ द्रष्टा, पुनः प्रयास करने वाला कार्यकर्ता - ये मानवीय हस्तक्षेप की आवश्यकता के बिना अधिकांश बहावों को साफ़ करते हैं। मानव रनबुक तभी चलन में आती है जब स्वचालन विशिष्टता या अस्पष्ट साक्ष्य की दीवारों से टकराता है।```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ı.
```रनबुक 'क्या करें' प्रश्न का उत्तर देता है; साक्ष्य-संचालित रनबुक इस प्रश्न का उत्तर देती है कि 'सबूत के बिना क्या नहीं किया जा सकता?'

## स्वचालन से पहले: पुनर्प्राप्ति पाइपलाइन परतें

पुनर्प्राप्ति पाइपलाइन कोई एकल कार्यकर्ता नहीं है, बल्कि परतें हैं जो एक दूसरे की पूरक हैं। प्रत्येक परत उस बात को संबोधित करती है जिसे पिछली परत हल नहीं कर सकी; किसी को भी अगले का काम करने का प्रयास नहीं करना चाहिए।```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` बनाने का प्रयास करता है - लेकिन डेटाबेस में समान idempotency कुंजी के साथ पहले से ही एक पंक्ति `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
```रनबुक में प्रत्येक निर्णय बिंदु के लिए प्रमाण की आवश्यकता होती है। 'पीएसपी का कहना है कि पकड़ लिया गया लेकिन स्थानीय समय सीमा समाप्त हो गई' → चंगा उम्मीदवार। 'पीएसपी नहीं मिला, स्थानीय प्रसंस्करण' → धनवापसी, प्रतीक्षा या आगे बढ़ने का उम्मीदवार नहीं। 'दो कैप्चर की गई लाइनें, अलग-अलग इडेम्पोटेंसी कुंजी' → दोहरा चार्ज, एक रिफंड।

## मैन्युअल समीक्षा कतार: दृश्यमान प्रतीक्षा

जिन रिकॉर्ड्स का स्वचालन समाधान नहीं कर सकता, उन्हें चुपचाप गायब नहीं होना चाहिए। मैन्युअल समीक्षा कतार एक दृश्य क्षेत्र है जहां ये रिकॉर्ड जमा होते हैं, पुराने होते हैं और प्राथमिकता दी जाती है।

| क्षेत्र | उद्देश्य |
| --- | --- |
| भुगतान आईडी | सहसंबंध |
| अटकने का कारण | यूनिकनेसवॉल / अस्पष्ट साक्ष्य / पीएसपीअज्ञात |
| साक्ष्यसारांश | चरण लॉग + पीएसपी क्वेरी सारांश |
| वही | वह कब से इंतज़ार कर रहा है |
| प्राथमिकता | राशि, ग्राहक शिकायत, एसएलए |

कतार में प्रत्येक रिकॉर्ड को रनबुक चरण से मेल खाना चाहिए; ऑपरेटर को कतार से 'क्या करें' प्रश्न पढ़ने में सक्षम होना चाहिए।

## रनबुक उदाहरण: अद्वितीयता दीवार के बाद```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

| स्थिति | स्वचालन | मानव रनबुक |
| --- | --- | --- |
| क्षणिक समयबाह्य | पुनः प्रयास करें कार्यकर्ता | जरूरी नहीं |
| वृद्ध फाइनलाइज पेंडिंग | सुलह | जरूरी नहीं |
| नपुंसकता संघर्ष | वह रुकता है और कतार में लिखता है | सबूत जुटाओ, फैसला करो |
| अस्पष्ट पीएसपी प्रतिक्रिया | वह रुकता है और कतार में लिखता है | आगे बढ़ें या प्रतीक्षा करें |

## रिकवरी पाइपलाइन चेकलिस्ट

1. क्या पुनः प्रयास, अटका हुआ द्रष्टा और सुलह परतें अलग-अलग और क्रमिक रूप से काम करती हैं?
2. क्या विशिष्टता बाधा उल्लंघन स्वचालित रूप से मैन्युअल समीक्षा कतार में लिखा जाता है?
3. क्या प्रत्येक रनबुक चरण स्पष्ट रूप से परिभाषित करता है कि उसे किस साक्ष्य की आवश्यकता है?
4. क्या मैन्युअल समीक्षा कतार में रिकॉर्ड उम्र और प्राथमिकता के आधार पर क्रमबद्ध हैं?
5. क्या मानवीय हस्तक्षेप के बाद ऑडिट रिकॉर्डिंग और स्टेप इवेंट लॉग प्रविष्टि अनिवार्य है?
6. क्या स्वचालन द्वारा हल की गई दर को मीट्रिक रूप से ट्रैक किया जाता है (automation_resolution_rate)?

## इस लेख से आपको क्या याद रखना चाहिए

1. पुनर्प्राप्ति पाइपलाइन स्वचालन प्रथम सिद्धांत के साथ स्तरित है; मनुष्य अंतिम सहारा है.
2. विशिष्टता दीवार स्वचालन को रोकती है - यह सुरक्षा कोई बग नहीं है।
3. रनबुक साक्ष्य-आधारित होनी चाहिए; प्रतिवर्ती क्रिया खतरनाक है.
4. मैन्युअल समीक्षा कतार अनसुलझे रिकॉर्ड को चुपचाप गायब होने से रोकती है।

> एक अच्छी पुनर्प्राप्ति पाइपलाइन मानवीय हस्तक्षेप को शून्य तक कम करने का प्रयास नहीं करती है - यह मानवीय हस्तक्षेप को सही समय, सही साक्ष्य और सही प्रक्रिया तक सीमित करती है।

अगले भाग में, हम मैसेजिंग परत पर आते हैं: बिल्कुल-एक बार झूठ है; गहराई से रक्षा के साथ प्रभावी-एक बार कार्य परिणाम कैसे प्राप्त करें?