35-4 · Bab 35 · 6 menit baca

Deployment Belum Selesai Sampai Kamu Tahu Aplikasinya Berfungsi

Pipeline hijau, log tanpa error, tapi pengguna tetap melaporkan masalah. Pelajari cara menangkap sinyal produksi, otomatis rollback, dan jadikan setiap deployment sebagai peluang belajar.

Deployment Belum Selesai Sampai Kamu Tahu Aplikasinya Berfungsi

Sebuah tim mendorong versi baru ke produksi. Pipeline hijau. Log deployment tidak menunjukkan error apa pun. Semua orang bernapas lega dan beralih ke tugas berikutnya. Dua jam kemudian, seorang pelanggan mengirim email ke dukungan mengatakan halaman checkout rusak. Tim panik menyelidiki, melakukan rollback, dan menghabiskan hari berikutnya mencari tahu apa yang salah.

Skenario ini umum terjadi. Banyak tim menganggap deployment selesai begitu versi baru mulai berjalan di server produksi. Namun dalam praktiknya, deployment baru benar-benar selesai ketika kamu tahu apakah versi tersebut benar-benar berfungsi dengan baik bagi pengguna.

Produksi Bukan Ruang Bersih

Ketika versi baru live, ia memasuki lingkungan yang tidak pernah bisa sepenuhnya ditiru oleh staging. Pengguna nyata membawa data nyata, pola lalu lintas nyata, dan konfigurasi perangkat nyata. Hal-hal terjadi yang tidak pernah diprediksi oleh lingkungan pengujian mana pun.

Sebuah query yang berjalan lancar dengan seribu baris di staging bisa melambat drastis dengan sejuta baris di produksi. Perubahan API yang tampak kompatibel ke belakang bisa merusak klien seluler yang belum diperbarui selama enam bulan. Fitur baru yang tampak hebat dalam review desain bisa membingungkan pengguna sehingga tidak ada yang mengkliknya.

Ini bukanlah kegagalan. Ini adalah sinyal. Pertanyaannya adalah apakah timmu siap menangkapnya.

Sinyal yang Penting

Tim yang baik tidak menunggu pengguna melaporkan masalah. Mereka menyiapkan sistem otomatis yang menangkap sinyal dari produksi. Sinyal yang paling berguna terbagi dalam beberapa kategori:

Perubahan tingkat error. Jika tingkat error melonjak tepat setelah deployment, kemungkinan ada yang rusak. Kenaikan 5 persen di semua endpoint mungkin perlu rollback segera. Kenaikan 0,1 persen di endpoint yang jarang digunakan mungkin hanya bug yang bisa diperbaiki di rilis berikutnya.
Degradasi waktu respons. Respons yang lebih lambat sering menunjuk pada bottleneck database, query yang tidak efisien, atau persaingan sumber daya. Sinyal ini sangat penting karena pengguna mungkin tidak langsung mengeluh, tetapi mereka akan mulai meninggalkan layanan.
Penurunan volume transaksi. Penurunan mendadak dalam transaksi yang selesai bisa berarti pengguna mengalami error, terjebak dalam alur, atau menyerah. Sinyal ini lebih sulit dideteksi karena memerlukan perbandingan lalu lintas saat ini dengan baseline historis.

Setiap sinyal memiliki arti yang berbeda. Kuncinya adalah mengetahui sinyal mana yang memerlukan tindakan segera dan mana yang bisa menunggu.

Berikut adalah contoh praktis bagaimana sebuah tim dapat mengotomatiskan keputusan rollback berdasarkan tingkat error:

#!/bin/bash
# Pemeriksaan kesehatan pasca-deployment: query tingkat error dan rollback jika > 5%
THRESHOLD=5.0
DEPLOY_ID=$(curl -s "https://monitoring.example.com/api/v1/deploy/latest" | jq -r '.id')
ERROR_RATE=$(curl -s "https://monitoring.example.com/api/v1/query?query=error_rate{deploy_id=$DEPLOY_ID}" | jq -r '.data.result[0].value[1]')

if (( $(echo "$ERROR_RATE > $THRESHOLD" | bc -l) )); then
  echo "Tingkat error $ERROR_RATE% melebihi ambang batas $THRESHOLD%. Melakukan rollback..."
  kubectl rollout undo deployment/my-app
  exit 1
else
  echo "Tingkat error $ERROR_RATE% dalam batas normal. Deployment dikonfirmasi."
fi

Dari Sinyal ke Akar Masalah

Setelah sinyal terdeteksi, langkah selanjutnya adalah menemukan akar masalah. Apakah itu bug kode? Ketidakcocokan konfigurasi? Masalah data? Masalah infrastruktur? Jawabannya menentukan siapa yang memperbaiki dan bagaimana caranya.

Diagram alir berikut mengilustrasikan bagaimana sebuah tim dapat bergerak dari deployment ke deteksi sinyal, analisis akar masalah, dan tindakan.

flowchart TD A[Deploy versi baru] --> B[Pantau sinyal] B --> C{Sinyal normal?} C -->|Ya| D[Deployment dikonfirmasi] C -->|Tidak| E[Selidiki akar masalah] E --> F{Bug kode?} F -->|Ya| G[Perbaiki kode] F -->|Tidak| H{Masalah konfig?} H -->|Ya| I[Perbaiki konfig] H -->|Tidak| J{Masalah data/infra?} J -->|Ya| K[Perbaiki data/infra] J -->|Tidak| L[Eskalasi] G --> M[Rollback atau hotfix] I --> M K --> M L --> M M --> B

Di sinilah banyak tim terjebak. Mereka melihat lonjakan error dan langsung berasumsi bahwa kode salah. Namun terkadang kode baik-baik saja dan masalahnya adalah nilai konfigurasi yang berbeda antara staging dan produksi. Terkadang migrasi skema database berjalan dengan benar tetapi kode aplikasi di-deploy sebelum migrasi selesai.

Tim yang matang tidak hanya memperbaiki masalah langsung. Mereka juga memperbaiki proses yang membiarkan masalah itu lolos. Jika migrasi database menyebabkan masalah, tambahkan pemeriksaan migrasi ke pipeline. Jika konfigurasi staging dan produksi melenceng, buatlah identik. Jika jenis perubahan tertentu terus menyebabkan masalah, perbarui checklist deployment untuk menangkapnya lebih awal.

Umpan Balik Meningkatkan Pengambilan Keputusan

Umpan balik dari produksi tidak hanya tentang memperbaiki bug. Ini juga membantu tim mengevaluasi keputusan mereka sendiri. Ingat kriteria kesiapan yang kamu tetapkan sebelum deployment? Apakah kriteria itu benar-benar mencegah masalah? Atau apakah masalah serius lolos karena kriteriamu tidak mencakup skenario itu?

Dengan data nyata dari produksi, tim dapat menyesuaikan kriteria deployment mereka. Mereka dapat melihat pemeriksaan mana yang efektif dan mana yang menciptakan rasa percaya diri palsu. Mereka dapat mengidentifikasi pola: mungkin semua insiden terkait database terjadi pada deployment hari Jumat, jadi mereka berhenti melakukan deployment perubahan database pada hari Jumat. Mungkin semua insiden terkait konfigurasi terjadi ketika anggota tim tertentu sedang cuti, jadi mereka menambahkan reviewer cadangan.

Beginilah proses deployment meningkat seiring waktu. Bukan dengan mengikuti praktik terbaik dari buku, tetapi dengan belajar dari data produksi Anda sendiri.

Kecepatan Umpan Balik Itu Penting

Semakin cepat umpan balik mencapai tim, semakin cepat mereka dapat merespons. Itulah mengapa validasi pasca-deployment adalah praktik kritis. Alih-alih menunggu error menumpuk, tim secara aktif memeriksa apakah versi baru berjalan normal setelah beberapa menit atau jam pertama.

Validasi pasca-deployment dapat mengambil beberapa bentuk:

Tes asap otomatis yang berjalan terhadap endpoint produksi tepat setelah deployment.
Perbandingan metrik yang menunjukkan snapshot sebelum dan sesudah dari tingkat error, waktu respons, dan throughput.
Analisis log yang mencari pola tidak biasa dalam beberapa menit pertama lalu lintas.

Beberapa tim melangkah lebih jauh dan menjalankan canary deployment, di mana versi baru hanya melayani persentase kecil lalu lintas. Jika sinyal terlihat baik, lalu lintas ditingkatkan secara bertahap. Jika sinyal memburuk, canary di-rollback secara otomatis. Pendekatan ini membatasi radius ledakan sambil tetap memberikan umpan balik produksi nyata.

Umpan Balik Membutuhkan Sistem

Mengumpulkan umpan balik tidak berguna jika tidak ada sistem untuk mengelolanya. Tim membutuhkan cara untuk mengumpulkan sinyal, menyaring kebisingan, dan memprioritaskan tindakan. Dasbor yang penuh dengan grafik saja tidak cukup. Sistem harus membantu tim membuat keputusan yang lebih baik.

Ini berarti menentukan ambang batas yang jelas untuk setiap sinyal. "Jika tingkat error melebihi 2 persen selama lebih dari lima menit, hubungi on-call engineer." "Jika waktu respons berlipat ganda untuk endpoint kritis mana pun, buat tiket untuk sprint berikutnya." Tanpa ambang batas, setiap sinyal tampak mendesak, dan tim kelelahan mengejar alarm palsu.

Ini juga berarti memiliki jalur eskalasi yang jelas. Tidak setiap sinyal membutuhkan respons yang sama. Beberapa sinyal memicu rollback otomatis. Beberapa memicu tiket. Beberapa memicu rapat untuk mendiskusikan apakah proses deployment perlu diubah. Sistem harus membuat perbedaan ini jelas.

Checklist Praktis untuk Umpan Balik Produksi

Berikut adalah checklist singkat untuk mengevaluasi apakah timmu mendapatkan umpan balik yang berguna dari produksi:

Apakah kamu memiliki peringatan otomatis untuk perubahan tingkat error, waktu respons, dan volume transaksi setelah setiap deployment?
Apakah kamu mengetahui nilai baseline untuk metrik ini sebelum melakukan deployment?
Apakah kamu memiliki ambang batas yang jelas yang membedakan antara "selidiki nanti" dan "rollback sekarang"?
Apakah kamu menjalankan tes asap pasca-deployment terhadap produksi?
Apakah kamu meninjau insiden deployment untuk meningkatkan pipeline dan kriteria Anda?
Apakah umpan balik dari produksi pernah mengubah cara kamu membangun pipeline?

Jika kamu menjawab tidak untuk lebih dari dua pertanyaan ini, timmu terbang buta setelah deployment.

Akhir Sebenarnya dari Sebuah Deployment

Sebuah deployment tidak selesai ketika versi baru berjalan. Ia selesai ketika tim tahu bahwa versi baru berjalan dengan baik. Pengetahuan itu berasal dari sistem umpan balik yang menangkap sinyal, menyaring kebisingan, dan mendorong tindakan. Tanpa sistem itu, setiap deployment adalah perjudian. Dengan sistem itu, setiap deployment menjadi kesempatan belajar yang membuat deployment berikutnya lebih aman.