معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۳ — Cost، Pricing، P&L، Entitlement و SLA · 240
SLA/Support Model
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «SLA/Support Model». می‌تواند برای «SLA/Support Model» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خلاصهٔ درس
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «SLA/Support Model».
می‌تواند برای «SLA/Support Model» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خروجی این درس
می‌تواند برای «SLA/Support Model» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
1) مسئله‌ای که این درس حل می‌کند
وقتی SLA فقط با یک عدد مثل «99.95%» فروخته شود، ممکن است هیچ‌کس نداند دقیقاً چه چیزی اندازه‌گیری می‌شود، window چیست، چه eventهایی exclude می‌شوند، چه consequenceای وجود دارد و آیا تیم support اصلاً توان پوشش وعده را دارد یا نه. این درس promise تجاری را به evidence عملیاتی متصل می‌کند.
2) مرز درس و خروجی
خروجی SLA-SLO Support Operating Contract v1 است. این درس مالک Plan/Entitlement درس ARC-020 یا Anti-fork Customization درس ARC-022 نیست و هیچ تغییر زندهٔ monitoring، staffing، billing credit یا contract اجرا نمی‌کند.
3) Fact: SLI، SLO و SLA یکی نیستند
Google SRE، SLI را measure کمی service level، SLO را target روی آن measure و SLA را agreement دارای consequence در صورت عدم تحقق objective معرفی می‌کند. بنابراین یک percentage به‌تنهایی SLA کامل نیست.
4) Fact: indicator باید به تجربهٔ کاربر نزدیک باشد
indicator راحتِ داخلی لزوماً signal مناسب کاربر نیست. اگر server availability سبز باشد ولی user-facing failure بالا رفته باشد، measurement contract ناقص است و نباید از آن success تجاری ساخت.
5) Measurement Contract را صریح کن
برای هر tier، sli_id، sli_definition، measurement_source و measurement_window را ثبت کن. بدون این چهار مورد، حتی target دقیق هم قابل audit نیست.
6) SLO را قبل از SLA بفهم
SLO target عملیاتی است و باید با capability واقعی service و dependencyها سازگار باشد. SLA سخت‌گیرانه‌تر از capability اثبات‌شده، contract را معتبرتر نمی‌کند؛ فقط overcommit ایجاد می‌کند.
7) Consequence مرز SLA را روشن می‌کند
اگر target هیچ consequence تعریف‌شده‌ای ندارد، آن را خودکار SLA ننام. consequence می‌تواند service credit یا remedy قراردادی دیگری باشد؛ خودِ نوع و مقدار آن تصمیم MAKNOW نیست مگر evidence تجاری جدا داشته باشد.
8) Support Severity را از Availability جدا نگه دار
Severity، response target، resolution target، support hours و escalation path یک محور جدا هستند. availability خوب، وعدهٔ 24/7 support را ثابت نمی‌کند.
9) Staffing باید promise را پوشش دهد
اگر contract می‌گوید critical response باید 24/7 باشد ولی staffing فقط weekday است، state باید HOLD_SUPPORT_UNSTAFFED بماند تا coverage واقعی یا تغییر promise مستند شود.
10) Dependency Boundary را پنهان نکن
یک service customer-facing نمی‌تواند به‌طور قابل‌اعتماد promise سخت‌گیرانه‌تری بدهد اگر critical dependency محدودکننده evidence نشده باشد. dependency objective باید در decision دیده شود، نه در پاورقی.
11) Exclusion و Error Budget را با دقت استفاده کن
exclusion_rule باید روشن و محدود باشد و نباید failure واقعی کاربر را از metric حذف کند. error_budget_policy نیز operating policy است؛ جای consequence قراردادی یا staffing evidence را نمی‌گیرد.
12) Core Evidence Contract
این درس 20 بُعد evidence دارد که 16 بُعد آن بحرانی است. جدول زیر baseline، measurement failure و support transfer را فشرده نشان می‌دهد؛ JSON/CSV mapping کامل را نگه می‌دارد.
| case | tier | SLI | SLO | measurement | SLA | consequence | support | staffing | dependency | state | evidence |
|---|---|---|---|---|---|---|---|---|---|---|---|
| baseline | PRO | user request success | 99.95%/30d | client+edge | 99.9% | 5% credit | SEV1 30m 24x7 | 24x7 | 99.95% | ADMISSIBLE | ev:arc021:baseline |
| measurement_failure | PRO | server uptime | 99.95%/30d | server only | 99.9% | 5% credit | SEV1 30m 24x7 | 24x7 | 99.95% | HOLD_MEASUREMENT_INVALID | ev:arc021:server-only |
| transfer | PRO | user request success v2 | 99.95%/30d | client+edge v2 | 99.9% | 10% credit | SEV1 30m 24x7 | 8x5 | 99.99% | HOLD_SUPPORT_UNSTAFFED | ev:arc021:transfer |
13) Typed state جلوی موفقیت جعلی را می‌گیرد
HOLD_EVIDENCE_MISSING، HOLD_MEASUREMENT_INVALID، HOLD_SUPPORT_UNSTAFFED، HOLD_DEPENDENCY_RISK، REJECT_SLA_OVERCOMMIT و BLOCKED_CONSEQUENCE_UNDEFINED خروجی معتبرند. هیچ‌کدام نباید با حدس به ADMISSIBLE تبدیل شوند.
14) Approval و Review Trigger
service tier فقط وقتی admissible است که ownerهای measurement/support مشخص باشند و review_trigger برای تغییر instrumentation، dependency objective، staffing coverage یا consequence تعریف شده باشد.
15) Lab و Transfer
Lab هشت fixture و 48 assertion دارد. در transfer، client-side SLI اضافه شده، dependency بهتر شده، overnight staffing حذف شده و financial service credit اضافه شده است. learner باید از evidence جدید تصمیم را دوباره محاسبه کند؛ baseline oracle نیست.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ARC-021-Q1 retrieval
Explain the difference among SLI, SLO and SLA, including the role of consequence.
ARC-021-Q2 application
Build SLA-SLO Support Operating Contract v1 for the baseline fixture.
ARC-021-Q3 diagnosis
Why does server-only availability fail when user-facing failures rise?
ARC-021-Q4 transfer
Recompute the transfer case after client-side instrumentation improves, dependency objective improves, overnight staffing disappears, and a financial service credit is added.
ملاک‌های ارزیابی (rubric)
Pass requires: correct SLI/SLO/SLA boundary; complete critical evidence; explicit non-success state when measurement/staffing/dependency/consequence is inadequate; no invented facts; and independent recomputation of transfer.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
Flow from user-relevant SLI through SLO, support/dependency evidence and SLA consequence to a bounded decision.
فایل‌های آزمایشگاه
هشت case مصنوعی را بررسی کنید، python run_checks.py را اجرا کنید و برای هر state ناموفق، field تعیین‌کننده را توضیح دهید. staffing، dependency، consequence یا measurement مفقود را با حدس پر نکنید.