Latihan Pemulihan: Mengapa Anda Harus Berlatih Menghadapi Kegagalan Sebelum Terjadi di Produksi

Beberapa bulan lalu, sebuah tim yang saya dampingi memiliki rencana pemulihan yang terdokumentasi dengan baik. Rencana itu tersimpan di wiki mereka, lengkap dengan diagram, prosedur langkah demi langkah, dan daftar siapa yang harus dihubungi saat terjadi masalah. Semua orang merasa siap. Kemudian, suatu Selasa malam, sebuah migrasi database secara diam-diam merusak kolom yang digunakan oleh layanan checkout. Tim membuka wiki, mengikuti langkah rollback, dan menemukan bahwa skripnya sudah tidak berfungsi. Perubahan infrastruktur baru-baru ini telah mengganti nama beberapa resource, tetapi tidak ada yang memperbarui rencana pemulihan. Yang seharusnya menjadi rollback lima menit berubah menjadi pertarungan sengit selama dua jam.

Kesenjangan antara rencana tertulis dan kemampuan untuk menjalankannya di bawah tekanan itu nyata. Dan satu-satunya cara untuk menutup kesenjangan itu adalah dengan berlatih.

Masalah dengan Rencana Tertulis

Rencana pemulihan tertulis memang berguna. Mereka memaksa Anda untuk memikirkan skenario kegagalan, mendokumentasikan dependensi, dan menetapkan tanggung jawab. Tetapi rencana di atas kertas hanyalah sebuah hipotesis. Rencana itu mengasumsikan bahwa langkah-langkahnya masih akurat, skripnya masih berjalan, orang-orang yang terlibat masih tahu apa yang harus dilakukan, dan tidak ada yang berubah sejak dokumen terakhir diperbarui.

Dalam praktiknya, sistem perangkat lunak berubah terus-menerus. Dependensi ditingkatkan, konfigurasi bergeser, skema database berevolusi, dan anggota tim datang dan pergi. Rencana pemulihan yang sempurna enam bulan lalu mungkin sudah benar-benar rusak hari ini. Satu-satunya cara untuk mengetahuinya adalah dengan mencoba menjalankannya.

Ini bukan tentang tidak mempercayai tim Anda. Ini tentang mengakui bahwa sistem yang kompleks memiliki celah yang tidak terlihat. Skrip rollback mungkin gagal karena variabel lingkungan baru ditambahkan. Langkah verifikasi mungkin memakan waktu terlalu lama karena dasbor monitoring telah dikonfigurasi ulang. Seorang anggota tim mungkin tidak memiliki kredensial database yang tepat karena mereka baru bergabung minggu lalu. Celah-celah ini hanya muncul ketika Anda benar-benar menjalankan rencana tersebut.

Seperti Apa Bentuk Latihan Pemulihan

Latihan pemulihan adalah skenario kegagalan yang disimulasikan dan dijalankan di lingkungan yang aman. Tujuannya bukan untuk menimbulkan kepanikan. Tujuannya adalah untuk menguji apakah prosedur pemulihan Anda benar-benar berfungsi. Ada beberapa format umum.

Game day adalah yang paling terstruktur. Tim menyisihkan satu hari penuh atau setengah hari untuk menjalani beberapa skenario kegagalan. Misalnya, Anda mungkin sengaja mematikan layanan kritis dan mengamati apakah failover otomatis berjalan seperti yang diharapkan. Atau Anda mungkin mensimulasikan database yang rusak dan melihat berapa lama waktu yang dibutuhkan untuk memulihkan dari cadangan. Game day bersifat komprehensif, tetapi membutuhkan persiapan dan koordinasi yang signifikan.

Failure drill lebih pendek dan lebih terfokus. Anda memilih satu skenario spesifik dan menjalaninya dalam satu atau dua jam. Misalnya, simulasikan bahwa deployment terbaru memperkenalkan bug di alur pembayaran, lalu ukur berapa lama waktu yang dibutuhkan tim untuk rollback dan memverifikasi bahwa versi sebelumnya sehat. Failure drill lebih mudah dijadwalkan dan dapat dilakukan lebih sering.

Tabletop exercise adalah bentuk yang paling ringan. Tim berkumpul di sekitar papan tulis atau dokumen bersama dan membahas skenario kegagalan secara verbal. Tidak ada sistem nyata yang disentuh. Ini berguna untuk menguji pengambilan keputusan dan alur komunikasi, tetapi tidak memvalidasi apakah langkah-langkah teknis benar-benar berfungsi.

Latihan yang paling berharga adalah yang menyentuh sistem nyata di lingkungan staging atau pre-production. Di situlah celah tersembunyi berada.

Diagram di bawah ini menangkap loop inti dari latihan pemulihan, dari simulasi hingga pembaruan rencana.

flowchart TD A[Simulasikan kegagalan di staging] --> B[Jalankan rencana pemulihan sesuai tertulis] B --> C{Amati hasilnya} C -->|Rencana berhasil| D[Dokumentasikan kondisi sukses] C -->|Rencana gagal| E[Identifikasi celah] E --> F[Perbaiki skrip, dokumen, atau akses] D --> G[Perbarui rencana pemulihan] F --> G G --> H[Jadwalkan latihan berikutnya] H --> A

Mengapa Kegagalan Saat Latihan Itu Berharga

Sangat menggoda untuk memperlakukan latihan pemulihan sebagai latihan lulus-gagal. Jika latihan berhasil, tim merasa senang. Jika gagal, tim merasa malu. Namun, cara pandang itu meleset dari tujuan.

Kegagalan selama latihan adalah anugerah. Itu berarti Anda menemukan masalah sebelum masalah itu mencapai produksi. Jika skrip rollback Anda gagal selama latihan, Anda punya waktu untuk memperbaikinya. Jika proses verifikasi Anda terlalu lama, Anda dapat mengoptimalkannya. Jika anggota tim tidak tahu cara memicu rollback, Anda dapat melatih mereka. Ini adalah masalah yang akan menyebabkan kerusakan nyata di produksi, tetapi sekarang masalah itu hanyalah peluang belajar.

Kebalikannya juga benar. Latihan yang berhasil mungkin memberi Anda kepercayaan diri yang palsu. Mungkin skenarionya terlalu sederhana. Mungkin tim memberikan perhatian ekstra karena mereka tahu itu adalah latihan. Mungkin lingkungan staging dikonfigurasi berbeda dari produksi. Latihan yang berhasil bukanlah bukti bahwa rencana pemulihan Anda kokoh. Itu hanyalah bukti bahwa rencana itu berhasil dalam kondisi spesifik tersebut.

Inilah mengapa latihan harus bervariasi. Rotasi skenario. Ubah waktu. Perkenalkan komplikasi yang tidak terduga. Semakin realistis latihannya, semakin berguna umpan baliknya.

Apa yang Diungkapkan Latihan di Luar Langkah Teknis

Latihan pemulihan mengungkap hal-hal yang tidak dapat ditangkap oleh dokumen apa pun. Latihan mengungkap siapa yang benar-benar memiliki akses untuk menjalankan rollback di produksi. Latihan menunjukkan apakah engineer yang sedang on-call menerima alert yang tepat dengan cukup cepat. Latihan menguji apakah komunikasi antar tim tetap jelas saat tekanan meningkat.

Saya pernah melihat latihan di mana skrip rollback berjalan sempurna, tetapi tim menghabiskan dua puluh menit untuk mencari tahu siapa yang memiliki wewenang untuk menyetujuinya. Saya pernah melihat latihan di mana langkah-langkah teknisnya benar, tetapi dasbor monitoring tidak menampilkan metrik yang tepat untuk mengonfirmasi bahwa sistem telah pulih. Ini adalah masalah organisasi dan proses yang hanya muncul saat Anda menjalankan latihan.

Seberapa Sering Anda Harus Berlatih

Frekuensi tergantung pada seberapa sering Anda melakukan deployment dan seberapa berisiko perubahan Anda. Tim yang melakukan deployment beberapa kali sehari harus berlatih setidaknya sebulan sekali. Tim yang melakukan deployment mingguan atau dua mingguan dapat berlatih setiap kuartal. Kuncinya adalah konsistensi. Satu latihan yang tidak pernah diulang hampir tidak berguna. Latihan kedua adalah saat Anda memverifikasi bahwa perbaikan dari latihan pertama benar-benar berfungsi. Latihan ketiga adalah saat prosesnya menjadi memori otot.

Setelah setiap latihan, dokumentasikan apa yang Anda pelajari dan perbarui rencana pemulihan Anda. Tambahkan langkah-langkah yang hilang. Perbaiki skrip yang rusak. Berikan akses kepada orang yang tepat. Rencana pemulihan yang diperbarui setelah setiap latihan menjadi dokumen hidup yang mencerminkan kenyataan, bukan artefak statis yang hanya mengumpulkan debu.

Daftar Periksa Singkat untuk Latihan Pertama Anda

Jika Anda belum pernah menjalankan latihan pemulihan, mulailah dari yang kecil. Pilih satu skenario yang membuat Anda khawatir. Itu bisa berupa deployment yang gagal, database yang rusak, atau layanan yang salah konfigurasi. Kemudian jalankan daftar periksa ini:

  • Pilih lingkungan yang aman (staging atau pre-production, bukan produksi).
  • Tentukan seperti apa kesuksesan itu (misalnya, sistem sehat dalam waktu 10 menit).
  • Tetapkan peran: siapa yang menjalankan latihan, siapa yang mengamati, siapa yang mencatat.
  • Jalankan skenario dan ikuti rencana pemulihan Anda persis seperti yang tertulis.
  • Catat waktu setiap langkah. Catat di mana rencana tidak jelas atau tidak lengkap.
  • Setelah latihan, diskusikan apa yang salah dan apa yang perlu diubah.
  • Perbarui rencana pemulihan dan jadwalkan latihan berikutnya.

Jangan bertujuan untuk kesempurnaan pada percobaan pertama. Bertujuanlah untuk belajar.

Intinya

Rencana pemulihan yang belum pernah diuji hanyalah sebuah harapan. Satu-satunya cara untuk mengetahui apakah tim Anda benar-benar dapat pulih dari kegagalan adalah dengan mensimulasikan kegagalan di lingkungan yang aman, mengamati apa yang terjadi, dan memperbaiki apa yang rusak. Latihan pemulihan bukan tentang membuktikan bahwa rencana Anda berhasil. Latihan ini tentang menemukan celah sebelum produksi menemukannya untuk Anda.