گزارش های آپ تایم و حسابرسی SLA

1) چرا ما به یک گزارش رسمی uptime نیاز داریم ؟

اعتماد مشتری و شفافیت قرارداد - یک روش اندازه گیری واحد، محاسبات قابل تکرار

SLO و مدیریت بودجه خطا - ارتباط واقعیت در دسترس بودن با انتشار و حوادث.
وام SLA صحیح هستند فرمول هدف، پرداخت قابل پیش بینی/آفست.
پایداری قانونی - پایه شواهد، حسابرسی مستقل، نگهداری قانونی.

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

در دسترس بودن SLI - درصد اعتبار سنجی/معاملات موفق در هر دوره.

SLO - هدف داخلی (به عنوان مثال 99. 95% در 28 روز)

SLA - تعهد خارجی (به عنوان مثال 99. 9 ٪/ماه + وام خدمات).
پنجره اندازه گیری - ماه تقویم (SLA) و پنجره نورد (SLO).
دامنه - کدام مؤلفه ها در محاسبه (لبه، API، پرداخت) گنجانده شده اند و کدام ها نیستند (پورتال مدیریت، غیر تحریک).

قانون: SLA ≤ SLO است و بر اساس SLI های تأیید شده توسط مشتری است.

3) منابع حقیقت (و زمانی که یکی مسئول است)

1. Synthetics (جعبه سیاه/بدون سر) SLI اصلی برای «دسترسی کاربر چشم» است.
2. Logs/metrics - مقیاس و ماهیت شکست را تایید می کند.
3. رویدادهای تجاری «موفقیت معامله» هستند (به عنوان مثال، پرداخت مجاز).
4. صفحه وضعیت - ارتباطات عمومی ؛ در برابر حقایق شماره 1-3 بررسی می شود.

در صورت اختلاف: اولویت به مصنوعی با حد نصاب صحیح از مناطق ≥2 داده شده است.

4) روش محاسبه در دسترس بودن

4. 1 فرمول پایه

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 حد نصاب چند منطقه ای

یک حادثه شمارش می شود اگر ≥N منطقه مستقل/ASN به طور همزمان یک شکست را ثبت کنند.
توصیه شده: N = 2 از 3 (EU/NA/APAC).

4. 3 نوع SLI

HTTP SLI: код 2xx/3xx، تاخیر ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/انقضای.
کسب و کار SLI: معاملات موفق/تمام تلاش ها (به استثنای شکست های مشتری).

4. 4 استثنا (مستند)

پنجره های نگهداری برنامه ریزی شده از قبل N ساعت اعلام شده و مشاهده شده است.
فورس ماژور از SLA (به عنوان مثال، ارائه دهنده فاجعه IX) - تنها در صورتی که شواهد و اطلاع عمومی وجود دارد.
خطاها/محدودیت های مشتری (سهمیه بیش از 4xx).

5) سیاست نگهداری پنجره

شکاف های زمانی توافق شده در قرارداد (به عنوان مثال،. خورشید 02: 00-04: 00 UTC + 0).
'Maintenance = true' markers in alert/panels → exclusion from SLI.
آستانه اطلاع رسانی: حداقل 5 روز کاری (یا همانطور که در قرارداد).
خارج از پنجره - تاثیر SLA در نظر گرفته شده است.

6) موارد لبه و قوانین گرد کردن

Brownout (تخریب جزئی): درصد خرابی ها (خرابی وزن) را شمارش کنید، نه «0/1».
Flapping: حداقل واحد حساب - فاصله نمونه (به عنوان مثال، 30-60 ثانیه) + هیسترزیس (برای: 2-5 دقیقه).
رانش ساعت: همه زمان ها در UTC و ISO-8601 ؛ هماهنگ سازی NTP.

7) نمونه هایی از PromQL (مصنوعی → آپ تایم)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) نمونه هایی از SQL (جمع آوری گزارش)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) قالب گزارش ماهانه (مشتری پسند)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) اعتبارات SLA: محاسبه و کاربرد

جدول اعتبارات: به عنوان مثال، 99. 0–99. 5٪ → 5٪ MRR ؛ 98. 0–99. 0% → 10%, و غیره.
True-up: اعتبار به عنوان یک یادداشت اعتباری برای حساب بعدی اعمال می شود.

اتوماسیون: «اگر» اندازه گیری _ در دسترس بودن

نمایشگاه برای مشتری: کارت پورتال «تعادل اعتبارات SLA».

11) حسابرسی، شواهد و نگهداری قانونی

دنباله حسابرسی: چه کسی/چه چیزی/زمانی محاسبه شده، نسخه روش، چک سام ها.
داده های خام تغییر ناپذیر است (فقط پیوست) ؛ تنظیمات - توسط سوابق جداگانه.
حقوقی نگه دارید: انجماد محدوده داده ها (نمونه, سیاهههای مربوط, کارت های حادثه, هشدار).
آرشیو کپی رایت - قفل شی WORM/S3.

12) آشتی با صفحه وضعیت عمومی

یک حادثه در یک صفحه وضعیت باید یک جدول زمانی و اجزای داشته باشد.
عدم تطابق زمان/مقیاس توسط رکورد اختلاف ایجاد شده و توسط RCA ارسال میشود.
خلاصه گزارش شامل بخش یادداشت های آشتی است.

13) حوادث و گزارش

هر پنجره خرابی مربوط به یک کارت INC (ID، SEV، مالک، RCA، CAPA) است.
در گزارش: لینک به INC، علت ریشه کوتاه، وضعیت CAPA.
برای SEV-1: موضوعات پست بیشتر ≤ 48 ساعت از بسته شدن.

14) کنترل کیفیت داده ها

بهداشت نمونه ها:> 99٪ از ضایعات موفقیت آمیز عوامل، عدم وجود شکاف> 5 دقیقه.
ضد سر و صدا: حد نصاب + چند پنجره، debounce.
نمونه برداری ردیابی/ورود ثبت و مستند شده است.
تست روش: تست واحد محاسبات، فایل های طلایی بر اساس داده های تاریخی.

15) امنیت و حریم خصوصی

TLS/mTLS برای وارد کردن، امضای بسته (HMAC).
نسخه PII در سیاههها/گزارشها ؛ گزارش SLA نباید اطلاعات شخصی را افشا کند.
RBAC/ABAC در گزارش ؛ آثار دسترسی به گزارش حسابرسی نوشته شده است.

16) داشبورد و ابزارک های SLO (چه چیزی را نشان می دهد)

در دسترس بودن کلی توسط سرویس برای ماه/سه ماهه.
پنجره های Downtime با شدت و کانال تشخیص.
سوزاندن بودجه خطا (سریع/آهسته) و روند.
انتشار پوشش - حاشیه نویسی محاسبات.
پیش بینی اعتبارات SLA - در روند فعلی.

17) برنامه پیاده سازی (3 تکرار)

1. مدل و داده (2 هفته): SLI/SLO/SLA را برطرف کنید، شامل مصنوعی حد نصاب، جمع آوری «مواد اولیه» در DWH.
2. محاسبه و گزارش (2-3 هفته): فرمول ها، SQL/PromQL، قالب های YAML/PDF، پورتال مشتری، اعتبار خودکار.
3. ممیزی و اتوماسیون (3-4 هفته): برگزاری حقوقی، آشتی با صفحه وضعیت، وب سایت های امضا شده، مقررات اختلاف.

18) چک لیست کیفیت گزارش

• محدوده، SLI، روش و پنجره اندازه گیری تعریف شده است.
• حد نصاب و چند پنجره وجود دارد ؛ تلنگر سرکوب شده است.
• استثنائات (نگهداری/نیروی majeure) مستند شده است.
• هر پنجره خرابی با INC و RCA مرتبط است.
• اعتبارات SLA محاسبه شده و در صورتحساب منعکس شده است.
• گزارش تجدید پذیر (فرمول/نسخه های داده).
• پیگیری حسابرسی و نگهداری قانونی گنجانده شده است.
• صفحه وضعیت عمومی تنظیم شده است.

19) مینی سوالات متداول

چرا synthetics منبع اصلی است ؟

این نزدیک به مسیر کاربر است و شامل یک محیط (DNS/CDN/WAF) است. معیارها/سیاههها - دلیل را روشن کنید.

چگونه تخریب جزئی را محاسبه کنیم ؟

خرابی وزنی: نسبت خرابی × مدت زمان پنجره، و نه «همه یا هیچ چیز».

آیا باید چک های «خام» را ذخیره کنم ؟

بله، داشتم. برای حسابرسی و تجدید نظر در یک اختلاف - خام مورد نیاز است.

نتیجه گیری

گزارش های Uptime و حسابرسی SLA یک «رقم در پایان ماه» نیست، بلکه یک سیستم قابل تجدید اندازه گیری، قوانین و شواهد است: SLI صحیح، چک کردن حد نصاب، فرمول های شفاف، ارتباط با حوادث و صورتحساب، کنترل استثنا و نگهداری قانونی. روش را ثبت کنید، محاسبه و اعتبار را به صورت خودکار انجام دهید، دنباله حسابرسی را حفظ کنید - و SLA های شما قابل کنترل، قابل فهم و ایمن خواهند بود.