Admission Gate با SLA/Capacity/Cost

1) مسئلهٔ واقعی: قرارداد فروخته شده، ظرفیت هنوز اثبات نشده

یک فرصت B2B می‌تواند از نظر فروش جذاب باشد و حتی Pilot خوبی داشته باشد، اما Admission تصمیمی جداست. قبل از پذیرش باید نشان دهیم SLI/SLO/SLA مورد انتظار با ظرفیت اندازه‌گیری‌شده، Quota واقعی، Failover reserve و Cost-to-Serve فعلی قابل پشتیبانی است. «Autoscaling داریم»، «Quota را بعداً زیاد می‌کنیم» یا «بعداً بهینه می‌کنیم» ظرفیت موجود نیست.

2) مرز درس و خروجی قابل تحویل

خروجی این درس Admission Gate Decision Contract v1 است. Forecast را از درس قبل مصرف می‌کنیم ولی Forecasting را دوباره طراحی نمی‌کنیم؛ Cost Ledger و Pricing Floor هم مالک این درس نیستند. تصمیم باید یکی از ADMIT، CONDITIONAL، REJECT یا HOLD باشد و از شواهد قابل مشاهده قابل بازتولید بماند.

3) SLI، SLO و SLA را یکی نکن

SLI یک سنجهٔ کمی از سطح سرویس است؛ SLO هدفی برای آن سنجه است؛ SLA توافقی است که پیامد برآورده‌نشدن SLO را هم وارد رابطه می‌کند. پس نوشتن «99.9%» بدون نام سنجه، Window و Consequence قرارداد قابل آزمون نمی‌سازد. Admission باید دقیقاً بداند چه چیزی وعده داده می‌شود.

4) Quota و Constraint ظرفیت نامرئی نیستند

AWS Well-Architected تأکید می‌کند Quotaها و Resource constraintها باید شناخته و مدیریت شوند و برای Failover نیز Headroom کافی وجود داشته باشد. بنابراین برنامهٔ درخواست افزایش Quota، تا وقتی در Region لازم تأیید و قابل مشاهده نشده، در Gate به‌عنوان ظرفیت فعلی شمرده نمی‌شود.

5) از Forecast به Envelope ظرفیت

فرض سناریوی پایه این است: P95 demand برابر 820 req/s و Load Test تکرارپذیر تا 1000 req/s قبل از degradation را نشان می‌دهد. اگر 180 req/s برای Failover reserve کنار گذاشته شود، Envelope باقی‌مانده دقیقاً 820 req/s است. این Feasible است اما Buffer ندارد؛ بنابراین نمی‌توان همان اطمینان حالتی را داد که مثلاً 15% Headroom اثبات‌شده دارد.

6) Capacity Margin را صریح حساب کن

در این درس effective_capacity = tested_capacity - failover_reserve و capacity_margin = effective_capacity - p95_demand است. برای ADMIT، طراحی MAKNOW علاوه بر عبور Hard Constraint، حداقل 10% P95 به‌عنوان Capacity Margin می‌خواهد. اگر Hard Constraint پاس شود ولی Margin کمتر باشد، فقط یک Exception معتبر و زمان‌دار می‌تواند مسیر CONDITIONAL بسازد؛ Exception ظرفیت فیزیکیِ ناکافی را جادویی زیاد نمی‌کند.

7) Quota را در هر Failure Domain ببین

یک Region اصلی با Headroom کافی، مدرک کافی برای Failover نیست. اگر معماری روی Region دوم حساب می‌کند، Quota و Usage همان Region هم باید Evidence داشته باشد. Missing failover-region quota یک «صفر» نیست؛ HOLD است چون هنوز نمی‌دانیم وعده در Failure mode قابل اجراست یا نه.

8) Unit Cost و Margin یک Gate مستقل‌اند

FinOps Unit Economics هزینهٔ فناوری را به Unitهای کسب‌وکار مثل tenant، transaction یا cost-to-serve متصل می‌کند. در این درس commercial_margin = price_or_value_basis - cost_to_serve است. Margin باید حداقل به margin_floor برسد. بالا بودن Revenue یا Gross Margin کلی شرکت جای Cost-to-Serve همین workload را نمی‌گیرد.

9) Serviceability و Freshness قبل از Optimism

اگر Serviceability ناشناخته باشد، Load Test قدیمی شده باشد یا Forecast/Cost model به Context فعلی متصل نباشد، Gate باید HOLD شود. HOLD شکست تجاری نیست؛ یعنی تصمیم قوی‌تر از شواهد موجود صادر نمی‌شود.

10) سناریوی پایه: چرا CONDITIONAL؟

در Baseline، SLO و SLA روشن‌اند، P95=820، Tested Capacity=1000 و Failover reserve=180 است؛ پس Margin ظرفیت صفر است. Quota و Cost فعلی Hard Constraint را پاس می‌کنند و Serviceability هم PASS است، اما Buffer طراحی‌شده وجود ندارد. چون Owner و Expiry یک Exception کوتاه‌مدت ثبت شده، نتیجه CONDITIONAL است؛ بدون آن Exception، پذیرش مجاز نیست.

11) میان‌بُر غلط: Future Capacity را Current Capacity نکن

اگر P95 به 900 برسد، Envelope فعلی 820 است. حتی اگر Ticket افزایش Quota باز باشد یا Auto Scaling تعریف شده باشد، این Evidence نشان می‌دهد Capacity آزموده‌شده برای وعده فعلی کافی نیست. تصمیم REJECT است تا زمانی که Capacity/Quota جدید اثبات شود و Gate دوباره اجرا شود.

12) Exception چه زمانی معتبر است؟

Exception باید Owner، Scope، Expiry و Stop/Pivot Trigger داشته باشد. Exception منقضی‌شده یا بدون Owner Evidence نیست. همچنین Exception برای Missing evidence می‌تواند فقط «زمان بررسی» تعریف کند؛ نباید Unknown را به Pass تبدیل کند. برای Hard capacity shortfall نیز Exception نباید واقعیت فیزیکی را نادیده بگیرد.

13) Lab: Gate را از Fixture بازسازی کن

در Lab، هشت Fixture مصنوعی داری. Evaluator فقط مقایسه‌های Deterministic را انجام می‌دهد: ظرفیت مؤثر، Margin ظرفیت، Quota Headroom، Commercial Margin، Freshness و Exception validity. ابتدا Baseline را بساز، سپس Mutationهای افزایش P95، Missing failover quota، افزایش Unit Cost، Expired Exception و Stale evidence را اجرا کن. هدف حفظ State درست است، نه گرفتن «بله».

14) Transfer: قرارداد سخت‌تر و شواهد ناهمگن

در Transfer، Service tier بالاتر می‌رود، P95 پانزده درصد زیاد می‌شود، Quota فقط در Region اصلی تأیید می‌شود و Cost-to-Serve نیز بالا می‌رود. از Baseline جواب را کپی نکن: P95 جدید 943 req/s است و از Envelope آزموده‌شده 820 بالاتر می‌رود. Stop condition روشن است: تا Load Test جدید، Failover quota و Unit Economics جدید Gate را پاس نکنند، Admission متوقف می‌ماند.

15) چک‌لیست تحویل

یک Contract قابل قبول باید Service tier، SLI/SLO/SLA و Window، Forecast ref و P95، Tested capacity، Quota/Usage/Headroom، Failover reserve، Capacity margin، Unit cost/Cost-to-Serve/Margin floor، Serviceability، Freshness، Exception owner/expiry، State، Stop/Pivot Trigger و Evidence ref را ثبت کند. هیچ Future plan نباید به‌عنوان Present capacity نوشته شود.