Lima Sinyal yang Harus Dipantau Setelah Setiap Deployment untuk Mengetahui Apakah Versi Baru Anda Sehat
Anda baru saja melakukan deployment versi baru. Pipeline menunjukkan hijau. Tim sedang memantau dashboard. Tapi, apakah aplikasi benar-benar berfungsi dengan baik bagi pengguna?
Tanpa sinyal yang konkret, Anda hanya menebak. Menebak mungkin berhasil jika hanya Anda yang menggunakan aplikasi. Namun, ketika orang lain bergantung padanya, Anda membutuhkan data. Anda perlu tahu, dalam hitungan menit, apakah versi baru itu sehat atau rusak.
Berikut adalah lima sinyal dasar yang harus dipantau setiap tim setelah deployment. Mulailah dengan satu atau dua, lalu tambahkan sisanya seiring waktu.
Ketersediaan: Dapatkah Pengguna Menjangkau Aplikasi?
Pertanyaan paling mendasar setelah deployment sederhana: apakah aplikasi dapat diakses? Jika server mati, aplikasi crash saat startup, atau port tidak terbuka, ketersediaan turun menjadi nol.
Tim biasanya memantau ini dengan health check endpoint. Ini adalah URL khusus yang diekspos aplikasi hanya untuk menjawab "apakah saya hidup?" Alat pemantau akan memukul endpoint ini secara berkala. Jika berhenti merespons, ada yang salah.
Ketersediaan biasanya diukur sebagai persentase: 99%, 99,9%, atau 99,99% dari uptime yang diharapkan. Semakin tinggi target, semakin kecil toleransi Anda terhadap gangguan. Target 99% berarti Anda bisa menanggung sekitar 7 jam downtime per bulan. Target 99,99% berarti sekitar 4 menit per bulan.
Untuk memeriksa ketersediaan segera setelah deployment, jalankan perintah curl sederhana terhadap health endpoint Anda:
curl -f http://localhost:8080/health && echo "OK" || echo "FAIL"
Flag -f membuat curl mengembalikan kode keluar non-nol jika respons HTTP adalah error (4xx atau 5xx). Kode keluar nol berarti endpoint dapat dijangkau dan sehat. Anda dapat menggunakan ini dalam skrip deployment untuk secara otomatis memutuskan apakah akan melanjutkan atau roll back.
Setelah deployment, periksa ketersediaan terlebih dahulu. Jika aplikasi tidak dapat dijangkau, tidak ada hal lain yang berarti.
Error Rate: Berapa Banyak Permintaan yang Gagal?
Aplikasi bisa hidup tetapi rusak. Setiap permintaan yang masuk mungkin gagal. Error rate mengukur berapa banyak permintaan yang berakhir dengan kode error, seperti HTTP 500 atau timeout.
Sebelum deployment, Anda harus mengetahui baseline error rate Anda. Mungkin itu 0,5% dari semua permintaan. Setelah deployment, jika angka itu melonjak menjadi 5%, ada sesuatu pada versi baru yang menyebabkan kegagalan.
Lonjakan error rate sering kali merupakan alarm pertama bahwa ada yang salah. Mudah dideteksi dan biasanya mengindikasikan masalah nyata. Peningkatan error yang tiba-tiba harus memicu investigasi segera, bukan sikap "tunggu dan lihat."
Latensi: Seberapa Cepat Aplikasi Merespons?
Pengguna tidak suka menunggu. Jika halaman yang dulu dimuat dalam satu detik sekarang membutuhkan lima detik, pengguna akan pergi. Latensi mengukur seberapa cepat aplikasi merespons permintaan.
Latensi dapat meningkat karena berbagai alasan. Kode baru mungkin lebih lambat. Pool koneksi database mungkin penuh. Server mungkin kewalahan oleh lalu lintas. Apa pun penyebabnya, latensi yang lebih tinggi secara langsung menurunkan pengalaman pengguna.
Anda perlu mengetahui rentang latensi normal sebelum deployment. Setelah deployment, bandingkan angkanya. Jika waktu respons rata-rata berlipat ganda, ada yang berubah. Bahkan peningkatan kecil pada latensi dapat mengindikasikan masalah yang akan memburuk di bawah beban yang lebih tinggi.
Saturasi: Seberapa Penuh Sumber Daya Anda?
Setiap sistem memiliki batas. CPU, memori, ruang disk, koneksi database, thread pool, bandwidth jaringan—semuanya memiliki batas atas. Saturasi mengukur seberapa dekat Anda dengan batas-batas tersebut.
Setelah deployment, pantau penggunaan sumber daya. Jika penggunaan CPU naik dari 40% menjadi 90%, versi baru mengonsumsi lebih banyak sumber daya. Itu mungkin tidak masalah jika Anda memiliki kapasitas cadangan. Tapi jika lalu lintas meningkat nanti, 90% itu akan menjadi 100%, dan aplikasi akan melambat atau crash.
Saturasi juga membantu dalam perencanaan kapasitas. Jika server secara konsisten berada pada penggunaan 80%, Anda mungkin perlu menambahkan server lain sebelum lonjakan lalu lintas berikutnya. Memantau saturasi setelah deployment memberi tahu Anda apakah versi baru mengubah profil sumber daya aplikasi Anda.
Log: Apa yang Sebenarnya Terjadi di Dalam?
Tidak semuanya bisa ditangkap sebagai angka. Ketika error rate melonjak, Anda perlu tahu alasannya. Di sinilah log berperan. Log adalah catatan peristiwa yang ditulis aplikasi saat berjalan.
Log yang baik memiliki level: info untuk operasi normal, warning untuk kejadian yang tidak biasa tetapi tidak kritis, error untuk kegagalan. Log juga memiliki konteks: timestamp, ID permintaan, nama fungsi, dan data yang relevan. Tanpa konteks, log hanyalah kebisingan.
Ketika terjadi kesalahan setelah deployment, log adalah tempat pertama untuk melihat. Apakah ada exception tertentu yang muncul? Apakah input tertentu menyebabkan crash? Apakah database tidak merespons? Log menceritakan kisah yang tidak bisa diungkapkan oleh angka saja.
Mulai dari yang Kecil, Konsisten
Anda tidak perlu memantau kelima sinyal sejak hari pertama. Mulailah dengan ketersediaan dan error rate. Keduanya akan menangkap sebagian besar masalah. Tambahkan latensi saat Anda perlu memahami kinerja. Tambahkan saturasi saat Anda mulai melakukan perencanaan kapasitas. Tambahkan log saat Anda perlu men-debug masalah yang lebih dalam.
Yang penting adalah konsistensi. Setiap deployment harus diukur dengan cara yang sama. Gunakan health check endpoint yang sama. Kumpulkan error rate dari sumber yang sama. Ukur latensi dengan alat yang sama. Hanya dengan begitu Anda dapat membandingkan versi secara jujur: apakah versi baru lebih baik atau lebih buruk dari versi lama?
Kelima sinyal ini memberi Anda data, bukan perasaan. Data memberi tahu Anda apakah akan melanjutkan, roll back, atau menyelidiki lebih lanjut.
Daftar Periksa Cepat untuk Pemantauan Pasca-Deployment
- Health check endpoint merespons
- Error rate tidak jauh lebih tinggi dari baseline
- Latensi rata-rata dalam rentang normal
- Penggunaan CPU, memori, dan disk tidak mendekati kapasitas
- Log tidak menunjukkan error atau exception yang tidak terduga
Langkah Selanjutnya
Sinyal-sinyal ini memberi tahu Anda apakah aplikasi sehat, tetapi tidak memberi tahu Anda apakah fitur baru benar-benar berfungsi seperti yang diharapkan. Sebuah versi dapat memiliki ketersediaan sempurna, error rate rendah, latensi cepat, dan tetap memberikan hasil yang salah. Di sinilah verifikasi berperan.
Namun, sebelum sampai ke sana, pastikan kelima sinyal ini sudah terpasang. Tanpa sinyal-sinyal itu, Anda terbang buta. Dengan sinyal-sinyal itu, Anda memiliki fondasi untuk mengetahui apa yang terjadi setelah setiap deployment.