SIOS LifeKeeper untuk Linux v 9.8.1 meningkatkan cara perusahaan mengelola HA/DR

SIOS LifeKeeper untuk Linux v 9.8.1 meningkatkan cara perusahaan mengelola HA/DR

Dalam lanskap yang didorong oleh teknologi saat ini, perusahaan mencari solusi inovatif untuk secara efektif menjaga lingkungan aplikasi mereka yang kompleks. Dalam video ini,Todd Doane, sales engineer di SIOS Technology, menjelaskan cara kerja versi terbaruSIOS Penjaga Kehidupan untuk Linuxmembantu perusahaan dalam menjaga sistem perusahaan yang penting terhadap downtime dan bencana. “Rilis ini menampilkan aKonsol Manajemen Web baru. Ini mandiri dan tidak memerlukan instalasi tambahan atau add-on pihak ketiga,” kata Doane.

Direproduksi dengan izin dariSIOS

Memilih Antara GenApp dan QSP: Menyesuaikan Ketersediaan Tinggi untuk Aplikasi Penting Anda

Memilih Antara GenApp dan QSP: Menyesuaikan Ketersediaan Tinggi untuk Aplikasi Penting Anda

GenApp atau QSP? Kedua solusi tersebut didukung oleh LifeKeeper dan membantu melindungi terhadap downtime untuk aplikasi penting, namun memahami perbedaan antara solusi ini penting untuk memilih solusi yang tepat untuk kebutuhan spesifik Anda. Berikut adalah beberapa fitur, manfaat, dan potensi kasus penggunaan untuk Anda putuskan mana yang paling cocok untuk lingkungan Anda.

Aplikasi Gen,kependekan dari Aplikasi Generik, adalah jenis sumber daya yang memungkinkan Anda mengelola aplikasi khusus dalam LifeKeeper. Dengan kerangka fleksibel Anda dapat menggunakan skrip Anda sendiri untuk melakukan berbagai tugas yang mungkin diperlukan aplikasi Anda untuk mengotomatiskan proses failover dan pemulihan. Fleksibilitas ini memungkinkan kontrol terperinci tentang bagaimana LifeKeeper menangani tindakan startup, shutdown, pemantauan, logging, dan lainnya untuk memastikan ketersediaan tinggi aplikasi Anda.

QSPatau Perlindungan Layanan Cepat dirancang untuk menjadi cara cepat dan mudah untuk melindungi layanan OS. QSP mengotomatiskan pemantauan, failover, dan pemulihan aplikasi ini dengan batas waktu bawaan yang dapat disesuaikan untuk tindakan ini. Selain itu, Anda dapat membuat hubungan ketergantungan sehingga layanan dapat dimulai dan dihentikan bersamaan dengan aplikasi lain yang memerlukan layanan tersebut.

Bagaimana cara memilih solusi yang tepat?

Hal pertama yang perlu Anda tentukan adalah apakah aplikasi Anda dapat dipulihkan dengan menghentikan dan memulai ulang layanan atau daemon. Jika ya, maka QSP mungkin merupakan solusi terbaik dan tercepat untuk menjaga aplikasi Anda tetap berjalan. Hal ini karena tidak memerlukan pengkodean dan dalam beberapa menit Anda dapat menambahkan aplikasi sebagai sumber daya QSP dalam GUI LifeKeeper. Selain itu, ini adalah bagian dari produk inti dan setiap pembaruan pengkodean disertakan dalam rilis produk baru. Namun, jika aplikasi Anda memerlukan apa pun selain pemeriksaan kesehatan sederhana dan kemampuan memulai ulang di tingkat layanan OS agar dapat pulih dengan benar, maka Anda sebaiknya menjelajahi GenApps. Membuat skrip khusus untuk jenis sumber daya GenApp akan memerlukan keterampilan teknis yang lebih mendalam dan pemeliharaan jangka panjang, namun fleksibilitas untuk melakukan tugas apa pun yang diperlukan untuk menjaga aplikasi Anda berjalan lancar sangatlah penting, terutama untuk aplikasi khusus. Tugas-tugas ini dapat berupa apa saja mulai dari pemantauan, pencatatan log, tugas pembersihan, atau perubahan konfigurasi.

Ingin detail teknis lebih lanjut?

GenApps dan QSP didukung pada LifeKeeper untuk Linux dan Windows, detail teknis lebih lanjut dapat ditemukan di tautan di bawah.

• GenApp untuk LifeKeeper untuk Linux
• GenApp untuk LifeKeeper untuk Windows
• QSP untuk LifeKeeper untuk Linux
• QSP untuk Penjaga Kehidupan untuk Windows

Direproduksi dengan izin dariSIOS

Apa Penyebab Terjadinya Kegagalan?

Apa Penyebab Terjadinya Kegagalan?

Saat bekerja di bagian dukungan, salah satu pertanyaan paling umum yang kami terima dari pelanggan adalah “Apa yang mendorong hal tersebutkegagalandari simpul utama saya ke simpul sekunder?”.

Ada beberapa alasan mengapa hal ini mungkin terjadi… dan kami akan mencoba menjelaskan penyebab paling umum dan bagaimana Anda dapat mengidentifikasinya.

Sebelum kita mulai, marimembedakan antara ‘failover’ dan ‘switchover’, karena banyak pelanggan menggunakan istilah ini secara bergantian.

‘Peralihan’ adalah tindakan memindahkan hierarki Anda secara manual dari simpul utama ke simpul sekunder. Hal ini dapat dilakukan melalui GUI, dengan melakukan ‘In Service’ pada node sekunder atau melalui baris perintah:

perform_action -a restore -t $LKTag (membawa hierarki ke dalam layanan)

Sebaliknya, ‘failover’ dilakukan tanpa interaksi manual apa pun… dan didefinisikan sebagai peralihan otomatis ke server cadangan setelah kegagalan server, aplikasi, atau perangkat keras/jaringan yang sebelumnya aktif..

Failover dan switchover pada dasarnya adalah operasi yang sama, hanya saja failover bersifat otomatis danbiasanya beroperasi tanpa peringatan, sedangkan peralihannya disengaja dan memerlukan campur tangan manusia.

Berikut ini adalah ‘kegagalan’ paling umum yang mengawali ‘kegagalan’:

1. Penyebab Tingkat Server

Kegagalan Server

• Server utama kehilangan daya atau dimatikan.
• Penggunaan CPU disebabkan oleh beban berlebihan — Di bawah beban I/O yang sangat berat, penundaan dan kondisi memori rendah dapat menyebabkan sistem menjadi tidak responsif sehinggaPenjaga Kehidupandapat mendeteksi server sedang down dan memulai failover.
• Kuorum/Saksi – Sebagai bagian dari mekanisme pagar I/O kuorum/saksi, ketika server utama kehilangan kuorum, “boot cepat”:, “pembunuhan cepat” atau “osu” dilakukan (berdasarkan pengaturan) dan failover dimulai. Saat menentukan kapan harus melakukan failover, server saksi mengizinkan sumber daya untuk digunakan di server cadangan hanya jika server tersebut memverifikasi bahwa server utama telah gagal dan tidak lagi menjadi bagian dari cluster. Hal ini akan mencegah terjadinya failover karena kegagalan komunikasi sederhana antar node ketika kegagalan tersebut tidak memengaruhi keseluruhan akses dan kinerja node dalam layanan.

Kegagalan Komunikasi (Detak Jantung).

LifeKeeper memiliki sinyal “detak jantung” bawaan yang secara berkala memberi tahu setiap server dalam konfigurasi bahwa server pasangannya sedang beroperasi. Secara default, LifeKeeper mengirimkan detak jantung antar server setiap lima detik (ini dapat disesuaikan untuk cluster yang sibuk). Jika masalah komunikasi menyebabkan detak jantung melewati dua detak namun kembali berlanjut pada detak jantung ketiga, LifeKeeper tidak mengambil tindakan. Namun, jika jalur komunikasi tetap mati selama tiga ketukan, LifeKeeper akan memberi label jalur komunikasi tersebut sebagai mati. Ini akan memulai failover jika jalur komunikasi redundan juga mati (kami merekomendasikan dua jalur).

Berikut ini dapat menyebabkan detak jantung tidak terdengar:

• Koneksi jaringan ke server utama terputus.
• Latensi jaringan.
• Lalu lintas jaringan yang padat di jalur komunikasi TCP dapat mengakibatkan perilaku yang tidak terduga, termasuk failover palsu dan masalah inisialisasi LifeKeeper.
• NIC gagal.
• Peralihan jaringan gagal.
• Menarik/menghapus konektivitas jaringan secara manual
• Server utama kehilangan daya atau dimatikan.
• Penggunaan CPU yang disebabkan oleh beban berlebihan — Di bawah beban I/O yang sangat berat, penundaan dan kondisi memori rendah dapat menyebabkan sistem menjadi tidak responsif sehingga LifeKeeper dapat mendeteksi server sedang down dan memulai failover.

Menyesuaikan parameter detak jantung:

LCMNUMHBEATS=Y (di mana Y adalah jumlah detak jantung sebelum mencatat kesalahan jalur komunikasi yang gagal di log). Standarnya adalah 3 dan dapat diubah jika sistem Anda sibuk atau melintasi WAN untuk menghindari kegagalan jalur komunikasi yang salah.

LCMHBEATTIME=5 (ini adalah interval dalam detik dan ini adalah default dan tidak boleh diubah).

Tunable ini TIDAK ada di file /etc/default/LifeKeeper secara default. Anda perlu menambahkannya untuk mengubah nilai detak jantung.

Setelah menambahkan merdu dan nilai-nilai ini di /etc/default/LifeKeeper Anda harus menghentikan LifeKeeper dan memulai ulang. Anda dapat menggunakan perintah lkstop -f, yang menghentikan LifeKeeper tetapi tidak mematikan aplikasi yang dilindungi.

Dan Anda perlu melakukan ini pada kedua sistem.

Ini akan memberikan waktu 5 kali Y detik sebelum LifeKeeper menandai jalur komunikasi sebagai gagal.

Apa itu Split-Brain dan apa penyebabnya?

Jika satu jalur komunikasi digunakan dan jalur komunikasi gagal, maka hierarki LifeKeeper mungkin mencoba untuk masuk ke layanan pada beberapa sistem secara bersamaan. Hal ini dikenal sebagai failover palsu atau skenario “otak terpecah”. Dalamskenario “otak terbelah”., setiap server yakin bahwa mereka mengendalikan aplikasi dan dengan demikian mungkin mencoba mengakses dan menulis data ke perangkat penyimpanan bersama. Untuk mengatasi skenario perpecahan otak, LifeKeeper dapat menyebabkan server dimatikan atau di-boot ulang atau meninggalkan hierarki di luar layanan untuk memastikan integritas data pada semua data bersama. Selain itu, lalu lintas jaringan yang padat di jalur komunikasi TCP dapat mengakibatkan perilaku yang tidak terduga, termasuk failover palsu dan kegagalan LifeKeeper untuk melakukan inisialisasi dengan benar.

Berikut ini adalah skenario yang dapat menyebabkan terjadinya split-brain:

• Salah satu kegagalan komunikasi yang tercantum di atas
• Shutdown LifeKeeper yang tidak tepat
• Kelaparan sumber daya server
• Kehilangan semua jalur jaringan
• DNS atau kesalahan jaringan lainnya
• Penguncian sistem

Memanfaatkan Kuorum/Saksi untuk mencegah terjadinya Split Brain

• Paket Dukungan Server Kuorum/Saksi untuk LifeKeeper (steeleye-lkQWK, selanjutnya disebut “Paket Kuorum/Saksi”) dikombinasikan dengan proses failover yang ada pada inti LifeKeeper memungkinkan kegagalan sistem terjadi dengan tingkat kepercayaan yang lebih besar dalam situasi di mana kegagalan jaringan total dapat terjadi menjadi hal yang umum. Hal ini secara efektif berarti bahwa failover situs lokal dan failover ke node di seluruh WAN dapat dilakukan sekaligus sangat mengurangi risikootak terbelahsituasi.
• Dalam sistem terdistribusi yang memperhitungkan partisi jaringan, terdapat konsep yang disebut kuorum untuk memperoleh konsensus di seluruh cluster. Node yang memiliki kuorum adalah node yang dapat memperoleh konsensus dari semua cluster dan diperbolehkan membawa sumber daya dalam pelayanan. Di sisi lain, node yang tidak memiliki kuorum adalah node yang tidak dapat memperoleh konsensus dari semua cluster dan tidak diperbolehkan membawa sumber daya untuk dilayani. Ini akan mencegah terjadinya perpecahan otak. Untuk memeriksa apakah suatu node memiliki kuorum disebut pemeriksaan kuorum. Dinyatakan “pemeriksaan kuorum berhasil” jika memenuhi kuorum, dan “pemeriksaan kuorum gagal” jika tidak memenuhi kuorum.
• Jika terjadi kegagalan komunikasi, menggunakan satu node di mana kegagalan terjadi dan beberapa node lainnya (atau perangkat lain) akan memungkinkan sebuah node mendapatkan “pendapat kedua” tentang status node yang gagal. Simpul untuk mendapatkan “pendapat kedua” disebut simpul saksi (atau perangkat saksi), dan mendapatkan “pendapat kedua” disebut pemeriksaan saksi. Saat menentukan kapan harus melakukan failover, node saksi (perangkat saksi) mengizinkan sumber daya untuk digunakan di server cadangan hanya jika node tersebut memverifikasi bahwa server utama telah gagal dan tidak lagi menjadi bagian dari cluster. Hal ini akan mencegah terjadinya failover karena kegagalan komunikasi sederhana antar node ketika kegagalan tersebut tidak memengaruhi keseluruhan akses dan kinerja node dalam layanan. Selama pengoperasian sebenarnya, simpul saksi (perangkat saksi) akan dikonsultasikan ketika LifeKeeper dimulai atau jalur komunikasi yang gagal dipulihkan. Pengecekan saksi hanya dapat dilakukan pada node yang memenuhi kuorum.

2. Penyebab Kegagalan Sumber Daya

LifeKeeper dirancang untuk memantau aplikasi individu dan kelompok aplikasi terkait, secara berkala melakukan pemulihan lokal atau pemberitahuan ketika aplikasi yang dilindungi gagal. Aplikasi terkait, misalnya, adalah hierarki di mana aplikasi utama bergantung pada penyimpanan tingkat rendah atau sumber daya jaringan. LifeKeeper memantau status dan kesehatan sumber daya yang dilindungi ini. Jika sumber daya ditentukan berada dalam keadaan gagal, maka akan dilakukan upaya untuk memulihkan sumber daya atau aplikasi pada sistem saat ini (node ​​dalam layanan) tanpa intervensi eksternal. Jika pemulihan lokal ini gagal, failover sumber daya akan dimulai.

Kegagalan Aplikasi

• Kegagalan aplikasi terdeteksi, namun proses pemulihan lokal gagal.
• Hapus Kegagalan – Selama proses failover sumber daya, sumber daya tertentu perlu dihapus dari layanan di server utama dan kemudian dimasukkan ke dalam layanan di server cadangan yang dipilih untuk menyediakan fungsionalitas penuh dari aplikasi penting. Jika proses penghapusan ini gagal, reboot server utama akan dilakukan sehingga mengakibatkan kegagalan server total.

Contoh kegagalan penghapusan:

• Tidak dapat melepas sistem file
• Tidak dapat mematikan aplikasi yang dilindungi (Oracle, mysql, postgres, dll)

Masalah Sistem File

• Disk Penuh — Pemantauan Kesehatan Sistem File LifeKeeper dapat mendeteksi kondisi sistem file penuh disk yang dapat mengakibatkan kegagalan sumber daya sistem file.
• Sistem File Tidak Dipasang atau Dipasang dengan Benar — Pengguna secara manual melepas atau mengubah opsi pada sistem file dalam layanan dan dilindungi LK.
• Kegagalan Remount — Berikut ini adalah daftar penyebab umum kegagalan remount yang dapat menyebabkan failover:
• sistem file rusak (kegagalan fsck)
• kegagalan membuat direktori mount point
• titik pemasangan sedang sibuk
• kegagalan pemasangan
• Kesalahan internal Penjaga Kehidupan

Kegagalan Alamat IP

Ketika kegagalan alamat IP terdeteksi oleh IP Recovery Kit, kegagalan yang diakibatkannya memicu eksekusi skrip pemulihan lokal IP. LifeKeeper pertama-tama mencoba mengembalikan alamat IP ke layanan pada antarmuka jaringan saat ini. Jika upaya pemulihan lokal gagal, LifeKeeper akan melakukan failover alamat IP dan semua sumber daya yang bergantung ke server cadangan. Selama failover, proses penghapusan akan membatalkan konfigurasi alamat IP pada server saat ini sehingga dapat dikonfigurasi pada server cadangan. Kegagalan proses penghapusan ini akan menyebabkan sistem melakukan boot ulang.

• konflik kekayaan intelektual
• tabrakan IP
• Kegagalan resolusi DNS
• Kegagalan NIC atau Switch

Konflik Reservasi

• Reservasi ke perangkat yang dilindungi hilang atau dicuri
• Tidak dapat memperoleh kembali reservasi atau kendali perangkat sumber daya yang dilindungi (disebabkan oleh intervensi pengguna manual, HBA, atau kegagalan sakelar)

Perangkat SCSI

• Perangkat SCSI yang dilindungi tidak dapat dibuka. Perangkat mungkin gagal atau mungkin telah dihapus dari sistem.

Sumber daya untuk mengidentifikasi penyebab failover

/var/log/lifekeeper.log

File log ini, yang ditulis oleh LifeKeeper, harus menjadi tempat pertama yang Anda lihat dalam menentukan apa yang mungkin menyebabkan failover.

Misalnya, salah satu alasan paling umum adalah kegagalan jalur komunikasi. Di bawah ini adalah contoh entri yang akan Anda temukan di lifekeeper.log ketika hal ini terjadi:

_{21 Sep 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 1 dari 48 pada dev 10.236.17.226/10.238.17.226 (nomor driver lcm = 129).}

_{21 Sep 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 1 dari 48 pada dev 10.236.17.226/10.237.17.226 (nomor driver lcm = 1360929).}

_{21 Sep 11:07:02 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 2 dari 48 pada dev 10.236.17.226/10.238.17.226 (nomor driver lcm = 129).}

Setelah mencapai jumlah detak jantung maksimum, failover dimulai:

_{21 Sep 11:10:49 es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 47 dari 48 pada dev 10.237.17.226/10.236.17.226 (nomor driver lcm = 71).}

_{21 Sep 11:10:49 es6ecc08tev eventslcm[47082]: PERINGATAN:lcd.net:::004258:Komunikasi ke es1ecc08tev paling lambat 10.237.17.226/10.236.17.226 GAGAL}

_{21 Sep 11:10:49 es6ecc08tev eventslcm[47082]: PERINGATAN:lcd.net:::004261:COMMUNICATIONS failover dari sistem “es1ecc08tev” akan dimulai.}

_{21 Sep 11:10:49 es6ecc08tev penjaga pantai[47121]: PEMBERITAHUAN:event.comm_down:::010466:KOMUNIKASI es1ecc08tev GAGAL}

/var/log/messages

File yang dihasilkan linux ini biasanya berisi pesan sistem yang dihasilkan oleh berbagai proses dan layanan yang berjalan pada sistem. Pesan-pesan ini dapat mencakup:

Pesan boot sistem: Informasi tentang proses boot sistem, termasuk pesan kernel dan pesan dari systemd atau sistem init lainnya.

Pesan permulaan dan penghentian layanan: Pesan yang menunjukkan kapan layanan dimulai atau dihentikan, termasuk kesalahan atau peringatan apa pun yang ditemui selama proses.

Pesan kernel: Informasi tentang pengoperasian kernel Linux, termasuk deteksi perangkat keras, inisialisasi perangkat, dan kesalahan atau peringatan kernel.

Pesan terkait jaringan: Informasi tentang koneksi jaringan, aktivitas firewall, dan perubahan konfigurasi jaringan.

Informasi kinerja sistem: Pesan terkait pemantauan kinerja sistem, seperti penggunaan CPU, penggunaan memori, dan statistik I/O disk.

Ketersediaan Tinggi SIOS dan Pemulihan Bencana

SIOS Technology Corporation menyediakanKetersediaan TinggiDanPemulihan bencanaproduk yang melindungi & mengoptimalkan infrastruktur TI dengan manajemen cluster untuk aplikasi terpenting Anda.Hubungi kami hari iniuntuk informasi lebih lanjut.

Direproduksi dengan izin dariSIOS

Tiga Tip untuk Dukungan yang Lebih Baik

Tiga Tip untuk Dukungan yang Lebih Baik

Betsy adalah Amazon Green Ford F-150 tahun 1999, kendaraan pertama yang saya beli. Saya tidak yakin bagaimana truk saya mendapat nama Betsy atau mengapa truk itu macet, tapi ternyata truk saya macet. Selama lebih dari 17 tahun, Betsy melakukan segalanya mulai dari berlayar di pantai hingga berlomba di jalur balap, mengangkut banyak perlengkapan lanskap, dan membawa keluarga saya yang semakin besar melintasi wilayah tenggara. Setelah bermil-mil dan bertahun-tahun mempelajari cara merawat truk, dia mulai menunjukkan keausannya. Pada suatu perjalanan sore, saya melihat pengukur suhu naik ke H (Tinggi). Setelah beberapa percakapan, saya membawa Betsy ke departemen Servis di dealer lokal untuk memulai cobaan berat yang dilakukan sendiri selama seminggu.

Pada kunjungan pertama, saya buru-buru memberikan rincian tingkat tinggi. “Setelah beberapa menit, truk menjadi panas,” kataku. Enam jam dan $100 kemudian, saya mengambil truk saya. Teknisi tidak dapat mereproduksi masalah tersebut. Jadi, saya dipulangkan dengan biaya diagnostik dan permintaan untuk kembali jika itu terjadi lagi. Pada kunjungan kedua, saya buru-buru menambahkan bahwa masalah terjadi setelah 18 menit atau 14 mil berkendara lebih dari 45 menit perjalanan. Enam jam dan sekitar $375 kemudian, saya mengambil truk saya. Teknisi dapat mereproduksi masalah tersebut dengan detail baru, dan mereka mengganti termostat dan selang. Pada kunjungan ketiga, telepon dari teknisi datang lebih awal, “Pak. Rhue, kamu akan membutuhkan radiator baru.”

Itulah versi singkat ceritanya. Versi yang lebih panjang mencakup kegagalan saya menjelaskan kepada teknisi servis bahwa antara kunjungan pertama dan kedua saya telah mengganti termostat. Hal ini juga mengabaikan fakta bahwa saya melakukan pembilasan dan pengisian cairan radiator dan kemungkinan besar membiarkan penjepit selang longgar dalam prosesnya. Yang terpenting, hal ini mengabaikan fakta bahwa tetangga saya, seorang mekanik, memberi tahu saya sebelum truk mengalami masalah ini, untuk mengganti radiator dan melakukan perawatan pencegahan lainnya. Sekarang, apa hubungannya semua ini dengan Pengalaman Pelanggan yang lebih baik?

Berikut adalah tiga pelajaran dari cobaan yang saya lakukan sendiri yang akan meningkatkan pengalaman pelanggan Anda, bukan hanya layanan otomotif Anda berikutnya.

Pertama, dapatkan dan berikan semua detailnya.

Pada kunjungan pertama saya, saya buru-buru memberikan rincian minimum kepada teknisi servis. Akibatnya, penyelesaian yang tepat tidak dapat dicapai. Banyak peristiwa di dunia terjadi pada waktu yang paling tidak tepat, dan membawa banyak tekanan dan keterbatasan waktu, namun tetap merupakan praktik terbaik untuk memberikan sebanyak mungkin detail kepada tim Pengalaman Pelanggan Anda. Kapan Anda menyadari masalah tersebut, atau kapan masalah tersebut terjadi? Apa yang Anda perhatikan atau apa saja gejala masalahnya? Hal lain apa yang terjadi pada saat itu?

Pertimbangkan rincian pendukung lainnya yang mungkin dapat Anda berikan, termasuk pesan kesalahan dan kode kesalahan, log sistem perangkat lunak, log klien, dan gambar apa pun yang menangkap kondisi atau gejala kesalahan. Seringkali kita berpikir bahwa hal-hal dalam perangkat lunak tidak ada hubungannya, padahal sebenarnya hal-hal tersebut sangat berkaitan.

Kedua, jelaskan apa yang telah Anda lakukan (baik atau buruk).

Ketika saya datang untuk kunjungan kedua, saya melakukan tindakan merugikan yang besar bagi diri saya sendiri dan para teknisi. Daripada menjelaskan semua hal yang telah saya coba (baik dan buruk), dan berbagi tentang upaya yang gagal untuk menyelesaikan masalah, saya menunda penyelesaian saya. Jika saya berbagi fakta bahwa saya telah mengganti termostat, melakukan pembilasan dan mengisi ulang radiator, mungkin teknisi akan mencari masalahnya di tempat lain. Saat Anda membagikan apa yang telah Anda lakukan untuk mengatasi masalah, dan apa yang mungkin telah Anda lakukan untuk memperburuk masalah, hal ini membantu tim Pengalaman Pelanggan Anda meningkatkan respons mereka, mempertajam area masalah lainnya, menghilangkan kesalahan palsu (masalah atau hal yang tidak terkait menyamar sebagai masalah nyata), dan memberikan pengalaman yang lebih baik secara keseluruhan.

Terakhir, jalankan rekomendasi sebelumnya.

Sebelum masalah ini muncul, tetangga saya memberikan rekomendasi berdasarkan pengalamannya selama bertahun-tahun dan usia truk saya. Dia menyuruh saya mengganti radiator, melakukan perawatan preventif, dan melakukan pemeriksaan rutin untuk kesehatan truk secara keseluruhan. Kemungkinan besar, tim Pengalaman Pelanggan Anda memiliki rekomendasi dalam basis pengetahuan mereka terkait dengan produk Anda dan pengalaman bertahun-tahun terkait pengoperasian dalam persyaratan ketersediaan perusahaan. Gunakan hal tersebut untuk pemeliharaan preventif, penyesuaian proaktif, dan memeriksa ketersediaan lingkungan Anda untuk kepatuhan terhadap praktik terbaik tersebut. Namun yang terpenting, ketika mereka membuat rekomendasi, jalankanlah. Pada akhirnya, Anda akan menghemat banyak waktu, uang, dan kerumitan.

Dua hari setelah kunjungan ketiga, pesanan radiator baru tiba dan saya mengganti radiator saya. Saya terus mengendarai Betsy selama beberapa tahun sebelum akhirnya menukarnya dengan SUV keluarga.

Direproduksi dengan izin dariSIOS

Pelatihan Admin SIOS LifeKeeper untuk Linux tersedia di Udemy

Pelatihan Admin SIOS LifeKeeper untuk Linux tersedia di Udemy

Pelatihan Admin SIOS, yang sebelumnya dapat diakses terutama melalui acara dua bulanan yang telah dijadwalkan sebelumnya, kini tersedia sesuai permintaan melalui Udemy.

Teknologi SIOStelah mengumumkan ketersediaan pelatihan SIOS LifeKeeper untuk Admin LinuxUdemy, pasar keterampilan online dan platform pembelajaran. Perkembangan ini menggarisbawahi dedikasi SIOS untuk memfasilitasi ketersediaan aplikasi penting dengan melengkapi bisnis di seluruh dunia dengan ketersediaan tinggi dan pemulihan bencana yang komprehensif (HA/DR) pelatihan teknis.

Platform Udemy menawarkan kenyamanan dan fleksibilitas yang tak tertandingi, memungkinkan pelajar mengakses pelatihan Admin SIOS kapan saja, di mana saja. Pelatihan SIOS LifeKeeper untuk Admin Linux mencakup konsep dan metodologi utama yang diperlukan untuk memastikan bahwa aplikasi penting Linux, ERP, dan database selalu tersedia, bahkan saat menghadapi kegagalan perangkat keras atau perangkat lunak.

“Kemitraan dengan Udemy ini menandai tonggak penting dalam misi kami untuk menjadikan keahlian SIOS HA/DR dapat diakses oleh semua orang,” kata Margaret Hoagland, VP Penjualan & Pemasaran Global, SIOS Technology Corp. “Dengan memanfaatkan platform Udemy, kami dapat menjangkau lebih banyak orang audiens profesional TI, memberdayakan mereka dengan pengetahuan dan keterampilan yang diperlukan untuk memastikan ketersediaan tinggi dan pemulihan bencana di organisasi mereka.”

Calon pelajar dapat mengakses kursus pelatihan SIOS LifeKeeper untuk Admin Linux dengan terlebih dahulu membuat akun gratis di Udemy, (www.udemy.com) dan mendaftar dengan email bisnis mereka. Setelah terdaftar, mereka menyerahkan formulir diSitus Pelatihan SIOS, menggunakan email bisnis yang sama dengan yang mereka gunakan untuk mendaftar di Udemy, untuk menerima undangan kursus.

Direproduksi dengan izin dariSIOS