शब्दों का अर्थ
Request path में रहने वाला हर check उत्तर देने में असफल हो सकता है: कोई dependency समय समाप्त कर सकती है, कोई signal missing हो सकता है, कोई key fetch नहीं हो सकती. Fail open का मतलब है कि request ऐसे आगे बढ़ती है जैसे वह check मौजूद ही न हो. Fail closed का मतलब है कि request अधिक सख्त path लेती है: उसे deny किया जाता है, challenge किया जाता है, या किसी मौजूदा अधिक मजबूत control पर भेजा जाता है.
इनमें से कोई भी सामान्य रूप से सही नहीं है. सही चुनाव इस पर निर्भर करता है कि route क्या करता है और गलत निर्णय की लागत क्या है.
Actor checks के लिए यह क्यों महत्वपूर्ण है
Actor checks requests में context जोड़ते हैं: interaction human जैसा दिखता है, AI-assisted है, agent-driven है, या unknown है. जब वह context उपलब्ध नहीं होता, तब भी application को response देना होता है. दो failure patterns आम हैं:
- अनजाने में fail closed. Timeout या missing signal को suspicious मान लिया जाता है, और outage के दौरान real users block हो जाते हैं.
- संवेदनशील actions पर अनजाने में fail open. Missing result को चुपचाप human मान लिया जाता है, और high-impact action अपेक्षा से कम scrutiny के साथ आगे बढ़ जाता है.
दोनों ही इसलिए होते हैं क्योंकि चुनाव स्पष्ट नहीं होता. समाधान है इसे प्रति route स्पष्ट रूप से तय करना. हमारे humans और AI agents के लिए app-level policies design करने वाले लेख में दिखाया गया है कि failure behavior प्रति-route policy में कैसे फिट होता है.
कैसे चुनें
एक व्यावहारिक तरीका है routes को risk tiers में बांटना:
- कम प्रभाव (public pages, documentation, read-only catalog routes): fail open. Missing actor result को कुछ भी बदलना नहीं चाहिए.
- मध्यम प्रभाव (signups, form submissions, लागत वाले searches): आम तौर पर logging के साथ fail open, या standard rate limit जैसी हल्की adaptation लागू करें.
- उच्च प्रभाव (account changes, data exports, अपरिवर्तनीय actions): fail closed को अपने मौजूदा अधिक मजबूत control पर fall back करें, जैसे re-authentication या confirmation. उद्देश्य block करना नहीं है, बल्कि उसी check पर लौटना है जिसका आप वैसे भी उपयोग करते.
फिर संबंधित मामलों के लिए वही व्यवहार परिभाषित करें:
- Timeout: check ने समय पर उत्तर नहीं दिया.
- Missing telemetry: integration नहीं चला या कोई signal अनुपस्थित था.
- Unknown: check चला, लेकिन evidence किसी determination का समर्थन नहीं कर सका.
- Stale evidence: result पहले का है और अधिक संवेदनशील action के लिए दोबारा उपयोग नहीं किया जाना चाहिए.
सामान्य गलतफहमियां
- "Fail closed अधिक सुरक्षित है." यह लागत को legitimate users पर डाल देता है. कम प्रभाव वाले routes के लिए incident के दौरान fail closed करना उस risk से अधिक नुकसान कर सकता है जिसे यह रोकता है.
- "Unknown एक failure है." Unknown एक valid result है. इसके लिए अपनी अलग स्पष्ट handling होनी चाहिए, जो आपके timeout handling से मेल भी खा सकती है और नहीं भी.
- "Missing result का मतलब human है." Evidence की अनुपस्थिति से कभी भी actor class infer न करें.
Proof of Actor इसे कैसे संभालता है
Proof of Actor किसी timeout या Unknown result पर कभी Human assign नहीं करता, और इसे install करने से कुछ block नहीं होता: teams observation mode में शुरू करती हैं. हर route और risk tier के लिए fail-open या fail-closed व्यवहार application owner की choice है, जिसे Route के माध्यम से आपके अपने code में लागू किया जाता है. इससे enforcement predictable रहती है और policy live होने से पहले आप outcomes की जांच कर सकते हैं.
Routing decisions कैसे fit होते हैं पढ़ें, या early access के लिए apply करें.