Dedicated Instance Pattern

۱) Dedicated یعنی تصمیم درباره مرز منابع، نه ساخت Customer Fork

درخواست «Dedicated Instance» به‌خودی‌خود مجوز ساخت Codebase، Release Train، Identity System یا تیم عملیاتی جدا نیست. Dedicated Instance Eligibility & Fleet Contract v1 ابتدا مشخص می‌کند دقیقاً کدام Resource Plane باید اختصاصی باشد و کدام بخش Product/Control Plane می‌تواند مشترک بماند.

۲) از یک Hard Isolation Reason شروع کن

دلیل باید در Evidence نوشته شود: الزام مقرراتی، Data Residency، Performance Isolation سخت یا Constraint صریح دیگر. «مشتری Dedicated دوست دارد» دلیل کافی نیست. اگر دلیل سخت از بین برود، Footprint موجود باید دوباره ارزیابی شود و نباید فقط به‌خاطر اینکه قبلاً ساخته شده حفظ شود.

۳) Dedicated Plane را از Shared Control Plane جدا کن

ممکن است Compute و Data برای یک Tenant اختصاصی باشند اما Identity، Onboarding، Release Orchestration، استاندارد Observability، Incident Tooling و Product Governance مشترک بمانند. همین جداسازی کمک می‌کند Silo SaaS به یک محصول سفارشی و جدا تبدیل نشود.

۴) مرز FACT و DESIGN را حفظ کن

Azure Deployment Stamps و راهنمای AWS برای SaaS Isolation الگوهای بیرونی مفیدی می‌دهند: Stamp می‌تواند Single-Tenant باشد، منابع Silo می‌توانند با عملیات مشترک SaaS همزیست باشند و محیط Dedicated می‌تواند همان Product Version محیط Pooled را اجرا کند. اما Threshold و Pricing و Stateهای MAKNOW را این منابع تعیین نمی‌کنند.

۵) ظرفیت رزرو را صادقانه حساب کن

Footprint اختصاصی باید برای Peak اعلام‌شده ظرفیت کافی رزرو کند. reserved_capacity و peak_capacity_requirement باید در یک Scope مقایسه شوند. ظرفیت Idle هم هزینه و Fleet Burden دارد و فقط به دلیل استفاده‌نشدن «رایگان» نیست.

۶) Unit-Cost Floor را آشکار کن

در این Lab، کف ساده هزینه برابر Recurring Reserved Cost تقسیم بر Useful Unit پیش‌بینی‌شده است. این فرمول Billing نیست؛ فقط جلوی تأیید معماری Dedicated بدون دیدن هزینه ظرفیت بلااستفاده را می‌گیرد.

۷) Automation یک Fleet Gate است

یک Tenant اختصاصی ممکن است ساده به نظر برسد؛ Fleet بزرگ از Tenantهای اختصاصی ساده نیست. Provisioning، Upgrade، Observability، Backup/Restore، Drift Check، Incident Response و Decommissioning باید تا حد کافی خودکار باشند. Automation ضعیف یعنی بدهی عملیاتی تکرارشونده.

۸) Product Version مشترک را حفظ کن

Dedicated Resource Plane نباید بی‌صدا به Application Code اختصاصی Tenant تبدیل شود. Same-Version Operation و Upgrade Policy مشترک، Product را واحد نگه می‌دارند. Customer-only Branch بدون مجوز، سیگنال REJECT است چون Release و Support را واگرا می‌کند.

۹) Configuration Delta و Drift را یکی ندان

Configuration ممکن است در Envelope تأییدشده متفاوت باشد. Drift یعنی واگرایی کنترل‌نشده از همان Envelope. هر دو را جدا ثبت کن. Drift نامعلوم = HOLD؛ Drift مدیریت‌نشده‌ی تأییدشده می‌تواند Footprint را تا زمان Repair نامعتبر کند.

۱۰) Observability و Backup جزو Footprint هستند

Deployment اختصاصی که در Monitoring مشترک دیده نمی‌شود یا Backup/Restore Profile قابل اتکا ندارد، Operationally Ready نیست. Isolation جایگزین کنترل‌های عملیاتی نمی‌شود.

۱۱) Contract را به Evidence وصل کن

جدول اصلی Requirement، مرز Dedicated/Shared، ظرفیت، هزینه، Automation، Version/Drift و Lifecycle را به یک State محدود و قابل ممیزی متصل می‌کند.

۱۲) Negative Case: Dedicated بدون Hard Reason

اگر Constraint مقرراتی یا Performance حذف شود ولی زیرساخت Dedicated باقی بماند، معماری خودکار ELIGIBLE نمی‌ماند. Reason Gate شکست خورده است. اگر Pooled Platform اکنون Control سازگار دارد، Migration را بررسی کن؛ Sunk Effort دلیل نگه‌داشتن Dedicated نیست.

۱۳) Negative Case: Tenant-only Code Branch

Branch اختصاصی مشتری، مرز Product را تغییر می‌دهد نه فقط مرز Infrastructure را. تا وقتی Product Model جداگانه‌ای در جای دیگری رسماً مجاز نشده باشد، این درس آن را Shortcut نامعتبر می‌داند و REJECT می‌کند.

۱۴) Transfer: Pooled Isolation حالا compliant شده

شش ماه بعد Constraint مقرراتی حذف می‌شود، Workload دوبرابر می‌شود و Pooled Platform Control ایزولیشن سازگار می‌گیرد. تصمیم را از Evidence جدید بساز. اگر Migration ایمن و کامل تعریف شده باشد، بازگشت به Pool را پیشنهاد کن؛ اگر Evidence مهاجرت ناقص است، حتی با وجود جذاب‌بودن Target Architecture، HOLD را حفظ کن.

۱۵) Completion Test

وقتی Reviewer دیگری بتواند از روی Evidence آشکار همان State را بازتولید کند، کار تمام است: Hard Reason، Dedicated/Shared Planes، Capacity، Unit-Cost Floor، Automation، Version/Upgrade، Configuration/Drift، Observability، Backup/Restore، Migration Path، Decommission Trigger و Evidence Ref. Verdict را هرگز از Evidence قوی‌تر نکن.