Sunucu çöktü: önce neye bakmalı ve hangi sırayla

Bu rehber sunucunun kendisiyle ilgilidir: sizin işlettiğiniz bir VPS, dedicated veya bulut sunucusu. Tek bir web sitesi başarısız oluyorsa ve makinedeki her şey çalışıyorsa ya da siteniz paylaşımlı hostingdeyse, bunun yerine Web sitesi çöktü: ne yapmalı rehberiyle başlayın. Burada makineye bakıyoruz: hiç yanıt veriyor mu, içeri girebiliyor musunuz ve ne durdu.

Adım 1: tam olarak ne çöktü?

"Sunucu çöktü" çok farklı üç şey anlamına gelebilir ve her birinin kendi çözümü vardır. Önce dışarıdan, sizin olmayan bir ağdan öğrenin. Sunucudaki web siteleri için web sitesi çökme kontrolü saniyeler içinde adın çözümlenip çözümlenmediğini, portun yanıt verip vermediğini ve hangi durum kodunun döndüğünü söyler. Makine için kendi bilgisayarınızdan ping ve bir port testi kullanın:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Sonuçları birlikte okuyun:

• Ping yok, SSH yok, web portu yok: makine kapalı, donmuş ya da önündeki ağ çökmüş. Adım 2'ye gidin.
• Ping yanıt veriyor, SSH vermiyor: makine çalışıyor, ama SSH engellenmiş, durmuş ya da sunucu yanıt veremeyecek kadar aşırı yüklü. Adım 3'e gidin.
• SSH çalışıyor, web sitesi çalışmıyor: sunucu iyi, bir hizmet değil. Adım 4'e gidin.

Bazı sunucular ping'i bilerek düşürür. Ping hiç çalışmadıysa port testlerine güvenin.

Adım 2: hiçbir şey yanıt vermiyor

Her şeyden önce sağlayıcınızın kontrol panelini veya bulut konsolunu açın. Üç soru çoğu durumu bir dakikada çözer:

1. Sunucu çalışıyor mu? Durdurulmuş bir örnek, askıya alınmış bir hesap veya başarısız bir ödeme, dışarıdan tam olarak bir kesinti gibi görünür.
2. Bilinen bir olay var mı? Sağlayıcının durum sayfasında bölgenizi veya veri merkezinizi kontrol edin.
3. Konsol ne gösteriyor? Web veya seri konsol, ağ olmasa bile makinenin ekranını gösterir. Bir kernel panic, döngüde "Out of memory: Killed process" veya bir dosya sistemi kontrolünde takılı kalan bir önyükleme, sorunun nerede olduğunu söyler.

Makine donmuşsa konsoldan yeniden başlatmak genellikle onu geri getirir. Yeniden başlatmadan önce konsolun ekran görüntüsünü alın: yeniden başladığında kanıt gider. Açılmıyorsa çoğu sağlayıcı, diski bağlayabileceğiniz, logları okuyabileceğiniz ve /etc/fstab veya bozuk bir ağ yapılandırmasını onarabileceğiniz bir kurtarma sistemi sunar.

Adım 3: ping yanıt veriyor, SSH vermiyor

Makine hayatta, yani neden onun üzerinde. Konsolu kullanarak oturum açın, sonra olağan şüphelileri kontrol edin:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Aceleyle eklenmiş bir güvenlik duvarı kuralı, birkaç yanlış paroladan sonra yasaklanan kendi IP adresiniz veya testi geçemeyen bir SSH yapılandırma değişikliği en yaygın kilitlerdir. Adresinizin yasağını sudo fail2ban-client set sshd unbanip YOUR_IP ile kaldırın ve SSH'ı yeniden başlatmadan önce her zaman sudo sshd -t çalıştırın. SSH çalışıyor ama çok yavaşsa sunucu aşırı yüklüdür: Adım 4'e gidin.

Adım 4: içerdesiniz, şimdi dört sayıyı okuyun

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Yük (uptime): CPU çekirdeği sayısının çok üzerindeyse makine aşırı yüklüdür. top veya htop hangi işlemin sorumlu olduğunu gösterir.
• Bellek (free -m): boş bellek ve swap yok, ayrıca dmesg içinde "Killed process" varsa, çekirdek hayatta kalmak için bir işlemi durdurmuştur. Genellikle veritabanı veya PHP'ydi.
• Disk (df -h): dolu bir disk sunucu sorunlarının en sık nedenidir. Veritabanları yazmayı bırakır, loglar durur, oturumlar başarısız olur. df -i inode'ları kontrol eder: milyonlarca küçük dosya tüm inode'ları tüketirse, gigabaytlarca boş yer olsa bile disk "dolu" olabilir.
• dmesg içinde G/Ç hataları veya salt okunur dosya sistemi: diskin kendisinde bir sorun var. Yazmayı durdurun, hâlâ yapabiliyorsanız bir yedek alın ve sağlayıcınızla iletişime geçin.

Yeri güvenle boşaltmak için sistem günlüğü ve eski arşivlerle başlayın:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Yer açmak için asla veritabanı dosyalarını veya web sitesi dosyalarını silmeyin.

Adım 5: hangi hizmet durdu ve neden

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed, bir hatayla durmuş her hizmeti listeler. O hizmetin günlüğü nedeni söyler: zaten kullanımda olan bir port, bir yapılandırma dosyasında söz dizimi hatası, eksik bir sertifika, yer kalmaması. Her yeniden başlatmadan önce yapılandırmayı test edin (nginx -t, apachectl configtest, php-fpm -t), sonra sudo systemctl restart SERVICE ile başlatın. Test olmadan yapılan bir yeniden başlatma, hâlâ yarı çalışan bir hizmeti çökertebilir.

Adım 6: ne değişti?

Kesintilerin nedenleri vardır ve neden genellikle son değişikliktir. Onu arayın:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Otomatik güncellemeler, yeniden başlatma bekleyen yeni bir çekirdek, bir dağıtım, diski yedeklerle dolduran bir cron işi, süresi dolmuş bir sertifika veya başkası tarafından yapılan bir yapılandırma düzenlemesi: bu satırlardan biri kesintinin başladığı zamanla örtüşüyorsa ipucunuz var demektir.

Aynı sunucu sorunları tekrar geldiğinde

Bir kez dolu bir disk veya durmuş bir veritabanı yüzünden çöken bir sunucu bunu yeniden yapacaktır. Dışarıdan kontrol, ne zaman çöktüğünü söyler; içeriden kontrol, önceden söyler. Sunucu ajanı yükü, belleği, diskleri ve hizmetleri makinenin içinden bildirir ve bir disk eşiğinizi aştığında veya işaretlediğiniz bir hizmet durduğunda, hâlâ harekete geçmek için zaman varken sizi uyarır. Ajanlı sunucu izleme ücretli planların parçasıdır.

Bunu gece 3'te yapmak istemiyorsanız

Sunucunuz çöktüyse ve kendiniz hata ayıklamak yerine onarılmasını tercih ediyorsanız, bir Quick Fix yaygın nedenleri sabit fiyatla çözer: durmuş bir hizmeti yapılandırma testi geçtikten sonra yeniden başlatır, dolu bir diski boşaltır ve süresi dolmuş bir sertifikayı yeniler; önce yedek alarak. Bu yetmediğinde bir Deep Fix günün her saatinde devralır, 15 dakikalık bloklar hâlinde faturalanır ve fiyat sipariş vermeden önce gösterilir. İkisi de Responder, root olarak SSH veya hosting alanınıza SSH erişimi üzerinden çalışır. Ayrıntılar sunucu çöktü onarımı ve acil sunucu desteği sayfasında.