Gece yarısı telefonunuz çaldığında, ya da e-posta kutunuzda art arda aynı alarmın düştüğünü gördüğünüzde, ilk tepkiniz genellikle o alarmın doğrudan işaret ettiği yere bakmak olur. “Yedek başarısız” diyorsa, yedekleme yazılımına koşarız. Ama bazen, alarm tek başına doğru olsa bile, bize hikayenin tamamını anlatmaz. Asıl sorun, çok daha derinde ve farklı bir katmanda saklı olabilir.
Kötü haber şu ki, bu tür senaryolarla sık sık karşılaşıyorum. Bir üretim firması müşterimizde yaşadığımız, ilk bakışta sadece bir yedekleme sorunu gibi görünen olay, aslında sistemler arası korelasyonun ne kadar kritik olduğunu gösteren güzel bir örnekti. Bir gece aniden, Acronis’ten ardı ardına “Backup failed” uyarıları gelmeye başladı.
Alarm Gürültüsü ve Gerçek Sorun Arasında Bir Gece
O gece gelen Acronis uyarılarının hata mesajı oldukça netti: “Cannot connect to the machine where network share … is located. The machine may be unavailable.” Yani, yedek hedefi olarak tanımladığımız SMB ağ paylaşımına ulaşılamıyordu. Bu, yedekleme planının kritik bir parçasıydı; Hyper-V hostumuz üzerindeki veritabanı sunucusunun gece yedeği, bu uzak SMB paylaşımına .tibx arşivi olarak yazılıyordu.
İlk düşüncem, doğal olarak, ağ paylaşımının olduğu sunucuda bir sorun olabileceğiydi. Belki kapalıydı, belki ağ bağlantısı gitmişti. Ancak, tam da bu düşüncelerle bağlantıları kontrol etmeye hazırlanırken, aynı dakikalar içinde Sophos Central’dan başka bir e-posta geldi. Bu, firewall üzerindeki IPsec VPN tünelinin “down” olduğuna dair bir uyarıydı.
İşte tam da bu noktada, o anki yorgunluğuma rağmen, kafamda şimşekler çaktı. İki farklı alarmın ortak bir noktası olmalıydı. Bu IPsec tüneli, adlandırmasından da belli olduğu üzere, özellikle yedekleme trafiği için ayrılmış bir tüneldi. Yani, yedekleme hedefi olan uzak SMB paylaşımına ulaşımın tek yolu bu tünelden geçiyordu.
Kök Nedeni Ortaya Çıkarmak: Bağlantıyı Kurmak
Resim netleşmeye başlamıştı. Olaylar zinciri şöyleydi:
- IPsec tüneli düştü. Bu, Sophos Central’dan gelen ilk uyarıydı.
- Uzak SMB hedefi erişilemez hale geldi. Tünel düştüğü için, yedekleme hedefi olan ağ paylaşımına giden yol kapanmıştı.
- Acronis “paylaşıma bağlanamıyorum” diye hata verdi. SMB hedefine ulaşamayan Acronis, doğal olarak yedekleme işlemini tamamlayamadı ve “Backup failed” hatası üretti.
Gördüğünüz gibi, yedekleme yazılımının kendisinde hiçbir sorun yoktu. Acronis görevini yapmaya çalışmış, ancak temel bir ağ bağımlılığı ortadan kalktığı için başarısız olmuştu. Eğer Sophos Central uyarısı gelmeseydi veya ben iki alarmı birbiriyle ilişkilendirmeseydim, muhtemelen saatlerce yedekleme sunucusu ve SMB paylaşımının olduğu makine üzerinde gereksiz yere debugging yapacaktım.
Bu durum, bana bir kez daha gösterdi ki, izleme sistemleriniz ne kadar çok alarm üretirse üretsin, eğer bu alarmlar arasında anlamlı bir korelasyon kuramıyorsanız, aslında sadece gürültü üretiyorsunuz demektir. Kök nedeni bulmak, iğneyle kuyu kazmaya dönüşebilir.
Dersler ve Pragmatik Yaklaşımlar
Bu olaydan çıkarılacak birkaç önemli ders var ve bunların hepsi saha tecrübemle örtüşüyor:
Bağımlılıkları Bağımsız İzlemek Esastır
Yedekleme trafiğini ayrı bir IPsec tüneline almak, güvenlik ve ağ segmentasyonu açısından iyi bir tasarım kararıydı. Bu sayede yedek trafiği diğer iş trafiğinden ayrılmış, potansiyel güvenlik riskleri azaltılmıştı. Ancak bu tasarımın bir bedeli vardı: o tünel artık yedeğin “tek bağımlılığı” olmuştu. Tünel izlenmiyorsa, yedek de aslında tam anlamıyla izlenmiyor demekti. Yedek planının başarılı olması için gerekli olan temel altyapı bileşenleri (ağ bağlantısı, depolama erişimi vb.) doğrudan ve bağımsız olarak izlenmeli.
Alarm Korelasyonu ya Otomatik Olmalı ya da İnsan Yapmalı
Çoklu monitoring kaynaklarından gelen alarmlar (firewall, yedekleme, hipervizör, depolama vb.) ayrı ayrı bağırdığında, kök neden genellikle görünmez hale gelir. Bu durumda korelasyonu ya benim gibi bir operatörün zihninde kurması gerekir ki bu yorucu ve hata yapmaya açık bir süreçtir, ya da tasarlanmış bir triyaj katmanının veya SIEM benzeri bir çözümün otomatik olarak yapması gerekir. KOBİ ortamlarında her zaman kapsamlı bir SIEM çözümü kurmak mümkün olmuyor, bu yüzden manuel korelasyon yeteneği ve doğru izleme stratejisi daha da önem kazanıyor.
”Backup Failed” Alarmı Yanıltıcı Olabilir
Sadece “backup failed” alarmına odaklanmak, sorunun kaynağını yanlış yere konumlandırmanıza neden olabilir. Benim yaşadığım bu vakada olduğu gibi, sorun aslında yedekleme yazılımının kendisinde değil, yedekleme işleminin temel bir bağımlılığındaydı. Bu yüzden, yedekleme hatalarını triyaj ederken sadece hata mesajına değil, aynı zaman diliminde sistemin diğer katmanlarında (ağ, depolama, sunucu) yaşanan diğer olaylara da bakmak gerekiyor.
Bu tür deneyimler, IT operasyonlarının sadece teknik bilgi değil, aynı zamanda detaya dikkat etme ve sistemler arası ilişki kurma becerisi gerektirdiğini hatırlatıyor bana. Bazen en basit görünen sorunların arkasında, birden fazla katmanı etkileyen karmaşık bir zincir olabiliyor.
Siz de benzer “alarm gürültüsü” ve kök neden avı hikayeleri yaşadınız mı? Sizin en ilginç korelasyon buluşunuz neydi? Yorumlarda paylaşın, öğrenelim.