Arsitektur Ketersediaan Tinggi dan Praktik Terbaik
13 Fakta yang Sedikit Diketahui tentang Ketersediaan Tinggi
1. Hypervisor HA tidak Sama dengan Aplikasi HA
Kesalahpahaman utama adalah bahwa saya memiliki ketersediaan tinggi karena saya memiliki redundansi di perangkat keras atau hypervisor saya. Namun, redundansi perangkat keras dan hypervisor tidak menjamin ketersediaan tinggi untuk aplikasi. Ini juga bukan jaminan bahwa orkestrasi aplikasi akan dijalankan dengan benar dalam kegagalan.
2. Dalam Ketersediaan Tinggi, Lebih Besar Tidak Sama Lebih Baik
Jika Anda seorang powerlifter, beban yang lebih besar lebih baik dan repetisi yang lebih kecil lebih baik. Atau, jika kita berbicara tentang pelukan. (Kamu ingat pelukan adalah hal yang biasa kita lakukan ketika kita melihat seorang teman dari kota yang berbeda, yang sudah lama tidak kita lihat.) Tapi, lebih besar tidak selalu berarti lebih baik. Batu ginjal yang lebih besar, misalnya, jelas tidak lebih baik. Dalam ketersediaan yang lebih tinggi, membuat solusi yang lebih besar dan lebih kompleks tidak selalu berarti bahwa Anda akan meningkatkan ketersediaan tinggi Anda. Ini mungkin berarti Anda memiliki ketersediaan yang sama atau kurang. Ini juga dapat berarti bahwa Anda memiliki sistem yang lebih besar dan lebih kompleks dengan banyak bagian yang bergerak untuk disortir saat pemadaman listrik.
3. Semuanya gagal… terkadang
Bahasa pemrograman aplikasi sudah ada sejak tahun 1950-an. Dan sementara bahasa, prosesor, IDE, dan kualitas kode telah meningkat, kenyataannya adalah "semua aplikasi gagal di beberapa titik." Kegagalan karena pengecualian, bug, penghentian yang tidak tertangani, penghentian yang tidak disengaja, kehabisan sumber daya, dan banyak lagi terjadi. Memiliki strategi ketersediaan aplikasi aktif/aktif, atau aktif/pasif tetap diperlukan.
4. Fokus pada 'mengapa' sebanyak 'bagaimana'
Kecenderungan alami kita untuk beralih ke mode penyelesaian tugas adalah aset yang diperlukan, tetapi perlu diatur dan dipandu oleh jawaban atas pertanyaan kita tentang mengapa. Menambahkan solusi ke lingkungan tanpa memahami kebutuhan bisnis, aplikasi, database, dan pemangku kepentingan akan menghasilkan:
- Kegagalan
- Lebih dari pengeluaran
- Di bawah rata-rata
- Kebingungan dan arsitektur berlebihan
- Semua yang di atas
Alih-alih hanya berfokus pada penerapan ketersediaan, gunakan sumber daya dan upaya yang diperlukan untuk memahami kebutuhan bisnis dan jawaban atas "mengapa"
5. Masalah yang belum ditambal adalah sumber penyesalan yang umum
Jika Anda melakukannya atau tidak, Anda akan memiliki konsekuensi. Konsekuensi dari semua masalah yang belum terselesaikan adalah penyesalan. Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah melihat secara langsung waktu henti yang disebabkan oleh pelanggan yang gagal mengatasi masalah yang diketahui secara tepat waktu.
6. Masalah yang tidak terdokumentasi juga menyebabkan waktu henti
Bayangkan adegannya. Admin baru sedang mencari server di jaringan. Laporan penggunaan menunjukkan server tidak aktif dan tidak ada klien yang terhubung. Tidak mengenali server dan tidak menemukan "tag", dokumentasi, atau pengidentifikasi lainnya, admin baru percaya bahwa itu harus dimatikan. Sayangnya, instance yang tidak terdokumentasi dan tidak terkomunikasikan sebenarnya adalah server siaga yang penghapusannya akan menyebabkan waktu henti saat server utama mogok secara tidak terduga. Ini bukan cerita fiksi, ini adalah kisah nyata dari admin baru yang salah mengidentifikasi server sebagai sistem QA yang menganggur dan mematikannya sebelum latihan patching.
7. Rasa puas diri juga merupakan musuh
Kita semua akan senang jika ketersediaan di tempat atau di cloud, atau di mana pun di antaranya adalah sesuatu yang dapat kita “atur dan lupakan.” Tetapi, sedikit, jika ada sesuatu dalam hidup yang benar-benar sesederhana "atur dan lupakan." Salah satu musuh terbesar ketersediaan Anda di masa depan, adalah kesuksesan Anda dengan ketersediaan tinggi sekarang. Ketika bencana sedikit dan jarang terjadi, dan tim merasa yakin bahwa mereka telah menyadari stabilitas yang berkelanjutan, rasa puas diri bisa masuk. Sukses menggoda kita untuk berpikir tidak ada yang akan berubah, dan rasa puas diri sehubungan dengan ketersediaan tinggi adalah musuh ketersediaan tinggi. Hal-hal di sekitar perusahaan Anda dan di dalam perusahaan Anda sedang berubah. Cloud berubah, kebutuhan bisnis Anda berubah, dan aplikasi serta Sistem Operasi juga berubah.
8. Perubahan itu sulit
Perubahan itu sulit. Tanyakan saja kepada siapa saja yang menyukai makanan manis yang telah mencoba melepaskan potongan kue kedua sebelum tidur. Resistensi serupa terjadi bahkan dalam ketersediaan tinggi. Tim, bahkan yang mengalami bencana, seringkali enggan untuk berubah meskipun perubahan itu baik. Mereka membutuhkan visi, pemahaman tentang mengapa, dan dukungan. Tim lain, yang memiliki solusi, enggan meningkatkan ketersediaan tinggi karena takut menimbulkan ketidakstabilan atau mengekspos diri mereka pada risiko baru.
9. Semua perubahan bukanlah perubahan yang baik
Perubahan itu baik, ketika perubahan itu baik. Saat mempertimbangkan perubahan pada solusi dan arsitektur ketersediaan yang lebih tinggi, sangat penting bahwa perubahan dianalisis terhadap tujuan, persyaratan, dan dalam lingkup peningkatan ketersediaan. Perubahan yang meningkatkan stabilitas, menambahkan perlindungan untuk komponen penting, menghilangkan solusi, mengoptimalkan ketersediaan layanan, dan diuji secara menyeluruh adalah perubahan yang baik.
10. Lebih murah tidak selalu lebih baik
Lebih murah tidak selalu lebih baik. Meskipun solusi yang lebih murah biasanya memiliki label harga yang lebih rendah, solusi tersebut mungkin juga memiliki sejumlah keterbatasan yang membuatnya kurang ideal. Ketika ada label harga yang lebih rendah, waspadalah terhadap fitur yang hilang seperti kurangnya kesadaran aplikasi, orkestrasi terbatas, kompleksitas tersembunyi, pemulihan manual dan kegagalan , dan terbatas pada tidak ada validasi pengguna. Solusi yang lebih murah mungkin juga gagal menyertakan dukungan pelanggan. Pastikan untuk memahami apakah solusi Anda yang lebih murah termasuk dukungan, atau jika dukungan tersebut merupakan tambahan, dan biaya tambahan yang besar.
Hal yang sama berlaku untuk penerapan yang lebih murah dengan komputasi, disk, atau penyimpanan yang lebih sedikit. Meskipun label harga dan biaya bulanan mungkin lebih rendah, solusi Anda mungkin juga berfungsi pada kapasitas yang kurang ideal.
11. Keras tidak sama dengan efektif
Pernah mendengar cerita tentang anak laki-laki yang menangis serigala. Solusi pemantauan aplikasi yang menghasilkan badai peringatan lebih cepat daripada solusi yang diabaikan. Memiliki solusi yang memberikan peringatan itu bagus, tetapi jika solusi itu memicu peringatan kritis karena kesalahan atau berlebihan, itu tidak efektif.
12. Ketersediaan Tinggi adalah budaya dan pola pikir, bukan hanya solusi produk atau perangkat keras
Perangkat lunak, perangkat keras, proses, solusi, dan layanan semuanya merupakan bagian dari ketersediaan tinggi. Namun, tanpa dukungan di seluruh fungsi TI dan unit bisnis, itu akan penuh dengan frustrasi dan terus-menerus menjadi sumber diskusi anggaran alih-alih diskusi tentang nilai, stabilitas bisnis, peningkatan kepuasan pelanggan, dan pengurangan risiko.
13. Sekarang belum terlambat
Harapan bukanlah strategi untuk ketersediaan tinggi, juga tidak berharap bahwa Anda tidak akan mengalami bencana kritis atau kegagalan aplikasi perlu menjadi strategi. Merancang dan merancang arsitektur perusahaan yang sangat tersedia dapat dimungkinkan sekarang, bahkan jika sudah berminggu-minggu atau berbulan-bulan sejak bencana terakhir.
Hubungi SIOS untuk mempelajari lebih lanjut tentang solusi ketersediaan tinggi untuk aplikasi Anda.
– Cassius Rhee, VP, Pengalaman Pelanggan Direproduksi dari SIOS
