Fail open বনাম fail closed

শব্দগুলোর অর্থ কী

request path-এর মধ্যে থাকা প্রতিটি check একটি answer দিতে ব্যর্থ হতে পারে: কোনো dependency time out করে, কোনো signal অনুপস্থিত থাকে, কোনো key fetch করা যায় না। Fail open মানে request এমনভাবে এগোয় যেন checkটি ছিল না। Fail closed মানে request আরও কড়া path নেয়: তা deny করা হয়, challenge করা হয় বা বিদ্যমান আরও শক্তিশালী control-এর কাছে পাঠানো হয়।

সাধারণভাবে কোনোটিই সঠিক নয়। সঠিক choice নির্ভর করে route কী করে এবং ভুল সিদ্ধান্তের খরচ কত।

actor checks-এর ক্ষেত্রে এটি কেন গুরুত্বপূর্ণ

actor checks request-এ context যোগ করে: interactionটি human, AI-assisted, agent-driven নাকি unknown দেখায়। সেই context অনুপলব্ধ হলে application-কে তবুও response দিতে হয়। দুটি failure pattern সাধারণ:

• অনিচ্ছাকৃত fail closed। কোনো timeout বা missing signal-কে suspicious ধরা হয়, এবং outage-এর সময় real user-রা blocked হয়ে যান।
• সংবেদনশীল action-এ অনিচ্ছাকৃত fail open। কোনো missing result নীরবে human হিসেবে ধরা হয়, এবং উচ্চ-প্রভাবের কোনো action প্রত্যাশার চেয়ে কম scrutiny নিয়ে এগিয়ে যায়।

দুটিরই কারণ হলো choice-টিকে implicit রেখে দেওয়া। সমাধান হলো route অনুযায়ী সেটি স্পষ্টভাবে ঠিক করা। মানুষ এবং AI agent-দের জন্য app-level policy design করা নিয়ে আমাদের post দেখায় যে failure behavior কীভাবে per-route policy-এর সঙ্গে মেলে।

কীভাবে নির্বাচন করবেন

একটি ব্যবহারিক পদ্ধতি হলো route-গুলোকে risk tier অনুযায়ী ভাগ করা:

• কম প্রভাব (public page, documentation, read-only catalog route): fail open। missing actor result কোনো কিছু বদলানো উচিত নয়।
• মাঝারি প্রভাব (signup, form submission, খরচযুক্ত search): সাধারণত logging সহ fail open, অথবা standard rate limit-এর মতো একটি নরম adaptation প্রয়োগ করুন।
• উচ্চ প্রভাব (account পরিবর্তন, data export, অপরিবর্তনীয় action): আপনার বিদ্যমান আরও শক্তিশালী control-এ fail closed করুন, যেমন re-authentication বা confirmation। লক্ষ্য block করা নয়, বরং আপনি যেটি anyway ব্যবহার করতেন সেই check-এ ফিরে যাওয়া।

তারপর সম্পর্কিত case-গুলোর জন্য একই behavior নির্ধারণ করুন:

• Timeout: check সময়মতো উত্তর দেয়নি।
• Missing telemetry: integration চলেনি বা কোনো signal অনুপস্থিত ছিল।
• Unknown: checkটি চলেছে, কিন্তু evidence কোনো determination সমর্থন করেনি।
• Stale evidence: resultটি আগের, এবং আরও সংবেদনশীল action-এর জন্য এটি পুনরায় ব্যবহার করা উচিত নয়।

সাধারণ ভুল ধারণা

• "Fail closed বেশি নিরাপদ।" এটি legitimate user-দের ওপর খরচ চাপায়। কম প্রভাবের route-গুলোর জন্য incident-এর সময় fail closed করা যে ঝুঁকি ঠেকায়, তার চেয়ে বেশি ক্ষতি করতে পারে।
• "Unknown মানে failure।" Unknown একটি বৈধ result। এর জন্য আলাদা, স্পষ্ট handling দরকার, যা আপনার timeout handling-এর সঙ্গে মিলতেও পারে আবার নাও পারে।
• "Missing result মানে human।" evidence না থাকার কারণে কখনোই actor class অনুমান করবেন না।

Proof of Actor এটিকে কীভাবে扱ে

Proof of Actor কখনো timeout বা Unknown result-এর জন্য Human নির্ধারণ করে না, এবং এটি install করলে কিছুই block হয় না: team-রা observation mode-এ শুরু করে। প্রতি route এবং risk tier-এর জন্য fail-open বা fail-closed behavior application owner-এর choice, যা Route-এর মাধ্যমে আপনার নিজের code-এ প্রয়োগ করা হয়। এতে enforcement পূর্বানুমেয় থাকে এবং কোনো policy live হওয়ার আগে আপনি outcome যাচাই করতে পারেন।

routing decision কীভাবে এর মধ্যে পড়ে তা পড়ুন, অথবা early access-এর জন্য আবেদন করুন.