Aptime izləmə

1) Niyə aptime izləmək

Aptime - xidmətin istifadəçi üçün mövcud olduğu vaxtın bir hissəsidir. Bu «ilk xətt» müşahidə olunur: dərhal əlçatmazlığı, şəbəkədəki deqradasiyanı, DNS/TLS nasazlığını, marşrut problemlərini və ya CDN-ni müşahidə etmək. Yüksək yüklü və tənzimlənən sistemlər üçün (fintech, iGaming) aptaym gəlirə, SLA-ya və cərimə risklərinə birbaşa təsir göstərir.

2) Terminlər və formullar

SLI mövcudluğu: 'SLI = (uğurlu yoxlamalar/bütün yoxlamalar) × 100%'.
SLO: 99 kimi pəncərə arxasında hədəf əlçatanlığı (adətən 28-30 gün). 9%.
SLA: xarici öhdəlik; həmişə daxili SLO ≤.
MTBF/MTTR: uğursuzluqlar arasında orta vaxt/orta bərpa müddəti.

99. 0% → ~ 432 dəqiqə əlçatmazlıq

99. 9% → ~ 43 dəqiqə

99. 99% → ~4. 3 dəqiqə

99. 999% → ~ 26 san

3) Hansı yoxlamalar lazımdır (qara qutu)

Xidməti «müştərinin gözü ilə» görmək üçün xarici nöqtələrdən (müxtəlif regionlar/provayderlər) işə salınır.

1. ICMP (ping) - əsas şəbəkə/qovşağın mövcudluğu. Sürətli, lakin biznes uğurunu əks etdirmir.
2. TCP connect - port dinləyir? Broker/DB/SMTP üçün faydalıdır.
3. HTTP/HTTPS - status kodu, başlıqlar, ölçü, redaktorlar, ilk bayta qədər vaxt.
4. TLS/sertifikatlar - etibarlılıq müddəti, zəncir, alqoritmlər, SNI, protokollar.
5. DNS - A/AAAA/CNAME, NS-sağlamlıq, yayılması, DNSSEC.
6. gRPC - zəng statusu, deadline, metadata.
7. WebSocket/SSE - əl sıxmaq, əlaqə saxlamaq, əks-səda mesajı.
8. Proxy/routing/CDN - müxtəlif PoP, hash cash testi, geo variantları.
9. Tranzaksiyalı sintetik ssenarilər (klik/formalar): «giriş → axtarış → depozit (qum qutusu)».
10. Heartbeat/cron-monitorinq - xidmət «pulsasiya» lazımdır (huk N dəqiqə); siqnal yoxdur - həyəcan.

• Taymautları real UX-ə yaxın qoyun (məsələn, TTFB ≤ 300 ms, total ≤ 2 s).
• Məzmun assertini (açar sözü/JSON sahəsi) yoxlayın ki, «200 OK» səhvlə uğur sayılmasın.
• Müstəqil provayderlər və şəbəkələr (multi-hop, müxtəlif ASN) vasitəsilə yoxlamaları təkrarlayın.

4) Ağ qutu və sağlamlıq xidməti

Orkestrator üçün Liveness/Readiness nümunələri (proseslər canlıdır? trafiki qəbul etməyə hazırsınız?).
Sağlamlıq asılılığı: DB, cache, broker hadisələr, xarici API (ödənişlər/KYC/AML).
Fich bayraqları/deqradasiya: problemlərdə kritik olmayan yolları yumşaq şəkildə söndürürük.

Ağ nümunələr xarici yoxlamaları əvəz etmir: xidmət «daxili sağlam» ola bilər, lakin DNS/TLS/marşrutu səbəbindən istifadəçi üçün əlçatmazdır.

5) Coğrafiya və çoxregionallıq

Əsas trafik bölgələrindən və kritik asılılıq provayderlərinin yanında sintetikanı işə salın.
Kvorum: Yerli anomaliyaları aradan qaldırmaq üçün ≥ N bölgələrdə (məsələn, 3-dən 2-də) uğursuzluq olarsa hadisəni qeyd edirik.
Kohortlara görə eşik: mühüm seqmentlər (ölkələr, VIP, telekom operatorları) üçün ayrı-ayrı SLI/SLO.

6) Alert siyasəti (minimum səs-küy)

Multi-region + multi-test: peycer yalnız razılaşdırılmış uğursuzluq (məsələn, HTTP və TLS eyni zamanda, ≥ 2 regionlar).
Debauns: N ardıcıl uğursuzluqlar və ya pəncərə 2-3 dəqiqə page əvvəl.

• L1: on-call (istehsal xidmətləri).
• L2: şəbəkə/platforma/təhlükəsizlik uğursuzluq əlamətindən asılı olaraq.
• Auto-closer: stabil M uğurlu yoxlamalar sonra.
• Sakit saatlar/güzəştlər: kritik olmayan daxili xidmətlər üçün - yalnız biletlər, peycer olmadan.

7) Status-səhifə və kommunikasiya

İctimai (müştəri) və özəl (daxili) status səhifələri.
Sintetik avtomatik insidentlər + əl izahları.
Mesaj şablonları: aşkar - müəyyən - təsir - bypass - ETA - həll - post-mordem.
Planlaşdırılan pəncərələr: əvvəlcədən elan edin, istisnalar SLO-dan ayrı olaraq nəzərə alınır.

8) Xarici asılılıqların uçotu

Hər bir provayder üçün (ödənişlər, KYC, poçt, CDN, buludlar) - bir neçə regiondan öz yoxlamaları.
Failover-marşrutlar: sintetika siqnalı ilə alternativ provayderə avtomatik keçid.
Provayder səviyyəsində fərdi SLO və inteqral e2e-SLO.
Provayderlərlə SLA razılaşdırın (status-webhucks, dəstək prioriteti).

9) Daşbordlar və açar vidjetlər

Yoxlamaların vəziyyəti ilə dünya xəritəsi (HTTP, DNS, TLS tiplərinə görə).
Relizlərin/bayraqların şərhləri ilə hadisələrin taymline.
Regionlar üzrə TTFB/TTL/latency P50/P95/P99.
Kohortlar üzrə mövcudluq (ölkə/provayder/cihaz).
MTTR/MTBF, aylıq mövcudluq büdcəsinin «fasilə dəqiqələri» və «burn-down» trendləri.
Ən yaxşı uğursuzluq səbəbləri (TLS-expiry, DNS-resolving, 5xx, timeouts).

10) Hadisə prosesi (sürətli ssenari)

1. Multi-region/multi-tip alert işləyir.
2. Növbətçi təsdiqləyir, relizləri dondurur, sahiblərini xəbərdar edir.
3. Sürətli diaqnoz: DNS/TLS/CDN statusu, son buraxılışlar, səhv qrafiki.
4. Dolama: marşrutun dəyişdirilməsi, folbek məzmunu/provayder, deqradasiya rejiminin aktivləşdirilməsi.
5. Bərpa: Sintetik/real trafik yaşıl olduğunu yoxlayın.
6. Status-səhifədə ünsiyyət; hadisənin bağlanması.
7. RCA və action items: düzəlişlər, testlər, alertlər, playbook.

11) SLA/SLO hesabatı

Aylıq hesabatlar: xidmətlər/regionlar üzrə aptaym, fasilə dəqiqələri, MTTR, səbəblər.
SLA ilə müqayisə: kreditlər/kompensasiyalar tətbiq olunarsa.
Rüblük review: eşiklərin aktuallaşdırılması, sintetikanın paylanması, asılılıqların siyahısı.

12) Yoxlama şablonları (nümunə)

• Metod: 'GET/healthz/public' (sirrsiz).
• Zaman: 2 s, retry: 1.
• Uğur: '2xx', 'X-App-Version' başlığı mövcuddur, JSON 'status': 'ok'.

• Müddət> 14 gün, valid zəncir, TLS protokolları 1. 2 + ', düzgün SNI.

• Cavab vaxtı ≤ 100 ms, A/AAAA qeydləri plana uyğun gəlir, SERVFAIL/REFUSED yoxdur.

• Webhook '/beat/{ service} '5 dəqiqədə bir dəfə; ardıcıl 2 siqnal yoxdur - L2 (fon tapşırıqları/ETL).

13) Giriş çek siyahısı

• Multi-regional xarici yoxlamalar (HTTP/TCP/DNS/TLS/dərin ssenarilər).
• Orkestrator üçün ağ readiness/liveness nümunələri.
• Kritik/qeyri-kritik yolların ayrılması, deqradasiya fiqa bayraqları.
• Alertlər, eskalasiya və avtomatik bağlanışlarda kvorum və debauns.
• Ictimai və daxili status səhifələri, mesaj şablonları.
• Xarici provayderlər üçün fərdi yoxlamalar və SLO + avtomatik failover.
• Dashboard: kart, time line, pursenti, fasilə dəqiqələri, MTTR/MTBF.
• SLA/SLO və post-insident RCA müntəzəm hesabatları.

14) Tez-tez səhvlər

NTTR/məzmunu olmayan yalnız ping/port - faktiki əlçatmazlıqda «yaşıl».
Bir monitorinq nöqtəsi yanlış müsbət/mənfi nəticələrdir.
TLS/DNS nəzarətinin olmaması - gecikmə/misconfig səbəbindən qəfil fasilələr.
Əlavə səs-küy: bir bölgədən/yoxlama tipindən tək uğursuzluqlar üçün alertlər.
Dəyişikliklə heç bir əlaqəsi yoxdur - daşbordlarda buraxılışların və bayraqların qeydləri yoxdur.
Nəzərə alınmayan asılılıqlar - ödəniş provayderi düşdü və ümumi status «yaşıl».

15) Yekun

Aptime-in izlənməsi yalnız «URL-lər» deyil. Bu, real bölgələrdən sintetik yoxlamalar sistemi, səs-küy olmadan ağlabatan risklər, status səhifələri vasitəsilə şəffaf ünsiyyət, xarici asılılıqların uçotu və ciddi hesabatdır. Düzgün qurulmuş bir aptime monitorinqi MTTR-ni azaldır, SLA-nı qoruyur və istifadəçi təcrübəsinin proqnozlaşdırıla biləcəyini qoruyur.