Cara Meningkatkan Kepuasan Pelanggan dalam Dukungan Teknis

Cara Meningkatkan Kepuasan Pelanggan dalam Dukungan Teknis

Kami memiliki pelanggan di seluruh dunia. Kami berbicara berbagai bahasa; kami berada di zona waktu yang berbeda; kami berada di negara yang berbeda. Tetapi ada banyak hal yang kami miliki bersama dalam hal dukungan teknis. Kita semua menginginkan dan mengharapkan dukungan terbaik ketika kita memiliki masalah dan membutuhkan bantuan. Apa arti menginginkan dan mengharapkan yang terbaik?mendukungSebenarnya maksudnya untuk tim IT?

6 Harapan Pelanggan terhadap Tim Dukungan Teknis

Berikut adalah hal-hal yang diharapkan pelanggan kami dari Tim Dukungan Teknis.

Dengarkan Pelanggan

Pelanggan (sama seperti orang lain) senang didengarkan. Saat berbicara dengan pelanggan, penting untuk membiarkan pelanggan menjelaskan masalahnya. Sebagai teknisi Dukungan, catat, dengarkan apa yang dijelaskan pelanggan, dan ajukan pertanyaan lanjutan untuk mengumpulkan informasi penting. Jangan menyela pelanggan saat mereka berbicara. Untuk memastikan Anda memahami apa yang dikatakan pelanggan, rangkum apa yang dikatakan pelanggan kepada Anda. Rangkum tindakan dan pastikan semua orang memiliki pemahaman yang sama. Jangan berasumsi Anda tahu masalahnya sebelum pelanggan menjelaskannya.

Bicaralah dengan Orang Sungguhan

Pelanggan masih lebih suka berbicara dengan orang “nyata”.dan bukan suara otomatis/AI/ChatBot. Pelanggan lebih suka berbicara langsung dengan agen dukungan yang memahami produk, bukan hanya mengikuti skrip. Tidak ada yang lebih membuat frustrasi daripada ketika Anda menelepon untuk meminta bantuan terkait masalah yang Anda alami, dan Anda harus melalui beberapa otomatisasi untuk mencoba berbicara dengan orang yang “sesungguhnya”. Seringkali Anda akhirnya berputar-putar dan kembali ke situasi awal! Waktu berharga dapat terbuang sia-sia hanya untuk mencoba berbicara dengan orang yang “sesungguhnya” melalui telepon untuk membantu Anda.   Pelanggan menelepon untuk meminta bantuanKami sangat menyarankan untuk mengadakan konferensi video guna berbagi masalah secara langsung dengan tim dukungan. Sebuah gambar bernilai seribu kata! Berdasarkan pengalaman kami, mencoba membantu pelanggan tanpa visual dan tanpa mengajukan pertanyaan “langsung” akan memperpanjang waktu penyelesaian masalah.

Tersedia 24 jam sehari, 7 hari seminggu.

Pelanggan kami tersebar di seluruh dunia dan ingin menghubungi dukungan kapan saja, siang atau malam. Kami menawarkan dukungan 24 jam sehari, setiap hari dalam seminggu. Untuk mengakomodasi hal ini, kami memiliki beberapa tim di seluruh dunia yang mencakup 24 jam sehari, setiap hari dalam seminggu. Saat pelanggan membutuhkan kami, kami siap membantu mereka. Kami memiliki prosedur untuk meningkatkan penanganan kasus ketika anggota tim kami membutuhkan bantuan segera.masalah waktu henti kritisHal ini memengaruhi bisnis pelanggan. Pelanggan kami menggunakan perangkat lunak Ketersediaan Tinggi dan Pemulihan Bencana kami, dan tim Dukungan Teknis kami memperkuat tujuan ini dengan selalu siap memberikan bantuan kapan pun dibutuhkan.

Teknisi Dukungan Berpengalaman

Pelanggan tidak punya waktu untuk berbicara di telepon dengan seseorang yang tidak dapat membantu mereka dan perlu meneruskan panggilan ke orang lain. Pelanggan ingin berbicara dengan teknisi dukungan yang dapat membantu menjawab pertanyaan dan mengatasi masalah mereka.SIOSKami selalu memastikan bahwa pelanggan dapat segera dihubungi oleh anggota tim dukungan teknis kami yang berpengalaman sehingga masalah dapat segera diatasi. Berdasarkan Survei Pelanggan kami, pelanggan menyukai tim dukungan teknis kami! Tim dukungan kami memiliki rata-rata 16 tahun pengalaman dukungan total; keahlian ini memungkinkan masalah untuk segera diatasi.ditangani dengan cepat dan seringkali tanpa perlu meningkatkan kasus ke tingkat yang lebih tinggi.ke kelompok lain. Pelanggan menghargai ketika mereka bertemu dengan personel berpengalaman yang dapat bergabung dalam konferensi video dan memberikan bantuan secara langsung berdasarkan pengalaman bertahun-tahun.

Bersikaplah transparan.

Pelanggan menghargai transparansi. Mereka ingin mengetahui kenyataan. Jangan membuat janji yang tidak dapat Anda tepati. Selalu pastikan pelanggan memahami apa yang akan Anda lakukan untuk membantu mereka menyelesaikan masalah dan kapan Anda akan menghubungi mereka kembali. Jelaskan langkah-langkah yang perlu dilakukan kepada pelanggan seiring berjalannya proses, dan pastikan langkah-langkah tersebut disetujui oleh pelanggan sebelum Anda melaksanakannya. Banyak pelanggan perlu mendapatkan persetujuan terlebih dahulu sebelum menerapkan perubahan pada sistem mereka.sistemDemi transparansi, penting untuk memberikan pembaruan berkala kepada pelanggan yang memberikan wawasan tentang proses dukungan. Bahkan jika pembaruan Anda adalah, “Kami masih menganalisis log,” beri tahu pelanggan hal ini agar mereka tetap mendapatkan informasi terbaru. Jangan katakan apa yang menurut Anda ingin mereka dengar; katakan yang sebenarnya.

Survei Pelanggan

Untuk setiap kasus yang dibuka pelanggan dengan dukungan teknis, survei dikirimkan kepada pelanggan setelah kasus ditutup. Ini memberi pelanggan kesempatan untuk memberikan umpan balik sehingga tim kami dapat terus meningkatkan produk, dokumentasi, dan dukungan kami. Tim dukungan kami meninjau survei pelanggan yang telah diisi setidaknya sekali seminggu dan menanggapi pelanggan yang memiliki kekhawatiran, ide, dan saran perbaikan, memberi tahu mereka tindakan apa yang telah kami ambil berdasarkan umpan balik mereka. Pelanggan sering berterima kasih kepada kami karena telah menyelesaikan masalah mereka dengan cepat dan karena menunjukkan komitmen kami terhadap keberhasilan mereka dengan menindaklanjuti catatan yang mereka tinggalkan setelah kasus ditutup.

Apa yang Diharapkan Pelanggan dari Tim Dukungan Teknis HA/DR 24/7

Pelanggan yang menghubungi untuk mendapatkan dukungan teknis padaProduk HA/DRPelanggan ingin tahu bahwa mereka didengarkan oleh orang sungguhan, bukan bot. Mereka berharap dapat berbicara dengan agen berpengalaman yang benar-benar tahu cara memperbaiki masalah mereka dan yang tetap transparan tentang apa yang terjadi di setiap langkahnya. Dengan menawarkan sentuhan manusiawi ini dengan ketersediaan 24/7, kami menunjukkan kepada pelanggan bahwa kami selalu ada ketika mereka membutuhkan kami. Dukungan teknis saat ini bukan hanya tentang menyelesaikan tiket; ini tentang membangun kepercayaan, mendengarkan, dan menjadi andal serta jujur ​​setiap kali pelanggan membutuhkan bantuan.

Sedang mencari tim dukungan teknis yang memahami HA/DR?Jadwalkan waktu dengan pakar SIOS HA.untuk melihat bagaimana kami menghadirkan ketersediaan tinggi, pemulihan otomatis, dan penerapan klaster yang andal.

Pengarang:Sandi Hamilton, Direktur Rekayasa Dukungan Produk di SIOS

Direproduksi dengan izin dariSIOS

Menjaga Keamanan Bangunan: Ketersediaan Tinggi dalam Sistem Pemeliharaan dan Keamanan

Menjaga Keamanan Bangunan: Ketersediaan Tinggi dalam Sistem Pemeliharaan dan Keamanan

Dalam episode iniTFiR: Mari Bicara, pembawa acara Swapnil Bhartiya berbicara dengannyaDave Bermingham, Direktur Kesuksesan Pelanggan di SIOS Technology, tentang mengapa ketersediaan tinggi dan ketahanan sangat penting bagipemeliharaan bangunan dan sistem keamananBermingham menjelaskan bagaimana sistem-sistem ini berbeda dari, tetapi sering berinteraksi dengan, teknologi bangunan lainnya, dan mengapa pengoperasian tanpa gangguan sangat penting untuk keselamatan penghuni dan fungsionalitas bangunan. Percakapan ini mengeksplorasi bagaimana organisasi dapat menyeimbangkan keamanan dengan aksesibilitas, peran teknologi baru seperti AI, pembelajaran mesin, dan IoT dalam meningkatkan keandalan, dan praktik terbaik untuk memastikan ketersediaan sistem melalui redundansi, pemantauan, dan perencanaan risiko.

Penulis: Beth Winkowski, Hubungan Masyarakat SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Merancang Ketersediaan Tinggi Melalui Modularitas dan Abstraksi

Merancang Ketersediaan Tinggi Melalui Modularitas dan Abstraksi

Sejauh ini, seri ini telah mengeksplorasi persamaan antara desain teknis dan retorika. “Retorika” dari solusi teknis, strategi mengkomunikasikan makna dan tujuan, disajikan melalui pola dan konsep desain. Pola dan konsep desain tersebut berfungsi sebagai fondasi konseptual, di mana makna tersebut diterjemahkan ke dalam bentuk terapan ketika dipraktikkan selama implementasi.

Seperti yang telah dibahas sebelumnya, keberlanjutan dan integritas dari hal inilandasan konseptualsangat penting untuk memastikan bahwa solusi selalu terjaga pada standar yang kondusif untuk pemeliharaan, peningkatan, dan keandalan jangka panjang. Eksternalfaktor-faktor yang memengaruhi desain suatu solusiHal ini menantang tujuan untuk menjunjung tinggi landasan konseptual yang dikemukakan dalam desain suatu solusi. Faktor-faktor eksternal ini dapat bertentangan dengan prinsip-prinsip yang ada, dan oleh karena itu, alat, aplikasi, dan platform yang digunakan dalam suatu solusi harus dipilih dengan cermat.

Pada bagian ketiga dan terakhir dari seri blog ini, modularitas dan abstraksi akan dieksplorasi sebagai cara untuk menetapkan batasan dan memastikan bahwa proyek-proyek dengan cakupan luas dapat terus menuai manfaat dari desain yang terstruktur dengan baik dan memiliki landasan retorika yang kuat.

Prinsip-prinsip Desain Ketersediaan Tinggi: Mengapa Modularitas dan Abstraksi Penting

Sebelum membahas modularisasi dan abstraksi sebagai strategi, penting untuk memahami mengapa hal-hal ini perlu diterapkan. Secara umum, dengan sebuah analogi, seorang pembicara yang mencoba meyakinkan audiensnya untuk menyetujui rencananya mungkin perlu terlebih dahulu menguraikan beberapa poin dasar. Dengan demikian, setiap pilar dasar argumennya dikemukakan dan dibenarkan.

Pembicara pertama-tama harus membangun dasar “A menyiratkan B” dan “C menyiratkan D”, yang kemudian dapat digunakan untuk membentuk argumen “B dan D menyiratkan E”. Strategi ini memastikan bahwa penalaran di mana “A menyiratkan B” tidak saling mencemari dan mengurangi poin terpisah “C menyiratkan D”. Strategi ini sering digunakan karena memungkinkan setiap komponen argumen pembicara untuk berdiri sendiri. Jika argumen “C menyiratkan D” cacat, argumen tersebut dapat diperbaiki sementara argumen “A menyiratkan B” tetap valid.

Alasan di balik struktur ini sama dengan alasan mengapa sistem teknis bersifat terdesentralisasi – masalah dalam sistem titik penjualan dapat diperbaiki tanpa perlu memperluas upaya perbaikan ke basis data, API, arsitektur jaringan, dan sebagainya. Strategi yang disebutkan di atas, tentu saja, mengacu pada konsep modularitas dan abstraksi.

Modularitas dalam Arsitektur Ketersediaan Tinggi

Pertama, membahas modularitas, ini adalah praktik menciptakan sistem dari komponen-komponen yang mandiri. Dalam pengertian retorika, argumen “A menyiratkan B” dan “C menyiratkan D” hanyalah modul-modul penalaran yang dirangkai menjadi argumen secara keseluruhan.

Secara teknis, komponen yang dimodularisasi (seperti sistem point of sale pada contoh sebelumnya) memungkinkan masalah diatasi sepenuhnya di dalam modul tempat masalah tersebut berasal. Setiap modul dalam solusi bertindak sebagai blok bangunan, dan masalah dalam satu blok bangunan dapat diselesaikan tanpa membongkar seluruh solusi.

Abstraksi sebagai Strategi untuk Desain Infrastruktur yang Dapat Diperluas

Berkaitan erat dengan modularitas adalah “abstraksi”. Abstraksi adalah praktik untuk memastikan bahwa desain solusi keseluruhan bersifat independen dan tidak bergantung pada desain modul-modul yang membentuk solusi keseluruhan tersebut.

Lebih lanjut, abstraksi sebagai strategi desain juga menyatakan bahwa setiap modul bersifat independen dan tidak bergantung pada desain modul lainnya. Ketika suatu solusi dirancang untuk menggunakan elemen-elemen yang diabstraksikan, elemen-elemen ini dapat digunakan kembali dan diterapkan dalam kasus penggunaan yang memungkinkan pemahaman diperluas di seluruh proyek.

Merancang Ketersediaan Tinggi yang “Tidak Mengganggu”

Ketika desain dibangun dari komponen modular, batasan-batasan akan digambar. Batasan-batasan ini memastikan bahwa setiap modul dapat “tidak mengganggu” modul-modul lainnya. Ketika komponen-komponen tersebut diabstraksikan, isi setiap modul dapat dipahami dengan lebih mudah.

Pada gilirannya, batasan-batasan tersebut berfungsi sebagai struktur yang memungkinkan pemahaman desain, dan abstraksi di dalam batasan-batasan ini berfungsi sebagai titik masuk untuk memahami dasar-dasar kasus penggunaan. Struktur yang disediakan melalui modularitas dan abstraksi mencerminkan peran retorika dalam menyediakan kerangka kerja yang memungkinkan pemahaman tujuan.

Mengelola Arsitektur Jaringan Kompleks dengan Solusi HA Modular

Seiring dengan pengembangan solusi teknis untuk mengatasi masalah yang lebih kompleks, kebutuhan akan kerangka kerja yang solid dalam desain solusi tersebut juga meningkat. Arsitektur jaringan, yang seringkali merupakan puncak dari banyak solusi yang kompleks dengan sendirinya, berfungsi sebagai contoh fantastis dari masalah yang semakin kompleks dan kebutuhan yang semakin besar akan kerangka kerja yang solid dalam desain. Lebih jauh lagi, arsitektur jaringan seringkali mengalami pertumbuhan yang berkelanjutan karena harus menyerap jaringan sistem yang luas yang berkontribusi pada tujuan bisnis yang berkembang.

Sebagai lapisan tambahan di atasnya, arsitektur solusi kemudian harus menerapkan solusi untukKetersediaan Tinggi dan/atau Pemulihan BencanaHal ini menciptakan titik rawan bagi munculnya konflik desain, tetapi dapat dengan mudah diatasi dengan strategi modularisasi dan abstraksi.

Menerapkan Modularitas dan Abstraksi dengan Perangkat Lunak Ketersediaan Tinggi SIOS

Manfaat dariPerangkat lunak Ketersediaan TinggiHal ini dapat dicapai tanpa beban kerumitan dan solusi yang rumit. SIOS LifeKeeper, sebagai contoh alat Ketersediaan Tinggi yang sesuai dengan desain, dibuat sedemikian rupa sehingga prinsip-prinsip operasinya dapat menyatu dengan mulus dengan lingkungan tempat ia digunakan.

LifeKeeper bersifat modular, karena tidak memaksakan persyaratan di luar sistem yang dilindungi LifeKeeper. LifeKeeper juga memfasilitasi abstraksi komponen infrastruktur menjadi elemen-elemen yang lebih kecil – sistem yang bekerja sama untuk memastikan ketersediaan dikelompokkan ke dalam sebuah “cluster”.

Melalui abstraksi ini, retorika lingkungan tetap kuat – memahami susunan satu klaster meletakkan dasar untuk memahami semua klaster. Lapisan desain dapat dipahami sesuai tujuannya; tidak perlu tanda bintang dan pertimbangan khusus tentang bagaimana implementasi berbeda di seluruh desain. Karena klaster bertindak secara independen dari klaster lain atau komponen solusi eksternal, batasan dapat ditarik di mana elemen desain dari setiap lapisan masing-masing terkandung, menghindari konflik dengan lapisan infrastruktur lainnya.

Membangun Infrastruktur Tangguh Jangka Panjang dengan SIOS Protection Suite

Seperti halnya perangkat lunak atau alat lainnya,SIOS Protection Suite(SIOS LifeKeeper dan/atau SIOS DataKeeper) memengaruhi desain lingkungan tempat mereka digunakan. Meskipun pola-pola ini diperkenalkan karena adanya lingkungan yang dilindungi oleh LifeKeeper dan DataKeeper, SIOS LifeKeeper dan SIOS DataKeeper dengan cermat memilih pola-pola yang digunakan untuk memastikan bahwa pola-pola ini memungkinkan abstraksi dan modularitas dalam solusi secara keseluruhan. Sebagai hasil dari abstraksi berlapis yang dimungkinkan oleh LifeKeeper dan DataKeeper, pengenalan utilitas ini memfasilitasi integrasi dengan infrastruktur TI yang mempertahankan kohesi dalam desain solusi.

Sebagai hasil dari pola desain yang digunakan, klaster yang dilindungi oleh SIOS Protection Suite (LifeKeeper dan/atau DataKeeper) membentuk elemen abstrak dan modular yang terintegrasi dengan mulus ke dalam desain dan solusi yang ada. LifeKeeper dan DataKeeper melakukan lebih dari sekadar menyederhanakan administrasi sistem tunggal atau masing-masing klaster; LifeKeeper dan DataKeeper bekerja dengan prinsip-prinsip yang berlaku dalam sebuah implementasi.

Pembuatan infrastruktur menjadi lebih sederhana dan efisien karena penggunaan SIOS Protection Suite memungkinkan metode yang mudah untuk memahami peran sistem dalam desain, sekaligus menyediakan metode sederhana untuk mengimplementasikan Ketersediaan Tinggi dan Pemulihan Bencana. Administrator dapat menggunakan LifeKeeper dan DataKeeper sebagai alat untuk meningkatkan kemampuan mereka dalam memahami, mengoperasikan, dan meningkatkan solusi untuk tahun-tahun mendatang.

Lihat bagaimana ketersediaan tinggi dapat mendukung desain infrastruktur Anda—tanpa menambah kerumitan.Minta demo hari ini!

Penulis: Philip Merry, CX Software Engineer di SIOS

Direproduksi dengan izin dariSIOS

Peran Penting Lingkungan QA dan Produksi dalam Ketersediaan Tinggi

Peran Penting Lingkungan QA dan Produksi dalam Ketersediaan Tinggi

Untuk tim TI yang mengelola aplikasi modern danMempertahankan ketersediaan yang tinggiMeskipun meluncurkan pembaruan bisa menjadi tantangan, bagian integral untuk mencapai keandalan adalah pemisahan lingkungan Jaminan Kualitas (QA) dan produksi. Meskipun mungkin tampak seperti praktik sepele, hal ini penting untuk mendeteksi potensi masalah dan menanamkan kepercayaan pada tugas pemeliharaan.

Lingkungan QA sebagai Tempat Pengujian untuk Ketersediaan Tinggi

Lingkungan QA berfungsi sebagai replika dari lingkungan produksi. Ini menyediakan lingkungan uji coba (sandbox) tempat fitur baru, perubahan konfigurasi, dan patch dapat diuji secara menyeluruh. Selain pengujian fungsional, lingkungan QA memungkinkan validasi proses, pengukuran kinerja, pengujian beban, dan validasi keamanan.

Ini adalah aktivitas penting untuk mengidentifikasi hambatan, kerentanan, atau masalah integrasi sebelum hal tersebut berdampak pada pengguna akhir atau membahayakan lingkungan Anda. Untuk sistem terdistribusi atauarsitektur awanLingkungan QA dapat membantu mensimulasikan latensi jaringan, penundaan replikasi basis data, dan kasus-kasus ekstrem operasional lainnya yang dapat mengganggu operasional bisnis jika tidak diuji.

Lingkungan Produksi dan Pengalaman Pengguna Akhir

Lingkungan produksi adalah tempat pengguna akhir bergantung pada sistem untuk berkinerja secara konsisten. Setiap waktu henti atau kegagalan yang tidak direncanakan dapat memiliki konsekuensi bisnis langsung, mulai dari hilangnya pendapatan hingga kerusakan reputasi.

Dengan memisahkan lingkungan produksi dari pengembangan dan pengujian yang sedang berlangsung, tim TI dapat memastikan stabilitas operasional. Lingkungan produksi yang dikonfigurasi dengan benar harus mencakup hal-hal berikut.strategi redundansi, mekanisme failover, dan alat pemantauan yang telah divalidasi melalui pengujian di lingkungan QA sebelum diterapkan.

Transisi yang Lancar Melalui Alur Implementasi yang Terstruktur

Ketersediaan tinggi tidak hanya tentang menjaga sistem tetap berjalan. Ini juga dapat mencakup membuat pembaruan dapat diprediksi. Lingkungan QA dapat mendukung alur kerja penerapan yang terstruktur, memungkinkan berbagai strategi seperti peluncuran bertahap dan rilis biru-hijau. Prosedur pengembalian (rollback), yang telah divalidasi sebelumnya di QA, memungkinkan tim untuk pulih dengan cepat jika masalah tak terduga muncul. Pendekatan terstruktur membuat pembaruan dapat diprediksi dan membantu menjaga kepercayaan pelanggan.

Manfaat Operasional dari Pemisahan Lingkungan QA dan Produksi

Memiliki lingkungan QA dan produksi yang terpisah juga dapat mendukung kepatuhan, kesiapan audit, dan koordinasi antar tim. Batasan yang jelas antara pengujian dan sistem yang berjalan dapat membantu tim operasional dan pengembangan berkolaborasi secara efisien. Hal ini juga membantu menyediakan kerangka kerja yang dapat diulang untuk pemantauan, pemecahan masalah, danperencanaan pemulihan bencana.

Lingkungan QA dan Produksi dalam Strategi Ketersediaan Tinggi

Lingkungan QA dan produksi memainkan peran penting dalam menjaga agar sistem berjalan lancar. Dengan memisahkan lingkungan, melakukan pengujian secara menyeluruh, dan mengelola penyebaran dengan hati-hati, tim TI dapat mengurangi waktu henti, mempertahankan ketersediaan tinggi, dan membuat transisi antar pembaruan menjadi lancar. Praktik-praktik ini membantu memastikan sistem tetap andal dan tangguh seiring perkembangannya.

Siap meningkatkan ketersediaan tinggi di seluruh lingkungan QA dan produksi?Minta demountuk melihat bagaimana SIOS membantu tim menerapkan pembaruan dengan percaya diri dan menjaga agar sistem penting tetap berjalan.

Penulis: Tristan Allen, Associate Customer Experience Software Engineer di SIOS Technology

Diterbitkan ulang dengan izin dari SIOS .

Bahaya Mematikan, Menghidupkan Kembali: Berpikir dalam Ketersediaan Tinggi

Bahaya Mematikan, Menghidupkan Kembali: Berpikir dalam Ketersediaan Tinggi

“Matikan, lalu hidupkan kembali.” Siapa pun yang pernah berpengalaman memecahkan masalah komputer pasti pernah mendengar saran ini. Saran ini terkenal sebagai solusi teknologi yang paling umum, dan mampu mengubah siapa pun menjadi ahli pemecah masalah TI. Masalahnya adalah, ini sebenarnya bukanlah solusi sebenarnya; ini hanya kebetulan menyelesaikan sebagian besar masalah. Dengan mematikan dan menghidupkannya kembali, kita dengan cepat dapat kembali beroperasi, tetapi kita tidak pernah benar-benar mengetahui apa masalah sebenarnya sejak awal.

Mengapa “Mematikan dan Menghidupkan Kembali” Berisiko dalam Sistem Ketersediaan Tinggi

Selain itu, dalam dunia ketersediaan tinggi, “mematikannya” bisa menjadi masalah besar. Bahkan hanya beberapa menit sajawaktu hentiHal ini bisa menjadi masalah besar bagi perusahaan yang harus memastikan infrastruktur kritis mereka tetap beroperasi. Karena itu, sebagai tim dukungan teknis di SIOS, kami jarang memberikan saran teknis yang terkenal buruk ini, tetapi kami memiliki versi kami sendiri.

Banyak yang telah menghubungi dukungan teknis di SIOS untukWindows DataKeeperJika mengalami masalah mirroring, Anda mungkin akan disarankan untuk menjalankan perintah “cleanupmirror.” Dalam situasi yang tepat, perintah ini sangat bagus untuk membantu seseorang mengatasi masalah besar dengan cepat. Perintah ini pada dasarnya menghapus konfigurasi mirror dan semua sisa-sisa yang mungkin ada, sehingga kita dapat membuat mirror baru, bebas dari masalah apa pun yang sebelumnya mengganggunya. Perlu dicatat bahwa ini sebenarnya tidak menghapus data apa pun, hanya replikasi antar sistem.

Perintah ini tidak memerlukan waktu henti, tetapi berarti sistem tidak akan memiliki ketersediaan tinggi hingga proses sinkronisasi ulang mirror selesai. Ini adalah salah satu langkah pemecahan masalah andalan kami dalam dukungan teknis, tetapi seperti “matikan, lalu hidupkan kembali,” terkadang hal ini dapat menyembunyikan masalah mendasar yang lebih serius, dan terkadang bisa berlebihan.

Hari ini, saya ingin membahas salah satu kasus di mana menjalankan cleanupmirror berhasil mengatasi masalah mendesak bagi pelanggan, tetapi hampir membuat kami melewatkan masalah yang cukup serius, yang dapat memengaruhi banyak pelanggan, namun memiliki solusi dan perbaikan yang sangat mudah.

Masalah Mirroring DataKeeper di Dunia Nyata Selama Migrasi

Ketika tim dukungan bergabung, pelanggan sudah cukup lama mencoba mengatasi masalah ini, dan mereka mulai panik. Mereka sedang melakukan upaya terakhir mereka.peralihanPengujian sedang dilakukan sebagai bagian dari migrasi mereka ketika mirroring DataKeeper mulai mengalami masalah. Pada titik ini, infrastruktur penting mereka mengalami gangguan, dan mereka khawatir hal itu akan mulai memengaruhi bisnis mereka. Ini adalah situasi yang sangat menegangkan, tetapi untungnya, para insinyur dukungan di sini melakukan pekerjaan yang sangat baik. Mereka menyeimbangkan tekanan, ketergesaan, dan kebutuhan untuk menemukan solusi yang baik, dan menjalankan perintah “cleanupmirror” yang sudah teruji dan terbukti, diikuti dengan pembuatan ulang mirror agar berfungsi dengan baik. Mereka menyelamatkan pelanggan dari kesulitan, dan semua orang melanjutkan pekerjaan. Untungnya, mereka juga meminta pelanggan untuk mengirimkan log, “sebagai tindakan pencegahan.”

Catatan dalam kasus ini agak membingungkan. Catatan tersebut menunjukkan bahwasebuah volume telah diubah ukurannyaNamun, pelanggan mengklaim bahwa mereka tidak melakukan aktivitas pengubahan ukuran apa pun selama panggilan tersebut. Terkadang pelanggan lupa menyampaikan informasi penting, jadi kami mengira mungkin mereka lupa menyebutkan detail tersebut dalam panggilan, tetapi pengubahan ukuran tersebut tidak masuk akal. Perubahan ukurannya sangat kecil, dan terjadi pada semua volume secara bersamaan dengan peralihan pertama. Tidak masuk akal bagi pelanggan untuk mengubah ukuran terabyte drive besar mereka dengan mengurangi kurang dari satu gigabyte sekaligus, tepat pada saat yang bersamaan dengan peralihan pertama, jadi kami menyelidiki lebih dalam. Ternyata drive target sedikit lebih besar daripada drive sumber, dan ada masalah pada produk kami terkait cara penanganan ukuran drive yang tidak sesuai.

Mengidentifikasi Akar Penyebab Mencegah Terulangnya Waktu Henti

Setelah kami menemukan solusinya, kami menyadari bahwa yang dibutuhkan untuk menyelesaikan masalah ini hanyalah melanjutkan mirroring. Ini adalah operasi umum, cepat, dan mudah yang hanya membutuhkan beberapa detik untuk memperbaiki masalah sepenuhnya. Tidak perlu sinkronisasi ulang berhari-hari sebelum kami kembali memiliki ketersediaan tinggi. Selain itu, setelah kami menemukan masalah ini, perbaikannya sangat cepat dan mudah untuk diimplementasikan pada versi produk berikutnya.

Ternyata pelanggan tersebut memiliki skenario migrasi yang unik, yang mengharuskan mereka untuk membuat target sedikit lebih besar, karena menyamakan ukurannya tidak mungkin dilakukan. Mereka masih memiliki beberapa sistem yang belum dimigrasikan, dan jika kami hanya menyelesaikan kasus ini dengan “cleanupmirror,” mereka akan menghadapi masalah ini setiap kali. Karena kami menemukan akar penyebabnya, kami dapat memberi mereka solusi cepat dan mudah, dan bahkan tindakan pencegahan yang lebih cepat yang dapat mereka lakukan sebelum menjalankan peralihan pertama. Kami juga dapat mempublikasikan solusi, sehingga pelanggan berikutnya yang mengalami masalah ini dapat menyelesaikannya dalam hitungan menit.

Mengapa Analisis Akar Penyebab Penting dalam Ketersediaan Tinggi?

Jadi, apa masalah besar dengan “matikan, lalu hidupkan kembali”? Itu menyembunyikan akar permasalahan. Jadi, apakah itu berarti Anda tidak boleh menggunakannya sama sekali? Itu masih merupakan salah satu saran teknologi terbaik yang ada. Seringkali, Anda sebenarnya tidak perlu tahu apa akar permasalahannya, dan mematikan lalu menghidupkannya kembali akan membantu Anda keluar dari masalah dengan sangat cepat.

Hal terpenting bagi seorang profesional TI adalah, ketika Anda tidak perlu segera keluar dari situasi sulit dan memiliki waktu luang untuk menyelidiki terlebih dahulu, Anda harus melakukannya. Jika tidak, Anda harus kembali lagi nanti dan melihat log untuk mencoba mencari tahu apa yang terjadi.

Jadi, silakan matikan dan hidupkan kembali sesuka hati Anda. Jadilah pesulap yang memecahkan satu masalah dalam hitungan menit, dan buat semua orang bertanya-tanya bagaimana Anda melakukannya. Tapi… sesekali… luangkan waktu untuk kembali dan mencari tahu mengapa Anda perlu mematikan dan menghidupkannya kembali… dan pertimbangkan kemungkinan bahwa mungkin ada solusi yang lebih mudah.

Untuk mempelajari lebih lanjut tentang bagaimana SIOS DataKeeper dan solusi ketersediaan tinggi dapat membantu Anda menghindari masalah tersembunyi seperti ini,minta demodari tim kami hari ini.

Penulis: Carter Chandler, CX Associate, Insinyur Perangkat Lunak di SIOS Technology

Direproduksi dengan izin dariSIOS