Respons Insiden Pemulihan Bencana: Disiplin untuk Tidak Bereaksi Secara Impulsif
Sebuah peringatan muncul, layanan berhenti merespons, tiket mulai menumpuk, dan seseorang berkata, “Kita perlu melakukan sesuatu!” Naluri untuk segera memulai aktivitas pemulihan itu dapat dimengerti, karena selama insiden, bertindak terasa produktif, sementara menunggu bisa terasa tidak bertanggung jawab. Di bawah tekanan seperti ini, melakukan hampir apa pun bisa terasa lebih baik daripada tidak melakukan apa pun.
Namun, beberapa keputusan yang paling merugikan adalah…pemulihan bencanaKesalahan terjadi bukan karena tidak ada yang bertindak, tetapi karena seseorang bertindak sebelum memahami apa yang telah terjadi. Filsuf Marcus Aurelius sering menulis tentang pentingnya memisahkan suatu peristiwa dari penilaian yang kita bentuk tentangnya. Kita pertama kali menerima kesan tentang apa yang telah terjadi, dan kemudian pikiran kita dengan cepat membentuk penjelasan. Jika kita tidak berhenti untuk memeriksa penjelasan itu dan tindakan yang mengarah pada keadaan tersebut, kita dapat mulai bereaksi terhadap suatu asumsi seolah-olah itu adalah fakta.
Mengapa Respons Insiden yang Impulsif Dapat Meningkatkan Risiko
Misalnya, anggaplah sebuah server tidak dapat dijangkau. Kesimpulan langsungnya mungkin server tersebut telah gagal, tetapi yang sebenarnya kita ketahui hanyalah bahwa kita tidak dapat berkomunikasi dengannya. Server tersebut mungkin masih berjalan sementara masalah jaringan mencegah kita untuk melihatnya.
Perbedaan itu penting dalam hallingkungan yang sangat tersediaMemindahkan aplikasi ke server lain secara manual mungkin dapat memulihkan layanan, tetapi juga dapat menciptakan situasi di mana kedua server mengira mereka seharusnya aktif. Dalam lingkungan ketersediaan tinggi, kondisi seperti ini sering disebut sebagai…skenario otak terbelah: dua sistem yang masing-masing bertindak seolah-olah mereka memiliki kepemilikan atas aplikasi atau sumber daya yang sama. Respons yang dimaksudkan untuk meningkatkan ketersediaan bagi pengguna akhir dapat menimbulkan risiko bagi aplikasi atau datanya.
Kita dapat mengamati masalah yang sama terjadi selama pemecahan masalah biasa pada komponen yang tidak kritis. Memulai ulang layanan mungkin dapat mengatasi masalah, tetapi juga mengubah kondisi yang ingin kita pahami. Setelah proses memulai ulang selesai, bukti yang berguna tentang masalah awal mungkin hilang. Kita mungkin telah memulihkan layanan tanpa mengetahui apa yang terjadi atau apakah hal itu mungkin terjadi lagi.
Perbedaan Antara Pengamatan dan Asumsi
Semua ini tidak menunjukkan bahwa tim harus berdiam diri selama pemadaman, karena Aurelius tidak menganjurkan keraguan, dan pengekangan tidak boleh menjadi alasan untuk penundaan atau ketidakaktifan. Intinya adalah bertindak berdasarkan apa yang kita ketahui, bukan berdasarkan apa yang kita takutkan akan terjadi. Saya pikir perbedaan itu mudah hilang ketika suatu insiden menjadi menegangkan. Orang-orang menginginkan pembaruan, peringatan terus muncul, dan periode keheningan dalam panggilan konferensi dapat terasa lebih lama dari yang sebenarnya. Seseorang mungkin menyarankan untuk melakukan reboot karena itu berhasil terakhir kali insiden kritis serupa terjadi.
Jadi, saran tersebut mulai terdengar seperti rencana, meskipun masalah saat ini mungkin memiliki penyebab yang berbeda, namun menunjukkan gejala yang serupa dengan masalah sebelumnya. Pengalaman dapat membantu, tetapi juga dapat menciptakan jalan pintas dalam pemikiran kita. Mengenali gejala yang familiar itu berguna; menganggapnya pasti memiliki penyebab yang sama dengan kejadian terakhir bukanlah hal yang tepat. Gejala serupa dapat berasal dari masalah yang sangat berbeda.
Respons yang lebih disiplin dimulai dengan hanya menyatakan apa yang telah dikonfirmasi. Alih-alih mengatakan, “Server sedang down,” pendekatan yang lebih baik mungkin adalah, “Server tidak merespons dari lokasi ini.” Susunan kata tersebut mungkin tampak seperti detail kecil, tetapi hal itu mencegah tim memperlakukan kesimpulan sebagai sebuah pengamatan. Hal itu juga memberi ruang bagi orang lain untuk melaporkan bahwa server dapat dijangkau dari tempat lain.
Mengapa Pemecahan Masalah yang Disiplin Penting Selama Pemadaman Listrik
Di sinilah respons insiden menjadi lebih dari sekadar pengetahuan teknis. Hal ini membutuhkan pengendalian diri atas keinginan untuk menyelesaikan masalah sebelum masalah tersebut dipahami. Terkadang, satu pengecekan tambahan sudah cukup untuk mengubah arah investigasi dan langkah selanjutnya.
Lokasi pemantauan kedua mungkin menunjukkan bahwa aplikasi masih tersedia secara internal, dan konsol lokal dapat mengkonfirmasi bahwa server yang diduga gagal sebenarnya sehat tetapi terisolasi. Informasi tersebut dapat mencegah tindakan pemulihan yang tidak perlu dan mengarahkan tim ke masalah sebenarnya.
Peran Otomatisasi dalam Pemulihan Bencana
Otomatisasi yang dirancang dengan baik mengikuti prinsip yang serupa. Otomatisasi berharga karena dapat merespons secara konsisten dan tidak perlu menunggu administrator bangun atau bergabung dalam panggilan. Namun, kecepatan saja tidak membuat respons otomatis menjadi benar.
Sistem otomatis harus bertindak ketika kondisi untuk pemulihan sudah jelas. Ketika informasi yang tersedia tidak lengkap atau saling bertentangan, perilaku yang lebih aman mungkin adalah berhenti dan mencari bukti lebih lanjut. Sistem dengan ketersediaan tinggi mempertimbangkan hal ini dalam beberapa cara. Jalur komunikasi independen dapat membantu membedakankegagalan satu koneksidari hilangnya seluruh server. Mekanisme kuorum atau saksi dapat memberikan perspektif lain ketika sistem tidak lagi dapat berkomunikasi satu sama lain. Kontrol ini penting karena pandangan sistem terhadap lingkungan mungkin akurat tetapi tidak lengkap.
Bagaimana SIOS LifeKeeper Mendukung Keputusan Pemulihan yang Lebih Cerdas
Penjaga KehidupanTeknologi ini dapat mendukung pengambilan keputusan melalui pemantauan sumber daya, penentuan dependensi, dan kebijakan pemulihan. Teknologi ini membantu melaksanakan proses tersebut.rencana pemulihan yang telah ditetapkanNamun, hal itu tidak dapat menentukan tingkat risiko apa yang dapat diterima untuk bisnis tertentu. Penilaian itu harus dilakukan oleh orang-orang saat lingkungan masih stabil, bukan diimprovisasi setelah suatu insiden terjadi.
Membangun Buku Panduan Insiden yang Lebih Baik untuk Pemulihan Bencana
Prosedur yang jelas mempermudah pengendalian. Buku panduan insiden yang baik harus membantu tim menetapkan apa yang diketahui sebelum melakukan perubahan yang berdampak besar. Buku panduan tersebut harus menjelaskan cara memastikan apakah aplikasi sudah aktif di tempat lain dan mengidentifikasi siapa yang berwenang untuk memulai pemulihan.
Tujuannya bukanlah untuk menghilangkan penilaian manusia. Tujuannya adalah untuk memberikan landasan yang andal bagi penilaian tersebut ketika waktu terbatas. Kita tidak dapat menghilangkan ketidakpastian dari teknologi; perangkat keras akan gagal, jaringan akan berperilaku tidak terduga, dan aplikasi terkadang akan mengejutkan orang-orang yang paling mengenalnya. Yang dapat kita lakukan adalah mempersiapkan diri untuk mengenali perbedaan antara suatu peristiwa dan penjelasan pertama kita tentangnya.
Disiplin dalam Pemulihan Bencana
Aurelius kembali pada gagasan itu karena gagasan tersebut paling relevan ketika keadaan sulit. Penilaian yang jernih mudah dilakukan ketika tidak ada yang dipertaruhkan. Nilainya menjadi relevan ketika tekanan membuat jawaban tercepat terasa seperti satu-satunya jawaban. Selama insiden, orang yang paling tenang di ruangan itu belum tentu tidak melakukan apa pun. Mereka mungkin memastikan bahwa tindakan selanjutnya menyelesaikan masalah yang sebenarnya terjadi. Dalam respons insiden, disiplin bukanlah ketiadaan tindakan. Disiplin adalah penolakan untuk membiarkan tekanan memilih tindakan untuk Anda.
Lindungi aplikasi penting dengan solusi ketersediaan tinggi dan pemulihan bencana yang dirancang untuk lingkungan TI yang kompleks.Minta demountuk melihat bagaimana SIOS LifeKeeper dapat membantu tim Anda mengurangi waktu henti dan pulih dengan percaya diri.
Ditulis oleh Aidan Macklen (Spesialis Dukungan Produk Madya)
Direproduksi dengan izin dariSIOS
