ਸ਼ਬਦਾਂ ਦਾ ਅਰਥ
ਜੋ ਵੀ check request path ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਉਹ answer ਦੇਣ ਵਿੱਚ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ: ਕੋਈ dependency timeout ਕਰ ਜਾਵੇ, ਕੋਈ signal ਗਾਇਬ ਹੋਵੇ, ਜਾਂ ਕੋਈ key fetch ਨਾ ਹੋ ਸਕੇ। Fail open ਦਾ ਮਤਲਬ ਹੈ ਕਿ request ਐਸੇ ਹੀ ਅੱਗੇ ਵਧਦੀ ਹੈ ਜਿਵੇਂ check ਮੌਜੂਦ ਹੀ ਨਾ ਹੋਵੇ। Fail closed ਦਾ ਮਤਲਬ ਹੈ ਕਿ request ਕੜਾ path ਲੈਂਦੀ ਹੈ: ਉਸਨੂੰ deny ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, challenge ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਮੌਜੂਦਾ ਹੋਰ ਮਜ਼ਬੂਤ control ਵੱਲ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਹੀ ਨਹੀਂ ਹੁੰਦਾ। ਸਹੀ ਚੋਣ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ route ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਗਲਤ decision ਦੀ ਕੀਮਤ ਕੀ ਹੈ।
Actor checks ਲਈ ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
Actor checks requestਾਂ ਵਿੱਚ context ਜੋੜਦੇ ਹਨ: interaction Human ਵਰਗੀ ਲੱਗਦੀ ਹੈ, Human + AI, Agent-driven ਜਾਂ Unknown। ਜਦੋਂ ਇਹ context ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ application ਨੂੰ ਫਿਰ ਵੀ response ਦੇਣਾ ਪੈਂਦਾ ਹੈ। ਦੋ failure patterns ਆਮ ਹਨ:
- ਅਣਜਾਣੇ ਵਿੱਚ fail closed। Timeout ਜਾਂ ਗੁੰਮ signal ਨੂੰ suspicious ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ outage ਦੌਰਾਨ ਅਸਲੀ users block ਹੋ ਜਾਂਦੇ ਹਨ।
- Sensitive actions 'ਤੇ ਅਣਜਾਣੇ ਵਿੱਚ fail open। ਗੁੰਮ result ਨੂੰ ਚੁੱਪਚਾਪ Human ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ high-impact action ਉਮੀਦ ਨਾਲੋਂ ਘੱਟ scrutiny ਨਾਲ ਅੱਗੇ ਵਧ ਜਾਂਦੀ ਹੈ।
ਦੋਵੇਂ implicit choice ਛੱਡਣ ਤੋਂ ਪੈਦਾ ਹੁੰਦੇ ਹਨ। ਇਸਦਾ ਹੱਲ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਹਰ route ਲਈ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਤੈਅ ਕੀਤਾ ਜਾਵੇ। Humans ਅਤੇ AI agents ਲਈ app-level policies design ਕਰਨ ਬਾਰੇ ਸਾਡੀ post ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ failure behavior per-route policy ਵਿੱਚ ਕਿਵੇਂ fit ਕਰਦਾ ਹੈ।
ਕਿਵੇਂ ਚੁਣਨਾ ਹੈ
ਇੱਕ practical approach routes ਨੂੰ risk tiers ਵਿੱਚ ਵੰਡਣ ਦੀ ਹੈ:
- Low impact (public pages, documentation, read-only catalog routes): fail open। ਗੁੰਮ actor result ਨੂੰ ਕੁਝ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ।
- Medium impact (signups, form submissions, cost ਵਾਲੀਆਂ searches): ਆਮ ਤੌਰ 'ਤੇ logging ਨਾਲ fail open ਕਰੋ, ਜਾਂ standard rate limit ਵਰਗੀ ਹਲਕੀ adaptation ਲਗਾਓ।
- High impact (account changes, data exports, ਨਾ ਮੁੜ-ਉਲਟਣ ਯੋਗ actions): ਆਪਣੇ ਮੌਜੂਦਾ ਹੋਰ ਮਜ਼ਬੂਤ control ਵੱਲ fail closed ਕਰੋ, ਜਿਵੇਂ re-authentication ਜਾਂ confirmation। ਮਕਸਦ block ਕਰਨਾ ਨਹੀਂ, ਸਗੋਂ ਉਸ check ਵੱਲ ਵਾਪਸ ਜਾਣਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ ਵਰਤਦੇ।
ਫਿਰ related cases ਲਈ ਉਹੀ behavior define ਕਰੋ:
- Timeout: check ਨੇ ਸਮੇਂ 'ਤੇ answer ਨਹੀਂ ਦਿੱਤਾ।
- Missing telemetry: integration ਨਹੀਂ ਚੱਲੀ ਜਾਂ ਕੋਈ signal ਮੌਜੂਦ ਨਹੀਂ ਸੀ।
- Unknown: check ਚੱਲੀ ਪਰ evidence ਨੇ determination ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕੀਤਾ।
- Stale evidence: result ਪੁਰਾਣਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਹੋਰ sensitive action ਲਈ ਦੁਬਾਰਾ ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੀਦਾ।
ਆਮ ਗਲਤਫ਼ਹਮੀਆਂ
- "Fail closed ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ." ਇਹ legitimate users 'ਤੇ ਲਾਗਤ ਧੱਕ ਦਿੰਦਾ ਹੈ। Low-impact routes ਲਈ incident ਦੌਰਾਨ fail closed ਹੋਣਾ ਉਸ risk ਨਾਲੋਂ ਵੱਧ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਇਹ ਰੋਕਦਾ ਹੈ।
- "Unknown ਇੱਕ failure ਹੈ." Unknown ਇੱਕ ਵੈਧ result ਹੈ। ਇਸਦੀ ਆਪਣੀ explicit handling ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਜੋ ਤੁਹਾਡੇ timeout handling ਨਾਲ ਮਿਲ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ ਵੀ।
- "ਗੁੰਮ 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 behavior application owner ਦੀ ਚੋਣ ਹੈ, ਜੋ Route ਰਾਹੀਂ ਤੁਹਾਡੇ ਆਪਣੇ code ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਇਸ ਨਾਲ enforcement ਅਨੁਮਾਨਯੋਗ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਕੋਈ policy live ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ outcomes ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ।
routing decisions ਕਿਵੇਂ fit ਕਰਦੀਆਂ ਹਨ ਪੜ੍ਹੋ, ਜਾਂ early access ਲਈ apply ਕਰੋ।