Saat Produksi Gagal: Mengapa Anda Perlu Ketertelusuran dan Rollback Image

Versi baru aplikasi Anda baru saja rilis. Lima menit kemudian, pengguna mulai melaporkan error. Pertanyaan pertama yang muncul di chat tim: "Versi apa yang sedang berjalan sekarang?"

Jika tidak ada yang bisa menjawab pertanyaan itu dengan cepat, Anda kehilangan waktu berharga. Menit berubah menjadi jam saat orang-orang menggali log deployment, memeriksa tag registry, dan bertanya-tanya untuk mencari tahu apa yang sebenarnya di-deploy. Saat Anda akhirnya tahu image mana yang berjalan di produksi, kerusakan sudah semakin parah.

Situasi ini lebih umum daripada yang diakui kebanyakan tim. Dan itu terjadi karena dua hal dianggap opsional: mengetahui secara pasti apa yang berjalan, dan memiliki cara yang andal untuk kembali ke sesuatu yang berfungsi.

Ketertelusuran Dimulai Saat Build

Kemampuan untuk melacak apa yang berjalan di produksi dimulai saat Anda membangun container image. Cara Anda memberi tag pada image tersebut menentukan apakah nanti Anda dapat mengidentifikasinya dengan pasti.

Tag seperti v1.2.3 atau production berguna bagi manusia. Tag membantu Anda mengenali versi sekilas. Tapi tag tidak dapat diandalkan untuk ketertelusuran. Tag hanyalah label yang menunjuk ke suatu image, dan label itu bisa berubah. Image myapp:production mungkin menunjuk ke versi 1.2.3 hari ini dan versi 1.3.0 besok. Jika Anda hanya melacak tag, Anda tidak akan pernah tahu pasti versi mana yang sebenarnya berjalan.

Sumber kebenaran yang andal adalah image digest. Digest adalah hash unik yang dihasilkan dari konten image. Jika dua image memiliki digest yang sama, maka keduanya identik. Tidak ada ambiguitas, tidak ada risiko salah tag, tidak ada label yang tertimpa. Saat Anda perlu tahu persis apa yang berjalan, digest-lah yang Anda butuhkan.

Catat Digest, Bukan Hanya Tag

Di pipeline Anda, Anda harus menangkap digest dari setiap image yang melewati setiap tahap. Saat image dibangun, catat digest-nya. Saat lolos pemindaian keamanan, catat lagi. Saat dipromosikan ke staging lalu ke produksi, simpan digest itu di catatan deployment Anda.

Di mana Anda menyimpan informasi ini? Tempat paling praktis adalah deployment manifest Anda. Deployment manifest adalah file yang memberi tahu sistem Anda cara menjalankan container. Di Kubernetes, itu adalah file YAML. Di Docker Compose, itu adalah file compose. Setiap kali Anda melakukan deployment, manifest harus mereferensikan digest yang tepat, bukan hanya tag.

Berikut tampilannya di deployment Kubernetes:

Untuk menangkap digest di pipeline Anda, gunakan urutan seperti ini:

# Build dan push image
docker build -t myregistry.com/myapp:latest .
docker push myregistry.com/myapp:latest

# Tangkap digest dari registry
export DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myregistry.com/myapp:latest)
echo "Deploying image: $DIGEST"

# Gunakan digest di deployment manifest
sed "s|image: myregistry.com/myapp:latest|image: $DIGEST|" deployment.yaml > deployment-digest.yaml
kubectl apply -f deployment-digest.yaml

Ini memastikan deployment Anda selalu mereferensikan konten image yang tepat, bukan tag yang bisa berubah.

Diagram urutan berikut mengilustrasikan di mana pencatatan digest dan rollback cocok dalam siklus hidup deployment:

spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.com/myapp@sha256:a1b2c3d4e5f6...

Perhatikan bagian @sha256:.... Itulah digest-nya. Saat Anda menggunakan format ini, Anda memberi tahu Kubernetes untuk menjalankan image yang tepat itu, bukan latest yang kebetulan ditunjuk.

Dengan mencatat digest di manifest Anda, Anda membuat catatan permanen. Anda dapat melihat ke belakang kapan saja dan tahu persis image mana yang berjalan. Anda dapat melihat kapan di-deploy, siapa yang memicu deployment, dan perubahan apa yang menyertainya.

Tanpa catatan ini, Anda hanya menebak. Dan menebak saat insiden sangat mahal.

Rollback: Jaring Pengaman yang Dibangun Sebelum Dibutuhkan

Ketertelusuran memberi Anda jawaban atas "apa yang berjalan?" Rollback memberi Anda jawaban atas "bagaimana cara kembali ke sesuatu yang berfungsi?"

Rollback adalah proses mengembalikan aplikasi ke versi image sebelumnya yang diketahui stabil. Tapi Anda tidak bisa melakukannya secara efektif di tengah insiden. Anda perlu mempersiapkannya sebelum deployment.

Strategi rollback yang baik dimulai dengan tiga pertanyaan:

1. Apakah image sebelumnya masih tersedia di registry?
2. Apakah deployment manifest sebelumnya masih bisa digunakan?
3. Apakah image sebelumnya kompatibel dengan konfigurasi saat ini?

Banyak tim menyimpan deployment manifest mereka di Git. Setiap kali melakukan deployment, mereka melakukan commit manifest dengan digest yang tepat. Jika terjadi kesalahan, mereka dapat mengembalikan manifest ke commit sebelumnya dan melakukan deploy ulang. Ini sederhana, dapat diaudit, dan berfungsi di berbagai lingkungan.

Di Kubernetes, Anda dapat menggunakan kubectl rollout undo untuk kembali ke revisi sebelumnya. Perintah ini berfungsi karena Kubernetes menyimpan riwayat revisi deployment. Tapi Anda perlu mengkonfigurasi berapa banyak revisi yang disimpan. Terlalu sedikit, dan Anda kehilangan kemampuan untuk rollback cukup jauh. Terlalu banyak, dan Anda menghabiskan memori cluster untuk riwayat yang mungkin tidak pernah digunakan.

Kapan Rollback Berhasil dan Kapan Tidak

Rollback cepat dan efektif untuk masalah di tingkat aplikasi. Jika versi baru memperkenalkan bug dalam logika bisnis, atau pembaruan library merusak sesuatu, rollback ke image sebelumnya akan memulihkan layanan dengan cepat.

Tapi rollback bukan perbaikan universal. Jika masalahnya ada di skema database, rollback image aplikasi mungkin tidak membantu. Database mungkin sudah berada dalam kondisi yang tidak bisa ditangani oleh kode aplikasi lama. Jika masalahnya ada di konfigurasi yang diubah terpisah dari image, rollback image saja akan meninggalkan konfigurasi buruk tersebut.

Ketahui batasan mekanisme rollback Anda. Uji secara teratur. Pastikan tim Anda tahu kapan menggunakannya dan kapan harus mencari solusi lain.

Setelah Rollback, Perbaiki Akar Masalah

Rollback memulihkan layanan. Itu tidak memperbaiki masalah. Setelah Anda rollback dan pengguna tidak lagi terpengaruh, pekerjaan sesungguhnya dimulai.

Image yang menyebabkan masalah perlu diperbaiki. Pipeline harus terus berjalan dengan versi yang sudah dikoreksi. Image baru itu melalui proses yang sama: build, scan, promote, deploy. Rollback adalah jaring pengaman, bukan akhir dari perjalanan.

Beberapa tim membuat kesalahan dengan menganggap rollback sebagai langkah terakhir. Mereka rollback, menyatakan insiden selesai, dan melanjutkan. Bug yang sama muncul lagi di rilis berikutnya karena tidak ada yang menyelidiki akar masalah. Jangan biarkan itu terjadi.

Daftar Periksa Praktis

Sebelum deployment produksi Anda berikutnya, jalankan daftar periksa ini:

• Setiap image di pipeline direferensikan dengan digest, bukan hanya tag
• Deployment manifest disimpan di version control dengan digest yang tepat
• Image sebelumnya disimpan di registry setidaknya untuk N versi terakhir
• Prosedur rollback didokumentasikan dan diuji di lingkungan non-produksi
• Tim tahu perbedaan antara masalah yang bisa diperbaiki dengan rollback dan masalah yang membutuhkan pendekatan berbeda

Artinya bagi Tim Anda

Ketertelusuran dan rollback bukanlah topik lanjutan. Itu adalah kebersihan operasional dasar. Anda tidak memerlukan platform yang kompleks atau alat mahal untuk menerapkannya. Anda memerlukan disiplin dalam cara memberi tag image, cara mencatat deployment, dan cara mempersiapkan diri saat terjadi kesalahan.

Lain kali produksi gagal, pertanyaan pertama akan tetap sama: "Versi apa yang berjalan?" Dengan ketertelusuran image yang diterapkan, Anda akan memiliki jawabannya dalam hitungan detik. Dan dengan mekanisme rollback yang teruji, Anda akan dapat memulihkan layanan dalam hitungan menit, bukan jam.

Bangun jaring pengaman sebelum Anda membutuhkannya. Diri Anda di masa depan, yang sedang debugging jam 2 pagi, akan berterima kasih.