പദങ്ങൾ എന്താണ് അർത്ഥമാക്കുന്നത്
ഒരു request path ൽ ഇരിക്കുന്ന ഓരോ check നും മറുപടി നൽകാതെ പോകാൻ കഴിയും: ഒരു dependency timeout ആകുന്നു, ഒരു signal ഇല്ലാതാകുന്നു, ഒരു key fetch ചെയ്യാൻ കഴിയില്ല. Fail open എന്നത് ആ check ഇല്ലാത്തതുപോലെ request മുന്നോട്ട് പോകുന്നു എന്നർത്ഥം. Fail closed എന്നത് request കൂടുതൽ കർശനമായ path സ്വീകരിക്കുന്നു എന്നർത്ഥം: അത് നിഷേധിക്കപ്പെടുന്നു, challenge ചെയ്യപ്പെടുന്നു അല്ലെങ്കിൽ നിലവിലുള്ള കൂടുതൽ ശക്തമായ control ലേക്ക് അയക്കപ്പെടുന്നു.
സാമാന്യമായി രണ്ടിലും ഒന്നും ശരിയല്ല. ശരിയായ തിരഞ്ഞെടുപ്പ് ആ route എന്താണ് ചെയ്യുന്നത്, തെറ്റായ ഒരു തീരുമാനത്തിന് എത്ര ചെലവുണ്ടാകും എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
actor checks ന് ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്
Actor checks request കൾക്ക് context നൽകുന്നു: ഇടപെടൽ human ആണോ, AI സഹായത്തോടെയാണോ, agent-driven ആണോ, unknown ആണോ എന്നത്. ആ context ലഭ്യമല്ലാത്തപ്പോൾ പോലും application response നൽകേണ്ടതുണ്ട്. രണ്ട് failure pattern കൾ സാധാരണമാണ്:
- അസാധുതയിൽ fail closed. ഒരു timeout അല്ലെങ്കിൽ ഇല്ലാത്ത signal സംശയാസ്പദമായി കണക്കാക്കപ്പെടുന്നു, outage സമയത്ത് യഥാർത്ഥ users block ചെയ്യപ്പെടുന്നു.
- സെൻസിറ്റീവ് action കൾക്ക് തെറ്റായ fail open. ഒരു missing result നിശബ്ദമായി human ആയി കണക്കാക്കപ്പെടുന്നു, പ്രതീക്ഷിച്ചതിനേക്കാൾ കുറവ് scrutiny യോടെ ഒരു ഉയർന്ന സ്വാധീനമുള്ള action മുന്നോട്ട് പോകുന്നു.
ഇരുവും തിരഞ്ഞെടുപ്പ് പരോക്ഷമായി വിടുന്നതിൽ നിന്നാണ് വരുന്നത്. പരിഹാരം അത് വ്യക്തമായി, ഓരോ route നും പ്രത്യേകം തീരുമാനിക്കുകയാണ്. മനുഷ്യരും AI agents ഉം സംബന്ധിച്ച app-level policies രൂപകൽപ്പന ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ post ൽ (/blog/designing-app-policies-for-humans-and-ai-agents) failure behavior per-route policy യിൽ എങ്ങനെ ഉൾപ്പെടുന്നു എന്ന് കാണിക്കുന്നു.
എങ്ങനെ തിരഞ്ഞെടുക്കാം
പ്രായോഗികമായ ഒരു സമീപനം routes നെ risk tier കളായി ഗ്രൂപ്പ് ചെയ്യുന്നതാണ്:
- കുറഞ്ഞ സ്വാധീനം (public pages, documentation, read-only catalog routes): fail open. Missing actor result ഒന്നും മാറ്റരുത്.
- മധ്യ സ്വാധീനം (signups, form submissions, cost ഉള്ള searches): സാധാരണയായി logging സഹിതം fail open, അല്ലെങ്കിൽ standard rate limit പോലുള്ള ഒരു ചെറിയ adaptation പ്രയോഗിക്കുക.
- ഉയർന്ന സ്വാധീനം (account മാറ്റങ്ങൾ, data exports, തിരികെ മാറ്റാനാകാത്ത actions): re-authentication അല്ലെങ്കിൽ confirmation പോലുള്ള നിലവിലുള്ള കൂടുതൽ ശക്തമായ control ലേക്ക് fail closed ചെയ്യുക. ഉദ്ദേശം block ചെയ്യുക എന്നതല്ല, എങ്കിൽ പോലും നിങ്ങൾ ഉപയോഗിക്കുമായിരുന്ന check ലേക്ക് തിരിച്ചുപോകുക എന്നതാണ്.
അതിനുശേഷം ബന്ധപ്പെട്ട കേസുകൾക്ക് ഒരേ behavior നിർവചിക്കുക:
- Timeout: check സമയത്ത് മറുപടി നൽകിയില്ല.
- Missing telemetry: integration പ്രവർത്തിച്ചില്ല അല്ലെങ്കിൽ ഒരു signal ഇല്ലായിരുന്നു.
- Unknown: check പ്രവർത്തിച്ചു, പക്ഷേ evidence ഒരു തീരുമാനത്തെ പിന്തുണച്ചില്ല.
- Stale evidence: result പഴയതാണ്, കൂടുതൽ സെൻസിറ്റീവ് action ക്കായി അത് വീണ്ടും ഉപയോഗിക്കരുത്.
സാധാരണ തെറ്റിദ്ധാരണകൾ
- "Fail closed കൂടുതൽ സുരക്ഷിതമാണ്." അത് legitimate users ലേക്ക് ചെലവ് മാറ്റുന്നു. കുറഞ്ഞ സ്വാധീനമുള്ള routes ക്ക്, incident സമയത്ത് fail closed ചെയ്യുന്നത് തടയുന്ന risk നേക്കാൾ കൂടുതൽ നാശം വരുത്താം.
- "Unknown എന്നത് ഒരു failure ആണ്." Unknown ഒരു സാധുവായ result ആണ്. അതിന് സ്വന്തം explicit handling വേണം, അത് നിങ്ങളുടെ timeout handling നോട് ഒത്തുപോകാമോ ഇല്ലയോ എന്നത് വേറെയാണു.
- "Missing result human എന്നാണ് അർത്ഥം." evidence ഇല്ലാത്തതിനാൽ ഒരു actor class നിഗമനം ചെയ്യരുത്.
Proof of Actor ഇതിനെ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു
Proof of Actor ഒരു timeout നും Unknown result നും Human നായി ഒരിക്കലും assign ചെയ്യില്ല, install ചെയ്താൽ ഒന്നും block ചെയ്യുന്നില്ല: ടീമുകൾ (/learn/glossary/observation-mode) observation mode ൽ തുടങ്ങുന്നു. ഓരോ route നും risk tier നും വേണ്ട fail-open അല്ലെങ്കിൽ fail-closed behavior application owner ന്റെ തിരഞ്ഞെടുപ്പാണ്, Route വഴി നിങ്ങളുടെ സ്വന്തം code ൽ പ്രയോഗിക്കപ്പെടുന്നു. അത് enforcement പ്രവചിക്കാവുന്നതാക്കുകയും ഏതെങ്കിലും policy live ആകുന്നതിന് മുമ്പ് outcomes പരിശോധിക്കാനും നിങ്ങളെ അനുവദിക്കുകയും ചെയ്യുന്നു.
റouting തീരുമാനങ്ങൾ എങ്ങനെ ചേരുന്നു എന്ന് (/how-it-works) വായിക്കുക, അല്ലെങ്കിൽ early access നു വേണ്ടി അപേക്ഷിക്കുക (/early-access).