امنیت، هویت، استقرار و تاب‌آوری · فصل ۹ — Resource، Provider، Cost و Organizational Failure · 131
Premature SaaS
failure را بعد از وقوع و به‌صورت موردی تحلیل می‌کند و هنوز detection، containment و repair path از قبل طراحی نشده است. موضوع جاری: «Premature SaaS». می‌تواند failure family «Premature SaaS» را بازتولید/تشخیص دهد و detection، containment و recovery مناسب را تعیین کند.
خلاصهٔ درس
failure را بعد از وقوع و به‌صورت موردی تحلیل می‌کند و هنوز detection، containment و repair path از قبل طراحی نشده است. موضوع جاری: «Premature SaaS».
می‌تواند failure family «Premature SaaS» را بازتولید/تشخیص دهد و detection، containment و recovery مناسب را تعیین کند.
خروجی این درس
می‌تواند failure family «Premature SaaS» را بازتولید/تشخیص دهد و detection، containment و recovery مناسب را تعیین کند.
1. شکست اصلی: پیچیدگی SaaS قبل از اثبات نیاز
Premature SaaS وقتی رخ می‌دهد که تیم قبل از تثبیت مدل مشتری و نیازهای عملیاتی، لایه‌هایی مثل multitenancy، tenant provisioning، billing hooks، per-tenant quotas، control plane و isolation tierهای متعدد را متعهدانه بسازد. ظاهر معماری ممکن است حرفه‌ای باشد، اما اگر requirement فعلی هنوز یک pilot، یک deployment داخلی و قرارداد محصولِ درحال‌تغییر باشد، این پیچیدگی می‌تواند هزینه و سطح خرابی را بالا ببرد بی‌آنکه outcome واقعی مشتری را بهتر کند.
2. SaaS یا multitenancy ذاتاً خطا نیست
این درس ضد SaaS نیست. وقتی business model، customer requirements، isolation، reliability، scale و عملیات چنین مدلی را توجیه کنند، SaaS می‌تواند انتخاب درست باشد. failure زمانی است که commitment پرهزینه و سخت‌برگشت قبل از evidence threshold انجام شود. بنابراین سؤال درست «SaaS خوب است یا بد؟» نیست؛ سؤال این است که «کدام capability همین امروز evidence دارد و کدام هنوز speculative است؟»
3. Tenant را قبل از tenancy model تعریف کنید
اگر خود مفهوم tenant مبهم باشد، طراحی shared control plane یا pooled storage جلوتر از مسئله حرکت می‌کند. ابتدا روشن کنید tenant چه کسی است: یک شرکت، department، environment یا account group؟ سپس تفاوت user و tenant، lifecycle tenant و boundary داده را ثبت کنید. تا وقتی این تعریف پایدار نیست، تصمیم‌های عمیق tenancy باید OPEN یا reversible باقی بمانند.
4. Requirement واقعی را از roadmap حدسی جدا کنید
داشتن دو مشتری، forecast رشد یا علاقه تیم به billing خودکار به‌تنهایی requirement مشترک نمی‌سازد. Record باید evidence مستقیم مشتری و قرارداد را جدا نگه دارد: آیا shared tenancy خواسته شده؟ آیا self-service provisioning لازم است؟ آیا SLO قراردادی داریم؟ آیا data residency یا compliance خاصی وجود دارد؟ اگر پاسخ‌ها هنوز نامعلوم‌اند، platform capability را به‌عنوان فرضیه ثبت کنید، نه الزام قطعی.
5. Isolation، SLO و compliance hard evidence هستند
مدل tenancy روی data isolation، blast radius، noisy-neighbor risk و عملیات اثر مستقیم دارد. یک مشتری regulated ممکن است deployment اختصاصی بخواهد حتی اگر تیم از نظر اقتصادی shared tenancy را ترجیح دهد. برعکس، چند مشتری با نیازهای مشابه و isolation قابل‌پذیرش ممکن است shared components را توجیه کنند. تصمیم باید از requirement بیاید، نه از زیبایی معماری.
6. Operations capacity بخشی از readiness است
SaaS فقط topology نرم‌افزار نیست؛ onboarding، upgrades، incident response، support، observability، access control و capacity management باید در مقیاس tenant قابل اجرا باشند. اگر تیم دو نفره است و حتی onboarding دستی هنوز نامطمئن است، ساخت control plane بزرگ می‌تواند operations debt تولید کند. automation readiness و support capacity را جداگانه بسنجید.
7. Shared-resource benefit باید از added complexity بیشتر باشد
اشتراک resource می‌تواند هزینه را کاهش دهد، اما isolation، metering، tenant-aware debugging، rollout segmentation و noisy-neighbor controls را اضافه می‌کند. اگر shared-resource benefit فقط یک حدس اقتصادی است و هنوز usage قابل اندازه‌گیری نداریم، از آن به‌عنوان proof استفاده نکنید. Record باید benefit، added complexity و evidence هر دو را کنار هم نشان دهد.
8. گزینه میانی: single-tenant، pilot یا staged tenancy
انتخاب‌ها binary نیستند. ممکن است امروز single-tenant deploy داشته باشید، tenant-aware identifiers را حفظ کنید، provisioning script کوچک بسازید و migration seam را نگه دارید؛ سپس با evidence جدید به hybrid یا pooled model حرکت کنید. staged tenancy اجازه می‌دهد capabilityهایی که requirement دارند زودتر ساخته شوند و capabilityهای speculative defer شوند.
9. Reversibility و migration seam را از ابتدا ثبت کنید
Recovery این failure با حذف همه قابلیت‌های آینده‌نگر انجام نمی‌شود. هدف این است که architecture boundary برگشت‌پذیر باشد: tenant identity از domain logic جدا، storage partition boundary روشن، provisioning interface کوچک و migration path تست‌پذیر باشد. اگر تغییر بعدی نیازمند rewrite سراسری است، migration cost و reversibility باید به‌عنوان ریسک صریح ثبت شوند.
10. چه چیزی را امروز نسازیم؟
Control plane، billing integration، pooled data layer یا isolation tier اضافه فقط وقتی build-now می‌شوند که requirement فعلی و operations evidence آن‌ها را توجیه کند. otherwise بهتر است interface و seam لازم را نگه داریم، نه implementation کامل را. این تفاوت «آماده‌بودن برای رشد» و «پرداخت هزینه رشد قبل از نیاز» است.
11. Containment، recovery و closure را جدا کنید
حذف یک feature از roadmap یا بازگشت به deployment ساده‌تر containment است. recovery وقتی قوی‌تر می‌شود که minimal architecture نیاز فعلی را برآورده کند و migration seam برای آینده حفظ شود. closure هم فقط وقتی است که Record نشان دهد build-now decisions به requirement trace می‌شوند، unknownها صریح‌اند و revisit trigger مشخص است؛ یک release موفق به‌تنهایی causal proof نیست.
12. SaaS Readiness & Reversibility Decision Record v1
Record حداقل tenant definition، validated customer requirement، isolation، SLO، compliance، tenant forecast، operations capacity، automation readiness، shared-resource benefit، added platform complexity، migration cost، reversibility، pilot scope، revisit trigger، closure decision و residual product risk را نگه می‌دارد. هر field باید OBSERVED، AUTHORITY، INFERRED یا UNKNOWN باشد؛ هیچ unknownی به‌صورت ضمنی fact نمی‌شود.
13. Classification: OPEN، PREMATURE، STAGED یا JUSTIFIED
OPEN یعنی tenant/requirement evidence کافی نیست. PREMATURE یعنی platform commitment از evidence جلو زده است. STAGED یعنی بخشی از capabilityها—مثلاً dedicated isolation، provisioning automation یا SLO operations—توجیه شده‌اند اما full shared SaaS هنوز evidence ندارد. JUSTIFIED یعنی requirement، operations readiness، automation و reversibility برای همان bounded scope هم‌راستا هستند. این classification business valuation یا حکم دائمی نیست.
14. Lab: هشت fixture و 64 assertion
Lab هشت سناریو دارد: pilot overbuilt، tenant نامشخص، دو مشتری با deploymentهای isolated، یک مشتری با self-service/SLO، shared-cost idea بدون isolation/automation، shared SaaS آماده، shared need با operations gap، و transfer fixture با مشتری regulated دوم. برای هر case هشت خروجی قطعی سنجیده می‌شود: tenant definition state، requirement evidence، isolation/reliability state، operations readiness، complexity posture، reversibility، SaaS classification و decision. مجموعاً 64 assertion اجرا می‌شود.
15. Exit checklist و انتقال
قبل از خروج، tenant را تعریف کنید؛ requirementها را از forecast جدا کنید؛ isolation/SLO/compliance را ثبت کنید؛ operations و automation readiness را بسنجید؛ benefit و complexity را مقایسه کنید؛ migration cost و reversibility را روشن کنید؛ build-now و defer را جدا بنویسید؛ revisit trigger و residual risk را نگه دارید. سپس transfer fixture را از صفر بسازید: مشتری regulated دوم strong isolation و availability قراردادی می‌خواهد. تعیین کنید کدام capability اکنون evidence دارد و کدام بخش full multitenancy هنوز زود است.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 retrieval
Why does a second customer not automatically justify shared multitenancy?
Q2 application
A regulated customer requires a dedicated deployment and contractual uptime. Which capability can become justified before pooled multitenancy?
Q3 diagnosis
A team expects shared infrastructure to reduce cost but has no tested isolation model or automated onboarding. What is the bounded diagnosis?
Q4 decision
What is the recovery move when current requirements are modest but future SaaS growth is plausible?
Q5 transfer
A second regulated customer adds strong isolation and an availability target. What changes?
ملاک‌های ارزیابی (rubric)
A sufficient response defines the tenant and bounded product context, separates current customer/contract evidence from inference, records isolation/SLO/compliance and operating readiness, compares platform benefit with added complexity, preserves UNKNOWN state, and chooses a reversible build-now/defer decision with a revisit trigger. A transfer response must be rebuilt from the changed fixture rather than copy the original classification.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Implement the bounded evaluator in starter.py for the eight supplied synthetic product/tenancy cases. No network calls are needed. Keep tenant definition, validated requirements, isolation/SLO/compliance, operations capacity, platform complexity and reversibility as separate evidence dimensions. Customer count or a cost hypothesis is never sufficient by itself. The evaluator should preserve OPEN state when decisive evidence is missing and distinguish premature commitment from a bounded staged path.
Run python run_checks.py to verify fixture shape before implementing the evaluator.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)