Web Sitesi Kesintisinde İlk 30 Dakika Müdahale Planı

Web siteniz açılmadığında ilk tepkiniz eklenti kapatmak, DNS kaydını değiştirmek veya sunucuyu yeniden başlatmak olabilir. Ancak bu adımlar yanlış katmana müdahale ederse kesintiyi uzatabilir. Önce sorunun ziyaretçilerin tamamını mı, belirli ağları mı, yoksa yalnızca tek bir sayfayı mı etkilediğini ayırmanız gerekir.

İyi bir web sitesi kesintisi müdahale planı, ilk 30 dakikayı sıraya koyar: etkiyi ölçer, kanıt toplar, en dar düzeltmeyi uygular ve erişimin geri döndüğünü doğrular. Aşağıdaki akış, WordPress ve WooCommerce sitelerinde olduğu kadar özel PHP uygulamalarında da temel teşhis çerçevesi olarak kullanılabilir.

0-5. dakika: Kesintinin kapsamını belirleyin

Önce sitenin gerçekten genel olarak mı kapalı olduğunu, yoksa tek bir cihazda ya da ağda mı sorun yaşandığını belirleyin. Kendi bilgisayarınızdan sayfanın açılmaması tek başına sunucu arızasını kanıtlamaz. Yerel DNS önbelleği, kurumsal güvenlik duvarı, tarayıcı önbelleği veya internet servis sağlayıcınız da etkili olabilir.

Farklı istemcilerden hızlı erişim testi

Aynı alan adını mobil veri kullanan bir telefondan ve mümkünse farklı bir bağlantıdaki bilgisayardan kontrol edin. Ana sayfanın yanı sıra yönetim paneli, statik bir dosya ve bilinen bir ürün sayfasını da deneyin. Böylece sorun tüm web sitesinde mi, belirli bir uygulama rotasında mı, daha erken anlaşılır.

Tarayıcıdaki hata mesajını aynen not alın. DNS_PROBE_FINISHED_NXDOMAIN, ERR_CONNECTION_REFUSED, TLS sertifika uyarısı, 403, 404, 502, 503 ve 504 aynı arızayı göstermez. Hatanın ekran görüntüsünü almak yerine kodu, saati ve test edilen adresi bir müdahale notuna yazmanız sonraki karşılaştırmaları kolaylaştırır.

curl -I --max-time 15 https://ornekalanadiniz.tld/

Bu komut, HTTPS adresine başlık isteği gönderir. curl sunucuda veya kendi bilgisayarınızda kurulu olmalıdır; komutun çalışması için siteye giriş yapmanız gerekmez. 200 veya 301 gibi bir HTTP yanıtı web sunucusuna ulaşabildiğinizi gösterir, fakat uygulamanın sağlıklı olduğu anlamına gelmez. Bazı uygulamalar HEAD isteğini farklı işleyebileceği için gerektiğinde gövdeyi de alan bir GET testiyle karşılaştırma yapın. 502 ve 504 web sunucusu ile arka uç arasındaki iletişimde sorun olabileceğini, 503 ise hizmetin geçici olarak kullanılamadığını düşündürür.

Tarayıcı ve komut satırı farklı sonuç veriyorsa proxy, CDN, DNS önbelleği veya cihaz kaynaklı bir fark olabilir. Tek bir testten hareketle DNS kaydını ya da SSL ayarını değiştirmeyin.

Son değişiklikleri zaman çizelgesine ekleyin

Kesinti başlamadan hemen önce yapılan değişiklikleri listeleyin: DNS güncellemesi, alan adı yenilemesi, SSL yenilemesi, eklenti veya tema güncellemesi, sunucu yapılandırması, PHP sürümü değişimi, veritabanı bakımı ve trafik artışı. Zaman ilişkisi neden ilişkisini kanıtlamaz; ancak hangi kontrollerin önce yapılacağını belirler.

Bu aşamada hedefiniz çözüm üretmek değil, kapsamı ve başlangıç zamanını kaydetmektir. Olay kaydına test saati, kullanılan ağ, hata kodu ve son değişiklikleri yazın.

5-10. dakika: DNS ve alan adı yönlendirmesini ayırın

DNS, alan adını bir IP adresine veya başka bir hedefe yönlendiren sistemdir. DNS hatasında tarayıcı çoğu zaman web sunucusuna hiç ulaşamaz. Bu nedenle DNS kontrolü ile web sunucusu kontrolünü birbirine karıştırmamak gerekir.

Yetkili DNS yanıtını kontrol edin

Aşağıdaki sorgu, alan adının hangi A kaydına yöneldiğini gösterir. IPv6 kullanıyorsanız AAAA kaydını da ayrıca kontrol edin.

dig +short A ornekalanadiniz.tld
 dig +short AAAA ornekalanadiniz.tld
 dig +short CNAME www.ornekalanadiniz.tld

dig Linux ve macOS sistemlerinde yaygın bir DNS aracıdır. Windows ortamında aynı sorguları DNS yönetim panelinden veya kurulu bir DNS aracından yapabilirsiniz. Boş yanıt, yanlış hedef, beklenmeyen CNAME veya yalnızca IPv6 kaydının bulunması erişim sorununa yol açabilir. Ancak DNS değişiklikleri önbellekler nedeniyle farklı istemcilerde aynı anda görünmeyebilir.

Alan adı kayıtlarının yetkili DNS sağlayıcısında beklediğiniz değerleri taşıdığını kontrol edin. A kaydı sunucunun güncel IP adresini göstermiyorsa önce kaynağı bulun: son değişiklik, alan adı yönetimi, DNS şablonu veya otomatik dağıtım sistemi. Rastgele yeni bir IP yazmak yerine mevcut doğru kaydın yedeğini alın ve yalnızca hatalı kaydı düzeltin.

DNS sorunlarını daha geniş bir kontrol listesiyle karşılaştırmak isterseniz DNS hatalarını kontrol etme başlığı ilgili bir sonraki okuma olabilir.

DNS kaydı doğru görünüyor ancak site açılmıyorsa bir sonraki katmana geçin. DNS’i tekrar tekrar değiştirmeniz sorunu çözmez; yalnızca farklı önbellek yanıtlarını artırabilir.

10-15. dakika: SSL ve web sunucusu katmanını test edin

DNS doğru hedefe gidiyor ve bağlantı kuruluyorsa SSL/TLS el sıkışması ile web sunucusunun yanıtını ayrı değerlendirin. SSL/TLS, tarayıcı ile sunucu arasındaki bağlantıyı şifreleyen ve sertifika doğrulaması yapan katmandır.

Sertifika ve süre kontrolü

Tarayıcı sertifika uyarısı veriyorsa sertifikanın alan adını kapsayıp kapsamadığını, geçerlilik tarihini ve ara sertifikaların sunulup sunulmadığını kontrol edin. Sunucuda OpenSSL varsa aşağıdaki komut temel bir gözlem sağlar:

openssl s_client -connect ornekalanadiniz.tld:443 -servername ornekalanadiniz.tld < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Bu komut sertifikanın başlangıç ve bitiş tarihlerini, konu alanını ve sertifika otoritesini gösterir. Komutun sonucunu uygulamak için değil, teşhis için kullanın. Sertifika süresi dolmuşsa kullandığınız sertifika yönetim aracının loglarını ve yenileme önkoşullarını kontrol edin. Sertifika dosyasını elle değiştirmeden önce mevcut yapılandırmayı yedekleyin ve geri dönüş dosyasını belirleyin.

HTTP yanıtını ve sanal host eşleşmesini kontrol edin

SSL testi başarılı olduğu halde tarayıcı 502, 503 veya 504 gösteriyorsa istek web sunucusuna ulaşmış, fakat arka uçta sorun oluşmuş olabilir. Nginx, Apache, LiteSpeed veya kullanılan başka bir web sunucusunun erişim ve hata loglarında kesinti saatini arayın. Log dosyalarının yolu dağıtıma ve panele göre değişir; bilmediğiniz bir dosyayı silmeyin veya log rotasyonunu elle tetiklemeyin.

Beklenmeyen 404 ya da farklı bir sitenin içeriği geliyorsa alan adı ile sanal host eşleşmesini, belge kökünü ve yönlendirme kurallarını inceleyin. Sadece ilgili alan adının yapılandırmasını karşılaştırın. Tüm web sunucusu yapılandırmasını baştan oluşturmak, çalışan diğer siteleri de etkileyebilir.

Web sunucusu yapılandırmasını değiştirdiyseniz önce sözdizimini doğrulayın; ardından yeniden yükleme yapın. Komutlar yazılım ve işletim sistemine göre değişir. Kullandığınız servis yöneticisinin belgelenmiş test komutunu ve geri dönüş yöntemini uygulayın. Yeniden yüklemeden sonra aynı curl -I testini tekrarlayın.

15-22. dakika: Uygulama, veritabanı ve PHP katmanını ayırın

Web sunucusu yanıt veriyor ancak WordPress, WooCommerce veya özel uygulama hata veriyorsa uygulama katmanını inceleyin. Beyaz ekran, 500 hatası, yönetim panelinde yavaşlama ve ürün sayfalarının açılmaması farklı belirtilerdir. Aynı anda eklenti silmek, PHP sürümünü değiştirmek ve veritabanını onarmaya çalışmak hangi müdahalenin etkili olduğunu belirsizleştirir.

Uygulama loglarını zaman aralığıyla inceleyin

Önce web sunucusu hata logu ile PHP hata logunu aynı dakikalar için karşılaştırın. Allowed memory size, maximum execution time, bağlantı reddi, dosya bulunamadı veya veritabanı kimlik doğrulama hataları farklı düzeltmeler gerektirir. WordPress kullanıyorsanız hata ayıklama kaydını üretim ortamında sınırsız biçimde açık bırakmayın; logda kişisel veri veya bağlantı bilgileri bulunabilir.

Veritabanı bağlantısı başarısızsa veritabanı servisinin çalıştığını, uygulama yapılandırmasındaki kullanıcı adı, parola, veritabanı adı ve sunucu bilgisinin değişmediğini kontrol edin. Önce yapılandırma dosyasının güvenli bir kopyasını alın. Parolayı loglara veya destek talebine düz metin olarak eklemeyin.

Veritabanında tablo onarımı, silme, toplu güncelleme veya geri yükleme veri değiştiren işlemlerdir. Güncel yedek ve geri dönüş planı olmadan bu adımlara geçmeyin. Sorun yalnızca tek bir eklenti veya tema güncellemesinden sonra başladıysa, panelin güvenli devre dışı bırakma yöntemini ve mevcut dosya yedeğini kullanarak yalnızca şüpheli bileşeni izole edin.

PHP-FPM ile CLI işlerini karıştırmayın

PHP-FPM web isteklerini karşılayan PHP işçileridir. CLI üzerinden çalışan cron görevleri, kuyruk tüketicileri veya import komutları ise HTTP isteği yapmadıkları sürece PHP-FPM işçisi tüketmez; ancak aynı CPU, RAM, disk ve veritabanı kaynakları için yarışabilir. Bu ayrım, “web işçisi doldu” varsayımını test ederken önemlidir.

PHP-FPM işçi sayısı dolmuşsa loglarda bekleme, zaman aşımı veya çocuk süreç sınırı belirtileri görülebilir. CLI kuyruğu aşırı CPU ya da veritabanı bağlantısı tüketiyorsa web istekleri yine yavaşlayabilir. Önce hangi sürecin kaynak kullandığını ölçün; ardından yalnızca o işin hızını veya paralelliğini geçici olarak azaltın. İşçi sayılarını körlemesine artırmak RAM tüketimini yükseltebilir.

22-27. dakika: Kaynak limitlerini ve trafik etkisini inceleyin

Site bazen açılıyor, bazen zaman aşımına uğruyorsa kaynak sınırı veya ani trafik artışı olasılığı yükselir. CPU, RAM, PHP süreçleri, disk alanı, disk I/O ve veritabanı bağlantı sayısı birlikte değerlendirilmelidir. Paylaşımlı hostingde bu metriklerin bir bölümü kontrol panelinde; VPS veya özel sunucuda işletim sistemi ve servis izleme araçlarında bulunabilir.

Kontrol panelinde giriş sınırı, CPU kullanım grafiği, RAM limiti, inode sayısı, disk doluluğu, I/O limiti ve eşzamanlı bağlantı uyarılarını kontrol edin. Bir limitin aşılması, limiti hemen yükseltmeniz gerektiğini göstermez. Önce hangi URL, cron görevi, eklenti, import veya trafik kaynağının tüketimi oluşturduğunu belirleyin.

VPS erişiminiz varsa teşhis amacıyla aşağıdaki salt-okunur komutlarla genel durumu görebilirsiniz:

uptime
free -h
df -h
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head

Bu komutlar yük ortalaması, bellek, disk doluluğu ve CPU kullanan süreçler hakkında anlık bilgi verir. df -h çıktısında dosya sistemi tamamen doluysa log yazılamaması veya veritabanı işlemlerinin başarısız olması mümkündür. Dosya silmeden önce hangi dosyanın güvenli olduğunu belirleyin; log, yükleme ve yedek klasörlerinde veri kaybı riski vardır.

WooCommerce sitelerinde ödeme, stok veya sipariş işlemlerini etkileyen agresif önbellek temizliği ve kuyruk durdurma adımlarını dikkatle ele alın. Sipariş verilerinin yazıldığı anda uygulamayı yeniden başlatmak veya veritabanını geri yüklemek yeni kayıtların kaybına yol açabilir. Önce işlem yoğunluğunu ve hata zamanını belgeleyin.

Sunucu kaynaklarının site ihtiyacına göre değerlendirilmesi için CPU, RAM ve trafik hesabı başlığı planlama aşamasında yardımcı olabilir. Ancak o yazıdaki genel hesap yaklaşımı, mevcut kesintinin kesin nedenini tek başına kanıtlamaz.

27-30. dakika: Sağlayıcı durumunu kontrol edin ve doğrulayın

DNS, SSL, web sunucusu ve uygulama tarafında açıklayıcı bir bulgu yoksa sağlayıcının durum sayfasını, bakım duyurularını ve destek kanalını kontrol edin. Paylaşımlı hostingde düğüm, ağ, depolama veya kontrol paneli sorunu sizin hesabınızda görünmeyebilir. VPS kullanıyorsanız sanal sunucunun çalışması, veri merkezindeki ağ veya üst katman depolama sorununu dışlamaz.

Destek talebine alan adını, kesintinin başlangıç saatini, farklı ağlardaki sonuçları, HTTP kodunu, DNS sonucunu ve yaptığınız güvenli kontrolleri ekleyin. Parola, özel anahtar, veritabanı bağlantı bilgisi veya kişisel müşteri verisi göndermeyin. Sağlayıcı sizden yeniden başlatma isterse bunun veri kaybı, açık sipariş veya çalışan import süreçleri üzerindeki etkisini sorun.

Bir ayar değiştirdiyseniz önce tek bir değişikliği doğrulayın. Ana sayfa, yönetim paneli, kritik bir ürün veya iletişim formu ve mümkünse yeni bir oturumdan erişimi test edin. HTTP yanıtını tekrar alın ve loglarda yeni hata oluşup oluşmadığına bakın. Sorun sürüyorsa yaptığınız değişikliği geri alın; art arda değişiklikler geri dönüşü zorlaştırır.

İlk 30 dakikadan sonra kalıcı iyileştirme

Site yeniden açıldıktan sonra olayı kapatmadan önce kök nedeni ve katkıda bulunan koşulları ayırın. Örneğin sertifikanın süresinin dolması kök neden olabilir; yenileme alarmının olmaması ise tekrar riskini artıran koşuldur. Aynı şekilde kaynak sınırı kesintiyi açıklayabilir, fakat hangi cron işinin sınırı tetiklediği ayrıca araştırılmalıdır.

Kesinti zaman çizelgesini, alınan log örneklerini, yapılan değişikliği, doğrulama sonucunu ve geri dönüş adımını saklayın. Uygulama dosyaları, veritabanı ve sunucu yapılandırması için mevcut yedeklerin gerçekten geri yüklenebilir olup olmadığını planlı bakımda test edin. İzleme sistemi kullanıyorsanız yalnızca ana sayfayı değil, kritik işlemleri ve farklı ağlardan erişimi de kapsayan uyarılar tasarlayın.

Kesintiyi erken fark etmek için uptime izleme ve alarm kurma yaklaşımını inceleyebilirsiniz. İzleme uç noktasını etkinleştirmek tek başına yeterli değildir; web sunucusunda bu uç noktaya güvenli erişim yolunu da tanımlamanız gerekir. Yönetim bilgisi döndüren bir sağlık uç noktasını herkese açık bırakmayın; erişimi kimlik doğrulama, IP kısıtlaması veya sınırlı yanıtla koruyun.

Sık Sorulan Sorular

Site yalnızca bazı ziyaretçilerde açılmıyorsa ne anlama gelir?

Farklı DNS yanıtları, IPv4 ve IPv6 yolları, CDN önbelleği veya bölgesel ağ sorunu olasıdır. Aynı URL’yi mobil veri ve sabit bağlantıda test edin; DNS kayıtlarını ve A/AAAA sonuçlarını karşılaştırın. Sorun yalnızca tek bir çözümleyicide görülüyorsa alan adı sağlayıcısına ilgili sorgu saatlerini iletin.

Sunucuyu hemen yeniden başlatmak doğru mudur?

Yeniden başlatma geçici kilitlenmeyi çözebilir, fakat logları ve çalışan işlemleri kaybetme riski taşır. Önce hata saatini, kaynak kullanımını ve kritik veri işlemlerini kaydedin; sağlayıcının önerdiği geri dönüş adımı yoksa bunu ilk seçenek yapmayın.

503 hatası her zaman hosting sağlayıcısından mı kaynaklanır?

Hayır. PHP-FPM havuzu, uygulama bakım modu, kaynak limiti, aşırı trafik veya web sunucusunun yapılandırması da 503 üretebilir. Yanıt kodunu ilgili saat aralığındaki web sunucusu ve uygulama loglarıyla eşleştirin. Yanıtın sabit bir bakım sayfasından mı, yoksa uygulamadan mı geldiğini de kontrol edin.

DNS değişikliğinin yayılmasını nasıl doğrularım?

Farklı ağlardan ve farklı DNS çözümleyiciler üzerinden sorgu yapın; ancak tek bir sorguyu kesin yayılım kanıtı kabul etmeyin. Eski ve yeni yanıtların ne kadar süre görülebileceği TTL ve önbellek davranışına bağlıdır. Yetkili DNS sunucusundaki kayıt ile istemcilerin aldığı yanıtı ayrı karşılaştırın.

Uygulanabilir son kontrol listesi

• Kesinti başlangıç saatini, etkilenen URL’leri, ağları ve hata kodlarını kaydedin.
• Mobil veri ve başka bir bağlantıdan erişimi karşılaştırın.
• A, AAAA ve gerekiyorsa CNAME kayıtlarını beklenen hedeflerle kıyaslayın.
• SSL sertifikasının alan adı ve geçerlilik tarihini doğrulayın.
• HTTP başlıklarını, web sunucusu loglarını ve PHP uygulama loglarını aynı zaman aralığında inceleyin.
• Veritabanı bağlantısını ve uygulama hatasını veri değiştirmeden test edin.
• PHP-FPM web işçilerini CLI cron ve kuyruk süreçlerinden ayrı değerlendirin.
• CPU, RAM, disk, I/O, PHP süreçleri ve veritabanı bağlantı limitlerini kontrol edin.
• Sağlayıcı duyurularını ve destek kanalını inceleyin.
• Tek bir dar değişiklik uygulayın, erişimi yeniden test edin ve işe yaramazsa geri alın.

Bu listeyi kontrol paneli, destek bilgileri, DNS kayıtları ve geri dönüş prosedürüyle birlikte erişilebilir bir olay müdahale belgesine dönüştürün. Bir sonraki bakım penceresinde de ana sayfa, yönetim paneli ve kritik işlem akışlarını izleyen testleri çalıştırın.