Yazılımda Hata Analizi: Üç Vaka ve Alınan Dersler

Üretim ortamında yaşanan kesintilerin büyük bölümü nadir görülen karmaşık hatalardan değil, atlanmış basit kontrollerden kaynaklanır. Aşağıdaki üç vaka farklı sistemlerde tekrar tekrar karşılaşılan örneklerdir.

Her vaka üç başlıkla ele alınıyor: ne oldu, kök neden neydi ve hangi önlem bu olayı baştan engellerdi.

Vaka 1: Yedeği olan ama geri yüklenemeyen veri

Bir tablo yanlış koşullu bir güncelleme sonucu bozuldu. Yedekleme işi her gece çalışıyor ve dosyalar diskte duruyordu. Geri yükleme denendiğinde arşivin bir bölümünün eksik yazıldığı, dosyanın haftalardır bozuk üretildiği görüldü.

Kök neden yedeğin alınmaması değil, hiç denenmemesiydi. Yedekleme işinin başarıyla tamamlanması, üretilen dosyanın kullanılabilir olduğu anlamına gelmiyor. Kayıtlarda işin başarılı görünmesi de yanıltıcı bir güven oluşturmuştu.

• Geri yükleme düzenli aralıklarla ayrı bir ortamda denenir ve sonuç kaydedilir.
• Yedek dosyasının boyutu ve satır sayısı önceki günle karşılaştırılır.
• Yedekler tek makinede tutulmaz.
• Veri değiştiren toplu sorgular önce salt okunur biçimde çalıştırılıp etkilenecek satır sayısı doğrulanır.

-- toplu güncellemeden önce etkiyi ölç
SELECT COUNT(*) FROM siparisler
WHERE durum = 'bekliyor' AND olusturuldu < '2026-01-01';

-- beklenen sayı doğrulandıktan sonra güncelle
UPDATE siparisler SET durum = 'iptal'
WHERE durum = 'bekliyor' AND olusturuldu < '2026-01-01';

Vaka 2: Göç sırasında kilitlenen tablo

Yoğun kullanılan bir tabloya yeni kolon eklendi. Değişiklik yerel ortamda saniyeler sürdüğü için üretimde de hızlı biteceği varsayıldı. Üretimde tablo milyonlarca satır içeriyordu ve işlem tabloyu uzun süre kilitledi; bu süre boyunca siparişler yazılamadı.

Kök neden, veri hacmi farkının hesaba katılmamasıydı. Yerel ortamdaki birkaç bin satır, üretimdeki davranış hakkında bilgi vermez. İkinci etken, göçün yoğun saatte çalıştırılmasıydı.

• Göçler üretim boyutuna yakın bir kopyada önce denenir ve süresi ölçülür.
• Büyük tablolarda kilitsiz değişiklik destekleyen yöntemler tercih edilir.
• Değişiklik trafiğin düşük olduğu saate planlanır.
• Kolon ekleme ve veri doldurma tek adımda değil, ayrı adımlarda yapılır.
• Geri alma adımı göçle birlikte yazılır.

Vaka 3: Zaman aşımı verilmeyen servis çağrısı

Ödeme sağlayıcısının servisi yavaşladı ve yanıt süresi otuz saniyeye çıktı. Uygulamadaki istemci için zaman aşımı tanımlanmamıştı. Her istek açık bir bağlantıyı bekletti, süreç havuzu doldu ve ödemeyle ilgisi olmayan sayfalar da yanıt vermemeye başladı.

Kök neden, dış bağımlılığın yavaşlamasının yerel bir sorun gibi ele alınmasıydı. Zaman aşımı tanımlanmadığında tek bir yavaş servis, tüm uygulamanın kaynaklarını tüketir:

$istemci = new GuzzleHttp\Client([
    'timeout' => 5,
    'connect_timeout' => 2,
]);

try {
    $yanit = $istemci->post($adres, ['json' => $veri]);
} catch (Throwable $e) {
    $gunluk->error('Ödeme servisi yanıt vermedi', ['hata' => $e->getMessage()]);
    return OdemeSonucu::gecici();
}

• Her dış çağrıya bağlantı ve yanıt zaman aşımı tanımlanır.
• Art arda başarısız olan servis için devre kesici uygulanır.
• Kritik olmayan çağrılar kuyruğa alınır, istek akışını bekletmez.
• Servis yanıt vermediğinde uygulamanın hangi biçimde çalışmaya devam edeceği önceden kararlaştırılır.

Olay sonrası ne yapılır?

Kesinti giderildikten sonra yazılan kısa bir olay raporu, aynı hatanın tekrarını engellemenin en ucuz yoludur. Rapor kişi aramaz; zaman çizelgesini, kök nedeni ve alınacak önlemleri içerir.

Suçlu arayan bir kültürde olaylar bildirilmez, yalnızca gizlenir. Sorumluluğun kişide değil sistemde aranması, hataların görünür kalmasını ve önlemlerin gerçekten alınmasını sağlar.

• Zaman çizelgesi: sorun ne zaman başladı, ne zaman fark edildi, ne zaman kapandı.
• Etki: hangi kullanıcılar, hangi işlemler, ne kadar süre.
• Kök neden: hangi kontrol eksikti.
• Önlemler: sahibi ve tarihi belirlenmiş somut maddeler.

Kontrol listesi

• Yedekten geri yükleme düzenli olarak denenir.
• Şema değişiklikleri üretim boyutunda önce ölçülür.
• Her dış çağrıda zaman aşımı tanımlıdır.
• Toplu veri değişiklikleri önce sayımla doğrulanır.
• Her olaydan sonra kısa bir rapor yazılır ve önlemler takibe alınır.

İlgili yazılar

• Veritabanı İndeksleme: Sorguları Hızlandırmanın Temelleri
• Monolit mi Mikroservis mi? Karar Kriterleri