“Hazırdır” sözünün arxasında sübut olsun
Bu siyahını hər sətri avtomatik işarələnən şablon kimi istifadə etmə. Hər yoxlama üçün mühit, nəticə və məsul şəxs yaz. Məsələn: “readiness var” yox, “instansiya hazır olmadan trafik almır; staging-də 26 sentyabrda yoxlanılıb”.
Buradakı konfiqurasiya nümunələri Spring Boot 3.5 üçündür. Öz versiyan, reverse proxy və yerləşdirmə mühitin üçün davranışı ayrıca sına. Siyahının bütün bəndlərinin hər servisə eyni formada tətbiqi tələb olunmur; tətbiq edilməyən bəndin səbəbini qeyd et.
İcazə sərhədini serverdə yoxla
- Qonaq, adi istifadəçi və admin üçün eyni endpoint-i ayrıca çağır. UI-da düyməni gizlətmək icazə yoxlaması deyil.
- Başqa istifadəçinin resurs ID-sini göndər: sifariş, fayl və profil məlumatı açılmamalıdır.
- Secret-ləri repository və container image-dən çıxar. Log, xəta cavabı və support ekranlarında da görünmədiyini yoxla.
- CORS üçün lazım olan origin-ləri açıq göstər. Cookie əsaslı girişdə CSRF strategiyasını da sına; CORS onu əvəz etmir.
- Login və parol bərpası kimi endpoint-lərə ölçülmüş sorğu məhdudiyyəti qoy. Proxy arxasında real client IP-nin etibarlı yolla alındığını yoxla.
Actuator-u ayrıca səth hesab et. Public HTTP üzərindən yalnız lazım olan endpoint-ləri aç; daxili metriklərə isə ayrıca şəbəkə və icazə qaydası ver. env, heapdump və oxşar diaqnostika məlumatları public olmamalıdır.
Liveness və readiness ayrı suallardır
Liveness: bu prosesin işləməsi davam edə bilərmi? Readiness: bu instansiyaya indi yeni trafik göndərmək olarmı?
Baza müvəqqəti dayananda bütün tətbiqləri restart etmək bazanı bərpa etmir. Buna görə liveness yoxlamasını xarici servislərin sağlamlığından asılı etmə. Readiness-ə bazanı daxil etmək isə şüurlu qərardır: ortaq baza sıradan çıxsa, bütün instansiyalar trafikdən çıxa bilər.
management:
endpoints:
web:
exposure:
include: health
endpoint:
health:
show-details: never
probes:
enabled: true
add-additional-paths: true
server:
shutdown: graceful
spring:
lifecycle:
timeout-per-shutdown-phase: 30s
Əlavə probe yolları əsas tətbiq portunda /livez və /readyz yoxlamalarını da açır. Yalnız ayrıca management portunun cavab verməsi istifadəçi sorğularının qəbul edildiyini sübut etmir. Proxy və security qaydalarında seçdiyin probe yolunun davranışını təsdiqlə.
İşləmək və hazır olmaq fərqlidir
Proses işləyir, amma başlanğıc hazırlığı tamamlanmayıb. Yeni istifadəçi sorğusu göndərilmir.
Gözləmənin və təkrar cəhdin sonu olsun
Bir sifariş sorğusunun ümumi büdcəsi 2 saniyədirsə, aşağı servisdə 3 dəfə 1 saniyə gözləmək bu büdcəyə sığmır. Connect timeout, cavab gözləmə vaxtı, təkrar cəhdlər və aradakı fasilələri birlikdə hesabla.
| Ssenari | Sınaq | Gözlənilən davranış |
|---|---|---|
| Aşağı servis cavab vermir | Staging-də gecikmə əlavə et | Sorğu müəyyən vaxtda bitir; thread-lər sonsuz tutulmur |
| Ödənişdən sonra cavab itir | Eyni idempotency key ilə təkrar et | İkinci ödəniş yaranmır |
| DB connection pool dolur | Trafiki tədricən artır | Gözləmə məhduddur; xəta və saturation görünür |
| Asinxron növbə yığılır | Worker-i müvəqqəti yavaşlat | Gecikmə ölçülür; yaddaş nəzarətsiz böyümür |
Hər xətanı retry etmə. Səhv giriş və icazə xətası təkrarla düzəlmir. Keçici xəta üçün məhdud cəhd, artan fasilə və təsadüfi paylanma seç. Bir neçə qatın eyni anda retry etməsi yükü çoxalda bilər.
Migration və bərpa ayrıca sınaq tələb edir
Yeni versiyanı işə salmazdan əvvəl migration-ı production-a bənzər məlumat həcmi ilə yoxla. Boş bazada tez bitən indeks yaratma əməliyyatı böyük cədvəldə kilid və gecikmə yarada bilər.
Sxema dəyişikliklərini mərhələləndir: yeni sahəni əlavə et, köhnə və yeni kodla uyğun işlət, məlumatı doldur, sonra köhnə sahəni sil. Tətbiqi əvvəlki versiyaya qaytarmaq dağıdıcı migration-ı öz-özünə geri almır.
Backup faylının mövcudluğu kifayət etmir. Ayrı mühitdə bərpa et, bir neçə real sorğunu işlə və ölçülmüş bərpa vaxtını qeyd et. “Nə qədər məlumat itirə bilərik?” və “Nə vaxta qayıtmalıyıq?” suallarının cavabını servis sahibi ilə razılaşdır.
Xəta baş verməzdən əvvəl nəyi izləyəcəyini seç
Bir dashboard-da sorğu sayı, xəta nisbəti, gecikmə paylanması və resurs doluluğu olsun. Tək orta gecikmə yavaş istifadəçiləri gizlədə bilər; p95 və p99-u trafik həcmi ilə birlikdə izlə.
Biznes nəticəsini də ölç: uğurla yaranmış sifariş, uğursuz ödəniş, gecikmiş tapşırıq. HTTP 200 həmişə istifadəçinin işinin alındığını bildirmir.
Loglarda correlation ID saxla, amma token, parol və lazımsız şəxsi məlumatı yazma. Bir test sorğusunu girişdən aşağı servisə qədər izləyib trace əlaqəsini yoxla. Alert-in kimə çatdığını və həmin şəxsin hansı runbook-a baxacağını əvvəlcədən müəyyənləşdir.
Son sınaq: proses işləyərkən versiyanı dəyiş
- Uzun çəkən sorğu başladıb yerləşdirməni işə sal. Sorğunun tamamlandığını və yeni trafikin hazır instansiyaya getdiyini yoxla.
- Platformanın termination vaxtını tətbiqin shutdown büdcəsi və yönləndirmə gecikməsi ilə uyğunlaşdır.
- Bir instansiyanı dayandır. Qalanlarının yükü qəbul etdiyini, yeni instansiyanın hazırlanmasını və session davranışını sına.
- Əvvəlki image ilə rollback et. Sxema və mesaj formatlarının uyğun qaldığını təsdiqlə.
- Buraxılışdan sonra əvvəlki trafiklə müqayisə et: xəta nisbəti, p95, CPU, yaddaş və biznes metrikləri.
Yoxlama nəticələrini release qeydinə əlavə et. Növbəti buraxılışda eyni işləri yaddaşdan təkrarlamaq əvəzinə, avtomatlaşdırıla bilənləri pipeline-a keçir.