Hindenbug — bu nədir, fəlakətli nəticələri və qorunma üsulları

Hindenbug nədir?

Hindenbug geri dönməz nəticələrə səbəb olan fəlakətli xarakterli proqram xətasıdır: istifadəçi məlumatlarının tam itkisi, verilənlər bazasının dağıdılması, kritik xidmətin dayanması və ya şirkətin maliyyə çöküşü.

Termin rəsmi elmi təsnifat deyil, lakin peşəkar proqramçı jarqonunda möhkəm yer tutmuşdur. Hindenbug texniki cəhətdən mürəkkəb olmaya bilər — bəzən müəyyən şəraitdə məlumatları məhv edən tək bir kod sətiridir. Digər səhvlərdən əsas fərqi — nəticələrin miqyasıdır.

Hər bir Hindenbug adi bir səhv kimi başlayır — Bohrbug, Mandelbug və ya Heisenbug. Onu fəlakətli edən qoruyucu mexanizmlərin olmamasıdır: ehtiyat nüsxələrin, əməliyyat limitlərinin, dəyişiklik izolyasiyasının. Sistemdə soft-delete və çoxsəviyyəli təsdiqləmə yoxdursa, SQL sorğusundakı bir səhv bütün istifadəçi cədvəlini silə bilər.

Hindenbug adının mənşəyi

Hindenbug adı 6 may 1937-ci ildə ABŞ-da qəzaya uğrayan LZ 129 "Hindenburq" Alman dirijablının fəlakətinə istinad edir. Göyərtəsindəki 97 nəfərdən 35-i öldü, dirijablın özü isə 34 saniyəyə yandı.

Proqram xətası ilə bənzətmə aydındır: "Hindenburq"dakı yanğın nəhəng uçuş aparatını dərhal məhv etdiyi kimi, Hindenbug da saniyələr və ya dəqiqələr ərzində aylarla və ya illərlə işin nəticələrini — verilənlər bazalarını, fayl anbarlarını, server konfiqurasiyalarını məhv edir.

Bohrbug kimi "sakit" səhvlərdən fərqli olaraq, Hindenbug adətən səs-küylü nəticələrlə müşayiət olunur: şirkət səhmlərinin düşməsi, top-menecerlərin işdən çıxarılması, məhkəmə iddiaları. Məhz buna görə belə dramatik ad almışdır — o, texniki mürəkkəbliyi deyil, nəticənin fəlakətli olduğunu əks etdirir.

Hindenbug-un xüsusiyyətləri

Hindenbug digər proqram səhvlərindən fərqləndirən bir sıra xarakterik xüsusiyyətlərə malikdir.

Nəticələrin geri dönməzliyi

Hindenbug-un əsas xüsusiyyəti — zərərin geri dönməz olmasıdır. Bohrbug-u düzəldib unutmaq olarsa, Mandelbug-u düzəldib yoxlamaq olarsa, Hindenbug "yanmış torpaq" qoyur: silinmiş məlumatlar ehtiyat nüsxələr olmadan bərpa olunmur, dağıdılmış verilənlər bazaları uzun müddətli bərpa tələb edir.

Kaskad effekti

Bir Hindenbug zəncirvari sıradançıxmalara səbəb olur. Məsələn, autentifikasiya xidmətindəki səhv API-ə girişi bloklayır, bu da frontendi, ödəniş şlüzunu, şəxsi kabineti və dəstək xidmətini iflic edir. Kaskad dəqiqələr ərzində onlarla xidmətə təsir edə bilər.

Yayılma sürəti

Müasir paylanmış sistemlər Hindenbug-u şəbəkə sürəti ilə yayır. Bir serverdəki səhv SQL sorğusu bütün replikalara replikasiya olunur. CI/CD vasitəsilə səhv konfiqurasiya eyni anda bütün prodakşn serverlərinə düşür.

Tarixdə məşhur Hindenbug-lar

Proqram mühəndisliyi tarixi klassik Hindenbug kimi dərsliklərə daxil olan bir neçə fəlakətli səhv tanıyır.

Knight Capital (2012) — 45 dəqiqəyə 460 milyon dollar

Yüksək tezlikli ticarət alqoritmindəki səhv 45 dəqiqə ərzində 7 milyard dollarlıq əməliyyatların aparılmasına səbəb oldu, zərər isə 460 milyon dollar təşkil etdi. Səbəb — koddakı unudulmuş flag, köhnə, istifadə olunmayan ticarət modulunu aktivləşdirdi. Şirkət bir neçə gün ərzində satıldı.

Amazon S3 (2017) — internetin yarısının dayanması

S3 hesablaşma sisteminin sazlanması zamanı səhv Amazon serverlərinin US-EAST-1 regionunda kütləvi söndürülməsinə səbəb oldu. Buna görə Slack, Trello, Quora və çoxlu startaplar da daxil olmaqla minlərlə sayt və xidmət saatlarla işləmədi. Səbəb — çox sayda serveri silən bir səhv əmr.

GitLab (2017) — prodakşn verilənlər bazasının silinməsi

GitLab mühəndisi replikasiya işləri apararkən təsadüfən prodakşn verilənlər bazası olan qovluğu sildi. 24 saatlıq məlumatdan yalnız 6 saatı bərpa edildi. Hadisə təhlükəli əmrin icrasından əvvəl yoxlamanın olmaması və kifayət qədər ehtiyat nüsxələnməməsi səbəbindən baş verdi.

Hindenbug-un qarşısını necə almaq olar

Hindenbug-un qarşısının alınması texniki deyil, təşkilati məsələdir. Aşağıda əsas qorunma təcrübələri verilmişdir.

Ehtiyat nüsxələr və Disaster Recovery

Müntəzəm ehtiyat nüsxələr Hindenbug-dan sonra bərpanın yeganə zəmanətidir. Ehtiyat nüsxələr avtomatik olmalı, müxtəlif fiziki yerlərdə saxlanmalı və mütəmadi olaraq bərpa üçün sınaqdan keçirilməlidir. İşləyən ehtiyat nüsxə olmadan Hindenbug biznes fəlakətinə çevrilir.

Təhlükəli əməliyyatların izolyasiyası

Kütləvi silmə və ya dəyişdirmə əməliyyatları çoxsəviyyəli təsdiqləmə tələb etməlidir. SQL-də WHERE olmadan DELETE prodakşnda mümkün olmamalıdır. MySQL üçün `pt-archiver` kimi alətlər məlumatları fasilələrlə partiyalarla silməyə imkan verir.

Circuit Breaker və limitlər

Circuit Breaker nümunəsi səhvlərin sayı həddi aşarsa əməliyyatı avtomatik dayandırır. Bir əməliyyatda silinə bilən və ya dəyişdirilə bilən yazıların sayına limitlər fəlakətli ssenarilərin qarşısını alır.

public class SafeDeleteStrategy {
    private static final int MAX_DELETE_BATCH = 1000;

    public void deleteRecords(final String condition) {
        int deleted = 0;
        while (true) {
            int batch = deleteBatch(condition, MAX_DELETE_BATCH);
            if (batch == 0) break;
            deleted += batch;
            pause(100);  // partiyalar arasında fasilə
        }
    }
}

Bu kod Hindenbug-un qarşısını alır, bir dəfəyə silinən yazıların sayını məhdudlaşdırır və əməliyyatlar arasında fasilə əlavə edir. Şərt təsadüfən çox geniş olarsa, sistem milyon əvəzinə yalnız 1000 yazını siləcək.

Hindenbug-dan sonra bərpa strategiyaları

Əgər Hindenbug artıq baş veribsə, reaksiyanın sürəti və düzgünlüyü kritik əhəmiyyət daşıyır. Hər dəqiqə gecikmə zərəri dərinləşdirir.

Dərhal dayandırma

Hindenbug aşkar edildikdə ilk hərəkət — bütün yazma əməliyyatlarını dayandırmaqdır. Verilənlər bazasına yazmanı bloklamaq, işçiləri dayandırmaq, CI/CD-ni söndürmək. İşi davam etdirmək vəziyyəti daha da pisləşdirir və bərpanı çətinləşdirir.

Zərərin qiymətləndirilməsi

Hansı məlumatların itirildiyini, hansıların isə yalnız zədələndiyini müəyyən etmək lazımdır. Tam itki və zədələnmə arasındakı fərq bərpa strategiyasını müəyyən edir. Təhlil məlumatların surətində aparılmalıdır, prodakşnda yox.

Ehtiyat nüsxələrdən bərpa

Əgər ehtiyat nüsxələr varsa — bərpa prosesi bərpa nöqtəsinin (RPO) və bərpa vaxtının (RTO) seçilməsinə düşür. Ehtiyat nüsxə nə qədər təzədirsə, məlumat itkisi o qədər azdır, lakin ehtiyat nüsxənin də qüsurlu məlumatlar ehtiva etmə ehtimalı bir o qədər yüksəkdir.

Kodda Hindenbug nümunəsi

Klassik Hindenbug-u nəzərdən keçirək — yoxlama olmadan miqrasiyada məlumatları silən SQL sorğusu.

-- Migration should delete only inactive sessions
DELETE FROM user_sessions
WHERE expired_at < NOW();
-- But the author forgot the WHERE clause and ran:
DELETE FROM user_sessions;  -- all sessions were deleted

Real layihədə belə bir sorğu bütün istifadəçiləri dərhal sistemdən çıxaracaq. Əgər sessiyalar yeganə autentifikasiya mexanizmi idisə — bütün istifadəçilər sistemə girişini itirəcək. Əgər bu serverdə ehtiyat nüsxə yoxdursa — nəticələr geri dönməz olacaq. Bu Hindenbug istifadəçilərin etibarını və şirkətin nüfuzunu saniyələr ərzində məhv edir.