Menguasai Runbook SRE Linux: Panduan Praktikal Menyelesaikan Masalah Pengeluaran

Senario

Organisasi anda menjalankan kluster Kubernetes pengeluaran pada nod berasaskan Linux. SRE yang bertugas menerima amaran untuk peningkatan latensi dalam respons aplikasi dan sekali-sekala ralat HTTP 503. Kluster menggunakan pelbagai nod pekerja, tetapi satu nod menunjukkan beban purata yang tinggi. Kesan perniagaan amat ketara pada waktu puncak.

Simptom

• Masa respons p95 aplikasi meningkat dari 300ms ke lebih 2s.
• kubectl top nodes menunjukkan penggunaan CPU/memori yang tinggi pada satu nod.
• Pengguna melaporkan gangguan masa.
• Purata beban nod (1 minit) melebihi bilangan teras CPU.
• dmesg mendedahkan peristiwa OOM (Kehabisan Memori) atau amaran I/O cakera.

Diagnosis

Mulakan dari pandangan peringkat tinggi dan sempitkan. Gunakan arahan Linux ini untuk mengumpul bukti.

1. Semak Beban Keseluruhan Sistem

uptime memberikan purata beban untuk 1, 5, dan 15 minit. Purata 1 minit yang jauh lebih tinggi daripada 15 minit menunjukkan lonjakan baru-baru ini.

top -b -n 1 menunjukkan proses yang diisih mengikut penggunaan CPU. Perhatikan wa (tunggu I/O) dan st (masa curi).

2. Analisis CPU dan Memori

vmstat 1 5 melaporkan aktiviti proses, memori, paging, blok I/O, perangkap, dan CPU. Lihat r (proses boleh laksana), b (proses tersekat), si, so (swap masuk/keluar), us, sy, id, wa.

free -m menunjukkan penggunaan memori. Periksa ruang memori rendah dan penggunaan swap yang tinggi.

ps aux --sort=-%mem | head -20 mengenal pasti pengguna memori teratas.

3. Periksa I/O Cakera

iostat -x 1 melaporkan penggunaan cakera, tunggu I/O, dan panjang barisan. %util tinggi atau await tinggi menunjukkan kesesakan cakera.

df -h memeriksa ruang sistem fail; cakera penuh menyebabkan kegagalan aplikasi.

4. Semak Log Sistem

dmesg -T | tail -30 menunjukkan mesej kernel, termasuk peristiwa pembunuh OOM, ralat perkakasan, atau isu sistem fail.

journalctl -u kubelet --since "1 jam lalu" menyerlahkan masalah kubelet (contohnya, kegagalan mount volume, status nod berubah-ubah).

5. Semak Kesihatan Nod Kubernetes

kubectl describe node <nama-nod> mendedahkan keadaan seperti MemoryPressure, DiskPressure, PIDPressure. Juga menunjukkan isu runtime kontena.

kubectl get events --sort-by='.lastTimestamp' memaparkan peristiwa kluster terkini.

Kawalan Risiko

• Semua arahan di atas adalah read-only dan selamat untuk pengeluaran.
• Jangan jalankan stress atau sysbench pada nod pengeluaran tanpa kelulusan jelas.
• Elakkan kill -9 pada proses kritikal; gunakan systemctl restart hanya selepas mengesahkan proses bukan punca.
• Sebelum membuat perubahan konfigurasi, simpan tetapan semasa (contohnya, sysctl -a > /tmp/sysctl.bak).

Pembalikan

• Jika anda melaraskan parameter kernel (contohnya, sysctl -w vm.swappiness=10), pulihkan dengan sysctl -p /etc/sysctl.conf atau reboot.
• Jika anda mengubah label atau taint nod Kubernetes, balikkan segera menggunakan kubectl label node <nama> <kunci>- atau kubectl taint node <nama> <kunci>-.
• Jika anda memulakan semula kubelet, pantau; jika gagal, gunakan systemctl status kubelet untuk melihat ralat dan kembalikan fail yang diubah.

Pengesahan

Selepas menggunakan pembaikan, jalankan semula arahan utama:

• uptime sepatutnya menunjukkan purata beban menurun.
• vmstat sepatutnya menunjukkan wa rendah dan banyak CPU idle.
• Latensi p95 aplikasi patut kembali ke aras asas.
• kubectl get nodes menunjukkan semua nod dalam status Ready.

Bila Perlu Hantar Tiket ke OpsGlobal

Hubungi OpsGlobal apabila: - Isu berterusan selepas anda menjalankan langkah asas. - Anda memerlukan liputan 24/7 untuk pemerhatian berterusan. - Punca utama melebihi kepakaran Linux atau Kubernetes pasukan anda. - Anda memerlukan pendapat kedua bebas tentang perubahan yang menjejaskan prestasi.

Pasukan SRE kami boleh mengambil alih penyelesaian masalah, memohon pembaikan cepat, dan menyediakan postmortem terperinci.