Çoğu işletme sahibi sunucu taşımayı bir dosya kopyalama işi sanır. "Yedeği alırım, yeni sunucuya atarım, DNS'i çeviririm, bitti" diye düşünür. Oysa bir e-pin scripti taşırken kopyaladığın şey sadece dosya ve veritabanı değil; aynı zamanda çalışan cron'lar, bekleyen teslimat kuyruğu, ödeme sağlayıcısına kayıtlı IP adresi, açık oturumlar, yarı kalmış siparişler ve bayilerinin o anda ekranda gördüğü bakiye. Bunlardan biri kayarsa sorun "site açılmıyor" gibi görünmez; site açılır, güzel görünür, ama arka planda para ile stok birbirine yanlış bağlanır.
Gerçek şu: taşımanın kendisi teknik olarak kolaydır. Zor olan, taşıma anında sistemin iki yerde birden canlı olmasını engellemektir. Bir dijital ürün satış scripti stok tüketen bir sistemdir. Aynı e-pin kodunu iki farklı veritabanı iki farklı müşteriye satabilir. Bu yazıda, taşımayı bir olay değil bir prosedür haline getiren sırayı anlatacağım; hangi adımın hangisinden önce gelmesi gerektiğini ve neden 03:00'te yapılan taşımaların ertesi sabah 09:00'da çöktüğünü.
Çoğu taşıma neden gece değil, ertesi sabah çöker?
Gece taşıma yaparsın, siteyi açarsın, ana sayfa gelir, panele girersin, ürünler listelenir. Her şey yolunda görünür çünkü test ettiğin şey okuma işlemleridir. Ertesi sabah ilk gerçek sipariş geldiğinde ise yazma tarafı devreye girer: sipariş kaydı, stok düşümü, kod ayırma, e-posta gönderimi, fatura numarası artırımı, bayi bakiye hareketi. Bir e-pin satış yazılımı asıl karmaşıklığını burada saklar.
Bu yüzden taşıma testi "site açıldı mı" ile bitmez. Yeni sunucuda gerçek bir uçtan uca test siparişi geçirmen gerekir: küçük tutarlı, kendi kartınla, gerçek ödeme sağlayıcısıyla, gerçek teslimat akışıyla. Kod teslim edildi mi, e-posta gitti mi, stok tabloda azaldı mı, bayi paneline hareket düştü mü? Bu dört soruya "evet" demeden taşıma bitmemiştir. Ayrıca sabah 09:00 aynı zamanda cron'ların ilk kez yoğun çalıştığı saattir; gece hiçbir zamanlanmış görev tetiklenmediği için sorun uykuda kalır.
Taşımadan önce hangi envanteri çıkarmazsan geri dönüşün olmaz?
Taşımanın ilk adımı dosya değil, envanter. Eski sunucuda tam olarak neyin çalıştığını yazmadan yeni sunucuyu kuramazsın, çünkü unuttuğun şeyi aramayı da akıl edemezsin. Çıkarman gereken liste şudur: PHP sürümü ve aktif eklentiler, veritabanı sürümü ve karakter seti, cron tanımları ve çalışma sıklıkları, kullanılan dış servis anahtarları, e-posta gönderim yöntemi, SSL sertifikasının kaynağı, dosya izin şeması, yükleme dizinlerinin yolu, ve varsa özel sunucu yapılandırmaları.
Özellikle karakter seti konusu Türkçe satış yapan bir epin yazılım kurulumunda felakete dönüşebilir. Eski sunucu farklı bir varsayılan collation kullanıyorsa, taşıma sonrası müşteri isimlerindeki Türkçe karakterler bozulur ve bu bozulma faturalara, e-postalara, hatta ödeme sağlayıcısına giden alıcı bilgisine yansır. Yedeği alırken karakter setini açıkça belirtmek, sonradan binlerce satırı düzeltmekten çok daha ucuzdur. Pinova tarafında beklenen ortam gereksinimlerini özellikler bölümünde tek tek doğrulayabilirsin.
DNS TTL'i düşürmeyi atlarsan iki sunucuya birden satış yaparsın
Bu, taşımanın en pahalı hatasıdır ve en kolay önlenebilenidir. Alan adının TTL değeri yüksekse, sen DNS'i yeni sunucuya çevirdikten sonra bir kısım ziyaretçi saatlerce eski sunucuya gitmeye devam eder. Eski sunucu hâlâ ayaktaysa ve veritabanı hâlâ yazılabilir durumdaysa, o ziyaretçiler eski veritabanına sipariş yazar. Yeni veritabanına ise başka siparişler düşer. Sonuç: aynı e-pin kodu iki müşteriye satılır, iki ayrı sipariş numarası aynı numarayı alır, muhasebe birbirine girer.
Doğru sıra şudur: taşımadan en az 24 saat önce TTL'i 300 saniyeye indir. Taşıma penceresi açıldığında eski paneli bakım moduna al ve yazmayı tamamen kapat. Sonra son yedeği al, aktar, test et, DNS'i çevir. Eski sunucuyu hemen silme; ama okunur ve satış yapamaz halde bırak. Bakım modu bir nezaket değil, veri bütünlüğü önlemidir.
| Sıra | Adım | Süre | Atlanırsa ne olur? |
|---|---|---|---|
| 1 | TTL'i 300 sn'ye indir | T-24 saat | Trafik saatlerce eski sunucuda kalır |
| 2 | Envanter ve yapılandırma dökümü | T-12 saat | Eksik cron ve anahtarlar fark edilmez |
| 3 | Yeni sunucuda boş kurulum + ortam testi | T-8 saat | Sürüm uyumsuzluğu geçiş anında çıkar |
| 4 | Eski panel bakım modu, yazma kapalı | T-0 | Çift veritabanına sipariş yazılır |
| 5 | Son yedek + aktarım + bütünlük sayımı | T+0:20 | Eksik tablo sessizce kaybolur |
| 6 | Uçtan uca gerçek test siparişi | T+0:40 | Teslimat zinciri kopuk yayına alınır |
| 7 | DNS değişimi + SSL doğrulaması | T+1:00 | Tarayıcı uyarısı dönüşümü keser |
| 8 | Cron'ları yeni sunucuda etkinleştir | T+1:15 | Kuyruk birikir, teslimat durur |
Taşıma sonrası ilk 72 saatte çıkan sorunların kaynağı
- DNS / TTL kaynaklı çift trafik 45%
- Cron ve teslimat kuyruğu 25%
- Dosya izinleri ve oturum yolu 20%
- Ödeme bildirim IP'si 10%
Cron, kuyruk ve otomatik teslimat: taşımanın en sessiz katili
Bir e-pin satış scripti arka planda yaşar. Ödeme bildirimini işleyen görev, bekleyen teslimatları gönderen görev, stok uyarısı üreten görev, tedarikçi API'sinden bakiye çeken görev. Taşımada dosyaları ve veritabanını taşırsın ama cron tanımları sunucunun kendisinde durur; yeni sunucuya otomatik gelmez. Site mükemmel çalışır, müşteri öder, sipariş "hazırlanıyor" der ve orada kalır. Müşteri destek yazar, sen panele bakarsın, sipariş görünür, hata yoktur. Çünkü hata yok; sadece kimse tetiklemiyor.
Aynı tuzağın ikinci yüzü de var: cron'ları yeni sunucuda açarken eski sunucuda kapatmayı unutmak. O durumda iki sunucu aynı tedarikçi API'sine aynı anda istek atar, aynı bekleyen siparişi iki kez işlemeye çalışır. Eski sunucudaki tüm zamanlanmış görevleri açıkça devre dışı bırakmak, taşıma kontrol listesinde ayrı bir satır olmayı hak eder.
Aktarım öncesi ve sonrası için sipariş, ürün, stok kodu, kullanıcı ve bakiye hareketi tablolarındaki kayıt sayılarını karşılaştır. İki liste birebir tutmuyorsa DNS'e dokunmadan geri dön; yayına alındıktan sonra fark edilen eksik tabloyu telafi etmek neredeyse imkânsızdır.
IP değişti, para akmıyor: ödeme ve API beyaz listeleri
Yeni sunucu yeni IP demektir. Ödeme sağlayıcın bildirim (callback) adresini doğrulamak için IP kontrolü yapıyorsa, tedarikçi API'n çağrıları IP bazlı yetkilendiriyorsa veya SMTP sağlayıcın gönderimi IP'ye bağlamışsa, bunların hepsi taşıma anında sessizce kırılır. Ödeme sayfası açılır, müşteri kartını girer, banka onaylar, ama bildirim sana ulaşmadığı için sipariş "ödeme bekliyor" olarak kalır. Müşteri parasını ödemiş ama ürününü almamıştır; bu, itibarına en hızlı zarar veren senaryodur.
Çözüm basit ama sıralı: taşımadan önce yeni sunucunun IP'sini ödeme sağlayıcı, tedarikçi ve e-posta servisi panellerine ekle. Eski IP'yi hemen silme; geçiş penceresi boyunca ikisini birlikte tut. Böylece hangi sunucudan gelirse gelsin istek kabul edilir. Bir hafta sonra eski IP'yi listeden kaldırırsın.
| Kontrol | Nasıl doğrularsın? | Durum |
|---|---|---|
| Veritabanı satır sayıları eşit | Kritik tabloların kayıt sayısını karşılaştır | Zorunlu |
| Gerçek test siparişi teslim edildi | Küçük tutarlı canlı ödeme + kod teslimi | Zorunlu |
| Cron'lar yeni sunucuda aktif | Son çalışma zamanı kaydını izle | Zorunlu |
| Eski sunucuda cron'lar kapalı | Zamanlanmış görev listesini boşalt | Zorunlu |
| Ödeme bildirim IP'si eklendi | Sağlayıcı panelinden test bildirimi | Zorunlu |
| SSL ve www yönlendirmesi çalışıyor | Dört varyantı tarayıcıda dene | Zorunlu |
| E-posta gönderimi spam'e düşmüyor | SPF ve DKIM kayıtlarını yeniden doğrula | Önerilir |
| Yedek otomasyonu yeni sunucuda kurulu | İlk yedeğin oluştuğunu gör | Önerilir |
Rollback planı olmayan taşıma, taşıma değil kumardır
Her taşımanın bir "vazgeçme anı" olmalı. Bu an, DNS'i çevirmeden hemen önceki noktadır. O noktaya kadar eski sunucu hâlâ gerçeğin kaynağıdır ve geri dönmek bedava. DNS'i çevirdikten sonra geri dönmek ise maliyetlidir, çünkü yeni sunucuda oluşan siparişleri eski sisteme taşımak gerekir.
Bu yüzden karar kriterlerini önceden yaz: satır sayıları tutmazsa dönerim, test siparişi teslim edilmezse dönerim, ödeme bildirimi gelmezse dönerim. Duygusal karar vermemek için bu üç cümleyi taşımadan önce belirlemek şarttır. Doğru kurgulanmış bir dijital ürün satış yazılımı taşıması, gece yarısı panik içinde alınan kararlara değil, sabah yazılmış bir listeye dayanır. Altyapı maliyetini hesaplarken fiyat sayfasındaki paket kapsamlarını da göz önünde bulundur.
Taşımayı olay değil, prosedür haline getir
Pinova'nın kurulum ve göç akışı, ortam doğrulamasından teslimat kuyruğuna kadar her adımı takip edilebilir kılar. Satışını durdurmadan taşınmak istiyorsan doğru yerdesin.
Sunucu taşıma sırasında sitemi kaç saat kapatmam gerekir?
Hazırlık doğru yapılırsa yazma işlemlerini kapattığın pencere genelde 30-60 dakikadır. Uzun kesintiler neredeyse her zaman yeni sunucunun taşıma anında sıfırdan kurulmaya çalışılmasından kaynaklanır; ortamı önceden hazırlarsan pencere kısalır.
Eski sunucuyu ne zaman kapatabilirim?
En az yedi gün bekle. Bu süre boyunca eski sunucuyu satış yapamaz ama okunabilir halde tut. Geç gelen ödeme bildirimleri, arama motoru istekleri ve önbelleklenmiş DNS kayıtları bu pencerede hâlâ eski adrese ulaşabilir.
Taşıma SEO sıralamamı etkiler mi?
URL yapısı ve içerik aynı kalıyorsa etki minimaldir. Zarar genelde taşıma sırasında yanlışlıkla değişen yönlendirmelerden, kaybolan sitemap dosyasından veya geçici olarak bırakılan engelleme kurallarından gelir. Yayına almadan önce robots ve yönlendirme kurallarını kontrol et.
Yedekten geri dönerken en çok neyi unutuyorlar?
Yükleme dizinini. Veritabanı geri yüklenir ama ürün görselleri, fatura PDF'leri ve yüklenmiş belgeler dosya sisteminde durur. Veritabanı ile dosya dizinini aynı ana ait iki parça olarak birlikte yedekle.
Sunucu taşıma, doğru sırayla yapıldığında müşterinin fark etmediği bir gecedir; yanlış sırayla yapıldığında ise haftalarca temizlediğin bir kazadır. Aradaki fark yazılımın hızı değil, akışın öngörülebilirliğidir. Pinova'nın sipariş, stok ve teslimat zincirini nasıl tek yerden izlenebilir kıldığını görmek istersen canlı demo üzerinden panelin içinde dolaş; taşıma kontrol listenin hangi maddelerinin zaten yazılım tarafından karşılandığını kendi gözünle değerlendir.