1.500 kullanıcılı, kurumsal bir müşteride çalışan izleme (UAM/DLP) platformunun verimlilik raporları bir sabah aniden anlamsızlaşmaya başladı. Normalde günlük ortalama 7-7,7 saat olan aktif çalışma süresi, bir günde ~1,3 saate düştü — sanki tüm şirket birdenbire çalışmayı bırakmış gibi görünüyordu. Veri hatası değildi; altyapıda gerçek bir arıza vardı.
Bu yazı, vendor'ın resmi çözümünün işe yaramadığı, kök nedeni kendimiz bulup kalıcı olarak çözdüğümüz gerçek bir vakanın kaydı.
Belirti: raporlar aniden çöküyor
| Dönem | Ort. günlük aktif süre | "4 saat altı" kullanıcı oranı |
|---|---|---|
| Normal dönem | ~7,7 saat | %6–9 |
| Arıza günü | 1,35 saat | %99,3 |
| Arıza sonrası (haftalarca) | ~1,3 saat | %99+ |
Kırılma bir günde tam etkisini gösterdi ve haftalarca sürdü — müşteri "sistem bozuk" diye şikayet etti, biz de veriyi teknik olarak inceledik: rakamlar doğruydu, ama normal çalışma performansını yansıtmıyordu.
Kök neden: her 15 saniyede bir çöken bir servis
Platformun ana izleme servisi, arka planda ~15 saniyede bir çöküp yeniden başlıyordu. Sebep: PostgreSQL'deki bir ek-dosya tablosunun birincil anahtar sayacı (sequence), 32-bit integer'ın maksimum değerine (2.147.483.647) ulaşmıştı. Servis her çöktüğünde, işletim sistemi o anda açık olan tüm ajan bağlantılarını sıfırlıyordu.
Sonuç zincirleme bir bozulmaydı:
- İzleme oturumları sürekli 15 saniyelik parçalara bölünüyordu.
- Aktivite kayıtları kesik ve eksik oluşuyordu.
- "Aktif çalışma süresi" hesaplaması, gerçek sürenin çok küçük bir kesrini yansıtıyordu.
Vendor'ın resmi güncellemesi neden yetmedi
Vendor'ın önerdiği resmi güncelleme paketini uyguladık — sorun devam etti. Güncelleme, sayaç kolonunun veri tipini değiştirmiyordu; sadece değeri geçici olarak sıfırlıyordu. Bir süre sonra sayaç yeniden maksimum değere ulaştı ve çökme döngüsü tekrar başladı.
Kendi tarafımızda kök nedeni izole ettik: sorun güncellemenin kapsamadığı bir veri tipi sınırıydı, semptomların tekrarı bunun kanıtıydı.
Kalıcı çözüm
Resmi güncelleme yolunun dışına çıkarak, üretim ortamında ilgili kolonun veri tipini 32-bit integer'dan 64-bit bigint'e yükselttik:
ALTER TABLE <tablo> ALTER COLUMN <sayaç_kolonu> TYPE bigint;
Yeni maksimum değer (~9,2 katrilyon) pratikte hiçbir zaman dolmaz. Değişiklik sonrası servis kesintisiz çalışmaya, veri akışı normale döndü — arıza bir daha tekrarlamadı.
Bunu proaktif yakalamasaydık, müşteri ilk iş gününde tüm raporlarının aylarca yanlış olduğunu keşfedip ciddi bir eskalasyon başlatacaktı. Bulguyu ayrıca vendor'a da resmi olarak bildirdik: bu tip veri tipi migrasyonlarının resmi güncelleme paketine dahil edilmesini ve benzer kurulumların proaktif denetlenmesini önerdik.
Çıkarımlar
- "Resmi güncelleme uyguladık" bir garanti değildir. Bir güncellemenin sorunu kapsadığını varsaymak yerine, düzeltmenin gerçekten neyi değiştirdiğini kontrol edin.
- Semptom tekrarı, kök nedenin bulunmadığının en net işaretidir. Geçici bir iyileşme sonrası sorun geri geliyorsa, çözüm veriyi değil sadece belirtiyi sıfırlamış demektir.
- Sayısal sınırlar (32-bit, vs.) sessiz zaman bombalarıdır. Yoğun trafikli, uzun süre çalışan sistemlerde bu tip sayaç kolonlarının kapasitesi düzenli olarak denetlenmeli.
- Kendi altyapınızı izlemek, vendor'ı beklemekten daha hızlıdır. Kök nedeni kendimiz bulduğumuz için müşteri bir sonraki iş gününe sağlıklı raporlarla başladı.