3 Tantangan dalam Mempertahankan Ketersediaan Tinggi dengan Infrastruktur Warisan

3 Tantangan dalam Mempertahankan Ketersediaan Tinggi dengan Infrastruktur Warisan

Ketersediaan tinggi (HA) sangat penting bagi organisasi yang bergantung pada akses berkelanjutan ke aplikasi, layanan, dan data. Baik untuk mendukung platform yang berhadapan langsung dengan pelanggan maupun operasi bisnis internal, waktu henti dapat dengan cepat menyebabkan kerugian finansial, masalah produktivitas, dan kerusakan reputasi. Meskipun banyak perusahaan terus menggunakan infrastruktur lama karena biaya, kompatibilitas, atau persyaratan bisnis, mempertahankan ketersediaan tinggi di lingkungan yang lebih tua menjadi semakin sulit dari waktu ke waktu. Sistem TI lama seringkali menimbulkan keterbatasan teknis dan risiko operasional yang dirancang untuk dihindari oleh platform modern.

Salah satu masalah paling umum dengan infrastruktur lama adalah meningkatnya ketidakcocokan antara paket perangkat lunak, pustaka, dan komponen sistem. Teknologi lama sering dibangun di atas ketergantungan yang sangat erat yang dirancang bertahun-tahun yang lalu, sebelum pemisahan (decoupling) benar-benar dipraktikkan. Seiring waktu, sistem ini menjadi sulit untuk diperbarui karena perangkat lunak telah berubah secara drastis atau tidak lagi dipelihara.

Berikut beberapa contoh masalah yang mungkin Anda hadapi dengan infrastruktur yang lebih tua:

• Memperbarui satu paket atau pustaka dapat secara tidak sengaja merusak komponen lain yang bergantung pada versi yang lebih lama. Saya sendiri pernah mengalami hal ini, di mana satu ketergantungan mengarah ke ketergantungan lain dan seterusnya, dan berjam-jam berlalu saat Anda mengkompilasi ulang selusin paket!
• Kurangnya dokumentasi tentang bagaimana layanan-layanan tersebut berinteraksi dapat mempersulit proses peningkatan versi.
• Terakhir, alat pemantauan, keamanan, atau otomatisasi modern mungkin tidak terintegrasi dengan baik dengan sistem yang sudah usang. Dalam lingkungan HA (High Availability), bahkan masalah kompatibilitas kecil pun dapat memicu gangguan besar.

Rencanakan modernisasi infrastruktur sebagai bagian dari strategi ketersediaan tinggi Anda.

Mempertahankanketersediaan tinggiPenggunaan infrastruktur yang lebih tua menghadirkan tantangan teknis dan operasional. Ketidaksesuaian paket, dukungan vendor yang terbatas, dan menurunnya keahlian internal dapat mengancam stabilitas sistem dan meningkatkan risiko waktu henti (downtime).

Meskipun sistem lama mungkin terus melayani fungsi bisnis penting, organisasi harus secara proaktif merencanakan modernisasi infrastruktur, meningkatkan praktik dokumentasi, dan berinvestasi dalam transfer pengetahuan sebelum keahlian penting hilang. Strategi HA yang kuat adalah tentang memastikan keandalan, keamanan, dan ketahanan operasional jangka panjang untuk masa depan.

Penulis: Cassy Hendricks-Sinke, Insinyur Sistem Senior, Operasi TI, SIOS

Direproduksi dengan izin dariSIOS

Aplikasi Generik LifeKeeper untuk Ketersediaan Tinggi dan Pemulihan Bencana

Aplikasi Generik LifeKeeper untuk Ketersediaan Tinggi dan Pemulihan Bencana

Kunci Sukses untuk Melindungi Aplikasi Penting bagi Bisnis

Ketersediaan Tinggi dan Pemulihan Bencana harus mencakup berbagai macam kasus penggunaan. Ada banyak sekali kasus penggunaan, sebanyak jumlah organisasi, jauh melebihi kemampuan dari satu solusi tunggal.Ketersediaan TinggiDanPemulihan BencanaSolusi ini memberikan dukungan siap pakai untuk setiap skenario. Meskipun banyak aplikasi umum memiliki beragam solusi Ketersediaan Tinggi dan Pemulihan Bencana yang tersedia, kasus penggunaan yang lebih spesifik membatasi pilihan yang tersedia untuk melindungi aplikasi yang sangat penting bagi bisnis.

Tentu saja, LifeKeeper tidak dapat mencakup setiap kasus penggunaan secara langsung. Namun, LifeKeeper menyediakan kerangka kerja yang serbaguna dan fleksibel yang dapat diadaptasi ke berbagai kasus penggunaan untuk mengatasi keterbatasan ini. Meskipun ampuh, kerangka kerja ini mungkin tampak kompleks bagi orang awam. Blog ini hadir untuk membantu memberikan pemahaman awal ketika mulai mengkonseptualisasikan Generic Application Recovery Kit untuk kasus penggunaan spesifik Anda.

Blog Terkait dan 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 Perangkat Lunak Senior 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 Perangkat Lunak Senior 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.

Mengkonseptualisasikan Aplikasi dan Mendefinisikan Pendekatan

Mengajukan Pertanyaan Terkecil Tentang Kesehatan Aplikasi

Administrasi sistem dan rekayasa perangkat lunak adalah dua bidang yang penuh dengan nuansa. Ada begitu banyak elemen berbeda di balik sebuah pertanyaan sehingga jawaban yang sederhana dan lugas sulit diperoleh. Dalam percakapan, hal ini mudah diatasi. Namun dalam kode, jawaban yang kompleks sulit diakomodasi. Mengajukan pertanyaan “terkecil” adalah praktik menargetkan pertanyaan pada elemen terkecil yang mungkin, sambil memastikan bahwa jawabannya memiliki kriteria yang jelas.

“Apakah aplikasinya berjalan?” Ini adalah pertanyaan “besar”; mungkin memerlukan jawaban yang panjang lebar. Ya, aplikasinya berjalan, tetapi tidak merespons. Ya, aplikasinya berjalan, tetapi berjalan di sistem lain – bukan sistem yang sedang Anda bicarakan. Kriteria jawabannya ambigu, dan jawabannya bernuansa – tingkat detail yang lebih disukai pengembang untuk tidak perlu ditangani.

“Apakah proses aplikasi sedang berjalan, dan apakah aplikasi secara aktif merespons permintaan?”

Meskipun lebih panjang untuk diucapkan, ini adalah pertanyaan yang lebih kecil. Pertanyaan ini secara jelas mendefinisikan kondisi di mana jawabannya adalah ya atau tidak. Meskipun perubahan ini merupakan peningkatan, ini belum menjadi pertanyaan “terkecil”. Pertanyaan sebelumnya jatuh pada jebakan yang sama yaitu menanyakan “Apakah X dan Y keduanya benar?” Jawaban ya atau tidak tidak dapat memberikan tingkat detail untuk menentukan kebenaran X dan Y secara independen. Pertanyaan terkecil membutuhkan kekhususan; pertanyaan tersebut harus memberikan wawasan penuh tentang status elemen terkecil dari keseluruhan yang lebih besar. “Apakah proses aplikasi berjalan pada sistem yang diinginkan?” Itu adalah pertanyaan kecil – dalam hal ini, ini adalah pertanyaan terkecil. Perlu diingat, mungkin ada beberapa pertanyaan “terkecil” – dalam contoh ini, “apakah aplikasi merespons kueri” juga memenuhi syarat.

Meskipun pertanyaan dapat dipecah hampir tanpa batas, ada batasnya. Mengajukan “pertanyaan terkecil?”, menyiratkan “Mengajukan pertanyaan terkecil yang masih memberikan informasi yang berguna/dapat ditindaklanjuti”. Mengajukan “Apakah saya berada di kereta menuju Philadelphia?” sudah cukup; melanjutkan dengan bertanya “Apakah saya berada di kereta menuju Philadelphia, dan ke arah mana Philadelphia?” memberikan lebih banyak informasi – tetapi tidak dapat ditindaklanjuti. Saya tidak dapat mengubah arah kereta. Saya tahu dari jawaban atas pertanyaan “Apakah saya berada di kereta menuju Philadelphia?” apakah saya perlu menelepon kantor untuk memberi tahu atasan saya bahwa saya akan terlambat.

Meskipun jelas dalam contoh ini, hal ini kurang terlihat jelas saat mengembangkan aplikasi generik. Sepanjang proses melindungi aplikasi generik, seseorang tetap harus memperhatikan gambaran yang lebih besar. Ini, seperti hal lainnya, adalah sebuah keterampilan – dengan latihan dan kolaborasi, akan muncul kemampuan untuk menentukan kapan suatu pertanyaan adalah pertanyaan terkecil, dan kapan nuansa lebih lanjut berhenti memberikan informasi tambahan yang bermanfaat.

Pertanyaan-pertanyaan luas yang telah dipecah menjadi pertanyaan-pertanyaan yang lebih kecil, spesifik, dan terarah mengenai elemen-elemen individual merupakan dasar pembuatan Generic Application Recovery Kits. Setiap “pertanyaan besar” dapat dijawab melalui gabungan jawaban yang diberikan untuk setiap elemen yang terlibat di dalamnya.

Setelah pertanyaan dipecah menjadi elemen terkecilnya, informasi yang perlu disampaikan menjadi jauh lebih jelas. Dengan mengetahui informasi yang dibutuhkan, pekerjaan selanjutnya dalam mengembangkan Generic Application Recovery Kit hanyalah tentang bagaimana mendapatkan informasi yang dibutuhkan dari informasi yang diberikan. Kita harus bekerja dengan informasi yang ada.

Bekerja dengan API Aplikasi dan API LifeKeeper

Seringkali, aplikasi menyediakan Antarmuka Pengguna Grafis (GUI) untuk menampilkan informasi atau menunjukkan perubahan yang terjadi pada aplikasi. Meskipun sangat bagus untuk penggunaan oleh manusia, hal ini kurang berguna ketika administrasi dilakukan oleh aplikasi. GUI dirancang untuk digunakan oleh manusia, dan aplikasi (dengan mengabaikan upaya pemrograman yang sangat besar dan kompleksitas yang tidak perlu) tidak dilengkapi untuk berinteraksi dengan GUI aplikasi lain seperti yang dilakukan manusia. Untuk keperluan LifeKeeper dan Sumber Daya Aplikasi Generik, pertukaran informasi antara skrip aksi Generic Application Recovery Kit dan aplikasi yang dilindungi harus dilakukan melalui Antarmuka Pemrograman Aplikasi, atau “API”.

LifeKeeper menyediakan API-nya sendiri untuk berinteraksi dengan LifeKeeper, hierarki, dan sumber daya di dalam hierarki. Dalam hal API LifeKeeper, utilitas baris perintah yang terdapat dalam produk adalah yang paling mudah digunakan dalam Aplikasi Generik. Sebagai rekomendasi umum, hanya utilitas baris perintah yang diuraikan dalam Dokumentasi Produk LifeKeeper (Dokumentasi Perintah Linux/Dokumentasi Perintah Windows) sebaiknya digunakan. Meskipun ada rekomendasi ini, perintah-perintah ini harus digunakan dengan hati-hati dan memperhatikan detail untuk memastikan bahwa tindakan yang tidak diinginkan tidak terjadi.

Tentu saja, LifeKeeper bukanlah satu-satunya faktor dalam Aplikasi Generik. Aplikasi yang dilindungi juga memerlukan API yang disajikan agar skrip aksi dapat memanfaatkan API aplikasi untuk mencapai hasil yang diinginkan. Mengembangkan Kit Pemulihan Aplikasi Generik memang membutuhkan pengetahuan tentang API aplikasi yang dilindungi dan penggunaan API tersebut dalam skrip aksi yang membentuk Kit Pemulihan Aplikasi Generik.

Menggunakan Kode Pengembalian dan Aliran Keluaran dalam Skrip Pemulihan

Baik itu API untuk LifeKeeper atau aplikasi yang dilindungi, informasi akan dikeluarkan terutama dalam dua cara:

• Kode Pengembalian
• Aliran Keluaran (kadang-kadang disebut “keluaran STDOUT/STDERR” atau hanya “keluaran terminal”)

Bagaimana Kode Pengembalian Membantu Menentukan Keberhasilan atau Kegagalan

Secara umum, kode pengembalian memberikan cara cepat untuk melihat apakah suatu utilitas berhasil atau gagal. Biasanya (dalam konteks lingkungan shell), kode pengembalian 0 menunjukkan keberhasilan, sedangkan kode pengembalian bukan nol menunjukkan kegagalan.

Tergantung pada aplikasinya, nilai pasti dari kode pengembalian dapat memberikan wawasan lebih lanjut tentang kesalahan yang ditemui. Seringkali, hasil dari tindakan yang dilakukan melalui API aplikasi dapat disimpulkan hanya dengan memeriksa kode pengembalian.

Dalam kasus yang lebih rumit, kode pengembalian mungkin hanya digunakan untuk memberi tahu program tindakan apa yang harus diambil setelah panggilan ke API aplikasi. Kode pengembalian sangat berguna ketika berurusan dengan utilitas yang berkaitan dengan keadaan beberapa elemen yang mendasarinya.

Bagaimana Aliran Keluaran Memberikan Informasi Aplikasi yang Lebih Detail

Output Stream, meskipun lebih kompleks untuk digunakan dalam sebuah program, terkadang diperlukan untuk pertukaran informasi atau untuk memverifikasi hasil. Jika menjalankan utilitas untuk mendapatkan nama host sistem, kode pengembalian saja tidak akan menunjukkan nama host tersebut, kecuali jika utilitas tersebut berhasil mengambil nama host. Dalam beberapa kasus, utilitas API dapat mengembalikan kode pengembalian yang berhasil jika informasi yang diminta telah diperoleh, tetapi informasi tersebut harus dievaluasi validitasnya berdasarkan keadaan.

Baik menggunakan kode pengembalian atau aliran keluaran, pengembangan Aplikasi Generik memerlukan penggunaan informasi yang tersedia. Saat memikirkan cara untuk mencapai tindakan sumber daya (yang diuraikan di bagian selanjutnya) atau menentukan informasi tentang aplikasi atau sumber daya LifeKeeper, cobalah untuk berpikir dalam hal kode pengembalian dan aliran keluaran, bukan antarmuka GUI. Akan sangat membantu jika membayangkan mencoba menyampaikan informasi melalui telepon. Artinya, informasi paling baik dikomunikasikan, tindakan paling baik didefinisikan, dan skenario paling baik ditangani ketika input dan output utilitas dilaporkan persis seperti yang akan diberikan sebagai input atau dilaporkan sebagai output.

Membangun Landasan untuk Perlindungan Aplikasi Generik

Bagian ini menjaga strategi tetap sangat konseptual. Strategi-strategi ini meletakkan dasar untuk memikirkan suatu aplikasi melalui respons yang diberikan terhadap pertanyaan dan tindakan yang dikeluarkan pada aplikasi tersebut. Ke depannya, pendekatan akan menjadi lebih spesifik untuk LifeKeeper dan proses pembuatan Generic Application Recovery Kit. Sementara itu, strategi-strategi ini berkembang seperti keterampilan lainnya, melalui latihan. Dalam komunikasi teknis, penulisan prosedur, atau kapasitas apa pun yang Anda geluti, mempraktikkan strategi konseptualisasi ini akan bermanfaat tidak hanya dalam jangka pendek tetapi juga dalam jangka panjang.

Butuh bantuan melindungi aplikasi penting bisnis yang tidak sesuai dengan model ketersediaan tinggi standar? SIOS dapat membantu Anda mengevaluasi lingkungan Anda dan menentukan pendekatan LifeKeeper yang tepat.Minta demoHari ini.

Penulis: Philip Merry, Teknisi Dukungan L3 di SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Panduan Dukungan SIOS Enterprise: Apa yang Dicakup oleh Paket Anda

Panduan Dukungan SIOS Enterprise: Apa yang Dicakup oleh Paket Anda

Apa Saja yang Termasuk dalam Paket Dukungan SIOS Enterprise Anda?

Berikut beberapa kiat singkat tentang apa yang tercakup dan tidak tercakup dalam dukungan tingkat perusahaan, dan ke mana harus mencari informasi tambahan berdasarkan tiga skenario umum.

Dukungan 24/7 untuk Waktu Henti Sistem Kritis

Skenario 1: Sistem Mati Setelah Jam Kerja

Tim Joan: Sekarang pukul 7 malam EST pada hari Minggu. Peralihan rutin antar node klaster SIOS LifeKeeper seharusnya berjalan lancar. Namun, sesuatu yang tidak terduga terjadi, mengakibatkan kegagalan peralihan. Terlepas dari semua upaya tim untuk menyelesaikan masalah, klaster tetap mati. Joan membutuhkan bantuan, tetapi dia tidak yakin apakah paket dukungan teknis SIOS-nya mencakup akhir pekan atau berapa lama waktu yang dibutuhkan untuk menghubungi petugas dukungan melalui telepon.

Pelanggan yang telah membeli (atau memperbarui) dukungan tingkat Enterprise mereka sebelum terjadi insiden memiliki akses untuk menerima dukungan 24 jam sehari, 7 hari seminggu. Dukungan ini mencakup akhir pekan dan hari libur untuk menangani Masalah Kritis. Masalah Kritis berarti sistem atau aplikasi produksi yang tidak berfungsi, di mana data Pelanggan tidak dapat diakses menggunakan Program SIOS. Untuk semua masalah Prioritas 1 (kritis), di mana operasi normal mengakibatkan hilangnya akses ke data produksi Anda, SIOS memberikan waktu respons 2 jam.

Jika Joan memiliki dukungan Enterprise yang valid, dia dapat menghubungi tim dukungan SIOS, dan masalahnya di luar jam kerja akan ditangani.

Dukungan Instalasi dan Konfigurasi

Skenario 2: Bantuan Instalasi Diperlukan

Tim Scott: Sekarang pukul 4 sore EST hari Kamis. Persetujuan untuk proyek infrastruktur baru telah selesai, termasuk konfigurasi ketersediaan tinggi yang diperlukan untuk aplikasi dan data penting. Pada pertemuan awal, para pemangku kepentingan menggeser tanggal peluncuran. Akibatnya, tim perlu memasang dan mengkonfigurasi sistem dengan cepat untuk menghindari gangguan layanan. Tim Scott tahu cara mengkonfigurasi aplikasi dan server, tetapi mereka ingin memastikan bahwa mereka memasang solusi HA dengan benar. Mereka membutuhkan bantuan, tetapi Scott tidak yakin apakah paket dukungan mereka mencakup bantuan untuk kesalahan instalasi.

Karena tim Scott sedang dalam fase implementasi, proyek infrastruktur baru ini melibatkan sistem yang belum divalidasi atau berhasil dioperasikan. Jika tim Scott memiliki dukungan SIOS Enterprise level yang valid, ia akan memiliki akses ke dokumentasi produk SIOS dan petunjuk instalasi. Namun, bantuan instalasi dan konfigurasi tidak tercakup dalam dukungan Enterprise Scott, tetapi ia dapat menghubungi perwakilan penjualan SIOS-nya untuk mengatur layanan instalasi Profesional berbayar. Layanan ini akan memastikan bahwa tim Scott mendapatkan bantuan yang mereka butuhkan untuk menginstal, mengkonfigurasi, dan memvalidasi klaster mereka dengan benar. SIOS menyediakan berbagai macamlayanan profesionalDirancang untuk membantu pelanggan menerapkan, mengelola, dan memelihara lingkungan HA mereka dengan cepat dan hemat biaya.

Analisis Akar Penyebab (RCA) Setelah Failover

Skenario 3: Dukungan RCA Pasca-Failover

Tim Amol: Sekarang pukul 2 pagi EST hari Selasa. Sebuah peringatan telah dikirimkan ke seluruh tim aplikasi di AjaxBjax Corp. Klaster yang melindungi sistem aplikasi paling penting perusahaan sedang melakukan failover. Amol memeriksa dasbor aplikasi dan menemukan bahwa failover berhasil dan semua aplikasi berfungsi. Namun, Amol tahu bahwa manajemen akan menginginkan beberapa penjelasan dan jaminan. Amol ingin memastikan bahwa semua layanan aplikasi aktif dan berfungsi, tetapi dia tidak yakin apakah rencana dukungan mereka mencakup hal ini.

Tim Amol sedang mencari RCA (Analisis Akar Penyebab) dan keyakinan bahwa sistem mereka akan terus beroperasi. Data Amol dapat diakses, dan aplikasinya berfungsi penuh. Sistemnya bukan server produksi yang mengalami gangguan kritis, maupun masalah P1. Namun, jika AjaxBjax Corp memiliki dukungan Enterprise yang valid untuk cluster mereka, mereka dapat menghubungi tim dukungan SIOS untuk mendapatkan panduan sepanjang waktu (US East), Senin hingga Jumat, untuk masalah RCA. Panggilan Amol pukul 2 pagi akan dialihkan ke salah satu pusat dukungan SIOS yang berpengalaman, di mana tim akan mulai bekerja sama dengan Amol.

Pertanyaan Tambahan Tentang Menghubungi Dukungan SIOS

Amol dan Joan dapat menghubungi dukungan melalui Saluran Bantuan Dukungan (AS: 877.457.5113; Internasional: +1.803.808.4270) dengan cakupan yang termasuk dalam Dukungan Perusahaan mereka. Scott dapat menerima bantuan yang dibutuhkannya, bukan dari tim Dukungan, tetapi melalui pembelian layanan untuk membantu konfigurasi dan instalasi. Tetapi bagaimana dengan skenario lain, di mana Scott, Amol, Joan, dan yang lainnya dapat menemukan informasi lebih lanjut tentang tingkat dukungan dan detail dukungan mereka? Atau apakah produk mereka telah mencapai fase pemeliharaan atau dukungan diperpanjang?

Jika Anda memerlukan informasi tambahan mengenai perjanjian dukungan Anda, Anda dapat merujuk pada Perjanjian Dukungan Teknis SIOS (TSA), yang disertakan dalam setiap pesanan. TSA juga mudah diakses di situs web kami.situs unduhan, dan dapat diminta melalui email ke Tim Dukungan SIOS disupport@us.sios.comSelain itu, jadwal produk dan informasi tingkat dukungan dapat ditemukan secara online di [tautan].Siklus Hidup Produkhalaman.

Pelanggan yang sudah mengetahui apa saja yang tercakup dalam paket mereka, tetapi membutuhkan bantuan terkait suatu masalah, jawaban atas pertanyaan umum, analisis akar penyebab, perangkat lunak terbaru, atau petunjuk untuk informasi lebih lanjut dapat membuka kasus baru melaluiPortal Dukungansitus web atau melalui email ke Kotak Masuk Dukungan disupport@us.sios.comSetelah kasus Anda dibuat, tim akan berupaya memberikan respons dan solusi tepat waktu.

Penulis: Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan

Direproduksi dengan izin dariSIOS

Mengapa Lingkungan Sandbox Sangat Penting untuk Ketersediaan Tinggi

Mengapa Lingkungan Sandbox Sangat Penting untuk Ketersediaan Tinggi

Meyakinkan Manajemen untuk Berinvestasi pada Infrastruktur Non-Produksi

Meyakinkan manajemen untuk berinvestasi dalam infrastruktur non-produksi bukanlah pekerjaan yang mudah. ​​Jika ditangani secara asal-asalan, diskusi mengenai klaster pengujian tambahan atau lingkungan sandbox dengan cepat berubah menjadi keluhan tentang membayar dua kali lipat untuk suatu lingkungan (infrastruktur, perangkat lunak, sumber daya TI, aplikasi, dan lisensi), dan tuduhan bahwa pengujiangugusan“menghasilkan pendapatan nol”. Diskusi biaya meluas menjadi campuran pernyataan bahwa pencadangan, DevOps, dan buku panduan perangkat lunak telah membuat lingkungan pengujian menjadi usang.

Namun, biaya karena tidak memiliki replika persis dari lingkungan produksi Anda untuk pengujian seringkali jauh lebih tinggi daripada biaya klaster pengujian tambahan. Biaya tambahan ini seringkali muncul dalam bentuk gangguan yang tidak direncanakan, data yang rusak, perbaikan darurat, dan tim teknik yang kelelahan.

10 Pertanyaan untuk Membantu Membenarkan Lingkungan Sandbox

Jika Anda kesulitan mendapatkan persetujuan anggaran untuk lingkungan sandbox yang layak, ajukan 10 pertanyaan ini kepada tim kepemimpinan Anda. Pertanyaan-pertanyaan ini akan mengalihkan percakapan dari biaya cluster duplikat ke nilai memastikan bisnis terhindar dari kerugian.

1. Berapa sebenarnya biaya yang ditimbulkan oleh waktu henti (downtime) bagi organisasi kita?

Mulailah dari inti permasalahannya. Jika sebuah implementasi gagal dan klaster HA produksi mati, berapa biaya yang harus ditanggung organisasi? Berapa kerugian yang kita alami per jam? Berapa tingkat pengeluaran perusahaan kita per unit bisnis?

Pertanyaan ini menggeser percakapan dari pernyataan yang samar ke biaya per menit dari pendapatan yang hilang, gaji karyawan yang menganggur selama pemadaman, dan biaya kerusakan reputasi yang lebih sulit diukur. Jika pemadaman produksi menelan biaya $300.000 per jam, mencegah hanya satu pemadaman selama empat jam setiap tahunnya dapat menghemat $1,2 juta. Dengan angka bisnis yang nyata, ROI dari penerapan sandbox untuk mengurangi risiko pemadaman yang mahal menjadi sangat jelas.

2. Berapa banyak kegiatan pemeliharaan yang kita lakukan setiap bulan?

Sederhana saja: frekuensi sama dengan paparan risiko. Paparan risiko sama dengan biaya tambahan. Jika Anda menerapkan pembaruan, patch, atau perubahan konfigurasi setiap minggu, Anda mempertaruhkan segalanya sebanyak 52 kali dalam setahun. Kembali ke pertanyaan 1: Berapa biaya yang harus ditanggung organisasi akibat satu jam waktu henti karena pembaruan patch yang buruk? Sekarang kalikan angka tersebut dengan frekuensi pemeliharaan Anda.

Seperti yang diingatkan Tristan Allen, Associate Software Engineer di SIOS, kepada pelanggan, sandbox yang merupakan replika dari lingkungan produksi menyediakan lingkungan yang sangat berharga “di mana fitur baru, perubahan konfigurasi, dan patch dapat diuji secara menyeluruh. Di luar pengujian fungsional, lingkungan QA memungkinkan validasi proses, benchmarking kinerja, pengujian beban, dan validasi keamanan. Ini adalah aktivitas penting untuk mengidentifikasi hambatan,kerentananatau masalah integrasi sebelum masalah tersebut berdampak pada pengguna akhir atau membahayakan lingkungan Anda.”

Kecepatan perilisan dan pembaruan pemeliharaan meningkatkan kebutuhan akan jaring pengaman.

3. Seberapa yakin kita untuk menerapkannya ke lingkungan produksi?

Apakah tim selalu menahan napas setiap kali mereka melakukan pembaruan di lingkungan produksi? Berapa kali kita mendengar ungkapan, “Itu hanya perubahan satu baris”? Kesalahan “off by one” dan “null pointer” adalah perubahan kecil yang secara historis menyebabkan waktu henti yang besar. Seberapa yakin Anda dengan kemampuan tim Anda untuk memastikan paket yang baru diimplementasikan bebas dari kesalahan pengkodean, kesalahan logika, masalah arsitektur, ketidakkompatibilitas pihak ketiga, atau kesalahan urutan?

Seberapa yakin tim Anda dengan kesehatan Anda?lingkungan produksiJika lingkungan produksi Anda rentan, klaster sandbox memungkinkan Anda untuk memvalidasi proses penerapan itu sendiri, secara signifikan mengurangi biaya dan tekanan dari pengembalian darurat, serta memvalidasi perbaikan sebelumnya.

4. Seberapa besar toleransi risiko kita dalam menerapkan patch keamanan langsung di lingkungan produksi?

Patch keamanan adalah hal yang mutlak, tetapi terkadang patch tersebut bertentangan dengan pustaka atau konfigurasi yang sudah ada. Menerapkan patch kernel atau pembaruan basis data langsung ke lingkungan produksi adalah sebuah pertaruhan.

Sebagai VP Pengalaman Pelanggan, kami bekerja langsung dengan pelanggan untuk mengembalikan pembaruan kernel yang diterapkan langsung ke lingkungan produksi. Meskipun pembaruan tersebut memperbaiki satu masalah, pembaruan itu memiliki efek samping yang tidak terduga yang sangat berdampak pada lapisan penyimpanan, menyebabkan kebuntuan, kerusakan aplikasi, dan hambatan lainnya.

Jika Anda kesulitan membenarkan penggunaan kluster QA penuh, tanyakan kepada tim manajemen Anda: Apakah kita bersedia mengambil risiko aplikasi bisnis kritis untuk menerapkan patch keamanan? Sandbox memungkinkan Anda untuk menerapkan patch ini di lingkungan yang identik terlebih dahulu, memastikan bahwa “memperbaiki” keamanan tidak “merusak” bisnis. Selain patch, sandbox memungkinkan Anda untuk menyebarkan aplikasi dan pembaruan baru untuk mengeksplorasi kerentanan atau risiko keamanan yang mungkin muncul.

5. Apa dampak finansial dan operasional dari korupsi data?

Waktu henti (downtime) bersifat sementara; kehilangan data bisa bersifat permanen. Perubahan yang tidak kompatibel pada penyimpanan yang mendasarinya, kesalahan logika aplikasi, atau masalah pada driver perangkat dapat secara diam-diam merusak data dengan cara yang tidak langsung terlihat. Apakah Anda ingin lingkungan produksi Anda menjadi tempat di mana Anda menemukan bahwa pembaruan pada alat pencadangan Anda berarti Anda tidak lagi dapat mencadangkan atau memulihkan data aplikasi penting Anda?

Pada saat Anda menyadari kesalahan dalam produksi, Anda mungkin sudah berminggu-minggu terperangkap dalam data yang rusak. Atau Anda mungkin mengalami krisis dan menyadari bahwa cadangan Anda tidak dapat dipulihkan pada perangkat lunak yang baru diperbarui. Sandbox memungkinkan Anda untuk menjalankan pengujian integritas data, migrasi data, pembaruan skema, perubahan driver, dan bahkan skenario perangkat lunak replikasi terhadap salinan data nyata, memastikan bahwa jika data hilang atau rusak, hal itu terjadi di lingkungan yang aman, bukan di lingkungan yang menagih pelanggan Anda.

6. Mampukah kita membiarkan integrasi pihak ketiga gagal tanpa menimbulkan pemberitahuan?

Aplikasi Anda kemungkinan besar bergantung pada API, otentikasi pihak ketiga, aplikasi pihak ketiga, atau bentuk ketergantungan lainnya. Hal-hal ini berperilaku berbeda di bawah beban dan terutama di lingkungan terklaster.

Perubahan yang tidak kompatibel sering kali muncul bukan dari kode Anda, tetapi dari bagaimana kode Anda berinteraksi dengan infrastruktur. Jika suatu perubahan berfungsi di laptop pengembang tetapi gagal ketika didistribusikan ke tiga node, itu adalah gangguan yang menghentikan bisnis. Sandbox menangkap bug “berfungsi di mesin saya” sebelum mencapai pelanggan.

7. Seberapa siapkah kita menghadapi skenario pemulihan bencana (DR) yang sebenarnya?

Sebagian besar organisasi memilikiRencana Pemulihan Bencana (DR)Secara teori, rencana yang belum diuji hanyalah sebuah hipotesis. Satu-satunya cara untuk memvalidasi strategi DR adalah dengan menjalankannya, mensimulasikan kegagalan total situs atau peristiwa kerusakan data. Tanpa klaster sandbox, pengujian rencana DR Anda mengharuskan Anda untuk menargetkan lingkungan produksi Anda. Hal ini menimbulkan risiko, biaya, logistik yang berbahaya, dan waktu henti.

Tanpa klaster sandbox, Anda harus sengaja menonaktifkan sistem penghasil pendapatan untuk memverifikasi apakah sistem tersebut dapat diaktifkan kembali. Hal ini membutuhkan koordinasi besar-besaran antara tim jaringan, penyimpanan, basis data, dan aplikasi. Biaya untuk upaya ini di lingkungan produksi mirip dengan biaya penggunaan meteran air pada sistem yang bocor.

Selain waktu henti (downtime), proses pengujian skenario DR di lingkungan produksi hanya menimbulkan risiko dan kompleksitas. Risikonya meliputi bekerja dengan data langsung dan memastikan kepatuhan yang ketat terhadap semua langkah perlindungan data. Kompleksitasnya biasanya bukan pada proses failover—melainkan pada proses pemulihan. Setelah berhasil melakukan failover ke situs sekunder atau node cadangan, mengembalikan klaster produksi ke keadaan semula (failback) merupakan operasi yang kompleks dan berisiko tinggi.

Ingatkan manajemen bahwa biaya pembuatan sandbox akan memungkinkan tim Anda untuk mensimulasikan kegagalan besar dan menjalankan prosedur pemulihan penuh selama jam kerja tanpa memengaruhi pengguna. Tim dapat bekerja sama untuk menyempurnakan “Buku Panduan Operasional”, menemukan dan menyelesaikan kekurangan proses dengan aman, dan berlatih secara menyeluruh sehingga ketika bencana nyata terjadi, tim menjalankan rutinitas yang terkoordinasi dengan baik daripada eksperimen pertama yang berbahaya.

9. Bagaimana cara kami menerima vendor baru dan melatih tim yang sudah ada?

Organisasi-organisasi yang luar biasa memiliki proses orientasi TI untuk anggota tim baru, vendor, dan penyedia layanan. Organisasi-organisasi ini memahami bahwa kerangka kerja orientasi yang terstruktur dengan baik sangat penting bagi anggota tim baru. Mereka menghargai dan memprioritaskan pembuatan sistem manajemen pembelajaran dan budaya yang kaya akan sumber daya komprehensif yang membantu pendatang baru memahami lingkungan HA (High Availability) kritis yang akan mereka kelola, pelihara, dan perbarui. Mereka juga memahami nilai pembelajaran berkelanjutan dan pendekatan proaktif untuk menjaga keterampilan tim tetap tajam.

Tanpa sistem sandbox yang merupakan replika langsung dari lingkungan produksi, proses onboarding TI Anda harus memanfaatkan klaster produksi Anda. Itu berarti lulusan baru perguruan tinggi tersebut harus belajar cara menjalankan sistem produksi.manajemen patchPerangkat lunak keamanan, dan pembaruan aplikasi dalam lingkungan HA pada sumber pendapatan utama perusahaan. Ketika mereka menemukan bagian yang tidak jelas dalam buku panduan, atau yang secara kebetulan hilang, biaya produktivitas dan risiko kerusakan reputasi bagi mereka dan bisnis dapat sangat merugikan.

Dalam mengadvokasi lingkungan sandbox, tekankan sifat dari proses onboarding berkelanjutan bagi vendor, mitra, dan penyedia layanan terkelola, serta risiko jika tidak ada tempat bagi individu dan tim tersebut untuk mempelajari bisnis atau mengeksplorasi prosedur. Jika organisasi Anda tidak memiliki sistem sandbox, pertimbangkan untuk mengajukan beberapa pertanyaan kepada pimpinan Anda:

• Ke mana anggota tim baru kita akan pergi untuk memahami lingkungan yang akan mereka kelola, pelihara, dan perbarui?
• Bagaimana mereka akan menjaga agar keterampilan mereka tetap mutakhir?
• Sistem apa yang kita gunakan untuk melakukan onboarding tim berikutnya dengan benar bila diperlukan?

10. Apakah biaya asuransi alat bantu dengar lebih murah daripada biaya bencana?

Terakhir, mari kita bahas masalah yang paling penting: biaya peralatan dan perlengkapan.

Ketersediaan Tinggiperangkat lunak pengelompokandan biaya komputasi terkait tidaklah gratis. Namun, bandingkan biaya tahunan lisensi dan infrastruktur sandbox dengan biaya satu kali kejadian downtime besar, rollback, atau kehilangan data. Dalam hampir setiap skenario, biaya pencegahan akan jauh lebih murah daripada biaya penanganannya.

Lingkungan Sandbox Merupakan Investasi Kelangsungan Bisnis

Seperti yang disimpulkan Tristan Allen, Associate Software Engineer di SIOS, dalam blognya:

Lingkungan QA dan produksiMemainkan peran penting dalam menjaga agar sistem berjalan lancar. Dengan menjaga lingkungan tetap terpisah, melakukan pengujian secara menyeluruh, dan mengelola penerapan dengan hati-hati, tim TI dapat mengurangi waktu henti, mempertahankan ketersediaan tinggi, dan membuat transisi antar pembaruan menjadi lancar.

Jika tim manajemen Anda kesulitan memahami manfaat dari lingkungan sandbox penuh, cobalah mengajukan beberapa pertanyaan berikut kepada mereka. Dengan mengajukan pertanyaan-pertanyaan ini, Anda mengalihkan diskusi dari percakapan biaya yang terlalu disederhanakan menuju dialog yang terfokus terkait dengan hal tersebut.kelangsungan bisnis, sehingga memudahkan manajemen untuk menandatangani persetujuan pos anggaran tersebut. Klaster sandbox bukanlah barang mewah; ini adalah aset mitigasi risiko bagi bisnis.

Minta demountuk melihat bagaimana SIOS membantu Anda mengurangi risiko downtime dengan solusi ketersediaan tinggi dan pemulihan bencana yang tangguh.

Penulis: Cassius Rhue, Wakil Presiden Pengalaman Pelanggan di SIOS

Direproduksi dengan izin dariSIOS

Mewarisi DataKeeper

Mewarisi DataKeeper

Apa Artinya Mewarisi Lingkungan DataKeeper

Konsep warisan seringkali mengingatkan kita pada aset yang diwariskan dari satu individu ke individu lainnya. Webster dan kamus lainnya mendefinisikan warisan sebagai:

Warisan terdiri dari aset, properti, dan terkadang utang yang ditinggalkan oleh orang yang meninggal, yang dibagikan kepada ahli waris melalui surat wasiat, perwalian, atau hukum pewarisan tanpa wasiat negara bagian. Biasanya termasuk uang tunai, real estat, saham, obligasi, barang pribadi (perhiasan, mobil), dan kepentingan bisnis.”

Dalam dunia TI, pewarisan memiliki sentuhan digital. Ketika seorang Administrator Sistem mewarisi sebuah klaster yang menggunakan alat-alat seperti…Penjaga DataMereka tidak berurusan dengan aset berwujud seperti perhiasan atau properti, melainkan sumber daya digital—bayangkan konfigurasi, peran, dan sumber daya volume kritis. Dan meskipun warisan ini diharapkan merupakan hasil dari seseorang yang pensiun dari perusahaan atau menerima promosi yang layak, kita akan berharap itu bukan karena seseorang beralih ke “pusat data BESAR di langit.” (Ya, humor adalah mekanisme penanggulangan bagi para profesional TI!)

Jadi, jika Anda beruntung mendapatkan klaster 1×1 yang sudah ada dengan peran SQL Server dan sumber daya DataKeeper Volume terkait, dari mana Anda harus memulai? Langkah-langkah apa yang harus Anda ambil untuk memastikan proses orientasi dan transfer pengetahuan yang lancar?

Untuk membantu memandu transisi tersebut, berikut beberapa pertanyaan kunci yang harus Anda ajukan kepada diri sendiri atau Tim Manajemen Anda:

Pertanyaan Administrasi Akun

Detail Manajer Akun

• Siapakah Manajer Akun yang saat ini bertanggung jawab atas akun ini?
  • Apa saja detail kontak mereka (email, telepon, dll.)?

Informasi Perizinan

• Bagaimana status perjanjian lisensi, kontrak, dan perpanjangan Anda?
• Apakah ada masa berlaku lisensi atau tenggat waktu perpanjangan yang perlu diperhatikan?
• Di mana saya dapat mengakses portal perizinan, dan apakah saya memiliki kredensial yang diperlukan?

Pertanyaan Administrasi DataKeeper

Memahami Lingkungan

• Menilai infrastruktur yang ada saat ini, termasukKlaster Failover Windows Serverpengaturan, server, penyimpanan, dll.
• Beban kerja dan aplikasi apa saja yang saat ini dilindungi oleh DataKeeper?

Konfigurasi dan Manajemen

• Pelajari konfigurasi DataKeeper.
  • Jenis pencermian Asinkron dan Sinkron apa yang digunakan?
  • Bagaimana konfigurasi node klaster?
  • Penyimpanan apa yang dibutuhkan?

Pemeliharaan dan Pembaruan Perangkat Lunak

• Bagaimana cara tetap mendapatkan informasi terbaru tentang rilis, patch, dan pembaruan untuk DataKeeper?

Pengujian Failover dan Pemulihan

• Sesekali, uji failover untuk memastikan konfigurasi HA dan DR berfungsi sebagaimana mestinya.
• Apakah data yang dicerminkan konsisten dan dapat dipulihkan jika terjadi bencana?

Memahami Kepemilikan dan Ketergantungan Sumber Daya

Setelah Anda memahami sebanyak mungkin tentang warisan Anda, langkah selanjutnya adalah mulai merawat apa yang telah diberikan kepada Anda, seperti yang digambarkan dalam ilustrasi di atas. Ketika “mewarisi” kepemilikan suatuKlaster SQL ServerOleh karena itu, sangat penting untuk mengidentifikasi dan berkomunikasi dengan semua tim lintas fungsi yang terdampak oleh administrasi klaster. Beberapa area kunci, karena jumlahnya banyak, yang perlu difokuskan meliputi:

Tim SQL Server atau Aplikasi

• Mendapatkan pemberitahuan proaktif tentang setiap perubahan yang direncanakan pada nama atau instance SQL Server.
• Diberi tahu tentang penyisipan atau operasi SQL besar yang dapat memengaruhi kinerja klaster.
• Berikan detail mengenai lokasi file basis data, cadangan, dan snapshot.

Tim Jaringan

• Komunikasikan rencana untuk memindahkan peran SQL atau sumber daya terkait ke jaringan yang berbeda.
• Bagikan informasi tentang alamat IP baru atau perubahan terkait jaringan lainnya yang dapat memengaruhi operasi klaster.

Tim Penyimpanan

• Berhati-hatilah saat melakukan perubahan pada volume Sumber dan Target (misalnya, mengubah ukuran, memformat, atau menambahkan partisi) karena hal ini dapat berdampak pada replikasi DataKeeper.
• Apakah bandwidth yang tersedia mencukupi untuk mirror yang ada?
  • Apakah Anda dapat berkolaborasi dengan Tim Jaringan untuk memastikan bandwidth mencukupi, terisolasi dari aplikasi lain untuk menghindari hambatan?

Mengapa Runbook Penting dalam Lingkungan DataKeeper:

Runbook merupakan bagian penting dari kelancaran operasional dan memberikan solusi yang baik untuk lingkungan yang menggunakan DataKeeper, bagi administrator klaster dan teknologi terkait. Idealnya, runbook yang dirancang dengan baik harus menjadi “dokumen hidup” yang berkembang seiring waktu, mencerminkan perubahan dalam infrastruktur, alur kerja, dan praktik terbaik. Jika administrator sebelumnya telah melakukan uji tuntas, runbook Anda seharusnya memiliki cakupan komprehensif di area berikut:

• Perbaikan/Pemecahan Masalah:Menangani masalah yang diketahui, yang dapat berada di mana saja dalam “stack,” misalnya, Lapisan Fisik hingga Lapisan Aplikasi.
• Alur kerja:Menerapkan perangkat lunak dan mengelola operasi klaster sehari-hari secara rutin.
• Pemeliharaan:bagaimanamanajemen patchdilakukan, pencadangan basis data, dll.
• Dukungan vendor:bagaimanahubungi SIOSMicrosoft, AWS, dan penyedia lainnya
  • Yang terpenting, kapan harus “menghubungi” mereka?

Poin-Poin Penting untuk Mewarisi DataKeeper

Blog ini menyoroti beberapa poin penting untuk menavigasi transisi tersebut, termasuk administrasi akun, kepemilikan sumber daya, kolaborasi lintas fungsi, dan nilai dari runbook. **Namun, penting untuk dicatat bahwa ini hanyalah beberapa pertimbangan di antara banyak hal lain yang mungkin berada di luar cakupan diskusi ini. Setiap lingkungan unik, dan administrasi klaster yang sukses membutuhkan pemahaman menyeluruh tentang infrastruktur, dependensi, dan alur kerja spesifik yang terlibat.**

Nikmati “warisan” Anda . . .

Jangan habiskan semuanya di satu tempat…

Minta demountuk melihat bagaimana SIOS DataKeeper dapat membantu menyederhanakan administrasi klaster dan mendukung ketersediaan tinggi.

Penulis: Greg Tucker, Insinyur Dukungan Produk Senior di SIOS

Direproduksi dengan izin dariSIOS