Müşteri arızası geldiğinde ilk on dakika

Yanımdakilerden biri şunu söyledi: "Sunucuyu açtığında anla, ne kadardır orada." Yani karar vermeden önce veri topla.

Aşağıdaki sıra, birkaç gerçek arızada yanımdakilerin izlediği yolun özetidir. Sıralamanın kendisi önemli; ilk adımda yanlış yere bakarsan kalan on dakika işe yaramaz.

KONTROL: Bu adımların hepsini sen mi yaptın, yoksa yanında izlerken mi yazdın? "Yanımda izledim" dersen ilk adımı senin yaptığın gibi yazmak yanlış olur.

0. Yeniden başlatma

İlk kural ve tek yazılması gereken kural: ilk olarak yeniden başlatma.

Kulağa ters geliyor. Çünkü çoğu arıza yeniden başlatınca geçiyor. Geçiyor olması sebebin düzeldiği anlamına gelmiyor — sadece belirti kayboluyor.

Yeniden başlattığında kaybolan şeyler:

Sunucunun neden o duruma düştüğüne dair loglar
Disk, bellek ve ağ durumu
Çöken servislerin son hata mesajları
Kimin, ne zaman, ne değiştirdiği bilgisi

On dakikan varsa önce kanıt topla, sonra düşün. Kanıt toplamak yeniden başlatmaktan hızlıdır.

1. Kapsamı belirle: bir şey mi, her şey mi?

İlk soru teknik değil. Müşteri ne diyor, sen ne görüyorsun?

"Site açılmıyor" → ağ mı, disk mi, DNS mi?
"Yavaş" → tek bir istek mi yavaş, her şey mi yavaş?
Aynı binadaki başka insanlar da etkileniyor mu?

Bu sonuncusu en değerli soru. Çünkü tek sunucuysa sunucuda, birden fazlaysa ağda ya da yerel sebeptedir. On dakikanı yarıya indiriyor.

Sonra kendi makinenden dene:

ping sunucu
ss -tulpn | grep -E ':(80|443|22)\b'

Sunucuya ulaşabiliyorsan ve 80/443 dinlenmiyorsa sorun ağ değil, sunucuda.

2. Fiziksel katman: gerçekten açık mı

Sanal makinede güç kablosunu kontrol etmezsin. Fiziksel sunucuda kontrol edersin.

Güç ışığı yanıyor mu
Disk hareket ışığı yanıp sönüyor mu (sürekli yanık da, hiç yanmaması da)
Fan dönüyor mu

Işıklar yanıyorsa sunucu açık demektir, o anlamda değil. Işıklar yanıyor ama disk ışığı yanmıyorsa disk sürücüde sorun olabilir.

KONTROL: Sunucu odasına bir kez girdin mi gerçekten? Yazı fiziksel katmanla başlıyorsa girdin demektir. Girmediysen bu adımı "ekibi ararız" diye yeniden yaz.

3. Açılıştan beri ne olmuş

Sunucu yeni açılmışsa, asıl soru "son bir saatte ne oldu".

uptime                      # ne kadar açık kalmış
systemctl --failed          # başarısız durmuş servisler
journalctl -p err -b        # BU açılıştan beri hatalar
journalctl -p err --since "2 hours ago"

uptime'ın çıktısında üç sayı var ve en çok ilgilendiğin şey sonuncusu: ortalama yük. Bunu çekirdek sayısıyla karşılaştır.

Çekirdek 4, yük 0.5 → rahat
Çekirdek 4, yük 12 → aşırı yüklü, kuyruk oluşuyor demektir

Çekirdek sayısını unutma, karşılaştırma olmadan bu sayının anlamı yok:

nproc

4. Disk — sessiz katil

Disk dolu bir sunucu kendini söylemez. Söyleyemez, çünkü log yazacak yer kalmamış olabilir.

df -h                  # alan doluluğu
df -i                  # inode doluluğu — gözden kaçar

df -i ayrı çünkü dosya sayısı bitmiş olabilirken alan bol görünebilir. Bu, uzun süre açık kalan bir sunucuda gerçekten oluyor.

Loglar nereye gitti diye bak:

du -sh /var/log/* | sort -h | tail
journalctl --disk-usage

5. Bellek — çekirdek sıfırlamış mı

free -m
journalctl -k | grep -i "killed process"

İkinci komut altın değerinde. Bellek tükenince Linux süreçleri seçer ve öldürür. Bu genelde en gürültülü süreç olur ve dışarıya bakınca "kaynak yok" gibi görünür.

dmesg içinde "Out of memory" veya "oom-kill" varsa sebebi bulmuşsun demektir.

6. Ağ — port dinleniyor mu

ss -tulpn | grep 8080

Bir şey "açık" görünüyor ama port dinlenmiyorsa, servis çalışmıyor demektir. Duyduğun "site açılmıyor" cümlesi aslında "servis ayakta değil" demektir ve bu ikisi aynı şey değil.

7. Ne değişti

En çok işe yarayan ve en çok atlanan adım: kimin ne zaman ne değiştirdiğini bulmak.

last                        # kim bağlanmış
history | tail -50          # kimin ne yaptığı (aktif oturumda)
ls -lt /etc/                # yapılandırma dosyaları ne zaman değişmiş
cat /var/log/apt/history.log    # paket ne zaman kurulmuş
crontab -l                  # zamanlanmış iş

Sunucu dün çalışıyorsa ve bugün çalışmıyorsa, bir şey değişti. ls -lt /etc/ tek komutla bunu gösterir: dün akşam /etc/hosts değişmişse sebebi bulunmuşsun demektir.

KONTROL: Gerçekten bu komutlardan birini yakaladın mı, yoksa listede "olabilirdi" mi yazıyor? İlk ikisini gerçekten yaptıysan buraya somut bir örnek koy — hangi dosya, ne zaman. O yazıyı iki kat değerli kılar.

8. Sertifika — ağ arızası gibi görünür

Bunu ayrı yazıyorum çünkü en çok yanıltan şey bu: süresi dolmuş bir TLS sertifikası, ağ arızası gibi görünür.

Kullanıcı "bağlanamıyorum" der, sen ağa bakarsın, ağ gayet iyidir. Aslında tarayıcı sertifikayı reddediyor.

Kontrol:

openssl s_client -connect site:443 -servername site </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

Son tarih geçmiş mi bak. Let's Encrypt sertifikaları 90 gün geçerli ve sürekli yenilenir. Yenileme çalışmıyorsa 90 gün sonra site kendiliğinden kapanır.

Zamanında yetişmezsen

Bazen on dakika yetmez, müşteri acele ediyor, sen de yeniden başlatmak zorunda kalırsın. O zaman bile önce bir şeyleri kaydet:

journalctl -b > /tmp/oncesi.txt
df -h > /tmp/oncesi-df.txt

Sonra yeniden başlat. Kaybettiğin şey az olur.

Bu yazının asıl mesajı

Tek cümle: önce ölç, sonra dokun. Dokunmadan önce toplayabildiğin her bilgi, sonradan geri getirebileceğin her şeyden değerli.

Aynı şeyi bir önceki yazıda "önce oku, sonra yap" diye duymuştum. Şimdi anladım neden o kadar tekrar ediliyor: yazılım dünyasında her komut geri alınabilir, fiziksel sunucuda her hamle kalıcı.