SLA/OLA با ارائه دهندگان

1) شرایط و مرزها

SLI - شاخص قابل اندازه گیری (در دسترس بودن، تاخیر P99، وب سایت های با موفقیت پردازش شده، RPO/RTO).

SLO - مقدار SLI هدف در هر پنجره اندازه گیری (به عنوان مثال، 99. 9 %/30 روز)

SLA - سند قانونی قانونی (SLO + روش + بازپرداخت).
OLA - اهداف و فرآیندهای داخلی که اطمینان از انطباق با SLA ها.
UC (قرارداد پایه) - «بستر» با اشخاص ثالث (کانال ها، مراکز داده، CDN، و غیره).

مرزها: به وضوح منطقه ارائه دهنده مسئولیت (ابر/WAF/CDN/دروازه پرداخت/ارائه دهنده KYC) را از منطقه خود (کد، پیکربندی، تنظیمات مشتری) جدا کنید.

2) ماتریس بحرانی و انتخاب مدل

ماتریس عمق SLA، دامنه چک ها و الزامات OLA/UC را تعیین می کند.

3) متریک و پنجره های اندازه گیری

در دسترس بودن - درصد زمانی که سرویس پرس و جو را با توجه به تحمل اجرا می کند.
تاخیر: p95/p99 برای عملیات کلیدی ؛ «موفقیت آهسته» محسوب می شود.
قابلیت اطمینان داده ها: RPO (حداکثر از دست دادن داده ها مجاز) و RTO (زمان بازیابی).
پهنای باند/محدودیت ها: سهمیه تضمین شده (RPS/MBps).
کیفیت یکپارچگی: سهم webhooks تحویل ≤ X دقیقه، سهم پاسخ 2xx، تکرار و deduplication.
پنجره اندازه گیری: ماهانه/نورد 30 روز، استثنا (فعالیت های برنامه ریزی شده) با محدودیت.

• 'در دسترس بودن _ ext = 1 − (Downtime_confirmed_outages/ Total_minutes_in_window)'
• که در آن قطع وضعیت غیر قابل دسترس تایید شده توسط نظارت خارجی، و نه فقط توسط صفحه وضعیت ارائه دهنده است.

4) محتوای SLA (قالب بخش)

1. موضوع و دامنه (خدمات، مناطق، نسخه های API).
2. تعاریف (SLI/SLO، «حادثه»، «کار برنامه ریزی شده»، «فورس ماژور»).
3. اهداف خدمات (SLOs) بر اساس طبقه بندی درخواست و منطقه.
4. نظارت و پایه شواهد: در چه راه، سنسورهای که، با چه فرکانس.
5. حوادث و افزایش: کانال ها، زمان پاسخ/به روز رسانی، نقش ها.
6. بازپرداخت: اعتبار/جریمه/پاداش، آستانه، فرمول.
7. امنیت و حریم خصوصی: DPA، رمزگذاری، سیاهههای مربوط، اطلاعیه های نقض.
8. تغییرات خدمات: مستهلک, پنجره اطلاع رسانی, سازگاری.
9. تداوم و DR: RPO/RTO، تست های بازیابی.
10. حسابرسی و انطباق: حق حسابرسی، گزارش، صدور گواهینامه.
11. برنامه خروج: صادرات داده ها، تاریخ، فرمت، کمک مهاجرت.
12. مقررات قانونی: صلاحیت، فورس ماژور، محرمانه بودن، مدت اعتبار.

5) نمونه هایی از جمله بندی (قطعات)

5. 1 در دسترس بودن و اندازه گیری

"ارائه دهنده فراهم می کند 99. 95% در دسترس بودن در هر ماه تقویم. در دسترس بودن توسط نظارت مصنوعی خارجی مشتری از مناطق ≥3 در فواصل ≤1 دقیقه اندازه گیری می شود. عدم دسترسی ثبت شده در ≥2 مناطق به طور همزمان یک حادثه سطح SEV2 محسوب می شود و در Downtime شمارش می شود

5. 2 کلید تاخیر API

"زمان پاسخ p99" POST/payments/authorize "≤ 450 میلی ثانیه در 95٪ روزهای ماه. گزارش تجزیه و تحلیل علت برای درصد درخواست هایی که بیش از آستانه ارائه شده است"

5. ۳ حوادث و افزایش

"S1: ACK ≤ 15 دقیقه، به روز رسانی هر ≤ 30 دقیقه، بازیابی هدف ≤ 2 ساعت ؛ S2: ACK ≤ 30 دقیقه، به روز رسانی ≤ 60 دقیقه ؛ S3: روز کاری بعدی کانال ها: تلفن 24 × 7, پل چت, ایمیل"

5. 4 بازپرداخت (اعتبار)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

وام ها روش های دیگر جبران خسارت را در سهل انگاری ناخالص حذف نمی کنند.

5. 5 تخفیف و سازگاری

حداقل 180 روز برای تغییراتی که سازگاری را از بین می برند اطلاع دهید. پشتیبانی همزمان برای vN و vN + 1 برای حداقل 90 روز

5. 6 خروج

"ظرف 30 روز پس از خاتمه، ارائه دهنده صادرات کامل داده ها را در فرمت های Parquet/JSON + به صورت رایگان ارائه می دهد ؛ خدمات مهاجرت اضافی - در تعرفه X. تخریب نسخه ها توسط قانون تایید شده است"

6) OLA: پشتیبانی داخلی برای SLA خارجی

• اهداف: دروازه p99 ≤ 200 میلی ثانیه، میزان خطا ≤ 0. 3٪، DR: RPO 0، RTO 30 دقیقه.
• مسئولیت: SRE-on-call، 24 × 7 ؛ داشبورد مشترک و هشدارها.
• فرآیندها: هرج و مرج دود در انتشار، پرف دود در روابط عمومی، اکتشافی از سایه.
• گیتس: بلوک را هنگامی که آزمون SLO/xaoc نتواند ؛ به روز رسانی runbook اجباری

7) نظارت و شواهد

Synthetics: پروب های خارجی (HTTP/TCP)، مسیر کاربر، «موفقیت آهسته».
RUM: نظارت بر کاربر واقعی برای تایید تاثیر.
همبستگی: «ارائه دهنده»، «منطقه»، «api _ method»، برچسب «incident _ id».
مصنوعات: تصاویر/مسیرهای پیاده روی/سیاهههای مربوط، صادرات KPI، جدول زمانی تشدید.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) حوادث و تعاملات

1. طبقه بندی SEV، باز کردن اتاق جنگ، هدف IC.

2. اطلاع از ارائه دهنده از طریق «کانال گرم»، انتقال مصنوعات.

3. دور زدن حالت/ویژگی های پرچم (کهنه، سایه، نرخ کلاه).

4. جدول زمانی مشترک، بازیابی.

5. اقدامات Postmortem +: به روز رسانی محدودیت های پیکربندی، کلید ها، مسیرهای پشتیبان.

6. شروع وام SLA، تثبیت در صورتحساب.

9) امنیت و DPA

DPA/حریم خصوصی: نقش کنترل کننده/پردازنده، دسته بندی داده ها، پایه قانونی بودن، مهلت پردازش/اهداف، زیر پردازنده ها و SLA های آنها.
رمزگذاری: TLS1 2 +، PFS ؛ داده «در حالت استراحت»، مدیریت کلید (KMS/HSM)، چرخش.
حسابرسی: گزارش دسترسی، اطلاعیه های نقض ≤ 72 ساعت، گزارش pentest در درخواست.
محلی سازی: منطقه ذخیره سازی، ممنوعیت صادرات بدون رضایت.

10) زنجیره تامین و قابلیت همکاری

SBOM/آسیب پذیری ها: سیاست آستانه CVSS و زمان تعمیر (انتقاد ≤ 7 روز، ≤ بالا 14).
سازگاری API: تست قرارداد، sandboxes و وسایل پایدار.
تغییرات ارائه دهنده: یادداشت انتشار اولیه، پیش نمایش/پنجره بتا، سازگاری عقب.

11) چند ارائه دهنده و feilover

فعال/فعال: سخت تر و گران تر، اما در دسترس بودن بالاتر (در نظر گرفتن سازگاری).

فعال/منفعل: سرد/گرم ذخیره، دکتر منظم تمرینات

انتزاع/آداپتورها: قرارداد واحد، مسیریابی بهداشت/هزینه/کربن (در صورت لزوم).
شرایط مجوز/تجاری: قابلیت حمل، محدودیت در خروجی داده ها، هزینه خروج.

12) برنامه خروج و تمرینات دوره ای

داده ها/کاتالوگ نمودار و حجم.
اسکریپت قابلیت حمل SDK/API (حداقل - منبع دوم).
آزمون خروج خشک: صادرات/واردات، بازگرداندن، بررسی ناوردا.
دوره های نگهداری/دفع قانونی پس از آزادی.

13) تست های قرارداد و انطباق

نمونه های API: مثبت/منفی، محدودیت ها، خطاها و بازپرداخت ها.
تحویل رویدادها/webhooks: امضا/زمان/پدربزرگ/تکرار.
خطوط پایه Perf: p99، پهنای باند ؛ تست رگرسیون در یادداشت انتشار از ارائه دهنده.
Cross-region: تخریب یک منطقه نباید SLO را در سطح جهانی نقض کند.

14) ضد الگوهای

SLA «در صفحه وضعیت» بدون اندازه گیری های خارجی.
اهداف یکسان برای همه مناطق/نقاط پایانی.
فقدان حقوق حسابرسی و گزارش های دقیق حادثه.
بدون OLA/UC → هیچ کس به انجام تعهدات خارجی در داخل وجود دارد.
برنامه خروج نامشخص → گروگان تامین کننده.
«جریمه فقط با وام» بدون حق فسخ در صورت نقض سیستماتیک.
بدون پنجره انتقال مستهلک میشود.

15) چک لیست معمار

1. SLI/SLO تعریف شده برای جریان کلیدی و مناطق ؟

2. انتخاب روش نظارت خارجی و پایه شواهد ؟

3. آیا حوادث، تشدید، پنجره های کاری برنامه ریزی شده و محدودیت استثنا در SLA بیان شده است ؟

4. مقیاس اعتباری/مجازات و حق فسخ برای نقض N?

5. DPA/امنیت: رمزگذاری، سیاهههای مربوط، اطلاعیه ها، زیر پردازنده، محلی سازی ؟

6. تست قرارداد و جعبه شن و ماسه در خط لوله ؟

7. OLA های داخلی/UC ها SLO های خارجی را فعال می کنند ؟

8. DR: RPO/RTO اعلام کرد، آموزش انجام شده، گزارش های موجود ؟

9. برنامه خروج: فرمت های صادرات، زمان بندی، عمل خروج خشک ؟

10. آیا گیت ها در CI/CD انتشار را مسدود می کنند که خطر نقض SLA را افزایش می دهد ؟

16) نمونه های کوچک (طرح)

16. 1 سیاست استقرار دروازه در خطر ارائه دهنده

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 صادرات «شواهد حادثه»

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 تست وب هوک قرارداد (شبه کد)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

نتیجه گیری

SLA/OLA نه تنها یک مقاله حقوقی است، بلکه یک مکانیزم معماری برای مدیریت ریسک و کیفیت است. معیارها و پنجره های مناسب، نظارت خارجی، روش های حادثه روشن و بازپرداخت، OLA/UC های داخلی، دروازه های خط لوله، چند فروشنده و یک برنامه خروج واقعی، وابستگی ارائه دهنده را به یک بخش کنترل شده، قابل اندازه گیری و اقتصادی قابل پیش بینی از پلت فرم شما تبدیل می کند.