Tətbiq inkişafında prodakşn yanır — bu nədir, səbəbləri və hərəkət alqoritmi

"Prodakşn yanır" nə deməkdir və hansı nasazlıqlar olur

"Prodakşn yanır" (production is on fire, everything is down) ifadəsi, prodakşn mühitinin düzgün işləmədiyi və bunun istifadəçilərə təsir etdiyi vəziyyəti təsvir edir. Nasazlıq tətbiqin tam əlçatmazlığı (blank screen, 502 xətası), qismən əlçatmazlıq (ödəniş modulu işləmir, lakin digər funksiyalar mövcuddur) və ya performans deqradasiyası (həddindən artıq uzun yükləmə) kimi özünü göstərə bilər. İnsidentin severity təsirlənən istifadəçilərin faizi və nasazlığın müddəti ilə müəyyən edilir.

Atlassian Statuspage (2025) məlumatlarına görə, 2024-cü ildə mobil tətbiqlər üçün orta downtime insident başına 27 dəqiqə olub. Ən çox rast gəlinən səbəblər: deploydan sonra kod reqresiyası (34%), bulud provayderinin imtinası (22%), verilənlər bazası problemləri (18%), konfiqurasiya xətaları (15%) və DDoS hücumları (11%). Əsas nəticə: nasazlıqların əksəriyyəti komandanın özünün etdiyi dəyişikliklərlə bağlıdır, xarici amillərlə deyil.

Crash (tətbiqin klient tərəfdə çökməsi) və backend outage (serverin əlçatmazlığı) arasında fərq qoymaq vacibdir. Crash adətən klient kodunun hotfixi ilə, backend outage isə infrastruktur dəyişiklikləri və ya servisin redeployu ilə düzəldilir. İzləmə metrikaları: klient üçün — crash-free rate, server üçün — error rate 5xx və p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — nasazlıq növünü tez müəyyən etməyə kömək edir.

İnsidentlərin severity səviyyələri: P0, P1, P2 və təsnifat meyarları

Vahid severity təsnifatı sürətli reaksiyanın əsasıdır. Onsuz komanda "bu nə qədər təcili" müzakirəsinə vaxt itirir, hərəkət etmək əvəzinə. Klassik şkala: P0 (critical) — tətbiq tamamilə əlçatmazdır və ya istifadəçi məlumatları sızır, reaksiya vaxtı — dərhal; P1 (high) — kritik funksionallıq istifadəçilərin 50%+-də işləmir, reaksiya vaxtı — 15 dəqiqə; P2 (medium) — qeyri-kritik funksionallıq istifadəçilərin bir hissəsində əlçatmazdır, reaksiya vaxtı — 1 saat.

P0 dərhal eskalasiya tələb edir: növbətçi mühəndis istənilən cari işi dayandırır və insidentə keçir. 10 dəqiqədən sonra problem həll olunmazsa — tech lead qoşulur. 30 dəqiqədən sonra — engineering managerə eskalasiya. P0 insidentləri üçün istənilən prosesləri pozmaq icazəlidir: tam code review olmadan hotfix etmək, birbaşa prodakşna deploy etmək, branch protection qaydalarını göz ardı etmək. Emergency override əvvəlcədən komanda səviyyəsində razılaşdırılmalıdır.

Severity cədvəli

Severity-ni aşağı salmaqla səhv etməmək son dərəcə vacibdir. P2 kimi təsnif edilən P0 + P1 gecikmiş reaksiyaya və downtime-in artmasına səbəb olur. Qayda: şübhəniz varsa — P0 qoyun. Over-classification under-classification-dan yaxşıdır: artıq görüş toplamaq, bir saatlıq bərpa vaxtı itirməkdən yaxşıdır.

İlk 10 dəqiqə: nasazlıq zamanı hərəkət alqoritmi

Timer starts: alert və ya istifadəçidən mesaj gəldiyi andan. İlk 10 dəqiqə — ən vacibdir. Alqoritm: 1) confirm the issue — problemin real olduğuna əmin olun (yalançı alarm deyil); 2) stop the bleeding — dərhal impact-i azaldın (rollback, feature toggle, endpointin bloklanması); 3) communicate — ümumi #incident kanalına status yazın: nə oldu, severity, nə edilir. İlk 10 dəqiqə kök səbəb analizinə sərf edilmir.

Qanaxmanı dayandırmaqla paralel olaraq bir mühəndis diaqnostikaya başlayır, ikincisi — kommunikasiyaya. Kommunikasiya kanalları: Slack #incident kanalı (komanda üçün), status səhifəsi (istifadəçilər üçün), email/SMS eskalasiyası (rəhbərlik üçün). Hər 15 dəqiqədən bir — status yeniləməsi: nə məlumdur, nə edilir, bərpa ETA-sı. Status page (StatuPage, Statuspal) xarici istifadəçilər üçün uptime və insident tarixçəsini göstərir.

Qanaxmanı necə dayandırmaq: rollback, feature toggle və hotfix

İlk və ən vacib qayda: prodakşnda problemi düzəltməyə çalışmayın. Yeni buraxılış nasazlığa səbəb olubsa — əvvəlki stabil versiyaya rollback edin. Nasazlıq feature toggle ilə söndürülmüş xüsusi funksiyadan qaynaqlanırsa — sadəcə toggle-ı söndürün. Nə rollback, nə də toggle mövcud deyilsə — minimal diff ilə hotfix. Rollback — ən təhlükəsiz variant, çünki artıq işləmiş vəziyyətə qayıdırıq.

Feature toggle (aka feature flag) — deploy olmadan stop-the-bleeding üçün güclü vasitədir. Ödəniş modulu çökübsə, lakin toggle ilə söndürülübsə — istifadəçilər sadəcə ödəniş düyməsini görmürlər, xəta ekranı almırlar. Toggle bildin qurulmasını tələb etmir, mağaza review tələb etmir, saniyələr ərzində işə düşür. Hər bir kritik funksiya server səviyyəsində söndürmə imkanı olan feature toggle (remote config) altında olmalıdır. Feature flag — ilk müdafiə xətti.

Rollback mümkün deyilsə (məsələn, geri dönməz BD miqrasiyasına görə) və toggle nəzərdə tutulmayıbsa — son vasitə: minimal düzəlişlə hotfix. Hotfix son buraxılış teqindən yaradılır, yalnız nasazlığı aradan qaldırmaq üçün lazım olan sətirləri ehtiva edir və fast-track deploy keçir ("Hotfix — təcili düzəlişlər" məqaləsinə baxın). Golden rule: stabilləşdirmədən sonra həmişə root cause analysis edin, səbəb aydın görünsə belə.

Səbəblərin diaqnostikası: loglar, metrikalar və alarmlar

Qanaxmanı dayandırdıqdan sonra (və ya paralel olaraq, mühəndis sayı imkan verirsə) diaqnostika başlayır. İlk mənbə — loglar. Mərkəzləşdirilmiş loglama (ELK, Grafana Loki, Datadog Logs) timestamp, istifadəçi ID və ya sorğu ID-si ilə xətanı tapmağa imkan verir. Vacibdir: loglar strukturlaşdırılmış (JSON) olmalıdır ki, grep sürətli işləsin. Structured logging — bütün servislər üçün məcburi tələb.

İkinci mənbə — metrikalar. Grafana, Datadog, New Relic xətaların nə vaxt pik etdiyini, hansı endpointlərdə, hansı status kodları ilə olduğunu göstərir. Deploydan əvvəl və sonra metrikaların müqayisəsi problemi konkret servisə və ya endpointə lokallaşdırmağa kömək edir. RED metrics (Rate, Errors, Duration) — mikroservislərin monitorinq standartıdır.

Üçüncü mənbə — distributed tracing. Jaeger, Zipkin, Datadog APM sorğunun mikroservislər vasitəsilə yolunu göstərir və gecikmə və ya xətanın harada baş verdiyini aşkar edir. Tracing xüsusilə kaskad imtinalarda faydalıdır, bir servisdəki nasazlıq bütün asılı servislərdə xətalara səbəb olduqda. Trace ID klientdən bütün backend servislərinə ötürülməlidir.

# kubectl və loglardan istifadə edərək sürətli diaqnostika nümunəsi
# Xətası olan podları siyahıla
kubectl get pods --field-selector=status.phase!=Running

# Çökmüş podun loglarını yoxla
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Son 30 dəqiqə ərzində servisdə xətaları axtar
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Vacib: qanaxmanı dayandırmadan səbəbi diaqnoz etməyə çalışmayın. İstifadəçilərin 50%-i crash görürsə — əvvəlcə rollback, sonra analiz. İstisna: rollback birbaşa hotfixdən daha çox vaxt aparacaqsa (məsələn, məlumat uyğunsuzluğu halında). Bu halda hotfix dərhal tətbiq edilir, post-mortem isə stabilləşdirmədən sonra keçirilir. Diagnosis before fix — downtime-i artıran təhlükəli nümunə.

Post-mortem: günahkar axtarmadan insidentləri necə təhlil etmək

Post-mortem (həmçinin incident review adlanır) — insidentin həllindən 24-72 saat sonra keçirilən strukturlaşdırılmış təhlildir. Məqsəd: nasazlığın niyə baş verdiyini, monitorinq və testlərin niyə onu prodakşna qədər tutmadığını və təkrarlanmanın qarşısını almaq üçün proseslərdə nəyi dəyişdirməyi anlamaq. Blameless culture — əsas prinsip: post-mortem prosesləri, alətləri və kommunikasiyanı müzakirə edir, konkret insanların səhvlərini deyil.

Post-mortem sənədinin strukturu: timeline (timestamp-larla hadisələrin xronologiyası), impact (təsirlənən istifadəçilər, müddət, maliyyə itkiləri), root cause (texniki kök səbəb), detection (necə aşkar edildi, niyə əvvəl tutulmadı), response (nə edildi, nəyi daha sürətli etmək olardı), action items (məsul şəxslər və son tarixlərlə konkret tapşırıqlar). Action items S.M.A.R.T. olmalıdır: specific, measurable, assignable, realistic, time-bound.

Prodakşn nasazlığından sonra tipik action items: susan metrikaya monitorinq və alert əlavə etmək; buraxılmış hal üçün test əhatəsini genişləndirmək; oxşar vəziyyət üçün addım-addım alqoritmlə runbook-a səhifə əlavə etmək; komandanı səhv istifadə olunan alət üzrə təlim keçirmək. Hər action item insidentin təkrarlanma ehtimalını azaldan beton dəyişiklikdir.