Çalışma süresi izleme

1) Neden çalışma süresini izleyin

Çalışma süresi - hizmetin kullanıcıya sunulduğu zaman paylaşımı. Bu, gözlemlenebilirliğin'ilk satırı'dır: anında erişilemezliği, ağ üzerindeki bozulmayı, DNS/TLS arızasını, yönlendirmeyi veya CDN sorunlarını fark eder. Yüksek yüklü ve düzenlenmiş sistemler için (fintech, iGaming), çalışma süresi doğrudan geliri, SLA performansını ve ceza risklerini etkiler.

2) Şartlar ve formüller

Kullanılabilirlik SLI: 'SLI = (başarılı kontroller/tüm kontroller) × %100'.
SLO: Pencere başına kullanılabilirliği hedefleyin (genellikle 28-30 gün), örneğin 99. 9%.
SLA: dış yükümlülük; Her zaman dahili SLO ≤.
MTBF/MTTR: Arızalar arasındaki ortalama süre/ortalama kurtarma süresi.

99. 0 % - ~ 432 dk kullanılamaz

99. 9 % ~ 43 dk

99. 99% → ~4. 3 dakika

99. %999 - ~ 26 sn

3) Hangi kontrollere ihtiyaç vardır (kara kutu)

Hizmeti "müşterinin gözünden" görmek için harici noktalardan (farklı bölgeler/sağlayıcılar) başlatılır.

1. ICMP (ping) - temel ağ/düğüm kullanılabilirliği. Hızlı, ancak iş başarısını yansıtmıyor.
2. TCP bağlantısı - port dinleme? Broker/DB/SMTP için yararlıdır.
3. HTTP/HTTPS - durum kodu, başlıklar, boyut, yönlendirmeler, ilk bayt zamanı.
4. TLS/sertifikalar - geçerlilik süresi, zincir, algoritmalar, SNI, protokoller.
5. DNS - A/AAAA/CNAME, NS-sağlık, dağıtım, DNSSEC.
6. gRPC - arama durumu, son tarih, meta veriler.
7. WebSocket/SSE - el sıkışma, bağlantı bakımı, yankı mesajı.
8. Proxy/routing/CDN - farklı PoP'lar, önbellek karması, coğrafi değişkenler.
9. İşlemsel sentetik senaryolar (tıklamalar/formlar): "Oturum açma - arama - para yatırma (sanal alan)".
10. Kalp atışı/cron izleme - servis "nabız" olmalıdır (her N dakikada bir kanca); Sinyal yok - alarm.

• Gerçek UX'e daha yakın zaman aşımları ayarlayın (örneğin, TTFB ≤ 300 ms, toplam ≤ 2 s).
• İçerik varlığını (anahtar kelime/JSON alanı) kontrol edin, böylece bir hatayla "200 OK" başarılı sayılmaz.
• Bağımsız sağlayıcılar ve ağlar (multi-hop, farklı ASN'ler) aracılığıyla kontrolleri çoğaltın.

4) Beyaz kutu ve sağlık hizmeti

Orkestratör için canlılık/Hazır olma testleri (süreçler canlı mı? Trafik almaya hazır?).
Bağımlılık sağlığı: DB, önbellek, olay aracısı, harici API'ler (ödemeler/KYC/AML).
Özellik bayrakları/bozulması: sorun olması durumunda, kritik olmayan yolları hafifçe devre dışı bırakın.

Beyaz örnekler harici kontrollerin yerini almaz: hizmet "içeride sağlıklı" olabilir, ancak DNS/TLS/rota nedeniyle kullanıcı tarafından kullanılamaz.

5) Coğrafya ve çok bölgesellik

Önemli trafik bölgelerinden ve kritik bağımlılık sağlayıcılarına yakın sentetikleri çalıştırın.
Quorum: ≥ N bölgelerinde (örneğin, 2/3) yerel anomalileri kesmek için bir başarısızlık varsa bir olay kaydedilir.
Kohortla eşik: Önemli segmentler için ayrı SLI/SLO (ülkeler, VIP'ler, taşıyıcılar).

6) Uyarı politikası (gürültü minimum)

Çok bölgeli + çok problu: yalnızca tutarlı bir arıza durumunda çağrı cihazı (örneğin, HTTP ve TLS aynı anda, ≥ 2 bölge).
Debowns: N ardışık arızalar veya çağrı öncesi 2-3 dakika pencere.

• L1: on-call (üretim hizmetleri).
• Arıza imzasına dayalı L2 ağ/platform/güvenlik.
• Otomatik kapatma: kararlı M başarılı kontrollerden sonra.
• Sessiz saatler/tavizler: kritik olmayan dahili hizmetler için - sadece biletler, çağrı cihazı yok.

7) Durum sayfası ve iletişim

Genel (istemci) ve özel (dahili) durum sayfaları.
Sentetik + manuel ek açıklamalardan otomatik olaylar.
Mesaj Şablonları: Algılandı - Tanımlandı - Etki - Geçici Çözüm - ETA - Çözüldü - Mordem Sonrası.
Planlanan pencereler: önceden duyurun, istisnaları SLO'dan ayrı olarak düşünün.

8) Dış bağımlılıkların dikkate alınması

Her sağlayıcı için (ödemeler, KYC, postalar, CDN, bulutlar) - çeşitli bölgelerden kendi kontrolleri.
Yük devretme yolları: Sentetik bir sinyal kullanarak alternatif bir sağlayıcıya otomatik geçiş.
Sağlayıcı düzeyinde ayrı SLO'lar ve entegre e2e-SLO.
Sağlayıcılarla SLA üzerinde anlaşın (durum web kitapları, destek önceliği).

9) Gösterge panoları ve anahtar widget'ları

Denetimlerin durumu ile dünya haritası (türe göre: HTTP, DNS, TLS).
Release/flag ek açıklamaları ile olayların zaman çizelgesi.
Bölgelere göre P50/P95/P99 TTFB/TTL/gecikme süresi.
Kohorta göre kullanılabilirlik (ülke/sağlayıcı/cihaz).
MTTR/MTBF, ay için kullanılabilirlik bütçesinin "boş dakikalar've" yanma "eğilimleri.
Arızaların başlıca nedenleri (TLS-sona erme, DNS-çözümleme, 5xx, zaman aşımları).

10) Olay süreci (geçici senaryo)

1. Çok bölgeli/çok tipli uyarı tetiklenir.
2. Görevli memur onaylar, salımların dondurulmasını açar, sahiplerine haber verir.
3. Hızlı tanılama: DNS/TLS/CDN durumu, en son sürümler, hata zamanlaması.
4. Bypass: rota değişikliği, folback içeriği/sağlayıcısı, bozulma modunu etkinleştirme.
5. Kurtarma: sentetiklerin/gerçek trafiğin yeşil olduğunu doğrulayın.
6. Durum sayfasında iletişim; olayı kapatmak.
7. RCA ve eylem öğeleri: düzeltmeler, testler, uyarılar, oyun kitapları.

11) SLA/SLO Raporlama

Aylık raporlar: hizmet/bölgeye göre çalışma süresi, kesinti dakikaları, MTTR, nedenler.
SLA ile karşılaştırma: Varsa krediler/tazminatlar.
Üç aylık incelemeler: eşiklerin güncellenmesi, sentetiklerin dağılımı, bağımlılıkların listesi.

12) Muayene şablonları (örnek)

• Yöntem: 'GET/healthz/public' (sır yok).
• Zaman aşımı: 2 s, yeniden deneme: 1.
• Başarı: '2xx', başlık 'X-App-Version' mevcut, JSON alanı '"durum":'tamam "'.

• Terim> 14 gün, geçerli zincir, protokoller 'TLS 1. 2 + ', doğru SNI.

• Yanıt süresi ≤ 100 ms, A/AAAA kayıtları planlandığı gibidir, SERVFAIL/REJECTED yoktur.

• Webhook'/beat/{ service}'her 5 dakikada bir; Üst üste 2 sinyalin yokluğu - L2 uyarısı (arka plan görevleri/ETL).

13) Uygulama kontrol listesi

• Çok bölgeli harici kontroller (HTTP/TCP/DNS/TLS/derin komut dosyaları).
• Orkestratör için beyaz hazırlık/canlılık örnekleri.
• Kritik/kritik olmayan yolların ayrılması, bozunma bayrakları.
• Quorum ve borç uyarıları, eskalasyon ve otomatik kapanma.
• Genel ve dahili durum sayfaları, mesaj şablonları.
• Dış sağlayıcılar + otomatik yük devretme için ayrı kontroller ve SLO.
• Panolar: harita, zaman çizelgesi, yüzdelik, boşta dakika, MTTR/MTBF.
• Düzenli SLA/SLO raporları ve olay sonrası RCA'lar.

14) Sık yapılan hatalar

Yalnızca HTTP/içerik içermeyen ping/port, gerçekte mevcut olmadığında yeşildir.
Bir izleme noktası - yanlış pozitif/negatif sonuçlar.
TLS/DNS kontrolü yok - gecikme/yanlış yapılandırma nedeniyle ani kesintiler.
Ekstra gürültü: Aynı bölgeden/kontrol türünden tek arızalar için uyarılar.
Değişikliklerle bağlantı yok - panolarda sürümlerin ve bayrakların ek açıklamaları yok.
Hesaplanmamış bağımlılıklar - ödeme sağlayıcısı düştü ve genel durum'yeşil ".

15) Alt satır

Çalışma süresi izleme sadece "zirve yapan URL'ler'ile ilgili değildir. "Bu, gerçek bölgelerden sentetik kontroller, gürültüsüz makul uyarılar, durum sayfaları aracılığıyla şeffaf iletişim, dış bağımlılıkların muhasebeleştirilmesi ve sıkı raporlama sistemidir. Düzgün bir şekilde oluşturulmuş çalışma süresi izleme, MTTR'yi azaltır, SLA'ları korur ve kullanıcı deneyiminin öngörülebilirliğini korur.