n8n में API incident workflow बनाएँ: validation, approval और उपयोगी failure signals

सुरक्षित तरीका: पहले diagnosis, remediation सिर्फ approval के बाद

API incident workflow को हर failed request पर अपने-आप कोई fix नहीं करना चाहिए। 503, malformed success response और timeout अलग-अलग observations हैं; ये एक ही root cause साबित नहीं करते। n8n में evidence capture करने, उसकी जाँच करने, संभावित कारणों का सारांश बनाने और किसी भी महत्वपूर्ण action को approve कराने के लिए अलग-अलग चरण बनाएँ।

नीचे दिया गया उदाहरण समझाने के लिए है, यह tested workflow export नहीं है। Node labels और response fields आपके API और n8n version के अनुसार अलग हो सकते हैं। मुख्य design principle यह है कि AI Agent से उसका अर्थ समझाने को कहने से पहले failure signal साफ़ तौर पर दिखे।

ज़रूरी चीज़ें और workflow की रूपरेखा

आपको ऐसा n8n workflow चाहिए जो API check को schedule कर सके या उसका event प्राप्त कर सके, monitored API के credentials और incident notifications भेजने की जगह चाहिए। अगर AI Agent का इस्तेमाल करना है, तो उसका model configure करें और उसे सिर्फ़ उतना evidence दें जितना ज़रूरी है। Remediation tools तभी उपलब्ध कराएँ जब उनकी स्पष्ट ज़रूरत हो—और उनके लिए human review ज़रूरी रखें।

एक उपयोगी रूपरेखा:

1. Trigger: scheduled check चलाएँ या incident event प्राप्त करें।
2. HTTP Request: health endpoint या संबंधित API operation को call करें।
3. Validate: status और अपेक्षित response fields जाँचें; timeout और request errors को सामान्य response से अलग पहचानें।
4. Evidence को normalize करें: timestamp, endpoint label, status, उपलब्ध होने पर latency और संक्षिप्त error detail वाला एक incident object बनाएँ।
5. Diagnosis: AI Agent से संभावित कारणों और evidence की कमियों का सारांश माँगें। ज़रूरत हो तो read-only tools जोड़ें।
6. Notify या approve करें: संक्षिप्त incident report भेजें। किसी tool को state बदलने की अनुमति देने से पहले human review अनिवार्य करें।
7. नतीजा दर्ज करें: action approve हुआ, deny हुआ या fail—यह दर्ज करें और संबंधित channel को सूचित करें।

API failure signals को स्पष्ट करें

सिर्फ़ एक “failed” flag पर निर्भर न रहें। कम-से-कम इन स्थितियों की जाँच करें:

• Transport failure: request timeout हो, connection न हो पाए या उपयोगी response मिलने से पहले fail हो जाए।
• HTTP failure: API non-success status लौटाए। Status code और जहाँ उचित हो, सुरक्षित रूप से छोटा किया गया error body दर्ज करें।
• Contract failure: response मिल जाए, लेकिन ज़रूरी fields मौजूद न हों या उनके types अपेक्षा से अलग हों।
• Business failure: HTTP request सफल हो, लेकिन response में application-level error बताया गया हो।

एक साधारण उदाहरण के लिए मान लें कि endpoint को status में ok और service field वाला JSON object लौटाना चाहिए। Validation step में इसके बराबर logic कुछ ऐसा हो सकता है:

const body = $json;
const valid = body.status === 'ok' && typeof body.service === 'string';

return [{
  json: {
    valid,
    signal: valid ? 'healthy' : 'contract_failure',
    service: typeof body.service === 'string' ? body.service : null,
    observedAt: new Date().toISOString(),
  },
}];

इस उदाहरण में माना गया है कि HTTP node पहले ही parsed response body दे चुका है। इसे node के वास्तविक output और आपके API contract के अनुसार ढालें। Request-error handling इस तरह configure करें कि failures उस branch तक पहुँचें जो error दर्ज करती है, न कि वे incident path से गायब हो जाएँ। Credentials, authorization headers और संवेदनशील response data को notifications और AI prompts से बाहर रखें।

Incident record से इन सवालों के जवाब मिलने चाहिए: क्या जाँचा गया, क्या अपेक्षित था, क्या देखा गया और क्या देखा नहीं जा सका? अज्ञात signal को पक्के diagnosis में न बदलें।

AI को evidence दें, अधिकार नहीं

AI Agent को एक संक्षिप्त incident object दें, उदाहरण के लिए:

{
  "endpoint": "orders-health",
  "observedAt": "2025-01-15T12:00:00Z",
  "signal": "http_failure",
  "statusCode": 503,
  "expected": "HTTP success and status=ok",
  "observed": "HTTP 503; response body omitted"
}

ये values सिर्फ़ उदाहरण हैं। Production में वास्तविक timestamp और response evidence का इस्तेमाल करें; बिना उचित ज़रूरत के secrets या customer data शामिल न करें। Agent से कहें कि वह देखे गए facts और hypotheses को अलग रखे, missing evidence बताए और अगली read-only जाँच सुझाए। एक उपयोगी निर्देश है: “जब तक दिया गया evidence समर्थन न करे, किसी root cause का दावा न करें। Evidence पर्याप्त न हो, तो बताएँ कि किस अतिरिक्त observation से मदद मिलेगी।”

Read-only tools से हाल का deployment record लिया जा सकता है या monitoring system से query की जा सकती है—अगर आपने वे tools connect और configure किए हों। यह न मानें कि कोई खास integration या parameter schema उपलब्ध है: tool के documented inputs जाँचें और उसे non-production data से test करें।

बदलावों से पहले human approval रखें

Service restart करने, record बदलने या बाहरी message भेजने जैसे actions के लिए human review step वाला n8n AI Agent tool इस्तेमाल करें। n8n के दस्तावेज़ बताते हैं कि workflow approval के लिए रुक सकता है; approved tool, AI द्वारा बताए गए input के साथ चलता है, जबकि denied call रद्द हो जाता है। आपके configuration के आधार पर approval, Slack या n8n Chat interface जैसे supported channels के ज़रिए भेजा जा सकता है। n8n की human-in-the-loop tool guidance देखें।

Reviewer को फैसला करने के लिए पर्याप्त context दें: incident identifier, देखे गए signals, प्रस्तावित action, प्रभावित service और tool के सटीक parameters। Documentation review context बनाने के लिए $tool.name और $tool.parameters का उल्लेख करता है। Agent के system prompt में बताएँ कि किन tools के लिए approval ज़रूरी है, denial का क्या मतलब है और reviewer के मना करने पर उसे कैसे जवाब देना चाहिए। Approval को इस बात का प्रमाण न मानें कि प्रस्तावित action सुरक्षित है; reviewer को फिर भी अनुरोध का आकलन करना होगा।

Denied action कोई ऐसी exception नहीं है जिसे छिपा दिया जाए। “नहीं किया गया” वाला नतीजा भेजें, diagnosis सुरक्षित रखें और कोई सुरक्षित अगला कदम सुझाएँ—जैसे escalation या एक और read-only जाँच।

ऐसा failure handling जो on-call responder के काम आए

हर incident path का अंत किसी उपयोगी नतीजे पर होना चाहिए:

• Validation सफल: observation दर्ज करें और incident उठाए बिना check बंद करें।
• Signal unhealthy है: evidence और diagnosis भेजें और अनिश्चितता साफ़-साफ़ बताएँ।
• Diagnostic step fail हुआ: बताएँ कि कौन-सा lookup fail हुआ; missing data को negative finding के तौर पर पेश न करें।
• Approval deny हुआ: बताएँ कि remediation नहीं की गई और अगला owner या निर्णय क्या है।
• Approved action fail हुआ: tool error रिपोर्ट करें और मूल incident context बनाए रखें।

अगर बार-बार होने वाली जाँचें channel को भर सकती हैं, तो service और incident window जैसे deduplication key का उपयोग करें। बार-बार आने वाले alerts को कितनी देर तक एक group में रखना है, यह अपनी monitoring practice के अनुसार तय करें; यह workflow pattern कोई सार्वभौमिक interval तय नहीं करता। Workflow पर निर्भर होने से पहले timeout, non-success status, malformed response, missing diagnostic data, denial और remediation failure को test करें।

दोबारा इस्तेमाल की जा सकने वाली review checklist

• क्या transport errors, HTTP errors और invalid response bodies को अलग-अलग पहचाना जा सकता है?
• क्या हर alert में अपेक्षित और देखा गया behavior तथा timestamp दिखता है?
• क्या secrets और अनावश्यक personal या customer data बाहर रखे गए हैं?
• क्या evidence अधूरा होने पर AI-generated explanations को hypotheses के रूप में चिह्नित किया जाता है?
• क्या state-changing tools human review के पीछे हैं और reviewer को parameters दिखते हैं?
• क्या approval denial और tool failure को साफ़ तौर पर नतीजे के रूप में दर्ज किया जाता है?
• क्या आपने सिर्फ़ healthy path नहीं, बल्कि हर failure branch test की है?

भरोसेमंद design यह नहीं है कि “AI API incidents ठीक करता है।” यह ऐसा workflow है जो failures को स्पष्ट करता है, AI से evidence व्यवस्थित करवाता है और महत्वपूर्ण बदलावों पर इंसानी नियंत्रण बनाए रखता है।