Apa yang Terjadi Setelah Deployment Berhasil

Log deployment mengatakan semuanya berhasil. Server berjalan tanpa error. Artifak terinstal dengan bersih. Pipeline menunjukkan hijau di semua tahap.

Tapi semua itu tidak memberi tahu Anda apakah versi baru benar-benar berfungsi untuk pengguna.

Deployment yang bersih hanyalah fase instalasi. Pertanyaan sesungguhnya dimulai setelah traffic mengenai kode baru. Apakah aplikasi berperilaku sesuai yang diharapkan? Apakah pengguna mendapatkan pengalaman yang Anda inginkan? Anda tidak akan menemukan jawabannya di log deployment.

Kesenjangan Antara Deployment dan Operasi Normal

Ketika sebuah tim mendorong versi baru dari layanan backend, beberapa menit pertama setelah deployment adalah yang paling mengungkap. Di sinilah kode baru bertemu dengan traffic nyata, data nyata, dan dependensi nyata. Masalah yang tidak pernah muncul di staging bisa langsung terlihat.

Kesalahan umum adalah menganggap deployment selesai begitu pipeline berubah hijau. Dalam praktiknya, deployment hanya selesai ketika Anda memiliki cukup bukti bahwa versi baru berjalan normal dalam kondisi produksi.

Lima Indikator yang Harus Diperiksa Setelah Deployment

Error Rate

Error rate adalah sinyal paling langsung bahwa ada yang salah. Jika layanan API Anda biasanya berjalan dengan tingkat kegagalan 0,1 persen dan tiba-tiba melonjak ke 5 persen setelah deployment, Anda punya masalah.

Untuk memeriksa error rate segera setelah deployment, query endpoint metrik Anda. Misalnya, dengan Prometheus:

curl -s 'http://localhost:9090/api/v1/query?query=rate(http_requests_total{status=~"5.."}[5m])'

Ini mengembalikan rate error 5xx selama lima menit terakhir. Bandingkan hasilnya dengan baseline sebelum deployment untuk memutuskan apakah rollback diperlukan.

Namun error rate saja tidak cukup. Lonjakan bisa berasal dari dependensi downstream, bukan dari kode Anda. Jika database mulai merespons lambat, setiap request yang menyentuh database akan gagal. Itu berarti Anda perlu membaca error rate bersama dengan indikator lain untuk memahami di mana masalah sebenarnya berada.

Latency

Terkadang versi baru tidak menghasilkan error sama sekali, tetapi setiap respons memakan waktu lebih lama. Pengguna masih bisa menggunakan aplikasi, tetapi pengalaman menurun. Peningkatan latency bisa berasal dari kode yang tidak efisien, perubahan query database, atau sumber daya server yang mencapai batasnya.

Jika latency terus meningkat setelah deployment dan tidak kembali normal, ada sesuatu di versi baru yang mengonsumsi lebih banyak waktu per request dari yang seharusnya.

Saturation

Ini tentang seberapa penuh sumber daya server Anda. CPU, memori, koneksi database, I/O disk. Versi baru bisa boros sumber daya tanpa disadari selama pengujian.

Misalnya, kode yang membuka koneksi database baru untuk setiap request dan tidak pernah menutupnya. Atau loop yang tidak perlu yang berjalan pada setiap panggilan API. Saturation bisa tetap tidak terlihat sampai traffic meningkat, lalu tiba-tiba server tidak bisa menangani beban tambahan meskipun error rate dan latency terlihat baik.

Dependency Health

Layanan backend jarang berjalan sendiri. Layanan API bergantung pada database, cache, dan layanan lain. Sebuah worker bergantung pada message broker. Ketika versi baru Anda mulai memanggil dependensi dengan cara yang berbeda, dependensi tersebut mungkin tidak merespons seperti yang Anda harapkan.

Terkadang masalahnya bukan di layanan Anda sama sekali. Masalahnya ada di layanan yang Anda panggil, dan versi baru adalah pertama kalinya dependensi tersebut diuji dalam kondisi nyata.

Business Signals

Ini adalah indikator yang paling spesifik terhadap aplikasi. Untuk API registrasi, sinyal bisnisnya adalah registrasi yang selesai per menit. Untuk worker pemrosesan pembayaran, itu adalah transaksi yang berhasil diproses.

Jika registrasi turun drastis setelah deployment tetapi error rate teknis tetap rendah, Anda tetap memiliki masalah serius. Sinyal bisnis perlu didefinisikan oleh tim yang memahami apa yang seharusnya diberikan oleh layanan. Sinyal-sinyal ini memberi tahu Anda apakah aplikasi melakukan tugasnya, bukan hanya apakah aplikasi berjalan.

Apa yang Harus Dilakukan Ketika Ada Masalah

Jika indikator menunjukkan bahwa versi baru tidak berfungsi dengan benar, respons teraman adalah rollback. Kembali ke versi sebelumnya yang diketahui stabil.

Diagram alir berikut memetakan proses monitoring pasca-deployment dan keputusan untuk rollback atau melanjutkan:

flowchart TD A[Deployment hijau] --> B{Periksa error rate} B -- ok --> C{Periksa latency} B -- alert --> R[Rollback] C -- ok --> D{Periksa saturation} C -- alert --> R D -- ok --> E{Periksa dependency health} D -- alert --> R E -- ok --> F{Periksa business signals} E -- alert --> R F -- ok --> G[Monitor] F -- alert --> R

Rollback harus diotomatisasi. Login ke server dan menukar file secara manual terlalu lambat dan rawan error ketika pengguna sudah terpengaruh.

Cara mengotomatisasi rollback tergantung pada strategi deployment Anda:

  • Rolling update: konfigurasikan pipeline untuk kembali ke versi sebelumnya jika error rate melebihi ambang batas.
  • Blue/green: alihkan traffic kembali ke lingkungan lama.
  • Canary: hentikan canary dan arahkan semua traffic kembali ke versi stabil.

Poin kritisnya adalah ambang batas rollback harus ditentukan sebelum deployment, bukan saat insiden. Misalnya: jika error rate tetap di atas 1 persen selama dua menit, rollback otomatis. Atau jika rata-rata latency meningkat 50 persen dari baseline, rollback.

Setiap layanan membutuhkan ambang batasnya sendiri. API kritis yang langsung diandalkan pengguna harus memiliki ambang batas yang lebih ketat daripada worker latar belakang yang memproses pekerjaan batch.

Checklist Praktis Pasca-Deployment

Gunakan checklist ini setelah setiap deployment untuk memverifikasi bahwa versi baru berjalan normal:

  • Error rate dalam rentang yang diharapkan (bandingkan dengan baseline sebelum deployment)
  • Latency tidak meningkat secara signifikan
  • Penggunaan sumber daya server (CPU, memori, koneksi) stabil
  • Semua dependensi kritis merespons normal
  • Sinyal bisnis (registrasi, transaksi, dll.) sesuai dengan pola yang diharapkan
  • Ambang batas rollback telah ditentukan dan diotomatisasi

Akhir Sebenarnya dari Sebuah Deployment

Deployment tidak selesai ketika pipeline berubah hijau. Deployment selesai ketika Anda telah mengonfirmasi bahwa versi baru berjalan normal dalam kondisi produksi. Beberapa menit pertama setelah traffic mengenai kode baru adalah yang paling penting. Di situlah Anda menangkap masalah sebelum mempengaruhi semua pengguna.

Tetapkan ambang batas Anda, pantau indikator Anda, dan otomatiskan rollback Anda. Jaring pengaman hanya berfungsi jika sudah siap sebelum Anda membutuhkannya.