ردیابی به موقع

1) چرا مانیتور آپ تایم

Uptime - سهم زمانی که سرویس در دسترس کاربر است. این «خط اول» قابلیت مشاهده است: بلافاصله متوجه عدم دسترسی، تخریب در شبکه، شکست DNS/TLS، مسیریابی یا مشکلات CDN می شود. برای سیستم های با بار بالا و تنظیم شده (fintech، iGaming)، زمان به طور مستقیم بر درآمد، عملکرد SLA و خطرات مجازات تاثیر می گذارد.

2) شرایط و فرمول ها

SLI = (چک های موفق/همه چک ها) × 100٪.
SLO: در دسترس بودن هدف در هر پنجره (معمولا 28-30 روز)، به عنوان مثال 99. 9%.
SLA: تعهد خارجی ؛ همیشه ≤ SLO داخلی استفاده کنید.
MTBF/MTTR: میانگین زمان بین خرابی/میانگین زمان بازیابی.

99. 0% → ~ 432 دقیقه در دسترس نیست

99. 9٪ → ~ 43 دقیقه

99. 99% → ~4. 3 دقیقه

99. 999% → ~ 26 ثانیه

3) چه چک هایی مورد نیاز است (جعبه سیاه)

راه اندازی از نقاط خارجی (مناطق مختلف/ارائه دهندگان) برای دیدن خدمات «از طریق چشم مشتری».

1. ICMP (پینگ) - دسترسی به شبکه/گره عمومی. سریع، اما منعکس کننده موفقیت کسب و کار نیست.
2. اتصال TCP - گوش دادن به پورت ؟ مفید برای کارگزاران/DB/SMTP.
3. HTTP/HTTPS - کد وضعیت، هدر، اندازه، تغییر مسیر، زمان به بایت اول.
4. TLS/گواهینامه ها - مدت اعتبار، زنجیره ای، الگوریتم ها، SNI، پروتکل ها.
5. DNS - A/AAAA/CNAME، NS سلامت، توزیع، DNSSEC.
6. gRPC - وضعیت تماس، مهلت، ابرداده.
7. WebSocket/SSE - دست دادن، تعمیر و نگهداری اتصال، پیام اکو.
8. پروکسی/مسیریابی/CDN - PoP های مختلف، هش حافظه پنهان، انواع جغرافیایی.
9. سناریوهای ترکیبی تراکنشی (کلیکها/فرمها): «login → search → deposit (sandbox)».
10. نظارت بر ضربان قلب/cron - سرویس باید «پالس» (قلاب یک بار در هر N دقیقه) ؛ بدون سیگنال - زنگ خطر.

• تنظیم زمانهای نزدیک به UX واقعی (به عنوان مثال، TTFB ≤ 300 میلی ثانیه، مجموع ≤ 2 ثانیه).
• دارایی محتوا (کلید واژه/فیلد JSON) را بررسی کنید تا «200 OK» با یک خطا موفقیت آمیز نباشد.
• چک های تکراری از طریق ارائه دهندگان مستقل و شبکه ها (چند هاپ، ASN های مختلف).

4) جعبه سفید و خدمات بهداشتی

زنده بودن/تست آمادگی برای ارکستر (فرآیندها زنده هستند ؟ آماده برای دریافت ترافیک.)

سلامت وابستگی: DB، کش، کارگزار رویداد، API های خارجی (پرداخت/KYC/AML).
پرچم های ویژگی/تخریب: در صورت بروز مشکلات، مسیرهای غیر بحرانی را به آرامی غیرفعال کنید.

نمونه های سفید جایگزین چک های خارجی نمی شوند: سرویس ممکن است در داخل «سالم» باشد، اما به دلیل DNS/TLS/route در دسترس کاربر نیست.

5) جغرافیا و چند منطقه ای

اجرای مصنوعی از مناطق کلیدی ترافیک و نزدیک ارائه دهندگان وابستگی بحرانی.
حد نصاب: یک حادثه در صورت عدم موفقیت در ≥ منطقه N (به عنوان مثال، 2 از 3) برای قطع ناهنجاری های محلی ثبت می شود.
آستانه کوهورت: SLI/SLO جداگانه برای بخش های مهم (کشورها، VIP ها، حامل ها).

6) سیاست هشدار (حداقل سر و صدا)

Multi-region + multi-probe: پیجر فقط در صورت خرابی مداوم (به عنوان مثال، HTTP و TLS به طور همزمان، ≥ 2 منطقه).
Debowns: N شکست متوالی یا 2-3 دقیقه پنجره قبل از صفحه بندی.

• L1: در تماس (خدمات تولید).
• L2 شبکه/پلت فرم/امنیت بر اساس امضای شکست.
• بستن خودکار: پس از بررسی های موفقیت آمیز M.
• ساعتهای آرام/امتیازات: برای خدمات داخلی غیر بحرانی - فقط بلیط، بدون پیجر.

7) صفحه وضعیت و ارتباطات

عمومی (مشتری) و خصوصی (داخلی) صفحات وضعیت.
حوادث خودکار از مصنوعی + حاشیه نویسی دستی.
قالب پیام: شناسایی - شناسایی - ضربه - Workaround - ETA - حل و فصل - پست موردم.
پنجره های برنامه ریزی شده: از قبل اعلام کنید، استثنائات را جدا از SLO در نظر بگیرید.

8) در نظر گرفتن وابستگی های خارجی

برای هر ارائه دهنده (پرداخت، KYC، ارسال نامه، CDN، ابرها) - چک های خود را از چندین منطقه.
مسیرهای شکست خورده: تعویض خودکار به یک ارائه دهنده جایگزین با استفاده از یک سیگنال مصنوعی.
SLO های جداگانه در سطح ارائه دهنده و e2e-SLO یکپارچه.
توافق در SLA با ارائه دهندگان (وضعیت webhooks، اولویت پشتیبانی).

9) داشبورد و ابزارک های کلیدی

نقشه جهان با وضعیت چک (بر اساس نوع: HTTP، DNS، TLS).
جدول زمانی حوادث با حاشیه نویسی انتشار/پرچم.
P50/P95/P99 TTFB/TTL/تاخیر بر اساس منطقه.
در دسترس بودن توسط کوهورت (کشور/ارائه دهنده/دستگاه).
MTTR/MTBF، «دقیقه بیکار» و «سوزاندن» روند بودجه در دسترس بودن برای ماه.
دلایل اصلی شکست (TLS-expiry، DNS-resolution، 5xx، timeouts).

10) فرآیند حادثه (سناریوی گذرا)

1. هشدار چند منطقه ای/چند نوع فعال می شود.
2. افسر وظیفه تأیید می کند، انجماد آزاد را روشن می کند، صاحبان را مطلع می کند.
3. تشخیص سریع: وضعیت DNS/TLS/CDN، آخرین نسخه ها، برنامه خطا.
4. دور زدن: تغییر مسیر، محتوای folback/ارائه دهنده، فعال کردن حالت تخریب.
5. بازیابی: بررسی کنید که ترافیک مصنوعی/واقعی سبز است.

6. ارتباط در صفحه وضعیت ؛ بستن حادثه

7. RCA و آیتم های عمل: رفع، تست، هشدار، playbooks.

11) گزارش SLA/SLO

گزارش های ماهانه: آپ تایم توسط سرویس/منطقه، دقیقه از خرابی، MTTR، دلایل.
مقایسه با SLA: اعتبارات/جبران خسارت، در صورت لزوم.
بررسی های سه ماهه: به روز رسانی آستانه، توزیع مصنوعی، لیست وابستگی ها.

12) قالب های بازرسی (به عنوان مثال)

• روش: 'GET/healthz/public' (بدون اسرار).
• اتمام وقت: 2 s, سعی کنید: 1.
• موفقیت: «2xx»، هدر «X-App-Version» در حال حاضر، فیلد JSON «» وضعیت «:» خوب «».

• مدت> 14 روز، زنجیره معتبر، TLS پروتکل 1. 2 + '، SNI درست است.

• زمان پاسخ ≤ 100 میلی ثانیه، سوابق A/AAAA به عنوان برنامه ریزی شده، بدون SERVFAIL/رد شده است.

• Webhook '/beat/{ service} 'هر 5 دقیقه ؛ عدم وجود 2 سیگنال در یک ردیف - هشدار L2 (وظایف پس زمینه/ETL).

13) چک لیست پیاده سازی

• چک های خارجی چند منطقه (HTTP/TCP/DNS/TLS/اسکریپت های عمیق).
• نمونه آمادگی سفید/زنده برای ارکستر.
• جداسازی مسیرهای بحرانی/غیر بحرانی، پرچم های تخریب.
• حد نصاب و بدهی در هشدار، تشدید و خودکار بستن.
• صفحات وضعیت عمومی و داخلی، قالب پیام.
• چک های جداگانه و SLO برای ارائه دهندگان خارجی + شکست اتوماتیک.
• داشبورد: نقشه، جدول زمانی، درصد، دقیقه بیکار، MTTR/MTBF.
• گزارش SLA/SLO به طور منظم و RCA پس از حادثه.

14) خطاهای مکرر

فقط پینگ/پورت بدون HTTP/محتوا سبز است زمانی که در واقع در دسترس نیست.
یک نقطه نظارت - نتیجه گیری مثبت/منفی کاذب.
بدون کنترل TLS/DNS - قطع ناگهانی به دلیل تاخیر/اشتباه تنظیم.
نویز اضافی: هشدار برای خرابی های تک از همان منطقه/نوع چک.
بدون ارتباط با تغییرات - هیچ حاشیه نویسی از انتشار و پرچم در داشبورد وجود دارد.
وابستگی های حساب نشده - ارائه دهنده پرداخت کاهش یافته است، و وضعیت کلی «سبز» است.

15) خط پایین

ردیابی به موقع فقط در مورد "URL های اوج نیست. این یک سیستم از چک های مصنوعی از مناطق واقعی، هشدار منطقی بدون سر و صدا، ارتباط شفاف از طریق صفحات وضعیت، حسابداری برای وابستگی های خارجی و گزارش دقیق است. نظارت بر زمان به درستی ساخته شده MTTR را کاهش می دهد، SLA ها را محافظت می کند و پیش بینی تجربه کاربر را حفظ می کند.