Apa yang Harus Diperiksa Setelah Deployment Tergantung pada Apa yang Baru Saja Anda Deploy

Anda baru saja mendorong versi baru ke produksi. Pipeline hijau. Deployment selesai tanpa error. Lalu apa?

Kebanyakan tim menatap dashboard dan berharap tidak ada yang rusak. Namun sinyal yang penting sepenuhnya tergantung pada apa yang Anda deploy. Memeriksa metrik yang sama untuk aplikasi, database, dan perubahan infrastruktur akan membuat Anda buta terhadap masalah yang sebenarnya. Setiap jenis deployment memiliki mode kegagalannya sendiri, dan Anda perlu mengawasi sinyal yang tepat untuk masing-masing.

Aplikasi: Pantau Bagaimana Request Ditangani

Saat Anda men-deploy versi baru sebuah aplikasi, hal terpenting yang perlu diketahui adalah apakah aplikasi tersebut menangani permintaan pengguna dengan benar. Dua metrik memberikan jawaban lebih cepat dari yang lain: error rate dan latensi.

Error rate memberi tahu berapa banyak permintaan yang gagal. Jika error rate melonjak tepat setelah deployment, ada yang salah. Bisa jadi bug di kode baru, ketidakcocokan konfigurasi, atau ketidakcocokan dengan lingkungan produksi. Apa pun penyebabnya, pengguna mengalami kegagalan, dan Anda perlu tahu segera.

Latensi memberi tahu berapa lama aplikasi merespons permintaan. Peningkatan latensi yang tiba-tiba berarti versi baru lebih lambat. Mungkin aplikasi mengonsumsi lebih banyak sumber daya, mengalami bottleneck, atau melakukan panggilan yang tidak efisien ke layanan hilir. Pengguna mungkin tidak melihat error, tetapi mereka akan merasakan kelambatan, dan itu sama merusaknya.

Throughput adalah sinyal berguna lainnya, terutama untuk aplikasi yang melayani banyak pengguna. Throughput mengukur berapa banyak permintaan yang dapat ditangani aplikasi per satuan waktu. Jika throughput turun sementara jumlah pengguna tetap sama, versi baru kurang efisien. Sesuatu di kode memperlambat segalanya, meskipun error rate dan latensi terlihat normal.

Ketiga sinyal ini adalah hal pertama yang harus diperiksa setelah deployment aplikasi. Mereka mencerminkan apa yang sebenarnya dialami pengguna. Jangan hanya mengandalkan apakah proses masih berjalan atau container masih aktif. Itu memberi tahu Anda bahwa aplikasi hidup, tetapi tidak memberi tahu apakah aplikasi bekerja dengan benar.

Diagram alir berikut merangkum metrik mana yang harus diperiksa terlebih dahulu berdasarkan apa yang Anda deploy:

flowchart TD Start([Deployment Selesai]) --> Type{Tipe Deployment?} Type -->|Aplikasi| App[Cek Metrik Aplikasi] Type -->|Database| DB[Cek Metrik Database] Type -->|Infrastruktur| Infra[Cek Metrik Infrastruktur] App --> App1[Error Rate] App --> App2[Latensi] App --> App3[Throughput] DB --> DB1[Replication Lag] DB --> DB2[Kinerja Query] DB --> DB3[Jumlah Koneksi] DB --> DB4[Ukuran Transaction Log] Infra --> Infra1[Kesehatan Node] Infra --> Infra2[CPU & Memori] Infra --> Infra3[Ruang Disk] Infra --> Infra4[Latensi Jaringan]

Database: Periksa Replikasi, Query, dan Koneksi

Database tidak melayani permintaan secara langsung seperti aplikasi. Mereka menyediakan data untuk aplikasi. Jadi sinyal yang perlu Anda awasi berbeda.

Status replikasi sangat kritis. Sebagian besar database produksi menggunakan replika untuk membaca data. Jika replikasi tertinggal atau rusak setelah deployment, aplikasi mungkin membaca data basi atau tidak konsisten. Ini sangat berbahaya setelah perubahan skema atau migrasi data. Beberapa detik replikasi lag mungkin masih bisa ditoleransi, tetapi menit lag berarti ada yang salah.

Kinerja query adalah hal berikutnya yang perlu dipantau. Setelah deployment yang mengubah skema, menambahkan indeks, atau mengubah cara aplikasi menulis data, beberapa query tiba-tiba bisa menjadi lambat. Perhatikan query yang memakan waktu lebih lama dari biasanya atau query yang mulai timeout. Satu query lambat bisa menyeret seluruh aplikasi.

Jumlah koneksi juga penting. Database memiliki jumlah koneksi terbatas. Jika deployment menyebabkan koneksi menumpuk atau menggantung, database bisa kehabisan koneksi yang tersedia. Permintaan baru akan gagal, dan aplikasi akan tampak rusak meskipun database itu sendiri sehat.

Ukuran transaction log adalah sinyal yang kurang jelas tetapi penting. Database menulis log untuk setiap perubahan. Jika deployment mengubah cara aplikasi menulis data, log mungkin tumbuh lebih cepat dari biasanya. Tanpa pembersihan yang tepat, log bisa memenuhi disk dan menghentikan database. Tim database biasanya memiliki ambang batas aman untuk ukuran log. Jika melebihi ambang itu, tindakan diperlukan.

Infrastruktur: Mulai dengan Kesehatan Node

Deployment infrastruktur mencakup perubahan pada server, container, jaringan, atau sumber daya cloud. Sinyal pertama yang harus diperiksa adalah kesehatan node. Apakah server atau container masih hidup? Apakah penggunaan CPU dan memori dalam kisaran normal? Apakah disk mulai penuh?

Infrastruktur yang sehat adalah prasyarat agar aplikasi dan database dapat berjalan dengan benar. Jika sebuah node terus restart atau kehabisan sumber daya, semua yang berjalan di atasnya akan menderita. Kesehatan node adalah garis dasar. Jika itu rusak, tidak ada hal lain yang penting.

Sinyal jaringan juga penting, terutama setelah perubahan pada aturan firewall, load balancer, atau service mesh. Perhatikan peningkatan latensi antar node, packet loss, atau koneksi yang terputus. Masalah ini sering tidak muncul langsung di metrik aplikasi, tetapi menyebabkan kegagalan misterius yang sulit di-debug.

Sinyal Saling Terkait, Tapi Mulailah dengan Satu

Sinyal aplikasi, database, dan infrastruktur tidak berdiri sendiri. Aplikasi lambat bisa disebabkan oleh database yang lambat. Database lambat bisa disebabkan oleh node infrastruktur yang kehabisan memori. Untuk mendapatkan gambaran lengkap, Anda perlu membaca sinyal dari ketiga lapisan secara bersamaan.

Namun saat Anda perlu mengambil keputusan cepat setelah deployment, setiap tim biasanya memiliki satu sinyal utama untuk dipantau. Tim aplikasi memantau error rate dan latensi. Tim database memantau replikasi dan kinerja query. Tim infrastruktur memantau kesehatan node. Mulailah dari sana. Jika ada yang terlihat salah, gali lapisan lain untuk menemukan akar masalah.

Daftar Periksa Praktis untuk Verifikasi Pasca-Deployment

  • Untuk deployment aplikasi: periksa error rate, latensi, dan throughput dalam lima menit pertama.
  • Untuk deployment database: periksa replikasi lag, query lambat, jumlah koneksi, dan ukuran transaction log.
  • Untuk deployment infrastruktur: periksa kesehatan node, penggunaan CPU dan memori, ruang disk, dan latensi jaringan.
  • Jika satu sinyal terlihat tidak normal, periksa sinyal terkait di lapisan lain untuk menemukan penyebab sebenarnya.

Kesimpulan

Jangan gunakan dashboard yang sama untuk setiap deployment. Sinyal yang penting tergantung pada apa yang baru saja Anda ubah. Aplikasi membutuhkan metrik tingkat permintaan. Database membutuhkan metrik lapisan data. Infrastruktur membutuhkan metrik sumber daya dan jaringan. Ketahui sinyal mana yang harus dipantau untuk setiap jenis deployment, dan Anda akan menangkap masalah sebelum pengguna Anda melakukannya.