ಪದಗಳ ಅರ್ಥ ಏನು
request path ನಲ್ಲಿ ಇರುವ ಪ್ರತಿಯೊಂದು ಪರಿಶೀಲನೆಯೂ ಉತ್ತರವನ್ನು ನೀಡಲು ವಿಫಲವಾಗಬಹುದು: dependency timeout ಆಗಬಹುದು, signal ಕಾಣೆಯಾಗಬಹುದು, key ಅನ್ನು fetch ಮಾಡಲಾಗದಿರಬಹುದು. Fail open ಎಂದರೆ ಪರಿಶೀಲನೆ ಅಲ್ಲಿ ಇಲ್ಲದಂತೆ ವಿನಂತಿ ಮುಂದುವರಿಯುತ್ತದೆ. Fail closed ಎಂದರೆ ವಿನಂತಿ ಕಠಿಣ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: ಅದನ್ನು ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ, challenge ಮಾಡಲಾಗುತ್ತದೆ ಅಥವಾ ಈಗಾಗಲೇ ಇರುವ ಬಲವಾದ ನಿಯಂತ್ರಣಕ್ಕೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೂ ಸರಿಯೆಂದು ಹೇಳಲಾಗದು. ಸರಿಯಾದ ಆಯ್ಕೆ route ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ತಪ್ಪಾದ ನಿರ್ಧಾರದ ವೆಚ್ಚ ಎಷ್ಟು ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ.
actor ಪರಿಶೀಲನೆಗಳಿಗೆ ಇದು ಏಕೆ ಮುಖ್ಯ
actor ಪರಿಶೀಲನೆಗಳು ವಿನಂತಿಗಳಿಗೆ context ಸೇರಿಸುತ್ತವೆ: interaction ಮಾನವದಂತಿದೆಯೇ, AI ಸಹಾಯ ಪಡೆದಿದೆಯೇ, agent ಚಾಲಿತವಾಗಿದೆಯೇ ಅಥವಾ unknown ಆಗಿದೆಯೇ ಎಂಬುದು. ಆ context ಲಭ್ಯವಿಲ್ಲದಾಗಲೂ application ಇನ್ನೂ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ಎರಡು failure pattern ಗಳು ಸಾಮಾನ್ಯ:
- ಅನಾಯಾಸ fail closed. timeout ಅಥವಾ ಕಾಣೆಯಾಗಿರುವ signal ಅನ್ನು ಸಂಶಯಾಸ್ಪದವಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು outage ಸಮಯದಲ್ಲಿ ನಿಜವಾದ ಬಳಕೆದಾರರು ತಡೆಗೊಳ್ಳುತ್ತಾರೆ.
- ಸೂಕ್ಷ್ಮ ಕ್ರಿಯೆಗಳಲ್ಲಿ ಅನಾಯಾಸ fail open. ಕಾಣೆಯಾಗಿರುವ ಫಲಿತಾಂಶವನ್ನು ಮೌನವಾಗಿ ಮಾನವ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ಕ್ರಿಯೆ ಉದ್ದೇಶಿಸಿದಕ್ಕಿಂತ ಕಡಿಮೆ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಮುಂದುವರಿಯುತ್ತದೆ.
ಇವು ಎರಡೂ ಆಯ್ಕೆಯನ್ನು ಅಡಗಿಟ್ಟುದರಿಂದ ಬರುತ್ತವೆ. ಪರಿಹಾರವೆಂದರೆ route ಪ್ರತಿ ಒಂದಕ್ಕೂ ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ಧರಿಸುವುದು. ಮಾನವರು ಮತ್ತು AI agent ಗಳಿಗಾಗಿ app-level ನೀತಿಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಕುರಿತು ನಮ್ಮ post ನಲ್ಲಿ failure behavior ಹೇಗೆ per-route policy ಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸಲಾಗಿದೆ.
ಹೇಗೆ ಆಯ್ಕೆಮಾಡುವುದು
ಒಂದು practical approach ಎಂದರೆ routes ಅನ್ನು risk tier ಗಳಾಗಿ ಗುಂಪುಮಾಡುವುದು:
- ಕಡಿಮೆ ಪರಿಣಾಮ (public pages, documentation, read-only catalog routes): fail open. ಕಾಣೆಯಾಗಿರುವ actor result ಏನನ್ನೂ ಬದಲಾಯಿಸಬಾರದು.
- ಮಧ್ಯಮ ಪರಿಣಾಮ (signups, form submissions, ವೆಚ್ಚ ಇರುವ searches): ಸಾಮಾನ್ಯವಾಗಿ logging ಜೊತೆಗೆ fail open, ಅಥವಾ standard rate limit ನಂತಹ ಸೌಮ್ಯ adaptation ಅನ್ನು ಅನ್ವಯಿಸಿ.
- ಹೆಚ್ಚಿನ ಪರಿಣಾಮ (account ಬದಲಾವಣೆಗಳು, data exports, ಹಿಂತಿರುಗಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕ್ರಿಯೆಗಳು): re-authentication ಅಥವಾ confirmation ನಂತಹ ಈಗಾಗಲೇ ಇರುವ ಬಲವಾದ ನಿಯಂತ್ರಣಕ್ಕೆ fail closed. ಉದ್ದೇಶ block ಮಾಡುವುದು ಅಲ್ಲ, ಆದರೆ ನೀವು anyway ಬಳಸುವ ಪರಿಶೀಲನೆಗೆ ಹಿಂದಿರುಗುವುದು.
ನಂತರ ಸಂಬಂಧಿತ ಪ್ರಕರಣಗಳಿಗೆ ಅದೇ behavior ಅನ್ನು ನಿರ್ಧರಿಸಿ:
- Timeout: ಪರಿಶೀಲನೆ ಸಮಯಕ್ಕೆ ಉತ್ತರಿಸಲಿಲ್ಲ.
- Missing telemetry: integration ಕಾರ್ಯನಿರ್ವಹಿಸಲಿಲ್ಲ ಅಥವಾ ಒಂದು signal ಕಾಣೆಯಾಗಿತ್ತು.
- Unknown: ಪರಿಶೀಲನೆ ನಡೆಯಿತು, ಆದರೆ ಸಾಕ್ಷ್ಯವು ನಿರ್ಧಾರಕ್ಕೆ ಬೆಂಬಲ ನೀಡಲಿಲ್ಲ.
- Stale evidence: ಫಲಿತಾಂಶವು ಹಿಂದಿನದು ಮತ್ತು ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮ ಕ್ರಿಯೆಗೆ ಮರುಬಳಕೆ ಮಾಡಬಾರದು.
ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಗಳು
- "Fail closed ಹೆಚ್ಚು ಸುರಕ್ಷಿತ." ಇದು ವೆಚ್ಚವನ್ನು ನಿಜವಾದ ಬಳಕೆದಾರರ ಮೇಲೆ ತಳ್ಳುತ್ತದೆ. ಕಡಿಮೆ ಪರಿಣಾಮದ route ಗಳಲ್ಲಿ, incident ಸಮಯದಲ್ಲಿ fail closed ಆಗುವುದರಿಂದ ಅದು ತಡೆಯುವ risk ಗಿಂತ ಹೆಚ್ಚಿನ ಹಾನಿ ಆಗಬಹುದು.
- "Unknown ಎಂದರೆ failure." Unknown ಒಂದು ಮಾನ್ಯ ಫಲಿತಾಂಶ. ಅದಕ್ಕೆ ತನ್ನದೇ ಆದ ಸ್ಪಷ್ಟ handling ಬೇಕು, ಅದು ನಿಮ್ಮ timeout handling ಗೆ ಹೊಂದಿಕೊಳ್ಳಬಹುದು ಅಥವಾ ಇಲ್ಲದಿರಬಹುದು.
- "ಕಾಣೆಯಾಗಿರುವ ಫಲಿತಾಂಶ ಎಂದರೆ ಮಾನವ." ಸಾಕ್ಷ್ಯದ ಕೊರತೆಯಿಂದ actor class ಅನ್ನು ಎಂದಿಗೂ ನಿರ್ಧರಿಸಬೇಡಿ.
Proof of Actor ಇದನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ
Proof of Actor timeout ಅಥವಾ Unknown ಫಲಿತಾಂಶಕ್ಕೆ ಎಂದಿಗೂ Human ಅನ್ನು ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು install ಮಾಡಿದರೆ ಏನನ್ನೂ block ಮಾಡುವುದಿಲ್ಲ: ತಂಡಗಳು observation mode ನಲ್ಲಿ ಆರಂಭಿಸುತ್ತವೆ. ಪ್ರತಿಯೊಂದು route ಮತ್ತು risk tier ಗಾಗಿ fail-open ಅಥವಾ fail-closed behavior application ಮಾಲೀಕರ ಆಯ್ಕೆ, ನಿಮ್ಮ own code ನಲ್ಲಿ Route ಮೂಲಕ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಅದು enforcement ಅನ್ನು ನಿರೀಕ್ಷಿತವಾಗಿರಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ policy live ಆಗುವ ಮೊದಲು outcomes ಅನ್ನು ಪರಿಶೀಲಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ.
routing decisions ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಎಂದು ಓದಿ, ಅಥವಾ early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ.