1. Değişiklikten Önce Risk ve Geri Dönüş Planı

Bir VPS üzerinde uygulama, web sunucusu veya sistem yapılandırması değiştirmeden önce hedefi, etkilenecek bileşenleri ve geri dönüş koşullarını yazılı hâle getirin. “Sorun çıkarsa eski hâle getiririm” yaklaşımı yerine hangi dosyanın, servisin, sürümün veya verinin nasıl geri alınacağını önceden belirleyin.

Ön kontrol listesi:

• Etkilenecek servisleri, bağımlılıkları ve olası kesinti süresini belirleyin.
• Uygulama dosyaları, yapılandırmalar ve veritabanı için güncel yedek alın.
• Yedeğin okunabildiğini doğrulayın; mümkünse geri yüklemeyi ayrı bir ortamda test edin.
• Yedekleri yalnızca aynı VPS üzerinde tutmayın. Disk arızası, yanlış silme ve sunucunun tamamen kaybedilmesi risklerine karşı ayrı bir depolama alanı kullanın.
• Aktif SSH oturumunu kapatmadan ikinci bir yönetim oturumu hazırlayın.
• Geri dönüşte ihtiyaç duyulacak paket, uygulama, bağımlılık ve yapılandırma sürümlerini kaydedin.
• Değişiklik öncesi temel metrikleri, mevcut sürümü ve kritik servislerin durumunu not edin.

Veritabanı kullanan uygulamalarda yalnızca dosya kopyalamak yeterli olmayabilir. Uygun yedekleme yöntemini kullanarak tutarlı bir veritabanı yedeği alın ve geri yükleme testi yapılmadan bu yedeği güvenilir kabul etmeyin. Yedekleme sırasında şifreleme, erişim yetkileri, saklama süresi ve silinmeye karşı koruma politikalarını da kontrol edin.

2. Kontrollü Yayına Alma ve Dosya Güvenliği

Mümkünse değişiklikleri doğrudan canlı dosyaların üzerine yazmak yerine yeni bir sürüm dizinine yükleyin. Bağımlılıkları ve yapılandırmayı bu dizinde hazırladıktan sonra sembolik bağlantıyı yeni sürüme çevirmek, sorun hâlinde doğrulanmış eski sürüme dönmeyi kolaylaştırır.

Örnek yayın akışı:


Gizli bilgileri Git deposuna, hata çıktısına veya herkese açık dosyalara koymayın. Ortam değişkenleri ve gizli yapılandırma dosyaları için erişim izinlerini sınırlandırın. Uygulamanın yazma ihtiyacı olmayan dizinleri yazılabilir bırakmayın; dosya sahipliği ve servis hesabı kullanımını kontrol edin.

Migration işlemleri veri şemasını değiştiriyorsa önce yedek alın. Yeni kodun eski şemayla kısa süre çalışıp çalışamayacağını, migration başarısız olduğunda verinin nasıl korunacağını ve geri dönüşün kod değişikliğiyle sınırlı kalıp kalamayacağını değerlendirin. Geri alınması zor şema değişikliklerinde önce staging ortamında prova yapın.

3. Health Check, Log ve Trafik Doğrulaması

Yayından sonra yalnızca ana sayfanın açılmasını başarı ölçütü saymayın. Oturum açma, veritabanı bağlantısı, statik dosyalar, kritik API uçları, dosya yükleme ve arka plan işlerini ayrı ayrı kontrol edin. Health check bağımlılıkların durumunu anlamlı bir sonuçla raporlamalı; ancak dışarıya veritabanı adresi, stack trace veya gizli hata ayrıntıları sızdırmamalıdır.

Kontrol sırasında şu sinyalleri izleyin:

• HTTP durum kodları, hata oranı ve beklenmeyen yönlendirmeler
• Uygulama, web sunucusu ve işletim sistemi hata logları
• CPU, bellek, disk alanı, disk I/O ve ağ bağlantısı kullanımı
• PHP-FPM, Node.js, Python worker veya benzeri süreçlerin yeniden başlaması
• Kuyrukta biriken işler, zaman aşımı ve veritabanı bağlantı hataları
• Yanıt sürelerinin yayın öncesi değerlerle karşılaştırılması

CDN veya ters proxy kullanıyorsanız önbelleğin eski sürümü göstermesi mümkündür. Önbelleği topluca temizlemeden önce etkilenen URL’leri belirleyin; gereksiz purge işlemleri geçici trafik ve kaynak yükü oluşturabilir. Mümkünse sürümleme veya cache-busting kullanarak yalnızca değişen varlıkları yenileyin.

TLS sertifikası yenilemelerinde yalnızca son kullanma tarihini değil, sertifika zincirinin istemciler tarafından doğrulanabildiğini, doğru alan adlarının kapsandığını ve otomatik yenileme görevinin çalıştığını da kontrol edin.

4. Sorun Hâlinde Geri Dönüş ve Olay Sonrası İnceleme

Hata oranı artıyor, kritik kullanıcı akışı çalışmıyor, veri yazma işlemleri bozuluyor veya kaynak tüketimi kontrol dışına çıkıyorsa teşhisi uzatmadan önceden belirlenen geri dönüş koşulunu uygulayın. Yeni sürüm dizinine yönlenen sembolik bağlantıyı eski ve doğrulanmış sürüme çevirin; gerekiyorsa ilgili servisi kontrollü biçimde yeniden başlatın.

Veritabanı migration’ı yapıldıysa yalnızca kodu geri almak yeterli olmayabilir. Önceden tanımlanmış geri dönüş prosedürünü, veri tutarlılığı kontrollerini ve gerekiyorsa yedekten geri yükleme planını uygulayın. Veri kaybı riski taşıyan işlemlerde mevcut durumu korumadan üzerine yazmayın.

Geri dönüşten sonra:

• Kritik uçları ve temel kullanıcı akışlarını tekrar test edin.
• Logları olay zamanı ve değişiklik adımlarıyla eşleştirin.
• Başarısız veya doğrulanmamış yedeği tekrar kullanmayın.
• Kalıcı düzeltme yapılmadan aynı değişikliği yeniden yayınlamayın.
• Kök nedeni, etkiyi ve alınan kararları kayıt altına alın.
• Runbook’u gerçek olayda öğrenilen bilgilerle güncelleyin.

Amaç yalnızca yayını tamamlamak değil, hatalı bir yayını dakikalar içinde güvenli biçimde durdurabilmektir. Her operasyon için şu üç sorunun cevabı önceden hazır olmalıdır: Hangi sinyalde yayını durduracağız, hangi doğrulanmış sürüme döneceğiz ve veriyi nasıl koruyacağız?