Ruzgar
New member
bu aşağıdakini geliştiri misin dahada kotrol altında tutmak için kurallar ekleyelim araştır düşün kuralları dahada geliştir . Aşağıda sunucuda anlık kaynak eşiğine (CPU / RAM / I/O / Network) göre adım adım, insan gibi hareket eden bir “operasyon talimatı” var. Her adımda kesin kural: veri kaybı yok, cache hariç hiçbir şey silinmez, işlem sırasında bağlantı koparsa tekrar bağlan ve kaldığın yerden devam et. Her adımda çıktıları ~/ops-logs/ içine kaydet (komut örnekleri verildi). Bu talimat bir insan işletim mühendisine verilecek şekilde yazıldı — bir bota doğrudan uygulanabilir mantıkla, ama anlatım insan odaklı. Genel kurallar (özet) Her adımı yaptığında çıktı al: command > ~/ops-logs/YYMMDD-HHMM-<kısa-ad>.log 2>&1 Kritik süreçleri öldürmeden önce PID’in neye ait olduğunu doğrula (ps -p <PID> -o pid,user,comm,%cpu,%mem,etime). Kritik servisleri öldürme yasağı: systemd, sshd, init, mysqld (harici onay olmadan), nginx/httpd (son çare hariç). PHP-FPM, uygulama scriptleri vb. öldürülebilir. Her müdahaleden sonra 5 dakika bekle ve aynı ölçümü yeniden yap; aynı durum devam ederse bir sonraki adımı uygula. Her 3 müdahalede bir (veya kritik durumdaysa her müdahalede) Slack/Teams/e-posta ile durumu bildir (kime, hangi kanalda). Bağlantı koparsa: tekrar SSH bağlan, son log dosyasını kontrol et (tail -n 200 ~/ops-logs/*.log | tail -n 200) ve devam et. Ölçümler — anlık durum alma (her kontrol döngüsünde çalıştır) date > ~/ops-logs/check-$(date +%s).log top -b -n1 -o %CPU | head -n 25 >> ~/ops-logs/check-$(date +%s).log top -b -n1 -o %MEM | head -n 25 >> ~/ops-logs/check-$(date +%s).log free -h >> ~/ops-logs/check-$(date +%s).log vmstat 1 5 >> ~/ops-logs/check-$(date +%s).log iostat -x 1 3 >> ~/ops-logs/check-$(date +%s).log # (iostat varsa) ss -tanp | head -n 80 >> ~/ops-logs/check-$(date +%s).log netstat -ntu | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 20 >> ~/ops-logs/check-$(date +%s).log CPU politikası (adım adım) A) CPU % < 80 Yapma — yalnızca izle. 1 dakikada bir ölçüm. B) CPU % ≥ 80 ve < 90 (uyarı seviyesi) top -b -n1 -o %CPU | head -n 20 ile ilk 5 süreci not al. Eğer ilk 1–3 işlem uygulama (php, python, node) ise: PHP-FPM havuzlarını reload et: systemctl reload plesk-php83-fpm >> ~/ops-logs/reload-php-$(date +%s).log 2>&1 Apache/Nginx reload: systemctl reload nginx systemctl reload httpd Ağır cron/job varsa (son çalıştırılanlar /var/log/cron), cron’u geçici durdurma (sadece takip et, durdurmak için yöneticinin onayı): systemctl stop crond (ONAYLA). Bekle 5 dakika; yeniden ölç. Eğer % <85 ise normal moda dön. C) CPU % ≥ 90 ve < 95 (kritik — müdahale) top -o %CPU al, en yüksek CPU kullanan PID’yi doğrula: ps -p <PID> -o pid,user,comm,%cpu,%mem,etime Eğer PID kritik bir sistem servisine ait değilse (bak kurala), hızlıca öldür: kill -9 <PID> >> ~/ops-logs/kill-<PID>-$(date +%s).log 2>&1 PHP-FPM yeniden başlat: systemctl restart plesk-php83-fpm >> ~/ops-logs/restart-php-$(date +%s).log 2>&1 MySQL işlem kilitleri kontrolü: mysqladmin processlist > ~/ops-logs/mysql-processlist-$(date +%s).log Uzun sorgu varsa ilgili sorgu sahibini mysqladmin kill <id>. Bekle 5 dakika, tekrar ölç. Eğer düzelmediyse C adımını tekrarla 1 kere. D) CPU % ≥ 95 ve < 98 (acil) Tüm PHP-FPM havuzlarını ondemand modu ve düşük max_children ile sınırla (önce backup al): Örnek: /opt/plesk/php/8.3/etc/php-fpm.d/*.conf dosyalarının yedeğini al: cp -a /opt/plesk/php/8.3/etc/php-fpm.d /root/php-fpm-d-backup-$(date +%s) Her havuz için pm = ondemand, pm.max_children = 2 değerini uygula (önce önemli havuzlar). (Bu işlem manuel veya düzenli script ile yapılır.) systemctl restart plesk-php83-fpm Eğer kaynak bir IP’den yoğun ise geçici engelle: netstat -ntu | awk '{print $5}' | sort | uniq -c | sort -nr | head iptables -I INPUT 1 -s <IP> -j DROP Bekle 5 dakika, tekrar ölç. E) CPU ≥ 98 (kritik — son çare) Tekrar doğrula ölçümlerde; SSH çok yavaşsa bile bağlanmaya çalış. Kritikleri kapat: ağır, non-kritik süreçleri öldür (örn. uygulama worker lar). Eğer halen düzelmiyorsa ve SSH tepki veriyorsa sunucuyu yeniden başlat (önce tüm logları topla): sync; sleep 2 shutdown -r +1 "Emergency reboot due to sustained CPU >98%" Reboot öncesi veritabanı tam yedekleme mümkün değilse yeniden başlat riskini kabul et (kısa downtime). Reboot sonrası hızlı kontrol: top, free -h, systemctl status plesk-php83-fpm. RAM politikası (adım adım) A) RAM % < 70 İzle. B) RAM ≥ 70 ve < 85 (uyarı) top -o %MEM ile en çok RAM yiyeni not et. PHP-FPM reload: systemctl reload plesk-php83-fpm Swap kullanımını kontrol et: swapon --show veya free -h. Bekle 5 dakika, tekrar kontrol. C) RAM ≥ 85 ve < 92 (kritik) Bellek tüketen PID’yi doğrula: ps aux --sort=-%mem | head -n 20 ps -p <PID> -o pid,user,comm,%cpu,%mem,etime,args Eğer CPU/RAM’i birlikte yiyorsa o süreci öldür: kill -9 <PID> (kritik servis değilse). Swap sıfırlama (eğer swap çok dolu ve IO sıkışması yoksa): swapoff -a && swapon -a Eğer bellek cache sıkışı ise (uygulamalara zarar vermeden) temizle: sync; echo 3 > /proc/sys/vm/drop_caches Bekle 5 dakika; tekrar ölç. D) RAM ≥ 92 ve < 98 (acil) Tüm PHP-FPM havuzlarını hızlı azalt (ondemand + düşük max_children) ve restart et: systemctl restart plesk-php83-fpm Uzun yaşayan arka plan işleri (örn. büyük import, backup) tespit et ve durdur (onayla). Eğer swap ve OOM mesajları geliyorsa (dmesg | tail -n 50), OOM tarafından öldürülen süreçleri incele. E) RAM ≥ 98 (kritik — son çare) Kritik olmayan süreçleri sırayla öldür (listele, not al, sonra ölür): for pid in $(ps aux --sort=-%mem | awk 'NR>1 {print $2}' | tail -n +6); do echo $pid; done (Bu komut ile manuel seçip öldüreceksin; otomatik öldürme tehlikelidir.) Hâlâ düzelmiyorsa sunucuyu reboot et (uyarı ve onay ile). Disk I/O politikası (adım adım) A) I/O < 70% — izle. B) I/O ≥ 70 ve < 90 iotop -o ile hangi PID disk I/O yapıyor. Ağır process tespit edilirse yeniden başlat veya öldür (ilk tercihin servis restart): systemctl restart plesk-php83-fpm systemctl restart mariadb Log dökümü kontrolü: du -sh /var/log/* | sort -hr | head -n 20 Gereksiz devasa logları silme; önce archive yap: cp /var/log/huge.log /root/huge.log.bak && : > /var/log/huge.log (logrotate tercih edilir). C) I/O ≥ 90 (kritik) Ağır PID’i durdur (önce ps doğrula), sonra servis restart. 5 dakika bekle; tekrar ölç. Eğer SSD/FS problemlerse dmesg kontrolü. Network / DDoS politikası (adım adım) netstat -ntu | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50 → yoğun IP’leri al. ss -s ve iftop ile bandwidth tüketimi doğrula. İlk adım: Cloudflare varsa bu saldırıyı Cloudflare üzerinden mitigasyon (challenge, rate-limit) uygula. Geçici IP engelleme (salt okunur liste, 1–2 saat): iptables -I INPUT 1 -s <IP> -j DROP 5 dakika bekle; eğer saldırı devam ediyorsa bant genişliği azaltmaya yönelik rate-limit kuralları uygula veya upstream sağlayıcıyla iletişime geç. MySQL politika (adım adım) mysql -e "show processlistG" — uzun sorguları tespit et. Uzun sorguyu öldür: mysql -e "kill <Id>" mysqladmin status ile genel durum. Eğer MySQL kendini toparlamıyorsa: systemctl restart mariadb (restart aktif bağlantıları keser, veri kaybı olmaz). 5 dakika bekle; tekrar kontrol. Kayıt tutma & raporlama Her müdahaleyi kısa bir notla ~/ops-logs/actions.log içine yaz: echo "$(date) | ACTION | <kısa-açıklama> | <komut> | çıktı dosyası" >> ~/ops-logs/actions.log Her 15 dakikada bir check dosyalarını topla ve Slack/Teams’e gönder (otomasyon veya manuel). Örnek gerçek akış (CPU yükseldiğinde insanın adım adım yapacağı) Ölç: top -b -n1 -o %CPU → CPU %92. İncele: ps -p 2345 -o pid,user,comm,%cpu,%mem,etime,args → PID 2345 PHP-FPM child, %CPU 78. Kill: kill -9 2345 → logla. Reload PHP-FPM: systemctl reload plesk-php83-fpm. Log kontrolü: tail -n 200 /var/log/plesk-php83-fpm/error.log → OOM tekrar var mı? Bekle 5 dk, tekrar ölç. Eğer %92→%60 düştüyse işi tamamla ve raporla. Eğer hala yüksekse bir üst adımı uygula (havuz limitlerini azalt). Son notlar (kritik uyarılar) kill -9 kullanırken dikkat: işlem anlık veritabanı bağlantısı tutuyorsa sorgu yarıda kesilir; veri kaybına sebep olabilir — kritik veritabanı işlemleri için önce mysqladmin processlist ile sorguyu durdurmak tercih edilir. swapoff -a işlemi IO’yu tetikleyebilir; zaten I/O yüksekse dikkatli ol. Sunucu reboot son çaredir; reboot öncesi tüm logları topla. Her müdahaleden sonra 5 dakika bekle ve aynı ölçümü tekrarla; sabırlı ol. Bu adım-adım yönergeyi doğrudan bir personele ver veya bir otomasyon motoruna (bot) çevirirken her adımın “do / log / wait / recheck / escalate” döngüsünü uygulayacak şekilde kurgula. Ġhtiyaç varsa bunu doğrudan çalıştırılabilir bir kontrol listesi veya bash pseudo-script hâline dönüştüreceğim.