Apa yang Terjadi Setelah Rollback: Memverifikasi Bahwa Pemulihan Anda Benar-Benar Berhasil

Anda baru saja menekan tombol rollback. Deployment yang menyebabkan error, respons lambat, atau korupsi database sudah tidak ada. Aplikasi Anda kembali ke versi sebelumnya. Tim Anda bernapas lega.

Tapi apakah sistem benar-benar berfungsi?

Rollback atau roll-forward bukanlah akhir dari sebuah insiden. Itu adalah bagian tengah. Pertanyaan sebenarnya adalah apakah pemulihan itu sendiri memperkenalkan masalah baru, meninggalkan data sisa, atau merusak integrasi dengan layanan lain. Tanpa verifikasi yang tepat setelah pemulihan, Anda mungkin menyatakan insiden selesai padahal sistem masih rusak dengan cara yang baru muncul berjam-jam kemudian.

Risiko Tersembunyi dari Pemulihan

Saat Anda melakukan rollback aplikasi, Anda tidak sekadar memutar waktu. Versi lama kembali, tetapi lingkungan mungkin telah berubah. Skema database mungkin tidak cocok. File konfigurasi bisa jadi berasal dari versi yang lebih baru. Data yang ditulis oleh versi bermasalah tetap ada di database. Layanan yang bergantung pada format API baru kini menerima respons lama dan rusak.

Roll-forward dengan hotfix memiliki risikonya sendiri. Anda memperbaiki satu bug, tetapi hotfix mungkin mengubah hal lain. Nilai konfigurasi yang berfungsi dalam perbaikan darurat mungkin tidak tepat untuk operasi normal. Hotfix mungkin ditulis dengan cepat tanpa pengujian biasa, dan bisa mengandung cacatnya sendiri.

Inilah mengapa verifikasi setelah pemulihan bukanlah opsional. Ini adalah jaring pengaman yang menangkap masalah yang diciptakan oleh pemulihan itu sendiri.

Mulai dengan Smoke Test

Cara tercepat untuk memeriksa apakah sistem hidup adalah smoke test. Ini adalah serangkaian pemeriksaan singkat yang mengonfirmasi fungsi inti aplikasi Anda berfungsi. Bukan setiap fitur, bukan setiap kasus tepi, hanya jalur kritis yang diandalkan pengguna.

Smoke test yang baik untuk aplikasi web mungkin mencakup:

• Dapatkah pengguna masuk?
• Dapatkah mereka melihat dasbor utama?
• Dapatkah mereka mengirimkan formulir atau menyelesaikan transaksi?
• Apakah ada error di log aplikasi?

Pemeriksaan ini harus diotomatisasi. Jika smoke test Anda memerlukan seseorang untuk mengklik layar secara manual, itu akan dilewati saat tim lelah dan tertekan setelah insiden. Otomatiskan sehingga dalam hitungan menit setelah pemulihan selesai, smoke test berjalan dan memberikan hasil lulus atau gagal yang jelas.

Misalnya, smoke test otomatis sederhana menggunakan curl mungkin terlihat seperti ini:

#!/bin/bash
# Smoke test sederhana setelah rollback

BASE_URL="https://my-app.example.com"

# Periksa endpoint health
if ! curl -f -s -o /dev/null "$BASE_URL/health"; then
  echo "GAGAL: Endpoint health tidak dapat dijangkau"
  exit 1
fi

# Periksa halaman login dapat dimuat
if ! curl -f -s -o /dev/null "$BASE_URL/login"; then
  echo "GAGAL: Halaman login tidak dapat dimuat"
  exit 1
fi

# Periksa API mengembalikan 200 untuk endpoint kritis
if ! curl -f -s -o /dev/null "$BASE_URL/api/v1/status"; then
  echo "GAGAL: Endpoint status API gagal"
  exit 1
fi

echo "LULUS: Semua smoke test berhasil"

Bandingkan Metrik Sebelum dan Sesudah

Smoke test memberi tahu Anda bahwa aplikasi berjalan. Metrik memberi tahu Anda apakah aplikasi berjalan dengan baik.

Bandingkan metrik utama sebelum insiden, selama insiden, dan setelah pemulihan. Metrik yang penting tergantung pada aplikasi Anda, tetapi yang umum meliputi:

• Permintaan per detik
• Tingkat error (persentase permintaan yang gagal)
• Waktu respons rata-rata
• Penggunaan memori dan CPU
• Latensi kueri database

Jika tingkat error setelah pemulihan masih lebih tinggi daripada sebelum insiden, ada yang salah. Mungkin sebuah layanan tidak dimulai ulang dengan benar. Mungkin konfigurasi tidak di-rollback. Mungkin proses pemulihan itu sendiri memperkenalkan hambatan baru.

Jangan hanya mengandalkan satu metrik. Tingkat error rendah yang dikombinasikan dengan latensi tinggi masih bisa berarti sistem tidak sehat. Lihat gambaran keseluruhan.

Verifikasi Database Memerlukan Perhatian Ekstra

Pemulihan database adalah bagian yang paling rumit. Jika Anda mengembalikan database ke cadangan yang diambil sebelum deployment, data apa pun yang ditulis antara cadangan tersebut dan rollback akan hilang. Data itu mungkin mencakup transaksi pengguna, pesanan, atau perubahan konfigurasi.

Anda perlu memeriksa:

• Apakah data yang hilang dapat diterima dari perspektif bisnis?
• Dapatkah Anda memulihkan data kritis dari log atau sistem lain?
• Apakah ada catatan yatim piatu yang ditinggalkan oleh versi baru yang tidak dapat ditangani oleh versi lama?

Terkadang jawabannya adalah bahwa beberapa kehilangan data dapat diterima. Di lain waktu Anda perlu memulihkan catatan tertentu secara manual. Either way, Anda perlu tahu apa yang hilang dan memutuskan apakah perlu tindakan.

Periksa Integrasi dengan Sistem Lain

Aplikasi Anda tidak hidup dalam isolasi. Setelah pemulihan, versi lama mungkin tidak kompatibel dengan API yang diubah oleh tim lain saat deployment Anda berlangsung. Atau hotfix mungkin telah mengubah format data yang dikirim ke sistem pemantauan, logging, atau analitik.

Uji koneksi:

• Dapatkah aplikasi Anda masih memanggil API eksternal?
• Apakah API tersebut mengembalikan respons yang dapat diuraikan oleh versi Anda?
• Apakah layanan hilir menerima data yang mereka harapkan?

Masalah integrasi setelah pemulihan sering terjadi karena tim sering fokus pada aplikasi mereka sendiri dan melupakan layanan yang bergantung padanya atau yang bergantung padanya.

Verifikasi dari Perspektif Pengguna

Dasbor dan log menunjukkan apa yang dilakukan sistem. Mereka tidak selalu menunjukkan apa yang dialami pengguna. Seorang pengguna mungkin melihat halaman kosong yang tidak menghasilkan log error. Sebuah transaksi mungkin gagal secara diam-diam karena frontend tidak menampilkan pesan error.

Jika memungkinkan, minta pengguna internal untuk menguji fitur utama setelah pemulihan. Atau gunakan alat pemantauan pengguna nyata untuk memeriksa metrik seperti tingkat keberhasilan transaksi dan durasi sesi. Metrik ini sering mengungkapkan masalah yang terlewatkan oleh pemantauan infrastruktur.

Dokumentasikan Temuan Anda

Setelah verifikasi selesai, tuliskan apa yang terjadi. Dokumentasi ini memiliki dua tujuan:

1. Ini memberikan bukti bahwa pemulihan berhasil dan sistem kembali normal.
2. Ini membantu tim Anda meningkatkan proses deployment dan pemulihan untuk lain kali.

Sertakan apa yang salah, apa yang dilakukan pemulihan, apa yang Anda periksa selama verifikasi, dan masalah apa pun yang Anda temukan. Catatan ini akan membantu anggota tim lain yang menghadapi masalah serupa di masa depan.

Daftar Periksa Verifikasi Praktis

Berikut adalah daftar periksa singkat untuk digunakan setelah pemulihan apa pun:

Diagram alir berikut mengilustrasikan urutan verifikasi dengan titik keputusan di setiap langkah:

• Smoke test lulus untuk semua fungsi kritis
• Tingkat error kembali ke level sebelum insiden
• Waktu respons normal
• Penggunaan sumber daya (CPU, memori, disk) stabil
• Integritas database diperiksa, kehilangan data didokumentasikan
• Semua integrasi eksternal berfungsi
• Metrik yang berhadapan dengan pengguna menunjukkan perilaku normal
• Temuan didokumentasikan untuk referensi di masa depan

Akhir Sebenarnya dari Sebuah Insiden

Verifikasi setelah pemulihan bukanlah formalitas. Ini adalah garis pertahanan terakhir sebelum Anda menyatakan insiden selesai. Tanpanya, Anda berisiko menyebut sistem sehat padahal masih rusak dengan cara yang akan menciptakan insiden yang lebih besar nanti.

Saat Anda mengonfirmasi bahwa sistem benar-benar berfungsi, itulah saat insiden benar-benar berakhir. Segala sesuatu sebelumnya hanyalah pemulihan.