Produ çökdürmək: bu nədir, səbəbləri və risklərin minimallaşdırılması

İnkişafda produ çökdürmək nə deməkdir

Produ çökdürmək — tətbiqin istehsal mühitində düzgün işləməyi dayandırdığı vəziyyətin qeyri-rəsmi təyinatıdır. Test və ya staging mühitindən fərqli olaraq, produksiya real istifadəçilərə xidmət göstərir, ona görə də hər hansı nasazlıq biznes üçün kritik əhəmiyyət daşıyır.

„Produ çökdürmək" ifadəsi müxtəlif ciddilik dərəcələrini ifadə edə bilər: funksionallığın qismən deqradasiyasından xidmətin tam əlçatmazlığına qədər. ITIL terminologiyasında bu, insident (incident) — xidmətin planlaşdırılmamış kəsilməsi və ya keyfiyyətinin azalması kimi təsnif edilir. Xidmətin kritikliyi nə qədər yüksəkdirsə, komanda bir o qədər tez reaksiya verməlidir.

Müasir DevOps təcrübələri produksiyanın çökməsinin nəticələrini minimallaşdırmağa yönəlmişdir. Datadog, New Relic və Sentry kimi alətlər produksiyanın vəziyyətini real vaxtda izləməyə və anomaliyalar barədə komandaya avtomatik bildiriş göndərməyə imkan verir.

# Əvvəlki versiyaya sürətli geri qaytarma
kubectl rollout undo deployment/api-server

# Deploy statusunu yoxla
kubectl rollout status deployment/api-server

# Xəta analizi üçün son loglara bax
kubectl logs deployment/api-server --tail=100 --since=10m

Bu nümunə Kubernetes-də deploy-u geri qaytarmaq üçün tipik əmrləri göstərir. Tez geri qaytarma — produksiyada problem aşkar edildikdə ilk addımdır və xidmətin iş qabiliyyətini dəqiqələr ərzində bərpa etməyə imkan verir.

Produksiyanın çökməsinin əsas səbəbləri

Stripe tərəfindən 2023-cü ildə aparılan 500-dən çox produksiya insidentinin təhlili əsas səbəb kateqoriyalarını müəyyən etdi. İnsidentlərin bölgüsü inkişaf və deploy proseslərindəki tipik zəif nöqtələri əks etdirir.

Deploy xətaları bütün insidentlərin demək olar ki, üçdə birini təşkil edir. Bu, adətən dəyişikliklər lazımi yoxlama olmadan əl ilə deploy edildikdə baş verir. Deploy-un avtomatlaşdırılması çoxmərhələli yoxlama ilə CI/CD pipeline vasitəsilə produksiyanın çökməsi riskini əhəmiyyətli dərəcədə azaldır.

Verilənlər bazası miqrasiyaları ilə bağlı problemlər xüsusi diqqət tələb edir. Yanlış miqrasiya nəinki produ çökdürə bilər, həm də geri qaytarılmayan məlumat itkisinə səbəb ola bilər. Buna görə də miqrasiyalar icradan əvvəl məcburi backup ilə pipeline-ın ayrıca addımında işə salınır.

Biznes və komanda üçün nəticələri

Produksiyanın çökməsi təkcə texniki problem deyil, həm də biznes insidentidir. Hər bir dəqiqəlik dayanma şirkətə xidmətin xarakterindən asılı olaraq müəyyən məbləğə başa gəlir. E-ticarət platformaları üçün bir saatlıq dayanmanın dəyəri yüz minlərlə dollar ola bilər.

Gartner 2024 tədqiqatı göstərir ki, enterprise tətbiqlərinin bir dəqiqəlik dayanmasının orta dəyəri 5600 dollar təşkil edir. Produksiyada insidentdən sonra orta bərpa müddəti təxminən 90 dəqiqədir. 90 dəqiqəlik dayanma biznesə yarım milyon dollardan çox başa gəlir.

Maliyyə itkiləri ilə yanaşı, produksiyanın çökməsi şirkətin reputasiyasına zərər vurur. Xidmətin əlçatmazlığı ilə qarşılaşan istifadəçilər rəqiblərə keçə bilər. Xüsusilə bank və tibb tətbiqləri üçün insidentlər kritikdir, çünki etibarlılıq əsas tələbdir.

Komanda üçün də nəticələr əhəmiyyətlidir. Produksiyada insidentdən sonra postmortem — kök səbəblərin təhlili və qarşısının alınması tədbirlərinin işlənib hazırlanması aparılır. Bu, xüsusilə növbətçi mühəndislərə (on-call) əlavə yük qoyur.

Produksiyada nasazlıqların qarşısının alınması strategiyaları

Produksiyanın çökməsinin qarşısının alınması bir neçə müdafiə səviyyəsinə əsaslanır. Hər bir səviyyə müəyyən bir sinif xətaları tutaraq onların son istifadəçilərə çatmasına mane olur.

• Staging mühiti — deploy-dan əvvəl son test üçün produksiyanın tam surəti
• Feature flags — deploy olmadan funksionallığı aktivləşdirmək və ya söndürmək imkanı
• Rolling-deploy — sağlamlıq monitorinqi ilə podların və ya qovşaqların tədricən yenilənməsi
• Canary buraxılışlar — yoxlama üçün yeni versiyaya trafikin kiçik bir hissəsinin yönləndirilməsi
• Avtomatik backup-lar — miqrasiyalarla hər deploy-dan əvvəl verilənlər bazasının anlıq surətləri

Feature flags çökmələrin qarşısının alınması üçün ən təsirli alətlərdən biridir. Kodu produksiyaya qeyri-aktiv vəziyyətdə yerləşdirməyə, məhdud istifadəçi qrupu üçün aktivləşdirməyə və problem aşkar edildikdə tez söndürməyə imkan verir. LaunchDarkly və Split.io kimi platformalar flagların idarə edilməsi üçün hazır həllər təqdim edir.

Monitorinq və alertinq — son müdafiə səviyyəsidir. Prometheus + Grafana və ya Datadog kimi alətlər produksiyadan metrikalar toplayır: latency, error rate, throughput. Həddlər aşıldıqda alert işə düşür və növbətçi mühəndis bildiriş alır. Komanda problem haqqında nə qədər tez öyrənərsə, insidentdən zərər bir o qədər az olar.

Produ çökərsə nə etməli

Produksiyanın çökməsi artıq baş verdikdə, əsas prioritet xidmətin iş qabiliyyətini bərpa etməkdir. Səbəblərin təhlili stabilləşmədən sonra aparılır. Tipik reaksiya prosesi aşağıdakı addımları əhatə edir.

İlk addım — insidentin miqyasını müəyyən etməkdir. Xidmət tamamilə əlçatmazdır, yoxsa funksionallığın yalnız bir hissəsi deqradasiyaya uğrayıb? Nə qədər istifadəçi təsirlənib? Bu suallara cavablar kritiklik səviyyəsini və zəruri tədbirləri müəyyən edir.

İkinci addım — dəyişikliklərin geri qaytarılması. Əgər insident son deploy-la bağlıdırsa, bərpanın ən sürətli yolu əvvəlki stabil versiyaya qayıtmaqdır. Bunun üçün git revert əmri və əvvəlki artefaktın təkrar deploy-u istifadə olunur. Geri qaytarma 10-15 dəqiqədən çox çəkməməlidir.

Üçüncü addım — kommunikasiya. Komandaya, rəhbərliyə və zəruri hallarda istifadəçilərə problem və bərpa müddətləri barədə məlumat vermək. Bunun üçün status page xidmətlərindən (Atlassian Statuspage) və Slack və ya Telegram kanallarından istifadə olunur.

Dördüncü addım — postmortem. Bərpadan sonra kök səbəblərin təhlili (RCA) aparılır və insidentin təkrarlanmasının qarşısını almaq üçün tədbirlər işlənib hazırlanır. Postmortem nəticələri sənədləşdirilir və komandanın bilik bazasının bir hissəsi olur.