Daha Güvenli Geçişler için SaaS Taşıma VPS Vaka Çalışması
28 Eylül 2026 tarihinde yayımlandı
Üretim veritabanı, fiilen arızalanmasından çok önce paylaşımlı ortamının kapasitesini aşmaya başlamıştı. Yoğun dönemlerde yanıt süreleri uzuyor, dağıtım pencereleri riskli görünüyordu ve ekip, bir eklenti güncellemesi veya veritabanı sorunu ters gittiğinde kullanabileceği düzgün bir kurtarma tatbikatına sahip değildi. Bu SaaS taşıma VPS vaka çalışması, uygulamasını yönetilen bir VPS'ye taşıyan bileşik bir B2B yazılım sağlayıcısını ele alıyor; sağlayıcı, taşıma gecesini bir kumar olayına dönüştürmedi.
Şirketin bir müşteri portalı, API'si, çalışan süreçleri, PostgreSQL veritabanı ve barındırma kurulumu iş yükü için fazlasıyla kalabalık hale gelene kadar burada çalışan arka plan e-posta işleri vardı. Bu, dramatik bir kesinti hikâyesi değildi. Bunlar nadiren faydalı olanlardır. Bu bir risk yönetimi hikâyesiydi: normal büyüme bir olaya dönüşmeden önce taşınmak.
Başlangıç Noktası: Hareket Alanı Kısıtlı Bir SaaS Yığını
SaaS sağlayıcısının yaklaşık 3.500 aktif kullanıcısı vardı ve trafik ABD çalışma saatlerinde yoğunlaşıyordu. Uygulaması geleneksel bir web yığını üzerinde çalışıyordu: Nginx, PHP-FPM, PostgreSQL, Redis ve zamanlanmış birkaç çalışan işi. Ekibin kaynak denetimi ve dağıtım betikleri vardı, ancak altyapı olağan pratik şekilde birikmişti: kimsenin cuma günü sunucuya dokunmak istemediği noktaya kadar birbiri ardına bir hizmet eklenmişti.
Acil baskı veritabanı performansıydı. CPU kullanımı sürekli yüksek değildi, ancak kısa süreli zirveler yavaş sorguların birikmesine neden oluyordu. Yedeklemeler raporlama işlerine yakın zamanda çalıştırıldığında disk G/Ç çekişmesi ortaya çıkıyordu. Uygulama genellikle kurtarılabiliyordu, ancak “genellikle” bir kurtarma hedefi değildir.
Ekibin ayrıca PHP sürümleri, hizmet yapılandırması, güvenlik duvarı kuralları ve izleme üzerinde daha fazla denetime ihtiyacı vardı. Paylaşımlı barındırma ilk aşamada yararlı olmuştu, ancak doğal sınırına ulaşmıştı. Bir VPS, şirketin fiziksel donanımı işletmesini gerektirmeden tahsis edilmiş özel kaynaklar ve kök düzeyinde denetim sunuyordu.
Her kararı şekillendiren bir kısıt vardı: müşteri oturumları ve ücretli iş akışları uzun süre kesintiye uğrayamazdı. Saatler süren kesintiye sahip bir taşıma teknik olarak mümkündü, ancak ticari açıdan cazip değildi.
VPS Taşımasından Önce Neler Kontrol Edildi
Yeni ortamı hazırlamadan önce taşıma planı, sistemi bağımsız olarak taşınabilecek bileşenler ile son bir geçiş gerektiren bileşenlere ayırdı. Statik uygulama dosyaları, konteyner imajları ve yapılandırmaların çoğu erkenden kopyalanabilirdi. Veritabanı, son geçişe kadar değişmeye devam ettiği için daha fazla özen gerektiriyordu.
Ekip, iyimserliğe dayanarak bir VPS planı seçmek yerine önce gerçek kullanımı ölçtü. Zirve CPU kullanımını, RAM tüketimini, veritabanı boyutunu, depolama büyümesini, IOPS davranışını, ağ aktarımını ve eşzamanlı çalışan süreçlerinin sayısını incelediler. Ortaya çıkan VPS, yalnızca mevcut ortalamaları karşılayacak kapasiteyle değil, trafik artışları ve bakım için ek kapasiteyle boyutlandırıldı.
Yönetilen VPS seçildi; çünkü iç geliştirme ekibi uygulamayı sürdürebiliyordu, ancak her işletim sistemi uyarısında gece boyunca müdahale noktası olmak istemiyordu. Bu ödünleşimi açıkça belirtmek gerekir: yönetilmeyen VPS barındırma kâğıt üzerinde daha düşük maliyetli olabilir, ancak yama uygulama, izleme, yedekleme doğrulama ve olay triyajı işlerini kendi çalışanlarınıza yükler. Özel altyapı personeli olan ekipler için bu mantıklı olabilir. Küçük bir SaaS ekibi içinse çoğu zaman düşük aylık fiyat etiketi taşıyan pahalı bir dikkat dağıtıcıya dönüşür.
Yeni VPS, uygulama verileri gelmeden önce güvenliği güçlendirilmişti. Erişim yalnızca SSH anahtarlarıyla sınırlandırıldı, gereksiz hizmetler kaldırıldı, güvenlik duvarı kuralları yalnızca gerekli trafiğe izin verdi ve otomatik güvenlik güncellemeleri yığınla uyumluluk açısından incelendi. Dağıtım ve hizmet süreçleri için ayrı sistem kullanıcıları oluşturuldu. Gizli bilgiler kod tabanından çıkarılarak korumalı yapılandırma dosyalarına taşındı.
Yedeklemeler iki biçimde yapılandırıldı: sunucu kaybından kurtarma için zamanlanmış sunucu dışı yedeklemeler ve verilerin daha hızlı geri yüklenmesi için veritabanına özgü yedeklemeler. Hiç geri yüklenmemiş bir yedekleme yalnızca umut vadeden bir dosyadır. Ekip, bir veritabanı yedeklemesini yalıtılmış bir test veritabanına geri yükledi ve uygulamanın bu veritabanını doğru şekilde okuyabildiğini doğruladı.
Kullanılan Taşıma Planı Aşamalı Bir Geçişti
Uygulama, taşıma gecesinden birkaç gün önce yeni VPS'ye dağıtıldı. Bu, ekibe gerçekçi yük altındaki davranışı karşılaştırma ve PHP uzantıları, dosya izinleri, cron yürütmesi, Redis yapılandırması ve e-posta teslimindeki küçük farklılıkları giderme zamanı verdi. Bu ayrıntılar, sorun yaratana kadar sıkıcıdır.
Uçtan uca test için bir hazırlama ana bilgisayar adı kullanıldı. İç personel oturum açma, hesap oluşturma, faturalandırma geri çağrıları, dosya yüklemeleri, zamanlanmış raporlar, API kimlik doğrulaması ve yönetim portalını kontrol etti. Geri alma yolunu da test ettiler. Geri alma planlaması kötümser göründüğü için birçok taşıma bu kısmı atlar. Aslında sorun sırasında sakin bir karar alınmasını sağlayan şey budur.
Son geçişin dört operasyonel aşaması vardı:
- Kayıt değişikliklerinin daha hızlı yayılması için DNS TTL'sini önceden azaltın.
- Eski platform çalışır durumda kalırken ilk veritabanı eşitlemesini gerçekleştirin.
- Kısa süreli son eşitleme için yazma ağırlıklı işlevleri bakım moduna alın.
- DNS'yi güncelleyin, üretim trafiğini doğrulayın ve yeni hizmetin kararlı olduğu onaylanana kadar eski ortamı kullanılabilir tutun.
İlk veri aktarımı, kullanıcıları etkilemeden veritabanının çoğunu taşıdı. Kararlaştırılan bakım saatinde ekip yeni yazmaları duraklattı, son artımlı eşitlemeyi çalıştırdı ve üretim hizmetlerini VPS üzerinde başlattı. Yazma duraklatması 11 dakika sürdü. Zaten gezinen kullanıcılar herkese açık sayfaların ve hesap sayfalarının çoğunu okumaya devam edebilirken faturalandırma bilgilerini güncelleme veya yeni kayıt gönderme gibi işlemler kısa bir bakım bildirimi gösterdi.
Bu yaklaşım ödünsüz değildi. Veritabanı çoğaltması kullanan sıfıra yakın kesintili bir taşıma, son bakım penceresini daha da kısaltabilir, ancak karmaşıklık ekler ve daha fazla ön hazırlık gerektirir. Bu SaaS sağlayıcısı için 11 dakikalık kontrollü yazma duraklatması, ekibin daha sonra işletmeye hazır olmadığı bir çoğaltma tasarımı oluşturmaktan daha güvenliydi. İyi altyapı her zaman en karmaşık altyapı değildir.
Geçiş Sırasında Neler Oldu
Son veritabanı kontrolünden sonra DNS kaydı güncellendi. Taşıma ekibi, trafik yeni VPS'ye ulaşırken erişim günlüklerini, hata günlüklerini, PostgreSQL bağlantılarını, PHP-FPM çalışan etkinliğini, yanıt sürelerini ve arka plan kuyruğu derinliğini izledi.
İlk saatte iki sorun ortaya çıktı. Zamanlanmış bir rapor işi eski sunucudan kalan sabit kodlanmış bir yol kullanıyordu ve bir harici API sağlayıcısı eski dış IP adresine izin vermişti. Bu sorunların hiçbiri geri almayı gerektirmedi. Rapor işinin yolu düzeltildi ve tedarikçi izin listesi yeni VPS adresi kullanılarak güncellendi. Günlükler artık aynı hikâyeyi anlatıyordu.
Ekip eski ortamı olduğu gibi tuttu, ancak buradaki herkese açık yazmaları devre dışı bıraktı. Bu, iki sistem arasında verilerin bölünmesini önlerken korumalı bir geri alma seçeneği oluşturdu. 24 saatlik kararlı uygulama davranışı, başarılı yedeklemeler ve normal kuyruk işleme sonrasında eski ortam üretim kullanımından çıkarıldı.
VPS'ye Taşınma Sonrası Sonuçlar
Anında elde edilen kazanım tutarlılıktı. Veritabanı ve web çalışanları artık kaynaklar için ilgisiz kiracılarla rekabet etmediğinden medyan uygulama yanıt süresi iyileşti. Hız artışından daha yararlı olan görünürlüktü: ekip CPU'yu, RAM'i, diski, ağı, hizmet durumunu ve veritabanı davranışını tek bir operasyonel görünümde görebiliyordu.
SaaS sağlayıcısı ayrıca daha düzenli bir bakım rutini kazandı. Güncellemeler üretimden önce hazırlama ortamında test edilebiliyor, yedeklemeler yoğun raporlama saatleri dışında çalıştırılıyor ve uyarılar için sorumlular belirleniyordu. Yönetilen operasyonel destek ve etkin izleme sunan kodu.cloud sayesinde, altyapı davranışına müdahale gerektiğinde iç ekibin daha net bir eskalasyon yolu vardı.
Taşıma her sorumluluğu ortadan kaldırmadı. Müşteri; uygulama sürümlerinden, verilerin doğruluğundan, kullanıcı izinlerinden ve tedarikçi entegrasyonlarından sorumlu olmaya devam etti. Barındırma katmanı izlenebilir, yamalanabilir, yedeklenebilir ve desteklenebilir, ancak hiçbir sağlayıcı yeni dağıtılan bir özelliğin iş mantığı hatası içerip içermediğini belirleyemez. Net sorumluluk sınırları sağlıklı bir kurulumun parçasıdır.
VPS Taşıması Planlayan SaaS Ekipleri için Dersler
Temel ders, taşıma kalitesinin geçiş penceresinden önce belirlenmesidir. Belgelenmemiş bir cron işini, süresi dolmuş bir API kimlik bilgisini veya aşırı büyümüş bir veritabanı tablosunu keşfetmek için en iyi zaman, müşteriler tarayıcılarını yenilerken değil, hazırlama aşamasıdır.
Ölçülmüş kaynak kullanımıyla başlayın, ardından büyüme için alan bırakın. Gerçek iş akışlarını test etmek için yeni sunucuyu yeterince erken oluşturun. Yedeklemeleri geri yükleyerek doğrulayın. Geri almayı neyin tetikleyeceğini ve bu kararı kimin verebileceğini belirleyin. Son olarak, dağıtım komutu tamamlandığında zafer ilan etmek yerine DNS değişikliklerinden sonra hizmeti izleyin.
Bir VPS taşıması ekibinize daha fazla denetim ve gece geç saatlerde daha az tahmin bırakmalıdır. Plan test edilmiş kurtarmayı, aşamalı aktarımı ve trafik geldikten sonra sunucuyu izleyen kişileri içeriyorsa hizmet yeniden sakin hale gelebilir.
Andres Saar Müşteri Hizmetleri Mühendisi