Uygulamada Özel Sunucu Desteği Vaka İncelemesi
29 Temmuz 2026 tarihinde yayımlandı
Veritabanı sunucusu hâlâ çevrimiçiydi, ancak yanıt süreleri milisaniyelerden birkaç saniyeye çıkmıştı ve uygulama kuyruğu büyüyordu. Bu özel sunucu desteği vaka incelemesi, bu olayın ilk 90 dakikasını takip ediyor: nelerin kontrol edildiği, nelerin değiştirildiği ve hızın geri getirilmesinin neden tek başına yeterli olmadığı.
Müşteri, vitrinini, sipariş işleme süreçlerini ve raporlama iş yüklerini tek bir özel fiziksel sunucuda çalıştıran büyüyen bir e-ticaret işletmesiydi. Günün o saatine göre trafik normaldi. Sorun, planlanmış bir raporlama görevinin beklenenden daha ağır bir sorgu düzenine dönüşmesinin ardından başladı. Henüz hiçbir şey çökmemişti; çoğu zaman garip olan kısım da budur. Teknik olarak konuşursak sunucu çalışıyordu, ancak müşterilerin bekletilmesi gereken bir sunucu gibi davranmıyordu.
Olay: tam arıza öncesinde yavaş hizmet
İlk uyarı uygulama izleme sisteminden geldi: ödeme adımı istekleri yanıt süresi eşiğini aşıyordu. İkinci bir uyarı, disk G/Ç beklemesinin sürdüğünü gösterdi. CPU kullanımı yüksekti ancak tavana vurmamıştı; bu da incelemeyi daraltmaya yardımcı oldu. CPU tamamen dolu olsaydı, ilk soru hesaplama doygunluğu olurdu. Burada süreçler, depolama işlemlerinin tamamlanmasını bekleyerek zaman harcıyordu.
Destek ekibi, kör bir yeniden başlatma yerine hızlı bir durum kontrolüyle başladı. Yoğun çalışan bir veritabanını yeniden başlatmak belirtileri birkaç dakika için temizleyebilir, ancak siparişleri kesintiye uğratabilir, bellekteki işleri kaybettirebilir ve kök nedeni bulmayı zorlaştırabilir. Bazen doğru eylem yeniden başlatmaktır. Bu, sahte bıyık takmış bir bakım stratejisi değildir.
İlk kontroller; sistem yükünü, bellek baskısını, disk gecikmesini, etkin veritabanı oturumlarını, uzun süren sorguları, dosya sistemi kapasitesini ve son planlanmış işleri kapsıyordu. Günlükler artık aynı hikâyeyi anlatıyordu: bir raporlama sorgusu, gecikme artışından kısa süre sonra başlamış, ardından depolama etkinliğini normal aralığın çok ötesine itmeye yetecek kadar büyük geçici tablolar oluşturmuştu.
Özel sunucu desteği vaka incelemesi: müdahale planı
Destek mühendisi buna önce canlı hizmet sorunu, sonra da ayarlama çalışması olarak yaklaştı. Öncelik, tekrarını önlemeye yetecek kadar kanıtı korurken ödeme adımını ve sipariş işlemeyi korumaktı.
Raporlama işi, müşteri işlemleri için gerekli olmadığı doğrulandıktan sonra duraklatıldı. Bu, G/Ç beklemesini hızla azalttı, ancak veritabanında hâlâ bir istek birikmesi vardı. Ekip, kaynakları gereksiz yere tutan birkaç sorgu oturumunu belirledi ve işlevlerini doğruladıktan sonra yalnızca bu oturumları sonlandırdı. Müşteriye dönük veritabanı bağlantıları olduğu gibi bırakıldı.
Ardından veritabanı önbelleği davranışı ve geçici tablo ayarları gözden geçirildi. İş yükü, özgün sunucu yapılandırmasından bu yana büyümüştü, ancak veritabanı parametreleri buna uygun şekilde ayarlanmamıştı. Bu, başarılı işletmelerde yaygındır. Web sitesi daha yoğun hâle gelir, raporlar büyür ve dünün makul ayarları yarının darboğazına dönüşür.
Dikkatli bir yapılandırma ayarı, ana makineyi aşırı taahhüt altına sokmadan veritabanı için bellek kullanımını iyileştirdi. Bu ayrım, özel bir sunucuda önemlidir. Fiziksel donanım size öngörülebilir kaynaklar sağlar, ancak belleği sonsuz yapmaz. Mevcut her gigabaytı tek bir hizmete atamak, işletim sistemi, izleme ajanları, yedeklemeler ve normal trafik sıçramaları için çok az alan bırakabilir.
Raporlama süreci daha sonra daha düşük etkili bir takvime alındı ve daha küçük yürütme pencerelerine bölündü. Bu müşteri için en iyi anlık yanıt yeni bir sunucu değildi. Bu, gelir açısından kritik iş yükleri ile iç analitik arasındaki çekişmeyi azaltmaktı. Hizmet yeniden sakindi.
Kurtarma ilan edilmeden önce desteğin kontrol ettikleri
Hızlı görünen bir ana sayfa, bir platformun sağlıklı olduğunu kanıtlamaz. Yanıt süresi uyarısı temizlendikten sonra mühendis bir saat daha izlemeye devam etti ve olaya yol açan göstergeleri kontrol etti.
Disk G/Ç beklemesi yerleşik aralığına geri döndü. Veritabanı bağlantı sayıları dengelendi ve yavaş sorgu günlüğü olağandışı bir hızda büyümeyi bıraktı. Ödeme adımı istekleri normal zamanlamalarına döndü, sipariş işleme ise hatasız şekilde farkı kapattı. Dosya sisteminde yeterli boş alan vardı ve hiçbir depolama uyarısı altta yatan bir disk sorununa işaret etmiyordu.
Yedekleme durumu da gözden geçirildi. Bunun nedeni olayın veri kaybına yol açmış olması değil, herhangi bir veritabanı müdahalesinin kurtarma seçenekleri anlaşılmış olarak yapılması gerektiğiydi. En son yedekleme başarıyla tamamlanmıştı, saklama zinciri mevcuttu ve geri yükleme prosedürü müşteri ortamı için belgelenmişti.
Bu yararlı bir operasyonel kuraldır: yedeklemeler, sorun başladıktan sonra eklenen bir onay kutusu değildir. İzlenmemiş, doğru şekilde saklanmamış ve geri yükleme için test edilmemiş bir yedekleme yalnızca umut bağlanan bir dosyadır.
Ödünleşim: ayarla, ayır ya da ölçeklendir
Anlık baskı kaldırıldıktan sonra müşterinin önünde üç mantıklı yol vardı. Doğru olan, raporlama kullanımının ne kadar hızlı büyüyeceğine ve işletmenin ne kadar yalıtıma ihtiyaç duyduğuna bağlıydı.
İlk seçenek, mevcut özel sunucuda ayarlamaya devam etmekti. Bu en düşük maliyetli yoldu ve raporlama öngörülebilir kaldığı sürece işe yarıyordu. Buna sorgu optimizasyonu, gözden geçirilmiş bir takvim, veritabanı yapılandırma incelemesi ve kullanıcıya dönük performans yeniden düşmeden önce eylemi tetikleyecek kapasite eşikleri dâhildi.
İkinci seçenek, iş yükü ayrımıydı. Raporlama, uygulama tasarımına bağlı olarak ayrı bir yönetilen VPS'e, veritabanı replikasına veya analitik hizmetine taşınabilirdi. Bu daha pahalıdır ve bir miktar mimari çalışma gerektirir, ancak raporlama etkinliğinin mağazanın işlem veritabanıyla doğrudan rekabet etmesini önler. Sık raporlar, toplu içe aktarmalar veya personel panoları olan işletmeler için ayrım çoğu zaman daha temiz bir uzun vadeli tercihtir.
Üçüncü seçenek, daha hızlı depolama, daha fazla bellek veya ek CPU kapasitesi ile özel sunucuyu ölçeklendirmekti. Bu, birincil iş yükünün donanımı gerçekten aşmış olduğu durumlarda uygun olabilir. Ancak tek başına ölçeklendirme, verimsiz bir sorguyu veya kötü zamanlanmış bir toplu işi düzeltmez. Daha büyük donanım değerli bir nefes alma alanı sağlayabilir, ancak önlenebilir davranışları sonsuza dek gizlemesi beklenmemelidir.
Müşteri aşamalı bir yaklaşım seçti: şimdi ayarla, yakından izle ve rapor hacmi mevcut eğiliminde devam ederse iş yükü ayrımını planla. Bu pratik bir karardı. Bir olay sırasında geçişi zorlamak için bir neden yoktu ve özgün düzenin sınırsız büyümeye uyacağını varsaymak için de bir neden yoktu.
Olaydan sonra ne değişti
Özel sunucu desteğinin kalıcı değeri yalnızca bir grafik kırmızıya döndüğünde birinin yanıt vermesi değildir. Asıl değer, grafik yeniden yeşile döndükten sonraki operasyonel takiptir.
Destek planına; disk gecikmesi, G/Ç beklemesi, veritabanı yavaş sorgu hacmi, kullanılabilir depolama ve yedekleme tamamlanması için odaklı uyarılar eklendi. Eşikler, başka bir ortamdan kopyalanmış genel değerler yerine müşterinin normal davranışı etrafında belirlendi. Yoğun bir ajans sunucusu ile sakin bir şirket web sitesi, aynı kalp atışına sahipmiş gibi izlenmemelidir.
Raporlama görevine tanımlı bir bakım penceresi, yürütme sınırları ve müşteri tarafında bir sahip atandı. Uygulama ekibi ayrıca sorgu bulgularını da aldı; böylece gelecekteki raporlama değişiklikleri üretime ulaşmadan önce gözden geçirilebilecekti. Net sahiplik, her ekibin işi başka birinin izlediğini varsaydığı tanıdık durumu önler.
Yönetilen altyapı kullanan müşteriler için, insan desteğinin gerçek fark yarattığı yer burasıdır. İzleme, bir diskin yoğun olduğunu bildirebilir. Bir teknisyen bu sinyali planlanmış bir işe, bir veritabanı düzenine, bir uygulama değişikliğine veya bir kapasite sorununa bağlayabilir; ardından en güvenli sonraki adımı sade bir dille açıklayabilir.
Kodu.cloud, özel sunucu yönetimine şu pratik sırayla yaklaşır: gözlemle, doğrula, canlı hizmeti koru ve bir sonraki olayı daha az olası hâle getir. Otomatik izleme ve yedeklemeler tekrarlanan kontrolleri yürütürken, mühendisler tek bir uyarı kuralına indirgenemeyen muhakeme gerektiren kararları ele alır.
Özel sunucular için operasyonel ders
Özel donanım, bir işletmeye kontrol, istikrarlı performans ve bilinmeyen komşularla kaynak paylaşmadan zorlu iş yüklerini çalıştırma olanağı verir. Bu aynı zamanda işletmenin daha az gösterişli işler için bir plana ihtiyaç duyduğu anlamına gelir: yama uygulama, kapasite incelemesi, yedekleme doğrulaması, hizmet izleme ve olay sahipliği.
Küçük bir ekip için tüm bunları ürün sürümleri, müşteri işleri ve gerçek uyku arasına sıkıştırmaya çalışmak risklidir. Daha büyük bir teknik ekip için bile, bir sorun işletim sistemleri, depolama, ağ ve uygulama davranışı boyunca uzandığında, yönetilen destek ek bir göz ve bir eskalasyon ortağı olarak yine de faydalı olabilir.
Pratik soru, bir özel sunucunun olay yaşayıp yaşayamayacağı değildir. Her altyapı kurulumu yaşayabilir. Soru, ortamın erken uyarı işaretlerini yakalayacak kadar iyi gözlemlenip gözlemlenmediği ve yavaş bir rapor bozuk bir ödeme adımına dönüşmeden önce yetkin bir kişinin harekete geçme yetkisine sahip olup olmadığıdır.
Kurtarma planını baskı altında takip edilebilecek kadar basit tutun: neyin izlendiğini bilin, yedeklemelerin nerede doğrulandığını bilin, hangi iş yüklerinin kritik olduğunu bilin ve kimin yanıt vereceğini bilin. Bu tür bir hazırlık, sanal ya da fiziksel bir sunucu odasına biraz daha fazla huzur verir.
Andres Saar Müşteri Hizmetleri Mühendisi