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

Ketersediaan Tinggi dan Pemulihan Bencana di Mana Saja: Dari Konsep Umum hingga Menghasilkan Solusi

Ketersediaan Tinggi dan Pemulihan Bencana di Mana Saja: Dari Konsep Umum hingga Menghasilkan Solusi

Blog Terkait / Rekomendasi Bacaan Pendukung

Dalam blog ini, diasumsikan pembaca sudah familiar dengan kerangka kerja Hierarki Sumber Daya LifeKeeper dan Klasterisasi LifeKeeper secara umum. Untuk latar belakang mengenai topik-topik ini, blog-blog yang tercantum di bawah ini memberikan konteks yang sangat baik. Selain itu, blog ini dibangun berdasarkan blog sebelumnya mengenai salah satu cara untuk menutup kesenjangan antara kemungkinan kasus penggunaan dan mekanisme perlindungan yang didukung melalui penggunaan “Quick Service Protection Application Recovery Kit” (QSP ARK) dalam LifeKeeper, yang tautannya ada di bawah.

• Klaster Linux/Pengelompokan Windows(Penulisan artikel ini ditujukan kepada Ibu Hoagland, Wakil Presiden Penjualan dan Pemasaran Global SIOS, dan Tim Pemasaran SIOS)
• Kecerdasan Aplikasi dalam Kaitannya dengan Ketersediaan Tinggi(Penulisan artikel ini ditulis oleh Ibu Hendricks-Sinke, Insinyur Sistem Senior, IT di SIOS)
• Tindakan sumber daya dan latar belakang tentangKit Pemulihan Aplikasi Generik(Tulisan ini ditulis oleh Bapak Birmingham, Senior Technical Evangelist)
• Memilih Antara GenApp dan QSP: Menyesuaikan Ketersediaan Tinggi untuk Aplikasi Kritis Anda(Penulisan artikel ini ditulis oleh Ibu Hendricks-Sinke, Insinyur Sistem Senior, IT di SIOS).

Namun, blog ini akan membahas opsi yang tersedia ketika QSP ARK tidak dapat memenuhi tuntutan Ketersediaan Tinggi dan Pemulihan Bencana untuk aplikasi atau kasus penggunaan tertentu.

Ringkasan Singkat

Bagian sebelumnya dari blog iniBagian ini membahas cara berpikir tentang sebuah aplikasi untuk tujuan menciptakan Generic Application Recovery Kit (GAP) guna melindungi aplikasi tersebut dengan LifeKeeper. Pada bagian ini, dasar-dasar pemahaman aplikasi yang disajikan pada bagian pertama akan dikontekstualisasikan untuk aplikasi tersebut dalam kerangka kerja Generic Application Recovery Kit LifeKeeper.

Karena bagian ini dalam rangkaian blog sebaiknya dipahami bersamaan dengan bagian sebelumnya, berikut adalah rangkuman singkat dari konsep-konsep yang disajikan di bagian 1.

Ajukan pertanyaan sesederhana mungkin yang tetap memberikan informasi bermanfaat/dapat ditindaklanjuti.

Dalam menentukan bagaimana pertanyaan luas akan dijawab, uraikan pertanyaan tersebut menjadi pertanyaan yang lebih kecil dengan jawaban yang lebih sederhana. Gunakan pertanyaan-pertanyaan yang lebih kecil tersebut untuk secara bertahap membangun kembali jawaban atas pertanyaan “luas” aslinya.

Gunakan informasi yang diberikan.

Pahami utilitas yang tersedia dan bagaimana utilitas tersebut menyampaikan informasi. Dengan mengetahui informasi yang dibutuhkan untuk menjawab “pertanyaan terkecil”, tentukan bagaimana informasi yang disajikan melalui API Aplikasi dapat digunakan untuk menentukan jawaban atas “pertanyaan terkecil” tersebut.

Setelah sesi penyegaran selesai, LifeKeeper akhirnya dapat diperkenalkan. Meskipun Ketersediaan Tinggi dan Pemulihan Bencana sering dikaitkan dengan kompleksitas, upaya signifikan telah dilakukan untuk memastikan bahwa pemahaman tentang aplikasi tertentu dapat dengan mudah diintegrasikan ke dalam kerangka kerja Generic Application Recovery Kit. Dengan fondasi sebelumnya, sekarang saatnya untuk menggunakannya sebagai dasar untuk berpikir seperti LifeKeeper.

Berpikir Seperti Penjaga Kehidupan

Bayangkan Anda berada dalam skenario “Freaky Friday”, seperti film di mana seorang gadis dan ibunya bertukar tubuh dan kesulitan menyesuaikan diri dengan tanggung jawab sehari-hari masing-masing. Orang yang tubuhnya Anda tukar sedang menghadiri kegiatan peluncuran (go-live) menggantikan Anda dan perlu mengetahui cara memulai aplikasi-aplikasi penting, memastikan aplikasi tersebut berjalan dengan benar, dan kemudian menghentikan aplikasi tersebut. Bagaimana Anda akan menjelaskan hal-hal ini kepada mereka jika Anda hanya memiliki waktu 15 menit untuk melakukan panggilan telepon? Detail apa saja yang perlu Anda sebutkan agar mereka dapat menyelesaikan pekerjaan tersebut?

Skenario ini, meskipun dibuat-buat, adalah cara yang bagus untuk menguraikan tindakan perlindungan sumber daya utama. LifeKeeper mengelola aplikasi untuk memastikan aplikasi tersebut hanya berjalan pada satu sistem, dan Hierarki Sumber Daya LifeKeeper memastikan bahwa aplikasi prasyarat dan sumber daya sistem diproses dalam urutan yang benar setiap kali sumber daya dipulihkan atau dihapus. Pada gilirannya, LifeKeeper memungkinkan pengembang untuk memikirkan tindakan pada aplikasi yang dilindungi dengan sumber daya Aplikasi Generik dalam konteks satu sistem. Menyederhanakan proses untuk melakukan start, stop, atau query pada aplikasi hingga ke hal-hal yang paling mendasar adalah langkah pertama untuk mendefinisikan apa yang perlu dicapai oleh skrip tindakan Aplikasi Generik. Ketika start, stop, dan query didefinisikan sesuai dengan strategi di atas, tindakan sumber daya berhubungan satu-ke-satu, seperti ini:

• Pulihkan Tindakan: Aplikasi Dimulai
• Hapus Tindakan: Aplikasi Berhenti
• Tindakan quickCheck: Aplikasi Kueri
  • CatatanTindakan QuickCheck bersifat opsional untuk Sumber Daya Aplikasi Generik, dan pemantauan tidak akan dilakukan jika tindakan QuickCheck tidak ditentukan. Namun, pemantauan aplikasi secara berkala sangat disarankan untuk memastikan hasil terbaik dalam mengimplementasikan Ketersediaan Tinggi dan Pemulihan Bencana!
• Aksi Pemulihan Lokal: Penghentian Aplikasi dan Mulai Aplikasi (secara berurutan)
  • CatatanTindakan Pemulihan Lokal bersifat opsional untuk Sumber Daya Aplikasi Generik. Jika Pemulihan Lokal tidak didefinisikan, Sumber Daya Aplikasi Generik tidak akan mencoba memulai ulang untuk memperbaiki dirinya sendiri pada sistem tempat kegagalan terdeteksi, tetapi akan berhenti pada sistem yang gagal, dan seluruh hierarki untuk aplikasi akan bermigrasi ke sistem siaga.

Terkadang, LifeKeeper perlu mengetahui detail tertentu tentang aplikasi yang sedang berjalan untuk melakukan tindakan yang tercantum di atas. Semua Sumber Daya LifeKeeper, termasuk Sumber Daya Aplikasi Generik, memiliki apa yang disebut “Bidang Informasi Sumber Daya”, yang tujuannya adalah untuk menyediakan informasi ini kepada skrip tindakan untuk digunakan selama tindakan sumber daya. Informasi sumber daya yang terdapat dalam bidang informasi dapat dikonfigurasi secara independen untuk setiap sistem pada saat perluasan sumber daya, memungkinkan tindakan sumber daya untuk menggunakan informasi spesifik untuk sistem tempat tindakan tersebut dilakukan. LifeKeeper juga menyediakan utilitas baris perintah untuk dengan mudah mendapatkan atau mengatur informasi sumber daya.

Merujuk kembali pada contoh “Freaky Friday”, detail apa saja yang perlu Anda sampaikan kepada orang yang Anda ajak bertukar peran? Pikirkan hal-hal seperti jalur utama untuk file aplikasi, pengaturan/nilai spesifik untuk argumen perintah, dan detail serupa. Bidang informasi adalah tempat yang tepat untuk menempatkan informasi yang harus diketahui untuk menentukan detail lain tentang aplikasi. Bidang informasi juga merupakan tempat yang tepat untuk memasukkan nilai untuk pengaturan, argumen perintah, atau nilai yang tidak dapat diperoleh dengan cara lain. Perlu dipertimbangkan, sesuai konvensi LifeKeeper, bahwa bidang informasi tidak sering (jika pernah) diubah selama masa pakai suatu sumber daya. Informasi yang bervariasi selama masa pakai suatu sumber daya sebaiknya tidak dimasukkan ke dalam informasi sumber daya untuk menghindari kerusakan bidang ini, dan sebagai gantinya diperoleh secara terprogram dalam skrip tindakan Sumber Daya LifeKeeper atau melalui skrip “pembantu” yang kemudian dapat dipanggil oleh skrip tindakan tersebut.

Sebagai bantuan tambahan, LifeKeeper dilengkapi dengan skrip templat untuk mengembangkan aplikasi generik. Ini merupakan titik awal yang fantastis untuk skrip aksi Aplikasi Generik, karena skrip tersebut telah disiapkan sebelumnya untuk menerima argumen masukan yang akan digunakan LifeKeeper saat memanggil aksi untuk sumber daya tertentu. Pada gilirannya, ini juga membuat informasi tersebut tersedia untuk digunakan dalam skrip aksi sumber daya.

Kesimpulan

LifeKeeper menyediakan beragam cara untuk melindungi aplikasi. Namun, beberapa aplikasi memiliki persyaratan di luar apa yang ditawarkan dalam LifeKeeper Application Recovery Kits. Dalam kasus seperti itu, perlindungan Ketersediaan Tinggi dan Pemulihan Bencana masih dimungkinkan, dan mungkin lebih mudah dicapai daripada yang diperkirakan sebelumnya. Aplikasi generik bukanlah sesuatu yang harus dihindari oleh suatu organisasi; sebaliknya, aplikasi generik adalah salah satu dari banyak alat ampuh yang ditawarkan oleh LifeKeeper untuk meningkatkan kemampuan Ketersediaan Tinggi dan Pemulihan Bencana suatu lingkungan. Kerangka kerja Aplikasi Generik dibuat agar mudah diakses dan serbaguna. Namun, jika organisasi Anda tidak memiliki sumber daya yang cukup untuk membuat Generic Application Recovery Kit sendiri, SIOS menawarkan Layanan Profesional di mana Insinyur SIOS akan mengoordinasikan persyaratan dan mengembangkan Generic Application Recovery Kit atas nama organisasi Anda. Jika dukungan berkelanjutan diperlukan, Layanan Profesional SIOS juga menyediakan penawaran yang memperluas dukungan produk normal untuk mencakup Aplikasi Generik yang dikembangkan oleh Layanan Profesional SIOS. Hambatan untuk melindungi aplikasi penting bisnis organisasi Anda semakin berkurang, dan SIOS Protection Suite untuk Linux atau Windows bertujuan untuk berada di garis depan dalam upaya menjadikan aplikasi yang tidak terlindungi sebagai sesuatu yang sudah ketinggalan zaman.

Tidak setiap aplikasi cocok dengan model ketersediaan tinggi standar. SIOS dapat membantu Anda merancang dan mengimplementasikan solusi LifeKeeper yang tepat untuk beban kerja penting bisnis Anda.Minta demoHari ini.

Penulis: Philip Merry, Insinyur Dukungan di SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Mengambil Alih Pengelolaan Klaster SIOS LifeKeeper untuk Linux

Mengambil Alih Pengelolaan Klaster SIOS LifeKeeper untuk Linux

Bayangkan Anda berdiri di luar mobil van Anda, menggendong bayi, meraih tas popok bayi ketika sebuah van hitam besar dengan garis merah berhenti di samping Anda. Pintu van perlahan terbuka, memperlihatkan sekelompok orang yang beragam. Sosok yang gagah keluar dari kendaraan, gaya rambut mohawk-nya menjulang tinggi ke langit, dan aura ketegasan yang kuat terpancar sebesar rantai emas di lehernya. Seorang veteran berpengalaman keluar dan memberi tahu Anda bahwa Anda sekarang adalah bagian integral dari operasi yang sangat penting.

Bayangkan Anda duduk di barisan depan, tengah kiri, di latihan eksklusif band favorit Anda. Anda mendengarkan mereka memainkan lagu-lagu hits favorit Anda, satu demi satu. Anda memainkan gitar udara mengikuti lagu-lagu klasik. Dengan ritme yang sempurna, Anda bergantian memukul-mukul kursi dan kaki Anda mengikuti irama drum. Akhirnya, Anda menemukan dua sedotan dari Big Gulp yang dibuang dan menggunakannya untuk menghentikan solo drum. Penantian seumur hidup telah berakhir, dan Anda akhirnya menjadi bagian dari penonton yang tiketnya terjual habis, tetapi tiba-tiba pemain drum berlari meninggalkan panggung, dan seorang manajer yang panik menunjuk Anda untuk naik ke panggung.

Carlos, an anjing Great Dane, adalah favorit utama untuk memenangkan gelar anjing terbaik di Big Boys Kennel Club. Anda hanya pernah mendengar tentang Carlos melalui rekan kerja yang menyukai anjing ras besar, tetapi hari ini Anda melihat sisi baru Carlos. Bahkan, Anda melihat setiap sisi Carlos karena pelatihnya baru saja mengantarkannya ke rumah Anda sementara dia menunggu di luar untuk mobil derek mengangkut van kerjanya dan mobil sewaan untuk membawa pengganti. “Hanya akan satu jam,” dia meyakinkan Anda. Tetapi menjaga anjing terbaik yang bernilai jutaan dolar agar terhindar dari bahaya bukanlah tugas yang mudah.

Jujur saja, kemungkinan besar A-Team asli atau versi aslinya tidak akan berhenti di samping mobil van Anda dan membawa Anda pergi untuk menjadi bagian dari acara rahasia, misi penting, dan penyelamatan negara. Demikian pula, peniruan Jimi Hendrix atau Sheila E terbaik Anda, dengan atau tanpa sedotan besar, mungkin tidak akan membawa Anda dari kerumunan ke sorotan pertunjukan yang tiketnya terjual habis. Dan meskipun Anda mungkin melihat Carlos atau favorit atau pemenang terbaik lainnya, kecuali Anda adalah pemilik, pelatih, atau juri, Anda kemungkinan besar tidak akan menghabiskan waktu tanpa pengawasan bersama mereka. Meskipun skenario ini tidak mungkin terjadi, ada kemungkinan Anda akan diminta untuk mengambil alih klaster LifeKeeper untuk Linux yang memiliki risiko, tanggung jawab, dan tingkat kekritisan yang serupa.

Apa yang Harus Dilakukan Saat Anda Mewarisi Klaster LifeKeeper untuk Linux

Banyak bisnis melaporkan bahwa kerugian akibat waktu henti (downtime) mencapai lebih dari $300.000 per jam, bahkan jutaan dolar. Perusahaan yang ingin menghindari bencana dan waktu henti seringkali menerapkan arsitektur yang kuat dengan redundansi di berbagai lapisan.

Selain redundansi ini, banyak perusahaan menerapkan perangkat lunak Ketersediaan Tinggi (High Availability/HA) sepertiSIOS LifeKeeper untuk LinuxUntuk menambahkan lapisan penting kemampuan pemantauan dan pemulihan pada infrastruktur, aplikasi, dan basis data yang sangat penting bagi bisnis mereka. LifeKeeper for Linux menyediakan pemantauan dan pemulihan sumber daya untuk infrastruktur, aplikasi, layanan, dan basis data, memastikan kelangsungan bisnis terjaga dan waktu henti diminimalkan atau dihindari. Meskipun tidak datang dalam bentuk mobil van hitam yang dikemudikan oleh petugas, ini sangat penting bagi misi bisnis.

Jadi, apa yang Anda lakukan jika tiba-tiba Anda bertanggung jawab sebagai administrator utama atau satu-satunya pengelola lingkungan LifeKeeper for Linux (LK-L) yang menghasilkan pendapatan lebih besar daripada beberapa lusin versi Carlos?

8 Langkah untuk Mengambil Alih Klaster SIOS LifeKeeper untuk Linux

Delapan langkah penting untuk mengambil alih klaster SIOS LifeKeeper for Linux meliputi:

1. Temukan dan tinjau buku panduan operasional (runbook) yang sudah ada.

Cari runbook yang sudah ada. Dokumen-dokumen ini biasanya tersimpan di repositori dokumen yang dibuat oleh administrator sebelumnya. Runbook yang detail sering memberikan wawasan tentang konfigurasi dan arsitektur klaster. Detail ini akan bermanfaat untuk administrasi dan operasi di masa mendatang.

2. Temukan versi produk LifeKeeper untuk Linux Anda.

Memahami versi produk Anda adalah bagian penting dari mengambil alih kepemilikan klaster. SIOS merilis pembaruan produk secara berkala yang menawarkan konten yang lebih kaya fitur, pembaruan keamanan, dan peningkatan. Saat Anda mengambil alih klaster produk yang sudah ada, Anda perlu mengetahui versi yang Anda gunakan agar dapat menilai beberapa faktor:

1. Di mana posisi produk Anda dalam siklus hidup produk dan dukungan?
2. Apakah Anda menggunakan versi produk terbaru?
3. Fitur baru atau perbaikan apa saja yang telah ditambahkan ke produk sejak versi Anda?
4. Di mana menemukan dokumentasi khusus versi?

Anda dapat menemukan versi produk melalui UI. Jika runbook Anda menunjukkan versi LifeKeeper 9.8.x atau yang lebih baru, Anda dapat menggunakan https://<servername>:5110 (atau https://<server_IP>:5110) untuk meluncurkan LifeKeeper Web Management Console (LKWMC). Setelah masuk, pilih properti:

Setelah halaman properti dimuat, temukan informasi versi Anda di bagian di bawah nama produk:

Jika Anda menggunakan versi LifeKeeper untuk Linux yang lebih lama,Aktifkan penerusan X11 dan luncurkan UI Java.melalui perintah /opt/LifeKeeper/bin/lkGUIapp dari sesi klien SSH.

Versi produk Anda juga dapat ditemukan melalui baris perintah sebagai berikut:

# rpm -qi steeleye-lk

Setelah Anda meluncurkan UI Java dan masuk, Anda dapat menuju ke halaman bantuan. Setelah Anda mendapatkan versi produk Anda, periksa siklus hidup produk dan informasi spesifik versi Anda melaluidocs.us.sios.com

3. Tinjau perjanjian dukungan teknis Anda

ItuPerjanjian Dukungan Teknis(TSA) menguraikan dukungan yang diberikan SIOS untuk produk-produk SIOS. TSA bermanfaat dalam mengidentifikasi informasi penting terkait pemeliharaan, peningkatan,dukungan produk, dan perbaikan produk. TSA juga memberikan informasi berharga mengenai penawaran dukungan 24/7 SIOS dan informasi kontak untuk akses. Memahami TSA sangat membantu untuk memastikan kepercayaan bahwa Anda tidak sendirian, tetapi didukung oleh tim SIOS. Memahami TSA juga membantu Anda menghindari kejutan selama penerapan dan pemeliharaan yang sedang berlangsung dengan mengidentifikasi apa yang tercakup dan tidak tercakup.

4. Ikuti Pelatihan Administrator SIOS

Jika transisi Anda mendesak, mungkin tidak ada administrator sebelumnya yang tersedia untuk memberikan pelatihan kepada Anda atau anggota tim baru Anda. Jangan panik. SIOS menyediakan pelatihan daring yang mudah diakses. Pelatihan ini memberikan gambaran komprehensif tentang produk LifeKeeper for Linux serta peran dan tindakan yang diperlukan untuk seorang administrator. Jika Perwakilan Akun Anda tercantum dalam buku panduan, hubungi mereka langsung untuk informasi lebih lanjut. Jika tidak, hubungisales@us.sios.comatausupport@us.sios.comuntuk bantuan.

5. Buat klaster demo atau uji coba.

Berbekal pelatihan administrator Anda, terapkan lingkungan pengujian tempat Anda dapat berlatih dan mengasah keterampilan serta pemahaman Anda tanpa secara langsung membahayakan data atau aplikasi perusahaan Anda. Membuat demo atauklaster ujiMembantu Anda dan tim Anda di masa depan memahami dasar-dasar produk dan membiasakan diri dengan antarmuka pengguna (UI).

Selain itu, jika tim Anda mewarisi sebuah runbook, membangun cluster Anda sendiri melalui runbook tersebut membantu Anda memvalidasi dan memperbarui buku panduan ini untuk masa mendatang. Jika memungkinkan, lakukan yang terbaik untuk meniru aplikasi dan data yang dilindungi oleh cluster produksi. Idealnya, cluster pengujian yang dibangun tim Anda harus semirip mungkin dengan sistem produksi. Ini membantu tim Anda memahami dependensi, perilaku, dan operasi dalam lingkungan yang aman sebelum menjalankan perintah di lingkungan produksi. Pastikan untuk menjalankan beberapa latihan penting, seperti:

1. Pengalihan manual
2. Pengalihan kegagalan server
3. Pemulihan aplikasi
4. Operasi pemeliharaan

6. Jadwalkan pemeriksaan kesehatan klaster.

Apemeriksaan kesehatan klasterLayanan ini memvalidasi seluruh lingkungan SIOS LifeKeeper untuk Linux. Anggap saja ini sebagai inspeksi multipoint untuk klaster HA Anda. Tim ahli SIOS akan melakukan tinjauan dan validasi terperinci terhadap log sistem, pengaturan sistem, run book, pengoperasian LifeKeeper, dan dokumentasi lainnya untuk memastikan lingkungan LifeKeeper, termasuk kit pemulihan aplikasi, dikonfigurasi dan beroperasi secara optimal. Laporan pemeriksaan kesehatan akan memberikan rekomendasi untuk memperbaiki dan/atau meningkatkan pengoperasian, mengurangi risiko potensi masalah, dan meningkatkan kesadaran Anda tentang produk.

7. Manfaatkan dukungan dan layanan profesional SIOS

A-Team adalah sebuah tim, bukan hanya satu individu dalam misi penting. Band favorit Anda lebih dari sekadar vokalis utama, drummer, atau gitaris. Ini adalah sekelompok profesional yang memiliki tujuan serupa, berupaya mencapai hal-hal besar, membuat musik yang hebat, menghindari kekecewaan penggemar, dan menikmati hasil dari pertunjukan yang tiketnya terjual habis. Kesuksesan Carlos mencakup para penangan, perawat, pelatih dan instruktur, pejalan kaki, dokter hewan, dan sejumlah ahli serta agen. Kesuksesan mereka adalah upaya tim, dan begitu pula kesuksesan Anda. Manfaatkan tim dukungan SIOS Anda disupport@us.sios.comatau melalui portal dukungan.support.us.sios.comuntuk mendapatkan akses ke wawasan dan informasi yang sangat berharga.

Portal Dukungan SIOS berisi ratusan artikel berbasis pengetahuan (KBA) yang bermanfaat, akses ke perangkat lunak terbaru, dan siap membantu para insinyur membimbing Anda menuju kesuksesan. Hubungi tim dukungan SIOS untuk memastikan Anda memiliki akses masuk ke portal dukungan dan dapat mengelola klaster Anda secara efektif. Tim dukungan juga dapat membantu Anda mendapatkan akses ke berbagai fitur SIOS.Layanan Profesionalpenawaran, termasuk pelatihan yang lebih lanjut, pemeriksaan dan validasi kesehatan tambahan, bantuan untuk instalasi klaster baru, atau layanan teknik siaga untuk pemeliharaan pertama Anda atau jendela peluncuran atau pemeliharaan di masa mendatang.

8. Tetap terhubung dengan SIOS

Rahasia sukses saat Anda mewarisi cluster baru adalah tetap berhubungan dengan SIOS. Jalin komunikasi rutin dengan Perwakilan Akun Anda. Titik kontak ini memungkinkan Anda untuk mengikuti opsi dan peluang baru, selalu selangkah lebih maju dalam hal perpanjangan lisensi, dan memahami cara menambahkan cluster baru untuk memperluas perlindungan aplikasi dan layanan tambahan.

Tetap terhubung dengan tim dukungan SIOS Anda melalui buletin dan email pemberitahuan. Email pemberitahuan memberikan informasi terbaru tentang fitur baru, rilis, atau pembaruan penting yang mungkin memengaruhi perangkat lunak Anda. Buka kasus melalui kotak masuk email dukungan atau Portal Dukungan kapan pun Anda memerlukan kejelasan tentang RCA (Analisis Akar Penyebab) atau memiliki masalah yang hanya membutuhkan pendapat kedua dari tim yang terlatih.

Mengambil alih klaster SIOS LifeKeeper untuk Linux tidak harus terasa terlalu sulit.Minta demountuk melihat bagaimana SIOS dapat membantu Anda melindungi aplikasi penting, mengurangi risiko downtime, dan mengelola ketersediaan tinggi dengan percaya diri.

Pengarang:Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan, SIOS Technology Corp.

Direproduksi dengan izin dariSIOS