Bugün bir bug öğrendin mi?
Basit Bir Tarih, Büyük Bir Problem
“Sınır Değer Analizi (Boundary Value Analysis) yapmanın önemi! Gelecek tarihler için zamanlama ve veri tipi limitlerinin test edilmemesi, yeni yılın ilk gününde küresel bir e-posta krizine yol açtı.”
1 Ocak 2022, saat 00:00 UTC
Milyonlarca kuruluş, yeni yılı kutlarken, Microsoft Exchange sunucuları sessizce çöküyordu. Sebebi? Bir tarih kontrolü. Evet, sadece bir tarih kontrolü. Y2K’nin 22 yıl sonraki kardeşi, Y2K22 ortaya çıkmıştı.
Neler Oldu?
Olay Özeti
Microsoft Exchange Server (2013, 2016, 2019 versiyonları) içindeki FIP-FS adlı anti-malware tarama motoru, 1 Ocak 2022’de çöktü. Sonuç: emailler transport kuyruklarında takılı kaldı, sistem Event ID 5300 ve 1106 hataları (Error 0x80004005) fırlatmaya başladı.
Binlerce kuruluş, kritik iş emaillerini gönderemez hale geldi.
Kök Neden: Bir Integer Taşması (Integer Overflow)
Burada basit ama ölümcül bir hata var:
FIP-FS motoru, imza dosyasının sürüm tarihini saklamak için signed Int32 (32-bit işaretli tam sayı) kullanıyordu.
Signed Int32’nin maksimum değeri: 2,147,483,647
2022 yılı için hesaplanan sürüm numarası: 2,201,010,001
Sonuç: Taşma (overflow). Sayı sınırı aştı, sistem çöktü.
Max Int32: 2,147,483,647
Actual value: 2,201,010,001 ↑ Aşıldı!
Bu kadar. Bir yazılım test mühendisinin en basit catch etmesi gereken bug tipi.
Neden Bu Kadar Önemli?
1. **Zamanlaması Mükemmel Değildi**
Yılbaşı gününde, pek çok sistem yöneticisi tatilde. Destek ekipleri azami kapasitede değil. Bug tam da bu an da patlıyor.
2. **Yaygın Etki**
Exchange Server, kurumsal emailin omurgası. Binlerce şirket, hükümet kurumu, hastane etkilendi. Kritik iş akışları durdu.
3. **Uyarı Yoktu**
Bu, güvenlik açığı değildi. Malware değildi. Sadece bir mantık hatası. Hiç kimse bunu tahmin etmemişti.
Gerçek Dünyada Y2K22’den Sonra
Etkilenen Kurumlar
- Sağlık: Hastaneler, hasta kayıtlarını gönderemedi
- Finans: Bankalar, kritik transferleri beklemede kaldı
- Hükümet: Resmi yazışmalar durdu
- İş: Binlerce şirket, işlemleri erteledi
Toplam Etki
Tam rakam bilinmiyor, ama:
- Downtime: Ortalama 2-4 saat
- Etkilenen sunucu sayısı: Yüz binlerce
- Ekonomik kayıp: Milyonlar dolar
Yazılım Test Mühendisinin Gözüyle: Bu Hatadan Ne Öğrenebiliriz?
✅ Ders 1: Edge Cases Önemlidir
Tarih değerleri, özellikle yıl değişimleri, her zaman test edilmesi gereken kritik noktalar.
Test senaryoları:
- Yılbaşı geçişleri (31 Aralık → 1 Ocak)
- Sınır değerleri (Int32.MaxValue)
- Sistem saati değişiklikleri
Bunu kaçırmak, milyonlarca insanı etkiler.
✅ Ders 2: Data Type Seçimi Kritik
Neden signed Int32 kullanıldı? Unsigned Int64 kullanılsaydı, sorun olmayacaktı.
// Yanlış int version = 2201010001; // Taşıyor
// Doğru long version = 2201010001L; // Güvenli
Veri tipi seçimi, sadece “teknik” bir karar değil. İş sürekliliğini etkiler.
✅ Ders 3: Prodüksiyonda Boundary Testing Yok Mu?
2022’ye yaklaştıkça, tarih-tabanlı sistemler test edilmeli. Özellikle:
- Antivirüs motorları
- Sertifika doğrulama sistemleri
- Lisans kontrol mekanizmaları
Bunlar genellikle tarih kullanır. Hepsi test edilmeli.
✅ Ders 4: Smoke Test Yeterli Değil
Birim testler ve entegrasyon testleri, bu hatayı bulabilirdi:
[Test]public void VersionNumber_ShouldNotOverflow_For2022()
{ int year = 2022; int versionNumber = year * 100000001; // Fails!
Assert.That(versionNumber, Is.GreaterThan(0));}
Bu test, hemen başarısız olacaktı. Ama yapılmamıştı.
Sonuç: Basit Hatalar Büyük Felaketler Yaratır
Y2K22, yazılım geliştirmenin en önemli dersini tekrar öğretti:
Basitlik tehlikelidir. Sınırlar önemlidir. Test etmeyin derseniz, ödül olarak 2,201,010,001 hata alırsınız.
Bir signed Int32, milyonları etkileyen bir felakete dönüştü.
Sonraki projenizde, tarih kontrolü yapan bir kod gördüğünüzde, bu yazıyı hatırlayın.
Test edin. Sınırları test edin. Yıl geçişlerini test edin.
Çünkü 1 Ocak saat 00:00’de, hiç kimse çöküntü istemez…