Ketersediaan Tinggi untuk Ketahanan TI

Ketersediaan Tinggi untuk Ketahanan TI

Lingkungan TI modern tidak pernah sekuat atau serumit ini. Organisasi kini menjalankan aplikasi penting di berbagai platform, termasuk cloud hybrid, infrastruktur terdistribusi, lokasi edge, dan beberapa zona ketersediaan.

Pada saat yang sama, tim yang bertanggung jawab untuk mengelola lingkungan ini sering kali diminta untuk mendukung lebih banyak sistem dengan sumber daya yang lebih sedikit. Hal itu menciptakan tantangan yang semakin besar bagi ketersediaan tinggi dan pemulihan bencana (HA/DR). HA/DR sangat penting untuk kelangsungan bisnis, tetapi pendekatan tradisional sering kali membutuhkan keahlian teknis yang mendalam, konfigurasi manual, dan pengawasan terus-menerus dari sejumlah kecil spesialis. Dalam realitas TI saat ini, model tersebut tidak lagi berkelanjutan.

Risiko dari HA/DR yang Terlalu Kompleks

Selama bertahun-tahun,ketersediaan tinggiHal itu diperlakukan sebagai disiplin ilmu khusus. Sekelompok kecil ahli memahami detail konfigurasi klaster, skrip failover, pengaturan kuorum, dan prosedur pemulihan. Pendekatan itu mungkin berhasil ketika lingkungan lebih kecil dan lebih terpusat.

Saat ini, tim yang sama mungkin bertanggung jawab atas ratusan beban kerja di berbagai sistem cloud, on-premises, dan hybrid. Ketika alat HA/DR sulit dipahami atau dioperasikan, organisasi menjadi bergantung pada beberapa orang kunci. Jika orang-orang tersebut tidak tersedia selama terjadi gangguan, bahkan rencana pemulihan “otomatis” pun dapat dengan cepat berubah menjadi proses manual yang menegangkan.

Di sinilah tempatnyawaktu hentiRisiko meningkat. Kesenjangan antara kompleksitas lingkungan dan kapasitas tim menjadi titik lemah dalam ketahanan bisnis.

Kesederhanaan dalam Ketersediaan Tinggi Bukan Berarti Kontrol yang Lebih Sedikit

Ada kesalahpahaman umum bahwa alat yang lebih sederhana kurang ampuh. Pada kenyataannya, solusi HA/DR yang dirancang dengan baik tidak menghilangkan kendali. Solusi tersebut justru mempermudah penerapan kendali secara konsisten.

HA/DR modern seharusnya mengurangi jumlah pekerjaan manual yang dibutuhkan dari administrator sambil tetap menerapkan kebijakan, ketergantungan, dan langkah pemulihan yang tepat. Alih-alih mengharapkan setiap anggota tim untuk memahami setiap detail teknis, perangkat lunak seharusnya memandu pengguna melalui alur kerja yang telah terbukti dan membantu mencegah kesalahan sebelum menyebabkan pemadaman.

Kesederhanaan semacam ini bukan tentang mengurangi kemampuan. Ini tentang membangun kecerdasan ke dalam sistem sehingga tim TI dapat fokus pada hasil, seperti menjaga ketersediaan aplikasi dan pulih dengan cepat ketika terjadi kesalahan.

Apa yang Seharusnya Disediakan oleh Bantuan Kemanusiaan/Penanggulangan Bencana Modern

Solusi HA/DR yang praktis seharusnya mempermudah pengelolaan ketahanan di seluruh tim TI. Artinya, kita harus melampaui kerumitan baris perintah dan memberikan administrator cara yang jelas dan terarah untuk melindungi sistem-sistem penting.

Alat bantu kesehatan/penanganan trauma yang efektif harus mencakup:

• Alur konfigurasi sederhana:Pengaturan terpandu yang membantu tim melindungi aplikasi seperti SQL Server, SAP, Oracle, dan beban kerja penting bisnis lainnya tanpa bergantung pada konfigurasi manual yang panjang.
• Otomatisasi berbasis kebijakan:Sistem cerdas yang mengetahui secara tepat bagaimana dan di mana harus memulai ulang layanan ketika terjadi kegagalan, berdasarkan aturan bisnis yang telah ditentukan sebelumnya.
• Visibilitas yang jelas:Tampilan terpadu untuk memantau kesehatan seluruh tumpukan aplikasi, sehingga tim dapat dengan cepat memahami apa yang terjadi selama insiden.
• Pembatas jalan terintegrasi:Pemeriksaan validasi proaktif yang mengidentifikasi masalah konfigurasi, penundaan jaringan, atau ketidaksesuaian patch sebelum mengganggu pemulihan.

Secara bersama-sama, kemampuan-kemampuan ini membuat HA/DR (High Availability/Disaster Recovery) lebih mudah diprediksi, lebih mudah diulang, dan lebih mudah dikelola oleh tim di bawah tekanan.

Memberdayakan Tim, Bukan Menggantikan Para Ahli

Mempermudah penggunaan HA/DR bukan berarti menghilangkan kebutuhan akan tenaga profesional TI yang berpengalaman. Hal ini membantu mereka fokus pada pekerjaan yang bernilai lebih tinggi.

Ketika proses pemeliharaan rutin, pemantauan, dan failover lebih mudah dikelola, arsitek dan spesialis senior dapat menghabiskan lebih sedikit waktu untuk mengelola konfigurasi klaster yang kompleks dan lebih banyak waktu untuk meningkatkan strategi, merencanakan proyek modernisasi, dan memperkuat ketahanan organisasi secara keseluruhan.

Pada saat yang sama, tim TI umum mendapatkan kepercayaan diri untuk mendukung sistem kritis dengan aman. Ketika hambatan masuk lebih rendah, lebih banyak orang dapat merespons secara efektif selama insiden tanpa takut memperburuk situasi.

Mengapa Kesederhanaan Penting untuk Ketahanan TI

Ketersediaan tinggi dan pemulihan bencana bukan hanya fungsi teknis. Ini adalah persyaratan bisnis. Ketika terjadi gangguan, kemampuan organisasi untuk pulih dengan cepat memengaruhi produktivitas, kepercayaan pelanggan, pendapatan, dan reputasi.

Dalam situasi krisis, kompleksitas memperlambat respons. Alat HA/DR yang jelas, otomatis, dan mudah digunakan membantu tim bertindak dengan percaya diri dan konsisten. Dengan mengurangi beban operasional pada administrator, organisasi dapat meningkatkan waktu pemulihan dan membuat waktu operasional lebih mudah diprediksi.

Bagi tim TI modern, kesederhanaan bukan lagi sekadar kenyamanan. Ini adalah bagian penting dari bisnis danKetahanan TI.

Siap menyederhanakan strategi ketahanan bisnis Anda?Hubungi kami hari iniuntuk mempelajari bagaimana solusi HA/DR otomatis kami dapat melindungi beban kerja penting Anda dan memberdayakan tim TI Anda tanpa kerumitan tambahan.

PengarangBenjamin Roy, Spesialis Pemasaran di SIOS

Direproduksi dengan izin dariSIOS

Manajemen Patch

Manajemen Patch

Solusi manajemen patch membantu tim TI menerapkan pembaruan, menguji patch, dan menjaga keamanan tanpa waktu henti yang direncanakan. Video ini menjelaskan bagaimana SIOS DataKeeper dan LifeKeeper memungkinkan penerapan patch dengan waktu henti mendekati nol melalui pengelompokan ketersediaan tinggi, pembaruan node siaga, dan failover otomatis, membantu organisasi tetap aman, patuh, dan tanpa gangguan.

Direproduksi dengan izin dariSIOS

Pengamatan dan Perhitungan: Menerapkan Pengalaman untuk Pengambilan Keputusan Bisnis yang Lebih Baik

Pengamatan dan Perhitungan: Menerapkan Pengalaman untuk Pengambilan Keputusan Bisnis yang Lebih Baik

Di dalambagian pertama dari seri iniSebelumnya, kami telah membahas bagaimana perkiraan dapat membantu memandu keputusan bisnis ketika tidak ada jawaban yang sempurna. Artikel ini mengembangkan ide tersebut dengan meneliti bagaimana observasi dan pengalaman membentuk penilaian yang lebih baik dari waktu ke waktu, membantu para profesional membuat keputusan yang lebih tepat dalam situasi di masa mendatang.

Mengapa Observasi Sangat Penting untuk Pengambilan Keputusan yang Lebih Baik

Ada banyak hal yang dapat dipelajari dari cara para matematikawan kuno mengambil inspirasi dari dunia di sekitar mereka untuk praktik dan studi mereka. Hal ini masuk akal karena pada masa itu, matematika lebih didorong untuk meringankan kesulitan masalah praktis sehari-hari: merepresentasikan kuantitas besar secara ringkas, bagaimana membagi lahan yang berbentuk tidak beraturan secara merata, menghitung bunga pinjaman, dan sebagainya. Jawaban atas masalah-masalah ini memiliki banyak implikasi teoretis yang lebih luas, tetapi didorong oleh pengamatan dunia nyata dan membantu menginformasikan praktik-praktik di masa mendatang.

Anda tidak selalu dapat memunculkan atau mengingat rumus atau perilaku sempurna untuk memprediksi atau menjelaskan segala sesuatu. Terutama ketika Anda tidak memiliki keuntungan dari kemajuan dan ketelitian matematika selama 2.000 tahun sebagai landasan. Di zaman kita sekarang, kita cenderung mencemooh temuan anekdot, dan dalam banyak kasus (matematika, ilmiah, medis), itu benar adanya. Tapi kita tidak membicarakan itu sekarang! Observasi adalah alat yang sangat ampuh, mungkin yang paling ampuh, dalam hubungan interpersonal. Ini bisa berupa hubungan di dalam perusahaan Anda atau hubungan eksternal dengan pengguna, pelanggan, atau mitra.

Menggunakan Pengalaman untuk Meningkatkan Keputusan di Masa Depan

Namun, masalah besar dengan observasi adalah sifatnya yang berdasarkan pengalaman. Tidak mungkin Anda mencoba mengamati sesuatu sebelum hal itu benar-benar terjadi, dan terkadang menunggu sampai sesuatu benar-benar terjadi untuk mencari tahu apa yang harus dilakukan sudah terlambat.

Di sinilah perhitungan proaktif berperan. Anda menggunakan pengetahuan Anda tentang situasi serupa untuk membangun ekspektasi tentang apa yang Anda harapkan akan terjadi, dan Anda dapat mempersiapkan diri sebelumnya untuk mengatasi situasi tersebut dan mengarahkannya menuju hasil yang Anda inginkan. Ini bukan Teorema Pythagoras, tetapi dalam konteks hubungan sosial dan bisnis, ini tetap merupakan pendekatan yang sangat terencana.

Siklus Pengamatan dan Perhitungan

Keduanya membentuk sebuah siklus. Anda mengamati sesuatu, Anda belajar darinya, pengamatan itu menjadi dasar perhitungan Anda di masa depan, perhitungan tersebut membantu Anda mempersiapkan diri dengan lebih baik untuk situasi di masa mendatang, dan seterusnya. Ini seperti permainan sulap.

Menerapkan Observasi pada Rapat dan Hubungan Bisnis

Dengan mengingat hal itu, Anda dapat mulai melihat bagaimana menerapkannya pada bisnis dan hubungan Anda. Dari mana pengamatan Anda berasal, apa saja yang diamati, dan di mana pengamatan tersebut dicatat?

Kemungkinan besar, catatan tersebut berasal dari pertemuan dan kegiatan Anda, sehingga pengamatan tersebut tersimpan dalam ingatan Anda dan (idealnya) dalam catatan atau notulen yang telah direkam. Oleh karena itu, saat Anda menyusun catatan dan notulen, Anda harus mempertimbangkan bagaimana memanfaatkannya sebaik mungkin sebagai arsip dari apa yang Anda amati dan alami dalam pertemuan tersebut.

Beberapa hal penting yang mungkin ingin Anda catat pengamatannya meliputi:

• Pengaturan waktu
• Budaya yang diamati
• Sejarah lisan
• Orang-orang yang hadir (beserta tanggung jawab mereka)
• Kekhawatiran yang disampaikan

Kemudian, ketika Anda harus melakukannya lagi, Anda dapat melihat kembali pengamatan tersebut dan mulai mengajukan pertanyaan seperti:

• “Bagaimana saya bisa melakukan ini dengan lebih baik lain kali?” atau
• “Apa yang akan saya lakukan jika mereka mengatakan <ini> sebagai gantinya?”

Itulah perhitungan Anda.

Membangun Kemampuan Pengambilan Keputusan Bisnis yang Lebih Baik Melalui Pengalaman

Bagian terbaiknya adalah, terlepas dari semua kerja pikiran, pembuatan hipotesis, dan perhitungan, apa yang Anda temukan tetaplah sebuah pendekatan terhadap situasi dunia nyata konkret yang akan Anda alami. Hal itu membuatnya terasa jauh lebih mudah didekati, dan sangat mudah untuk melihat kapan dan bagaimana hal itu membuahkan hasil saat Anda mulai menerapkan pelajaran-pelajaran ini. Ditambah lagi, mungkin Anda akan merasa nyaman atau bahkan bangga karena mengetahui bahwa Anda menggunakan praktik-praktik yang telah digunakan dan disempurnakan sejak zaman kuno! Sama seperti orang-orang zaman dahulu, Anda akan merintis teori praktik Anda sendiri yang sepenuhnya didorong oleh pengalaman dan pengamatan Anda terhadap dunia di sekitar Anda.

Penulis: Matthew Pollard

Direproduksi dengan izin dariSIOS

Mengapa Ketersediaan Tinggi dan Pemulihan Bencana Kini Menjadi Prioritas Bisnis

Mengapa Ketersediaan Tinggi dan Pemulihan Bencana Kini Menjadi Prioritas Bisnis

Ketersediaan tinggiDanpemulihan bencanaDulunya, hal-hal tersebut terutama dipandang sebagai tanggung jawab TI. Hal-hal itu penting, tetapi sering diperlakukan sebagai pengamanan teknis yang dikelola di balik layar.

Pola pikir itu sedang berubah.

Dalam ekonomi digital saat ini, waktu aktif sistem (uptime) terkait langsung dengan pendapatan, produktivitas, pengalaman pelanggan, dan kepercayaan merek. Ketika sistem penting mengalami gangguan, dampaknya meluas jauh melampaui bidang TI. Transaksi terhenti, karyawan kehilangan akses ke alat-alat penting, pelanggan menjadi frustrasi, dan kepercayaan organisasi dapat terkikis dengan cepat.

Ketersediaan tinggi (HA) dan pemulihan bencana (DR) bukan lagi sekadar persyaratan teknis. Keduanya merupakan bagian penting dari kesinambungan bisnis, manajemen risiko, dan ketahanan jangka panjang.

Poin-Poin Penting

• Waktu henti (downtime) merupakan risiko perusahaan:Ketersediaan Tinggi dan Pemulihan Bencana bukan lagi sekadar tugas TI; keduanya sangat penting bagi pendapatan, kepercayaan merek, dan kelangsungan bisnis.
• Ketahanan siber adalah suatu keharusan:Dengan ransomware yang menargetkan cadangan data, pemulihan bencana modern membutuhkan infrastruktur yang terisolasi dan tidak dapat diubah untuk menjamin pemulihan yang bersih.
• Kompleksitas membutuhkan otomatisasi:Lingkungan hybrid, multi-cloud, dan kontainer modern membutuhkan failover otomatis dan pemantauan berbasis AI untuk mengelola ketahanan secara efektif.
• Pengujian proaktif sangat penting:Teknik seperti rekayasa kekacauan (chaos engineering) memungkinkan tim TI untuk memvalidasi kesiapan pemulihan tanpa mengganggu beban kerja produksi.
• Selaraskan ketahanan dengan dampak bisnis:Tujuan Waktu Pemulihan (RTO) dan Tujuan Titik Pemulihan (RPO)Harus ditentukan oleh kebutuhan keuangan, operasional, dan peraturan yang spesifik.

Menghitung Biaya Sebenarnya dari Waktu Henti Sistem TI

Biaya akibat waktu henti terus meningkat seiring dengan semakin bergantungnya organisasi pada sistem digital. Satu kali gangguan saja dapat menyebabkan kerugian finansial, penundaan operasional, masalah kepatuhan, dan kerusakan reputasi.

Bagi organisasi layanan kesehatan, gangguan sistem dapat menunda akses ke informasi pasien atau mengganggu perawatan. Bagi produsen, hal itu dapat menghentikan jalur produksi. Bagi perusahaan jasa keuangan, hal itu dapat mengganggu transaksi dan merusak kepercayaan pelanggan. Bahkan gangguan singkat pun dapat menimbulkan konsekuensi jangka panjang.

Gangguan layanan publik juga dengan cepat menarik perhatian. Insiden CrowdStrike tahun 2024 menunjukkan bagaimana satu gangguan teknologi dapat memengaruhi maskapai penerbangan, bank, dan penyedia layanan kesehatan di seluruh dunia. Namun saat ini, organisasi menghadapi ancaman yang lebih disengaja: serangan siber yang ditargetkan. Operator ransomware sekarang secara aktif menargetkan repositori cadangan untuk mencegah organisasi memulihkan sistem mereka. Karena itu, pemulihan bencana menyatu dengan keamanan siber. Para pemimpin TI mengalihkan fokus mereka ke ketahanan siber dengan memastikan mereka memiliki cadangan yang terisolasi (air-gapped) dan tidak dapat diubah (immutable) yang tidak dapat dienkripsi. Pendekatan ini memungkinkan mereka untuk memulihkan lingkungan yang “diketahui bersih” tanpa membayar tebusan.

Bagaimana Kompleksitas Cloud dan IT Hibrida Mempengaruhi Pemulihan Bencana

Lingkungan TI saat ini lebih terdistribusi dan kompleks daripada sebelumnya. Organisasi beralih dari mesin virtual tradisional, memindahkan aplikasi penting ke berbagai platform multi-cloud, lingkungan hibrida, dan infrastruktur berbasis kontainer seperti Kubernetes. Setiap lapisan memperkenalkan ketergantungan yang harus dipahami dan dilindungi. Ketika aplikasi cloud-native modern mengalami gangguan, tim tidak dapat hanya memulihkan server. Mereka harus memulihkan platform orkestrasi, konfigurasi cloud, dan infrastruktur sebagai kode (IaC) yang membuat aplikasi tersebut berjalan.

Pada saat yang sama, tim TI diharapkan untuk menjaga ketersediaan sistem sambil mengelola patch, peningkatan, perubahan konfigurasi, persyaratan keamanan, dan kebutuhan bisnis yang terus berkembang. Banyak tim juga beroperasi dengan sumber daya terbatas atau menghadapi pergantian personel yang menciptakan kesenjangan pengetahuan.

Kompleksitas ini membuat ketahanan lebih sulit dicapai hanya melalui teknologi. Organisasi membutuhkan proses yang jelas, tim yang terlatih, prosedur yang terdokumentasi, dan alat yang menyederhanakan ketersediaan di berbagai lingkungan.

Strategi HA dan DR yang kuat membantu mengurangi beban ini. Dengan meningkatkan visibilitas, mengotomatiskan tindakan pemulihan, dan menyederhanakan manajemen, organisasi dapat membantu tim TI merespons lebih cepat dan dengan keyakinan yang lebih besar.

Mengintegrasikan HA dan DR ke dalam Operasi TI Harian

Ketersediaan tinggi (high availability/HA) dan pemulihan bencana (disaster recovery/DR) dulunya diperlakukan sebagai disiplin ilmu yang terpisah. HA berfokus pada menjaga sistem tetap berjalan selama kegagalan lokal, sementara DR berfokus pada pemulihan dari gangguan yang lebih besar seperti pemadaman pusat data, peristiwa regional, atau bencana alam.

Saat ini, organisasi membutuhkan pendekatan yang lebih terpadu.

HA dan DR seharusnya menjadi bagian dari operasi TI sehari-hari, termasuk pemeliharaan rutin, patching, pembaruan sistem, dan perubahan konfigurasi. Alih-alih hanya menganggap aktivitas ini sebagai risiko terhadap ketersediaan, tim dapat menggunakannya untuk memvalidasi proses failover dan memastikan kesiapan pemulihan.

Pengujian rutin sangat penting. Rencana pemulihan yang hanya ditinjau sekali atau dua kali setahun mungkin tidak mencerminkan infrastruktur, ketergantungan aplikasi, atau realitas kepegawaian saat ini. Pendekatan HA dan DR modern memungkinkan pengujian yang lebih sering, seringkali tanpa mengganggu beban kerja produksi.

Hal ini menggeser ketahanan dari upaya reaktif menjadi praktik proaktif.

Menguji Kegagalan Sebelum Terjadi

Setiap organisasi pada akhirnya akan menghadapi gangguan. Kegagalan dapat berasal dari masalah perangkat keras, bug perangkat lunak, kesalahan manusia, insiden siber, gangguan layanan cloud, atau peristiwa eksternal yang tidak terduga. Yang terpenting adalah seberapa cepat dan efektif organisasi dapat merespons.

Pengujian ketahanan terkontrol, termasuk praktik seperti rekayasa kekacauan (chaos engineering), dapat membantu.

Rekayasa kekacauan (chaos engineering) melibatkan pengenalan kegagalan terkontrol ke dalam suatu sistem untuk memahami bagaimana sistem tersebut merespons di bawah tekanan. Tujuannya adalah untuk mengungkap kelemahan sebelum menyebabkan gangguan nyata. Tes-tes ini membantu tim mengidentifikasi ketergantungan tersembunyi, meningkatkan prosedur pemulihan, dan memperjelas peran selama insiden.

Konsepnya mirip dengan latihan simulasi keadaan darurat. Tim yang berlatih dalam kondisi terkontrol akan lebih siap ketika terjadi gangguan nyata.

Dengan alat yang tepat, tim TI dapat memvalidasi konfigurasi, memastikan kesiapan failover, dan melatih staf tanpa harus mematikan sistem produksi. Hal ini membangun kepercayaan operasional sekaligus mengurangi risiko kegagalan yang tidak terduga.

Otomatisasi Sangat Penting untuk Ketahanan

Seiring berkembangnya infrastruktur, proses pemulihan manual menjadi lebih sulit dikelola. Respons yang dipimpin manusia dapat lambat, tidak konsisten, dan rawan kesalahan, terutama selama insiden bertekanan tinggi.

Otomatisasi kini sangat penting untuk HA (High Availability) dan DR (Disaster Recovery) yang efektif, dan dengan cepat berkembang menjadi ketahanan berbasis AI. AI defensif otomatis dapat memantau sistem untuk mendeteksi anomali dan memicu failover cerdas sebelum terjadi kerusakan total. Analitik prediktif membantu mengidentifikasi pola yang menandakan kegagalan perangkat keras atau lonjakan lalu lintas di masa mendatang. Ketika tim dapat bertindak berdasarkan tanda-tanda peringatan dini ini, mereka dapat menyelesaikan masalah sebelum pengguna terpengaruh.

Kemudahan penggunaan juga penting. Solusi HA dan DR seharusnya tidak memerlukan pengetahuan spesialis yang mendalam untuk setiap tugas. Antarmuka yang jelas, konfigurasi yang disederhanakan, dan visibilitas yang kuat membantu tim TI generalis mengelola ketahanan secara lebih efektif. Hal ini mengurangi beban operasional dan menurunkan kemungkinan kesalahan.

Prioritas Bisnis Harus Menjadi Panduan untuk Perlindungan

Tidak semua aplikasi memerlukan tingkat perlindungan yang sama. Beberapa sistem dapat mentolerir penundaan singkat atau kehilangan data yang terbatas. Sistem lain harus tetap tersedia dengan gangguan minimal.

Itulah mengapa perencanaan HA dan DR harus dimulai dengan dampak bisnis.

Organisasi perlu mengidentifikasi aplikasi mana yang paling penting, bagaimana waktu henti akan memengaruhi operasional, dan tingkat pemulihan apa yang dibutuhkan. Tujuan Waktu Pemulihan (RTO) dan Tujuan Titik Pemulihan (RPO) harus mencerminkan kebutuhan bisnis yang sebenarnya, bukan asumsi.

Hal ini membantu menghindari dua masalah umum: terlalu melindungi beban kerja yang kurang penting dan kurang melindungi sistem yang penting.

Keselarasan ini bukan lagi sekadar praktik terbaik, karena dalam banyak kasus, ini merupakan persyaratan hukum. Pemerintah dan badan pengatur menjadikan ketahanan operasional sebagai mandat yang ketat. Regulasi seperti Digital Operational Resilience Act (DORA) di Eropa dan aturan pengungkapan SEC yang lebih ketat di AS memaksa dewan direksi untuk membuktikan kemampuan pemulihan mereka, bukan hanya mendokumentasikannya.

Ketika strategi HA dan DR selaras dengan prioritas bisnis, para pemimpin dapat lebih mudah menunjukkan kepatuhan kepada auditor dan membuat keputusan yang lebih baik tentang investasi infrastruktur. Ketahanan menjadi lebih mudah dibenarkan ketika dikaitkan langsung dengan hasil bisnis.

Keterlibatan eksekutif juga sangat penting. Ketersediaan harus dibahas bersamaan dengan risiko keuangan, kepatuhan, pengalaman pelanggan, dan kinerja operasional. Ketika kepemimpinan memahami waktu operasional sebagai tanggung jawab bersama, ketahanan menjadi bagian dari budaya organisasi.

Membangun Budaya Kesiapsiagaan

Beberapa tahun terakhir telah menunjukkan bahwa gangguan dapat datang dari berbagai arah. Kegagalan perangkat lunak, masalah rantai pasokan, serangan siber, perubahan staf, masalah infrastruktur, dan gangguan layanan cloud semuanya dapat memengaruhi hal tersebut.kelangsungan bisnis.

Organisasi yang paling tangguh melakukan lebih dari sekadar membangun sistem yang redundan. Mereka menciptakan budaya kesiapan.

Artinya, mendokumentasikan rencana pemulihan, mengujinya secara berkala, memperbarui prosedur seiring perubahan lingkungan, dan menjadikan ketahanan sebagai bagian dari pengambilan keputusan TI sehari-hari. Ini juga berarti memastikan bahwa pengetahuan penting tidak hanya berada di tangan satu orang atau tim.

Kesiapsiagaan bukanlah proyek sekali jalan. Ini adalah disiplin yang berkelanjutan.

Dengan mengintegrasikan HA (High Availability) dan DR (Disaster Recovery) ke dalam operasional sehari-hari, organisasi dapat mengurangi ketidakpastian dan meningkatkan kemampuan mereka untuk memberikan layanan yang andal bahkan dalam menghadapi peristiwa yang tidak terduga.

Kesimpulan

Ketersediaan tinggi dan pemulihan bencana telah melampaui sekadar persyaratan teknis. Keduanya kini menjadi komponen inti dari ketahanan bisnis.

Organisasi bergantung pada aplikasi-aplikasi penting untuk melayani pelanggan, menghasilkan pendapatan, mendukung karyawan, dan menjaga kepercayaan. Ketika aplikasi-aplikasi tersebut tidak tersedia, bisnis akan langsung merasakan dampaknya.

Seiring dengan semakin kompleksnya lingkungan TI, ketahanan membutuhkan kombinasi yang tepat antara sumber daya manusia, proses, dan teknologi. Organisasi yang menjadikan HA (High Availability) dan DR (Disaster Recovery) sebagai bagian dari perencanaan bisnis yang lebih luas akan lebih siap untuk mengelola gangguan, melindungi waktu operasional, dan menjaga kepercayaan di dunia yang tidak dapat diprediksi.

Tujuannya bukan lagi sekadar pulih setelah kegagalan. Tujuannya adalah untuk menjaga agar bisnis tetap berjalan!

PengarangBenjamin Roy, Spesialis Pemasaran di SIOS

Direproduksi dengan izin dariSIOS

Respons Insiden Pemulihan Bencana: Disiplin untuk Tidak Bereaksi Secara Impulsif

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