Production Ortamında Gerçekten Kullandığım 15 Linux Terminal Komutu

Bunlar production operasyonlarında her gün gerçekten kullandığım 15 Linux terminal komutu. Kitaplardan ezberlenmiş bilgiler değil — bunlar kesintilerde, kapasite kontrollerinde ve gece yarısı bir şeyler yanıp tutuşurken beni ayakta tutan komutlar. Linux sysadmin veya DevOps mühendisi olarak çalışıyorsan, sürekli bu komutlara uzanacaksın.

Ortamımda Linux sunucuları, Windows Server, load balancer'lar ve CDN altyapısı bir arada çalışıyor. Günüm genelde tüm fleet üzerinde hızlı bir health check ile başlar ve bu komutlar o iş akışının belkemiğini oluşturur. Gel sana bunları ne için kullandığıma göre gruplayarak anlatayım.

Hızlı Sunucu Sağlığı ve Kaynak Kontrolleri

Biri "sunucu yavaş" dediğinde tahmin etmem — kontrol ederim. İlk hamlelerim bunlar.

htop benim top yerine tercih ettiğim araç. Süreçleri, CPU'yu, belleği ve load average'i renkli ve kaydırılabilir bir görünümle veriyor. Herhangi bir sütuna göre sıralayabiliyorum ve arayüzden direkt sorunlu PID'leri kill edebiliyorum. htop kurulu değilse, yeni bir kutuya ilk iş olarak onu kurarım.

df -h disk kullanımını insanın okuyabileceği formatta gösterir. Inode tükenmesinden şüphelendiğimde df -i ile birlikte kullanırım — özellikle mail sunucularında veya milyonlarca küçük dosya barındıran sistemlerde. Inode'lar, disk alanından önce tükenir ve insanlar bunu beklediklerinden daha sık yaşar.

free -m hızlı bir bellek görüntüsü verir. Sadece kullanılan değil, available belleğe bakarım. Modern Linux çekirdeklerinde cache geri kazanılabilir, yani düşük "free" bellek gösteren bir sunucu illa sorunlu demek değildir.

uptime, load average'i ve kutunun ne kadar süredir çalıştığını kontrol etmenin en hızlı yolu. 4 çekirdekli bir makinede load değerini 32 olarak görüyorsam, htop açmadan önce başım belada biliyorum.

Her Gün Başvurduğum Ağ Troubleshooting Komutları

Ağ sorunları muhtemelen uğraştığım işlerin %40'ı. Bu komutlar bana saatler kazandırıyor.

ss -tulpn yıllar önce netstat'ın yerini aldı ve daha hızlı. Hangi portlarda ne dinleniyor ve o socket'in sahibi hangi süreç onu görmek için kullanıyorum. Çıktısı temiz ve anlık.

ss -tulpn | grep :443

Bu tek satırlık komut bana nginx veya apache'nin gerçekten 443'e bindiğini ya da başka bir şeyin o portu ele geçirip geçirmediğini söyler.

curl -I tarayıcı açmadan HTTP yanıtlarını doğrulama yöntemim. Load balancer'ları yeniden yapılandırırken veya CDN davranışını kontrol ederken sürekli kullanırım:

curl -I https://example.com

dig benim DNS silahım. dig +short example.com bana sadece cevabı verir. dig @8.8.8.8 example.com ile belirli bir resolver'a sorgu atabiliyorum. DNS değişiklikleri yayılmadığında, sorunun tam olarak nerede olduğunu söyler.

mtr, ping ve traceroute'u canlı ve güncellenen tek bir görünüme birleştirir. Kullanıcılar belirli bir uç noktaya gecikme yaşadıklarında 100 paketlik bir rapor için mtr -rwc 100 remote-host çalıştırırım. traceroute'un tek başına yapamadığı şekilde hop başına paket kaybını gösterir.

Baskı Altında Süreç ve Log İncelemesi

Gece 2'de bir şey bozulduğunda, bu komutlar suçluyu hızlı bulmamı sağlar.

journalctl -u servicename --since "1 hour ago" /var/log içinde eşelemek zorunda kalmadan systemd servis loglarını okuma yöntemim. Tek komutla tail, filtreleme ve zaman sınırı koyabiliyorum:

journalctl -u nginx --since "30 min ago" --no-pager | tail -50

grep -rn config'lerde arama yapma yöntemim. -r dizinleri özyinelemeli gezer, -n satır numaralarını gösterir. 20 nginx config'i arasında yanlış upstream tanımlanmış config dosyasını bulmam gerektiğinde çalıştırdığım komut budur:

grep -rn "proxy_pass" /etc/nginx/

tail -f /var/log/syslog klasiktir ama ben genelde tail -F kullanırım — büyük F log rotation'ı yönetir, yani izlerken dosya rotate olursa yeni dosyayı takip etmeye devam eder. Küçük detay ama uzun bir incident sırasında büyük fark yaratır.

Dosya Transferi ve Hızlı Düzenlemeler

rsync'in yeri doldurulamaz. Yedekler, migrasyonlar ve sunucular arası config dizinlerini senkronize etmek için kullanıyorum. En çok kullandığım flag'ler:

• -a — archive modu, yetkileri, sahipliği ve symlink'leri korur
• -v — verbose çıktı
• -z — transfer sırasında sıkıştırma yapar
• --dry-run — önce simüle et, production'a dokunmadan önce her zaman

rsync -avz --dry-run /var/www/ user@remote:/var/www/

Dry run doğru görünüyorsa --dry-run'ı çıkarıp gerçekten çalıştırırım. Bu alışkanlık beni production verisini ezelden sayamayacağım kadar çok kez kurtardı.

vim benim editörüm. Göz alıcı değil ama dokunduğum her sunucuda bulunur. .vimrc'mi minimal tutarım — satır numaraları, syntax highlighting ve 4 boşluklu tab. Hiç girmediğim bir kutuda hızlı bir config değişikliği yapmam gerektiğinde vim'in orada olduğunu bilirim.

Güvenlik ve Erişim Denetimi

last bana son giriş geçmişini gösterir. Bir güvenlik endişesini araştırırken veya bir kutuya kimin eriştiğini doğrularken başladığım yer burasıdır. last -a kaynak IP'yi de içerir, asıl ihtiyacım olan da budur.

find / -perm -4000 -type f 2>/dev/null SUID binary'lerini listeler. Olmaması gereken beklenmedik SUID dosyalarını tespit etmek için periyodik olarak çalıştırırım. Bir saldırgan SUID root shell bırakırsa, bu komut onu bulur.

Bu Komutlarla Günlük İş Akışım

Bunların gerçek bir senaryoda nasıl bir araya geldiğine bakalım. Bir web sunucusunun yavaş yanıt verdiğine dair bir alert aldığımı varsayalım.

1. ssh ile gir, uptime çalıştır — load average'i kontrol et
2. htop — CPU'yu sömüren süreci bul
3. ss -tulpn | grep :443 — nginx'in hala dinlediğini doğrula
4. journalctl -u nginx --since "10 min ago" — hataları kontrol et
5. tail -F /var/log/nginx/access.log — canlı trafik paternlerini izle
6. curl -I http://localhost — yerel yanıtı test et

Bu sıralama yaklaşık iki dakika sürer ve sorunu genelde ya kontrolden çıkmış bir süreç, ya config sorunu ya da upstream bağımlılığı olarak daraltır. Önceki yazılarımda da belirttiğim gibi, tekrarlanabilir bir tanı sıralamasına sahip olmak, ezoterik flag'leri ezberlemekten daha önemli.

Son Düşünceler

Bu 15 komut egzotik değil. İş atları. Production'da, baskı altında, bir şeyin hemen düzeltilmesi gerektiğinde gerçekte yazdığın komutlar bunlar. Kendi ops araç setini oluşturuyorsan, buradan başla — daha şık alternatiflerin peşinden koşmadan önce bunlara hakim ol.

İpucu: Uzun olanlar için alias oluştur. Yönettiğim her sunucudaki .bashrc'de alias jctail='journalctl -u $1 --since "1 hour ago" --no-pager | tail -50" satırım var.

Kapak görseli: personalgraphic.official · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/198895458@N04/53097628210