Saat Pipeline Hijau Belum Berarti Deployment Sehat

Anda baru saja menyelesaikan sebuah deployment. Pipeline menunjukkan warna hijau. Setiap langkah build berhasil, semua pengujian berjalan bersih, dan skrip deploy selesai tanpa satu pun error. Anda menutup laptop dengan perasaan puas.

Lalu laporan pengguna pertama masuk. Aplikasi berjalan lambat. Beberapa permintaan gagal. Beberapa menit kemudian, koneksi pool database habis, dan aplikasi praktis down.

Apa yang terjadi? Pipeline mengatakan semuanya baik-baik saja.

Skenario ini lebih umum daripada yang ingin diakui kebanyakan tim. Build yang sukses hanya membuktikan bahwa kode Anda bisa dikompilasi atau dikemas. Itu tidak membuktikan bahwa aplikasi Anda benar-benar bisa menerima permintaan, terhubung ke database, atau mengembalikan respons yang benar. Ada celah antara "deploy selesai" dan "aplikasi berfungsi." Celah itulah yang diisi oleh health signal.

Apa Sebenarnya yang Diberitahukan Health Signal

Health signal adalah cara aplikasi Anda melaporkan kondisinya sendiri. Bentuk yang paling umum adalah health endpoint: URL khusus yang bisa dipanggil oleh pipeline, load balancer, atau tim operasi untuk memeriksa apakah aplikasi berfungsi. Anda mungkin pernah melihat endpoint bernama /health atau /healthz. Saat dipanggil, aplikasi yang sehat mengembalikan HTTP 200. Aplikasi yang tidak sehat mengembalikan 500 atau kode error lainnya.

Namun nilai sebenarnya bukan terletak pada endpoint itu sendiri. Melainkan pada apa yang sebenarnya diperiksa oleh endpoint tersebut. Health endpoint yang selalu mengembalikan 200 tanpa memedulikan kondisi nyata aplikasi lebih buruk daripada tidak memiliki health check sama sekali. Ini memberikan keyakinan palsu. Pipeline Anda mengira deployment berhasil, tetapi pengguna Anda sudah mengalami error.

Readiness vs Liveness: Dua Pertanyaan Berbeda

Ada dua jenis health check yang berbeda, dan keduanya menjawab pertanyaan yang berbeda.

Diagram alir berikut mengilustrasikan perbedaan antara liveness dan readiness check serta bagaimana keduanya memandu keputusan deployment:

flowchart TD A[Permintaan Health Check] --> B{Apakah proses aplikasi berjalan?} B -->|Tidak| C[Liveness gagal: Restart container] B -->|Ya| D{Apakah aplikasi siap melayani traffic?} D -->|Tidak| E[Readiness gagal: Hapus dari load balancer] D -->|Ya| F[Readiness berhasil: Kirim traffic] C --> G[Upaya pemulihan otomatis] E --> H[Tunggu dan coba readiness lagi] F --> I[Aplikasi melayani pengguna normal] H --> D G --> B

Readiness memberi tahu sistem apakah aplikasi siap menerima traffic. Saat aplikasi baru saja dimulai, mungkin perlu beberapa detik untuk terhubung ke database, memuat cache, atau memanaskan koneksi. Selama waktu itu, aplikasi harus melaporkan dirinya sebagai "belum siap." Load balancer atau orkestrator kemudian akan menahan pengiriman permintaan hingga aplikasi memberi sinyal bahwa ia siap. Tanpa readiness check yang tepat, pengguna mungkin menemukan aplikasi yang setengah jadi yang mengembalikan error atau timeout.

Liveness memberi tahu sistem apakah aplikasi masih hidup dan memproses. Jika aplikasi mengalami deadlock, kehabisan memori, atau memasuki kondisi di mana ia tidak bisa menangani pekerjaan apa pun, liveness check akan mendeteksinya. Di lingkungan kontainer seperti Kubernetes, liveness check yang gagal biasanya memicu restart otomatis.

Kedua check ini memiliki tujuan berbeda dalam pipeline deployment Anda. Saat Anda menjalankan deployment, pipeline biasanya memanggil readiness check terlebih dahulu. Jika versi baru tidak menjadi siap dalam waktu yang wajar, pipeline dapat memutuskan untuk roll back segera. Itu jauh lebih baik daripada membiarkan versi setengah jadi melayani pengguna. Liveness check, di sisi lain, lebih berguna setelah deployment selesai. Mereka menjaga aplikasi tetap berjalan sehat sepanjang waktu.

Berikut adalah contoh YAML praktis yang mengonfigurasi kedua probe untuk deployment Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:1.0.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 3

Dalam contoh ini, readiness probe memeriksa /ready setiap 10 detik setelah penundaan 5 detik. Jika gagal tiga kali, Kubernetes berhenti mengirim traffic ke pod. Liveness probe memeriksa /live lebih jarang dan me-restart container jika gagal.

Apa yang Seharusnya Diperiksa oleh Health Check yang Baik

Health check yang hanya mengembalikan 200 tanpa memverifikasi apa pun hanyalah hiasan, bukan sinyal. Health check yang bermakna harus menguji komponen yang penting bagi fungsi aplikasi Anda:

  • Konektivitas database: Dapatkah aplikasi mencapai database dan menjalankan query sederhana?
  • API eksternal kritis: Apakah layanan yang diandalkan aplikasi Anda tersedia?
  • Sumber daya internal: Apakah thread pool sehat? Apakah penggunaan memori dalam batas wajar?

Namun ada trade-off. Health check yang menguji setiap dependensi pada setiap panggilan bisa menjadi beban bagi sistem. Jika pipeline atau load balancer Anda memanggil endpoint setiap beberapa detik, check yang berat dapat menurunkan performa atau bahkan menyebabkan kegagalan berantai.

Pola umum adalah menjaga liveness check tetap ringan: cukup konfirmasi bahwa proses berjalan. Readiness check bisa lebih dalam, karena dipanggil lebih jarang dan hasilnya secara langsung memengaruhi apakah traffic dialihkan ke instance tersebut.

Health Signal dalam Strategi Deployment Progresif

Health signal menjadi lebih penting lagi saat Anda menggunakan strategi deployment seperti canary atau blue-green. Bayangkan Anda meluncurkan versi baru ke subset kecil pengguna. Pipeline Anda dapat memantau health endpoint dari versi baru tersebut. Jika health check mulai menunjukkan error atau waktu respons meningkat, pipeline dapat secara otomatis mengalihkan traffic kembali ke versi lama.

Tanpa health signal, Anda mengandalkan laporan pengguna. Laporan pengguna memang berharga, tetapi datang terlambat. Pada saat seseorang mengajukan laporan bug, banyak pengguna mungkin sudah terpengaruh. Health check yang berjalan setiap beberapa detik dapat menangkap masalah dalam hitungan detik, bukan menit atau jam.

Apa yang Terjadi Saat Health Check Tidak Ada atau Lemah

Tim yang melewatkan health check yang tepat sering kali menemukan masalah dengan cara yang sulit. Sebuah deployment berhasil, tetapi versi baru tidak bisa terhubung ke database karena kredensial berubah. Pipeline melaporkan sukses. Pengguna melihat error. Seseorang harus menyelidiki secara manual, menyadari masalahnya, dan memicu rollback. Proses itu memakan waktu, dan selama waktu itu, aplikasi mengalami degradasi.

Hal yang sama berlaku untuk dependensi. Jika aplikasi Anda bergantung pada API eksternal dan API tersebut down, health check yang baik akan melaporkan aplikasi sebagai tidak sehat. Health check yang lemah akan melaporkan sehat, dan pengguna Anda akan mengalami kegagalan sementara dashboard monitoring Anda menunjukkan hijau.

Daftar Periksa Praktis Singkat

Jika Anda menyiapkan health check untuk aplikasi Anda, berikut adalah daftar singkat hal-hal yang perlu diverifikasi:

  • Apakah health endpoint Anda benar-benar memeriksa sesuatu yang bermakna, atau hanya mengembalikan 200?
  • Apakah Anda memiliki readiness dan liveness check terpisah dengan kedalaman yang berbeda?
  • Apakah pipeline Anda menggunakan readiness check untuk memutuskan apakah akan melanjutkan deployment atau roll back?
  • Apakah health check Anda cukup ringan sehingga tidak menurunkan performa saat dipanggil sering?
  • Apakah strategi deployment progresif Anda menggunakan health signal untuk mendeteksi masalah sejak dini?

Ujian Sebenarnya dari Sebuah Deployment

Pipeline hijau bukan bukti bahwa aplikasi Anda berfungsi. Itu adalah bukti bahwa proses build dan deploy Anda berjalan tanpa error. Ujian sebenarnya terjadi setelah deploy, saat traffic mengenai versi baru. Health signal adalah jembatan antara "deploy selesai" dan "aplikasi benar-benar melayani pengguna dengan benar."

Ketika pipeline Anda dapat mendeteksi bahwa versi baru tidak sehat dalam hitungan detik dan secara otomatis roll back, Anda telah beralih dari berharap deployment berjalan lancar menjadi mengetahui bahwa deployment aman. Itulah perbedaan antara deployment yang terlihat bagus di atas kertas dan yang benar-benar bekerja di produksi.