Saat deployment baru berjalan, tim DevOps perlu jawaban cepat terhadap pertanyaan: apakah sistem tetap responsif dan sumber daya terpakai wajar? htop/top memberikan jawaban real-time dengan metrik CPU, memori, load, dan thread. Dengan fokus pada deployment dan rollback, artikel ini langsung menjelaskan cara mengamati anomali dari perubahan baru tanpa perlu alat kompleks.

Berikut saya jelaskan konteks tantangan deployment, cara membaca metrik utama, contoh perintah serta skrip ringan, checklist observasi, hingga langkah postmortem dan pencegahan.

Konteks Tantangan Deployment dan Rollback

Deployment modern sering berlangsung secara rolling update atau blue-green. Tujuannya menjaga layanan terus berjalan sambil mengaktifkan versi baru. Tantangan utamanya adalah mendeteksi dampak performa sejak awal, lalu memutuskan rollback jika terjadi degradasi. Di sinilah htop/top jadi alat ringan untuk memantau container atau VM tanpa perlu agent khusus.

Saat merilis update, tiga risiko utama terdeteksi cepat dengan htop/top:

  • Overload CPU pada subset instance yang sedang menerima trafik baru.
  • Spike memori akibat kebocoran resource atau alokasi terlalu besar.
  • Thread dan load average yang naik drastis menandakan blocking atau antrean I/O.

Menggunakan alat ini saat deployment membantu tim menilai apakah rollback perlu dipicu segera atau cukup menunggu stabilisasi.

Interpretasi Metrik htop/top untuk Deteksi Anomali

CPU dan Load Average

htop/top menunjukkan persentase penggunaan CPU per core dan load average. Perhatikan kombinasi berikut selama rollout:

  • CPU rata-rata di atas 80% pada seluruh core disertai load average yang naik berarti request baru tidak cepat selesai; bisa jadi rollback lebih aman.
  • Jika hanya satu core tinggi lalu load average relatif rendah, kemungkinan task single-threaded yang tidak kritikal.

Aturan sederhana: bandingkan load average dengan jumlah CPU. Load 2 pada 4 core masih wajar; load 6 menunjukkan antrean menumpuk.

Memori dan Swap

Memori yang mendekati 100% bersama swap aktif menandakan kemungkinan kebocoran atau kebutuhan konfigurasi heap. Dengan htop Anda melihat bar memori dan swap langsung, sementara top memberikan baris singkat. Jika memori meningkat linear selama rollout, monitore snapshot heap atau limit container.

Threads dan Per-Proses Behavior

htop memudahkan melihat proses mana yang punya banyak thread. Saat deployment, jika versi baru menciptakan puluhan thread per worker, pemeriksaan stack trace atau thread pool perlu dilakukan. Gunakan kolom THREAD di htop atau kombinasi top -H -p PID untuk inspeksi lebih lanjut.

Perintah dan Skrip Ringan untuk Observasi

Alias dan Watch

Tambahkan alias untuk mempermudah pemanggilan:

alias topdeploy='top -b -n 1 | head -n 20'
alias htopdeploy='htop -d 10'

Gunakan watch untuk melihat perubahan dari waktu ke waktu tanpa perlu refresh manual.

watch -n 5 'ps --sort=-%cpu -eo pid,ppid,cmd,%cpu,%mem | head'

Perintah ini membantu menyorot proses paling berat setiap 5 detik. Kombinasikan dengan script sederhana yang mengirim alert email/slack bila CPU atau memori melewati batas.

Integrasi Alert Sederhana

Buat skrip bash ringan:

#!/bin/bash
CPU=$(top -b -n1 | awk '/Cpu/ {print $2+$4+$6}')
MEM=$(free -m | awk '/Mem/ {print $3/$2 * 100}')
if (( $(echo "$CPU > 85" | bc -l) )) || (( $(echo "$MEM > 90" | bc -l) )); then
  echo "Alert: resource tinggi" | mail -s "htop alert" [email protected]
fi

Jalankan skrip ini lewat cron atau CI/CD pipeline hooks setelah deployment stage. Jika alert muncul, langsung buka htop/top untuk verifikasi proses terkait.

Checklist Observasi Deployment

  1. Sebelum rilis: pastikan baseline CPU, memori, load tercatat (screenshot htop/top). Simpan trigger threshold.
  2. Saat rollout: pantau per-node dengan htop/top 5 detik sekali, perhatikan proses baru, cari load spike sesudah traffic dialihkan.
  3. Setelah release: pastikan load average kembali ke baseline, swap tidak aktif, dan aplikasi baru tidak memakan thread/handle tinggi.

Gunakan checklist ini di runbook deployment agar setiap engineer tahu kapan harus memicu rollback.

Postmortem Ringan dan Tindakan Pencegahan

Jika rollback terjadi, catat metrik htop/top yang mencatat anomali: apakah CPU naik bersamaan dengan load? Apakah thread baru muncul? Gunakan informasi ini untuk memperbarui runbook.

Tindakan pencegahan konkret:

  • Buat baseline metrik htop/top per release, dokumentasikan threshold dan waktu observasi.
  • Terapkan rollback plan yang terhubung dengan alarm htop/top. Contoh: bila CPU > 90% dan load > jumlah CPU selama 2 interval, jalankan rollback otomatis.
  • Sertakan langkah retro: temukan apakah perubahan kode memicu thread blocking atau memori leak.

Runbook yang menggabungkan observasi htop/top dengan tindakan spesifik mempersingkat waktu respons dan mengurangi false positive.

Kesimpulan

htop/top tetap relevan untuk observasi deployment dan rollback karena cepat, tidak memerlukan setup agent, dan memberikan metrik penting (CPU, memori, load, thread) secara instan. Jika digunakan dengan checklist, alias/perintah otomatis, dan postmortem sederhana, tim DevOps dapat mendeteksi degradasi lebih awal dan mengambil keputusan rollback bermakna.