Production mühitində işləyən məhsul üçün ən vacib sual “server işləyirmi?” deyil, istifadəçi əsas işi uğurla görə bilirmi? sualıdır. Qeydiyyat, giriş, sifariş, ödəniş, hesabatın yaradılması və ya bildirişin çatdırılması pozulanda, bunu ilk olaraq support sorğusundan, sosial şərhdən və ya gəlir azalmasından öyrənmək artıq gecdir. Düzgün application monitoring and support yanaşması problemi istifadəçi bildirməzdən əvvəl aşkar edir, təsiri qiymətləndirir və komandanı konkret hərəkətə yönəldir.
Bu, sadəcə daha çox dashboard almaq demək deyil. Monitorinq məhsulun kritik istifadəçi axınlarına, sahiblik modelinə və insident prosesinə bağlanmalıdır. Əks halda komanda çoxlu CPU, log və request qrafiki görəcək, amma “ödənişlər həqiqətən tamamlanırmı?” sualına tez cavab verməyəcək.
Əvvəlcə istifadəçinin uğurlu nəticəsini müəyyən edin
Texniki metriklər lazımdır, lakin onlar biznes nəticəsinin əvəzi deyil. Hər məhsul üçün 3–7 kritik səyahəti seçin və hər biri üçün ölçülə bilən uğur vəziyyəti yazın. Məsələn:
- Yeni istifadəçi qeydiyyatı təsdiq e-poçtu ilə tamamlanır.
- Müştəri daxil olur və öz hesab məlumatlarını görür.
- Sifariş yaradılır, ödəniş təsdiqlənir və istifadəçiyə nəticə göstərilir.
- Mobil tətbiq açılır, sessiya bərpa olunur və əsas ekran yüklənir.
- Fon prosesində yaradılan hesabat hazır olur və istifadəçiyə təqdim edilir.
Bu yanaşma monitorinqi komponent siyahısından məhsul risk xəritəsinə çevirir. Məsələn, “payment API 200 qaytardı” hələ ödənişin biznes baxımından uğurlu olması demək deyil. Provider webhook-u gecikə, sifariş statusu yenilənməyə və ya istifadəçiyə uğursuz nəticə görünə bilər. Ona görə həm texniki cavabı, həm də biznes hadisəsinin son vəziyyətini izləmək lazımdır.
Hər production məhsul üçün əsas müşahidə qatları
1. Xaricdən görünən əlçatanlıq və sintetik yoxlamalar
Black-box və ya sintetik yoxlama real istifadəçi kimi sistemə kənardan baxır. O, sadəcə ana səhifənin cavab verməsini deyil, kritik ssenarinin işləməsini yoxlamalıdır: giriş səhifəsi açılır, API token verir, kataloq yüklənir və ya test hesabı ilə checkout başlanır.
Yoxlamaları məhsulun istifadə olunduğu regionlardan işə salın və endpoint, DNS, TLS sertifikatı, redirect, status kodu və cavab müddəti üzrə nəticəni saxlayın. Sadə health endpoint faydalıdır, amma o, istifadəçiyə görünən axının işlədiyini sübut etmir. Sintetik test uğursuzdursa və eyni zamanda real error rate artırsa, yüksək prioritetli insident üçün güclü siqnaldır.
2. Veb tətbiqinin error rate və gecikməsi
Web application monitoring üçün request sayını, uğursuz cavab nisbətini və gecikmə paylanmasını endpoint, status kodu, region, tətbiq versiyası və mümkün olduqda tenant üzrə izləyin. Orta cavab müddəti təkbaşına yetərli deyil: istifadəçilərin kiçik, lakin vacib hissəsi üçün yaranan uzun gecikmələri gizlədə bilər. p95 və p99 kimi yüksək percentillər, xüsusilə giriş, axtarış, checkout və məlumat saxlanması üçün daha praktik siqnaldır.
500 xətalarını 400 xətaları ilə qarışdırmayın. Bəzi 4xx cavabları istifadəçi giriş səhvi və ya gözlənilən validasiya nəticəsi ola bilər; digər tərəfdən 401 və 403 artımı token, session və ya konfiqurasiya problemi göstərə bilər. Error metriklərini route və xəta növü üzrə bölün. “5xx artdı” alerti faydalıdır, “bütün endpoint-lər normaldır” dashboard-u isə triage üçün kifayət etmir.
3. Trace, metric və strukturlaşdırılmış log əlaqəsi
İnsident zamanı komanda “nə baş verdi?” və “harada baş verdi?” suallarına cavab axtarır. Metrik trendi göstərir, strukturlaşdırılmış log konkret hadisəni izah edir, trace isə bir sorğunun frontend, API, database, queue və üçüncü tərəf xidmətlərindən keçən yolunu göstərir. OpenTelemetry bu telemetriya siqnallarını trace, metric və log kimi standartlaşdırılmış şəkildə toplamaq və ixrac etmək üçün istifadə edilə bilər.
Hər request-ə correlation ID və trace ID qoşun. Loglarda ən azı timestamp, environment, service, tətbiq versiyası, request və ya job ID, xəta tipi və təhlükəsiz kontekst olmalıdır. Parol, kart məlumatı, access token və ya lazımsız şəxsi məlumatları log-a yazmayın. Məlumatın minimallaşdırılması həm təhlükəsizlik, həm də dəqiq araşdırma üçün vacibdir.
4. Mobil crash, ANR və release keyfiyyəti
Mobile app crash monitoring yalnız ümumi crash sayını izləmək deyil. Crash-free users və crash-free sessions, fatal və non-fatal xətalar, Android-də ANR-lər, iOS və Android versiyası, cihaz modeli, OS versiyası və tətbiq release-i üzrə segmentləşdirmə lazımdır. Yeni release-dən sonra müəyyən cihaz qrupunda crash sürətlə artırsa, web backend tam sağlam görünsə belə istifadəçilər məhsula çata bilməyə bilər.
Crash hesabatında breadcrumb-lar — məsələn, “login”, “payment method selected”, “submit tapped” kimi əvvəlki hadisələr — problemi təkrar yaratmaq üçün dəyərlidir. Mobil crash alətləri yeni, yenidən yaranan və sürətlə artan problemlər üzrə alert göndərə bilər. Lakin alert yalnız sahib, severity və runbook ilə birləşəndə əməli dəyər yaradır.
Yeni tətbiq versiyasını tam auditoriyaya bir anda yaymaq əvəzinə mərhələli rollout edin. Hər mərhələdə crash-free göstəricisi, API error rate, startup vaxtı və kritik funnel-lərin tamamlanmasını əvvəlki stabil release ilə müqayisə edin. Mobil məhsulun hazırlanması və release intizamı üçün mobil tətbiqlərin hazırlanması xidmətinə baxa bilərsiniz.
5. Queue, scheduler və fon işlərinin vəziyyəti
İstifadəçinin gördüyü nəticə çox vaxt asinxron prosesdən asılı olur: e-poçt göndərilməsi, fayl emalı, indeksləmə, export, bildiriş, settlement və ya AI emalı. Bu proseslər üçün sadəcə “worker up” metrikası kifayət deyil. Queue depth, ən köhnə mesajın yaşı, uğurlu və uğursuz job sayı, retry sayı, dead-letter queue həcmi, işləmə müddəti və son uğurlu run vaxtını izləyin.
Məsələn, gecə hesabatı 02:00-da başlamalıdırsa, 02:10-da “işləyir” siqnalı yox, 03:00-a qədər “uğurla tamamlandı və nəticə yaradıldı” siqnalı daha qiymətlidir. Səssiz uğursuzluqları tutmaq üçün heartbeat və freshness yoxlamaları yaradın: gözlənilən periodda yeni fayl, yeni qeyd və ya tamamlanmış job yoxdursa, ticket və ya page yaransın.
6. Ödənişlər və üçüncü tərəf inteqrasiyaları
Ödəniş provider-i, SMS, e-poçt, xəritə, market-data, identifikasiya və digər inteqrasiyalar məhsulun bir hissəsidir. Hər biri üçün çağırış həcmi, uğur nisbəti, timeout, retry, provider-in cavab kodları, webhook qəbul nisbəti və emal gecikməsi izlənməlidir. İnteqrasiya uğursuzluğu daxili 500 xətası yaratmaya bilər, amma istifadəçini yarımçıq prosesdə saxlaya bilər.
Ödəniş axınında idempotency, provider event ID və daxili order ID-ni əlaqələndirin. Webhook-ları imza yoxlaması ilə qəbul edin, təkrar çatdırılmaya hazır olun və event emalı uğursuz olduqda izlənə bilən retry mexanizmi saxlayın. FinTech və inteqrasiya ağır məhsullarda bu əməliyyat detalları xüsusilə vacibdir; uyğun təcrübə üçün FinTech və trading sistemləri səhifəsinə baxın.
Alert qaydası: hər siqnal insanı oyatmamalıdır
Yaxşı alert “təcili, hərəkət edilə bilən və istifadəçiyə görünən təsir var” mesajını verir. Google SRE yanaşmasında latency, traffic, errors və saturation əsas siqnallar kimi göstərilir. Praktik olaraq alertləri üç səviyyəyə bölmək faydalıdır:
- Page: aktiv istifadəçi təsiri var, sahib dərhal reaksiya verməlidir. Məsələn, checkout sintetik testi və real ödəniş uğur nisbəti eyni anda pisləşib.
- Ticket: təcili deyil, amma izlənməli risk var. Məsələn, disk doluluğu artım trendinə görə yaxın günlərdə limitə çatacaq.
- İnformasiya: release, konfiqurasiya dəyişikliyi və ya gözlənilməz, lakin təsirsiz hadisə. Bu mesaj pager-a getməməlidir.
Threshold-ları kor-koranə seçməyin. Normal davranışın bazasını, günlük pikləri və məhsulun riskini nəzərə alın. Az trafikli sistemdə faiz əsaslı error rate tək request səbəbindən yanıltıcı ola bilər; minimum request sayı və zaman pəncərəsi əlavə edin. Yüksək trafikli məhsulda isə yalnız 15 dəqiqəlik orta göstərici insidenti gec aşkar edə bilər.
Sahiblik və runbook olmadan monitorinq yarımçıqdır
Hər alert üçün cavabdeh komanda və ya şəxs, eskalasiya yolu, təsir olunan istifadəçi axını, dashboard linki və qısa runbook olmalıdır. Runbook nəzəri sənəd deyil; on-call mühəndisin ilk 10 dəqiqədə tətbiq edə biləcəyi konkret addımlar toplusudur:
- Alertin real istifadəçi təsiri yaratdığını sintetik və real metriklərlə yoxlayın.
- Scope-u müəyyən edin: hansı region, release, endpoint, platforma və ya tenant təsirlənib?
- Son deploy, feature flag, konfiqurasiya və provider status dəyişikliyini yoxlayın.
- Mitigasiya seçin: rollback, flag-in bağlanması, queue-nun dayandırılması, traffic yönləndirməsi və ya provider fallback.
- İstifadəçi və biznes təsirini qeyd edin, sonra kök səbəb və izləmə tədbirlərini planlaşdırın.
Runbook-ları incident keçdikdən sonra yeniləyin. Eyni alert üçün hər dəfə fərqli insanın fərqli araşdırma aparması məhsulun dəstək modelində boşluq olduğunu göstərir.
90 dəqiqəlik ilkin monitorinq inventarı
Mövcud məhsul üçün başlanğıc olaraq bu sualları cavablandırın:
- İlk beş kritik istifadəçi əməliyyatı hansılardır və hər biri üçün “uğurlu” nəticə nədir?
- Bu əməliyyatların sintetik yoxlaması varmı?
- Hansı API route-larında p95/p99 latency və 5xx izlənir?
- Hər release üzrə mobil crash və ANR təsiri görünürmü?
- Hər kritik queue və scheduled job üçün freshness, failure və backlog siqnalları varmı?
- Ödəniş və inteqrasiya event-ləri daxili biznes obyektləri ilə əlaqələndirilirmi?
- Hər page alertinin sahibini və runbook-unı on-call mühəndis 30 saniyədə tapa bilirmi?
Bu sualların çoxuna “bilmirik” cavabı varsa, problem alət çatışmazlığı deyil; monitorinq dizaynı, sahiblik və software support and maintenance prosesinin yenidən qurulmasıdır.
Monitorinqi məhsulun davamlı dəstək modelinə çevirin
Monitorinq bir dəfə qurulub unudulan infrastruktur işi deyil. Yeni endpoint, yeni mobil release, yeni payment provider və ya yeni background job çıxanda telemetriya, dashboard, alert və runbook da dəyişməlidir. Bu iş release planına daxil edilmədikdə komanda yalnız problem baş verəndə sistemin necə işlədiyini öyrənir.
POLADO-da texniki dəstək və konsaltinq xidməti məhsulun monitorinq xəritəsini, performans və release risklərini, alert keyfiyyətini və incident response prosesini praktik şəkildə nəzərdən keçirməyə kömək edir. Məhsulunuz veb və mobil kanallarda işləyirsə, veb platformaların hazırlanması və support komandası ilə birlikdə kritik axınlara uyğun ölçülə bilən monitorinq planı hazırlamaq üçün bizimlə əlaqə saxlayın.