IT dünyasında “bir yıldır sorunsuz çalışıyor” cümlesi kadar yanıltıcı az şey vardır. Bu ifade, genellikle altta yatan bir kırılganlığı örtbas eden, sessiz bir garanti gibidir. Ta ki, o sessizlik bir gün aniden bozulana kadar.
Yakın zamanda bir müşterimizde yaşadığımız bir durum, bu gerçeği bana bir kez daha hatırlattı. Hikaye tanıdık: kritik bir yedekleme deposu, yaklaşık bir yıldır tıkır tıkır çalışıyordu.
”Bir Yıldır Çalışıyor” Mitolojisi ve Gerçekler
Yıllardır saha tecrübem bana şunu öğretti: “Bir yıldır çalışıyor” demek, genellikle “bir yıldır test etmedim” veya “bir yıldır şansımız yaver gitti” anlamına gelir. Özellikle yedekleme gibi iş kritik sistemlerde bu durum, felaket anında büyük sürprizlere yol açabilir.
Bizim durumumuzda, Acronis yedek deposu olarak bir SMB paylaşımı kullanıyorduk. Basit, pratik ve bir yıldır da görevini layıkıyla yerine getiriyordu. Ta ki o güne kadar.
Semptomlar Başlıyor: Beklenmedik Bir Kesinti
Bir gün yönetim konsolu üzerinden yedek deposuna erişim sorunu yaşamaya başladık. Başta “geçicidir” diye düşündük, ama sorun anlık değildi. Erişim kesintisi saatler sürünce, durumun ciddiyetini anladık. Müşterinin yedekleri alınamıyor, mevcut yedeklere erişilemiyordu.
Bu tür durumlarda ilk akla gelen şey genellikle “Acaba ne değişti?” sorusudur. Ancak bazen hiçbir şey değişmemiş gibi görünürken de sorunlar patlak verebilir. Özellikle vendor’ın bulut tabanlı bir servisi ile yerel bir kaynak arasında bir entegrasyon varsa, sorumluluğu belirlemek karmaşık hale gelebilir.
Vendor Desteğiyle Dans: Kanıt Zincirinin Önemi
Sorunu çözmek için doğal olarak vendor’ın MSP destek hattına bir bilet açtık. Bu tür bilet süreçleri bazen düşündüğünüzden çok daha uzun sürebilir ve sabır gerektirir. Bizim vakamızda da durum farklı değildi; yazışma birkaç gün boyunca devam etti.
Birden fazla destek mühendisi ve hatta iş ortağı yöneticisi sürece dahil oldu. Genellikle “benzer vakaları inceledikten sonra…” veya “şu logları gönderin…” gibi standart yanıtlarla karşılaşırsınız. İşte tam bu noktada, kendi kanıt zincirinizi oluşturmanız hayati önem taşır.
Destek ekibiyle konuşurken, “geçen yıldan beri bu alana sorunsuz erişiyorduk; dün ise iki saat boyunca erişemedik” gibi ifadelerle geçmiş davranışı kanıtlamamız gerekti. Bu, bizim sistemlerimizi ne kadar iyi izlediğimizin, logları ve zaman çizelgesini ne kadar düzenli tuttuğumuzun bir göstergesiydi.
Müşteri tarafındaki SMB deposu ile vendor’ın bulut konsolu arasındaki entegrasyonda bir sorun olduğunda, sorumluluğun hangi tarafta olduğu başta belirsizdi. Bu durum, bilet sürecini daha da uzatabiliyor, çünkü her iki taraf da kendi kısmının sorunsuz çalıştığını iddia edebilir.
MSP’nin Görevi: Acil Durum Planı ve Kendi Sorumluluğumuz
Bilet süreci günler sürerken, müşterinin iş sürekliliği riske giriyordu. Yedeklerin alınamaması kabul edilemez bir durumdu. Bu nedenle, bilet açar açmaz bir ara çözüm veya workaround planı düşünmek zorundaydık.
Alternatif bir depolama alanı belirleyip geçici olarak yedekleri oraya yönlendirmek veya lokal bir hedefe yedek almak gibi adımlar, bu tür kesintilerde müşteri tarafında yaşanacak olumsuz etkileri en aza indirmek için kritik. Müşteriye karşı son sorumluluk her zaman MSP’dedir, bu yüzden proaktif olmak şart.
SMB tabanlı yedek depoları, kurulum kolaylığı ve maliyet etkinliği nedeniyle pratik çözümler sunar. Ancak aynı zamanda kırılgan kesişim noktalarıdır. Kimlik doğrulama, ağ bağlantısı ve vendor agent’ının doğru çalışması gibi birçok bağımsız faktörün aynı anda doğru olması gerekir. Bu zincirdeki tek bir halka koptuğunda, tüm sistem çöker.
Dersler ve Çıkarımlar: Kırılgan Kesişim Noktaları
Bu olaydan çıkardığım temel dersleri şöyle özetleyebilirim:
- “Bir yıldır çalışıyor” hiçbir şeyin garantisi değil: Özellikle vendor bulut konsolu ile yerel depo gibi iki tarafın kesişiminde yaşayan kurulumlarda, her zaman beklenmedik sorunlara hazırlıklı olun.
- Kendi kanıt zincirinizi oluşturun: Vendor desteğiyle verimli çalışmanın anahtarı, MSP’nin kendi detaylı kayıtlarıdır. Zaman çizelgesi, hata mesajları, “ne değişti” listesi gibi bilgiler, sorunun teşhisini hızlandırır ve sorumluluğun belirlenmesinde yardımcı olur. Destek hattı bu detayı sizin için tutmaz.
- Ara çözüm planlarınız hazır olsun: Bilet süreçleri günler sürebilir. Müşteriye karşı sorumluluk sizde olduğu için, bilet açılırken mutlaka bir ara çözüm veya workaround planı düşünülmüş olmalı.
- SMB tabanlı depoların hassasiyeti: SMB tabanlı yedek depoları pratik olsa da, kimlik doğrulama, ağ ve vendor agent’ının aynı anda doğru çalışması gerektiği için kırılgan kesişim noktalarıdır. Bu tür kurulumlarda ekstra dikkatli olunmalı ve düzenli kontroller yapılmalıdır.
Bu tür olaylar, bize teknoloji dünyasında hiçbir şeyin mutlak olmadığını ve sürekli tetikte olmamız gerektiğini hatırlatır. Güvenliğimizi ve iş sürekliliğimizi sağlamak için sadece çözümler kurmakla kalmıyor, aynı zamanda bu çözümlerin her zaman çalışır durumda olduğundan emin olmak için de çabalıyoruz.
Siz bu konuda ne düşünüyorsunuz? Vendor desteğiyle çalışırken yaşadığınız benzer tecrübeler veya aldığınız dersler oldu mu? Yorumlarda benimle paylaşın.