TL; DR: Bangun berlebihan, modular; uji ketersediaan; memonitor dengan cermat.
Setelah menyadari bahwa mencoba memeras penjelasan apa pun mungkin sangat lama sehingga saya akan menuliskan semua pengamatan yang telah saya buat.
Mempertanyakan premis
Sistem cloud adalah obat mujarab
Bahkan jika Anda ingin sepenuhnya menggunakan cloud, dengan penyedia cloud top, Anda masih perlu merancang aplikasi Anda untuk ketahanan, alasan. AWS mungkin menggantikan VM Anda, tetapi aplikasi Anda harus mampu me-restart jika dibiarkan di tengah perhitungan.
Kami tidak ingin menggunakan sistem cloud, karena x / y / z
Kecuali jika Anda adalah organisasi yang sangat besar, Anda lebih baik menggunakan sistem cloud. Sistem cloud Top-3 (AWS, MSFT, Google), mempekerjakan ribuan insinyur untuk memberi Anda SLA yang dijanjikan dan dashboard yang mudah dikelola. Ini sebenarnya tawaran yang bagus untuk menggunakannya sebagai pengganti menghabiskan uang receh di rumah ini.
Masalah dalam pelingkupan dan desain
Menentukan, mengukur, dan kemudian secara terus-menerus mengukur ketersediaan layanan merupakan tantangan yang lebih besar daripada menulis solusi untuk masalah ketersediaan.
Menentukan dan mengukur 'ketersediaan' lebih sulit dari yang diharapkan
Banyak pemangku kepentingan memiliki pandangan yang berbeda tentang ketersediaan, dan apa yang mungkin terjadi adalah definisi yang disukai oleh seseorang dengan gaji tertinggi, definisi lain. Ini kadang-kadang definisi yang benar, tetapi seringkali eko-sistem tidak dibangun untuk mengukur hal yang sama karena definisi ideal itu sangat sulit untuk diukur, apalagi memantau secara real time. Jika Anda memiliki definisi ketersediaan yang tidak dapat dipantau secara real time, Anda akan menemukan proyek serupa yang dilakukan sendiri berulang-ulang dengan kesamaan yang menakutkan. Tetap dengan sesuatu yang masuk akal dan sesuatu yang dapat dengan mudah dipantau.
Orang-orang meremehkan kompleksitas sistem yang selalu tersedia.
Untuk mengatasi gajah di dalam ruangan, izinkan saya mengatakan ini: "Tidak ada sistem multi-komputer 100% tersedia, mungkin di masa depan tetapi tidak dengan teknologi saat ini." Di sini dengan teknologi saat ini, saya mengacu pada ketidakmampuan kami mengirim sinyal lebih cepat daripada kecepatan cahaya dan hal-hal semacam itu. Semua insinyur komputer layak mengetahui keterbatasan komputasi terdistribusi , dan sebagian besar dari mereka tidak akan menyebutkannya dalam rapat, karena khawatir mereka akan terlihat seperti noobs. Untuk menebus semua yang tidak menyebutkan keterbatasan komputasi terdistribusi, saya akan mengatakan, ini rumit tetapi tidak selalu mempercayai komputer .
Orang melebih-lebihkan kemampuan insinyur mereka
Sayangnya, ketersediaan masuk dalam kategori, di mana Anda tidak tahu apa yang Anda inginkan tetapi Anda tahu apa yang tidak Anda inginkan. Agak sulit bahwa kategori 'tahu keinginan' seperti UI. Dibutuhkan sedikit pengalaman dan banyak membaca untuk belajar dari pengalaman orang lain dan lebih banyak lagi.
Membangun sistem yang tersedia dari dasar
Pastikan Anda akan menginjili kepada setiap arsitektur dan tim desain tentang prioritas ketersediaan yang tepat sebagai persyaratan sistem.
Atribut sistem membantu ketersediaan
Karakteristik sistem berikut telah terbukti berkontribusi terhadap ketersediaan sistem:
Redundansi
Beberapa contohnya adalah tidak pernah hanya memiliki satu VM di belakang VIP atau tidak pernah hanya menyimpan satu salinan data Anda. Ini adalah pertanyaan yang IAAS yang baik akan membuat Anda lebih mudah untuk menyelesaikannya tetapi Anda masih harus membuat keputusan ini.
Modularitas
REST modular lebih baik daripada SOA monolitik. Bahkan layanan modular mikro sebenarnya lebih tersedia daripada HATEOS REST yang biasa . Alasannya dapat ditemukan dalam diskusi terkait Yield di bagian selanjutnya. Jika Anda melakukan pemrosesan batch maka lebih baik untuk pemrosesan batch dalam batch 10-an yang masuk akal dibandingkan dengan berurusan dengan batch 1.000.000.
Kegembiraan
"I am always angry"
- Hulk
Sistem yang tangguh selalu siap untuk pulih. Ketahanan ini berlaku untuk instance seperti mengakui ACK untuk penulisan hanya setelah menulis ke disk RAID, dan mungkin pada setidaknya dua pusat data. Tren terbaru lainnya adalah menggunakan struktur data bebas konflik , di mana struktur data memikul tanggung jawab untuk menyelesaikan konflik ketika disajikan dengan dua versi yang berbeda. Suatu sistem tidak dapat bertahan sebagai renungan, itu harus diprediksi dan dibangun. Kegagalan dijamin dalam jangka panjang, jadi kita harus selalu siap dengan rencana untuk pulih.
Jejak log
Secara teknis ini adalah subtipe Ketahanan, tetapi yang sangat istimewa karena menangkap semua kemampuan. Meskipun upaya terbaik, kami mungkin tidak dapat memprediksi pola ketidaktersediaan. Jika memungkinkan, pertahankan jejak log yang cukup dari aktivitas sistem untuk dapat memutar ulang kejadian sistem. Ini akan, dengan biaya manual yang besar, memungkinkan Anda untuk pulih dari situasi yang tidak terduga.
Atribut ketersediaan
Daftar atribut top-of-mind 'ketersediaan' yang tidak lengkap: Demi diskusi, mari kita asumsikan pertanyaan yang diajukan pengguna adalah, "Berapa banyak item yang saya miliki di keranjang belanja saya?"
Ketepatan
Apakah Anda harus menghasilkan jawaban yang paling akurat atau apakah membuat kesalahan? Hanya untuk referensi, ketika Anda menarik uang dari ATM, itu tidak dijamin benar. Jika bank menemukan kesalahan, Anda mungkin membalik transaksi. Jika sistem Anda menghasilkan bilangan prima, maka saya kira, Anda mungkin ingin jawaban yang benar setiap saat.
Menghasilkan
Lewati poin ini, jika Anda selalu menjawab benar untuk pertanyaan topik sebelumnya. Terkadang jawaban atas pertanyaan tidak harus tepat, misalnya berapa banyak teman yang saya miliki di Facebook saat ini? Namun jawabannya diharapkan berada di stadion baseball +/- 1 sepanjang waktu. Ketika Anda menghasilkan hasil yang diharapkan, hasil Anda adalah 100.
Konsistensi
Jawaban Anda mungkin benar pada satu titik waktu, tetapi pada saat cahaya telah meninggalkan layar dan memasuki retina pengamat, segala sesuatu dapat berubah. Apakah itu membuat jawaban Anda salah? Tidak, itu hanya membuatnya tidak konsisten. Sebagian besar aplikasi pada akhirnya konsisten, tetapi triknya adalah menentukan model konsistensi seperti apa yang akan disediakan oleh aplikasi Anda. Secara kebetulan aplikasi Anda dapat berjalan di satu komputer, Anda dapat melewati pembacaan indah ini pada teorema CAP .
Biaya
Banyak tergantung pada apa dampak total dari efek jangka pendek (kehilangan pendapatan) dan efek jangka panjang (reputasi buruk, retensi pelanggan). Bergantung pada jenis pelanggan (pembayaran / gratis, ulangi / unik, captive) dan ketersediaan sumber daya berbagai tingkat ketersediaan jaminan harus dibangun di dalamnya.
Menuju peningkatan ketersediaan sistem yang ada
Manajemen operasional mesin individual dan jaringan sangat rumit, sehingga saya anggap Anda telah menyerahkannya kepada penyedia cloud atau Anda sudah cukup ahli untuk mengetahui apa yang Anda lakukan. Saya akan menyentuh topik lain di bawah ketersediaan. Untuk strategi jangka panjang Define-Measure-Analyze-Control adalah pertandingan surgawi, sesuatu yang telah saya lihat sendiri.
- Tetapkan apa yang 'ketersediaan' bagi para pemangku kepentingan Anda
- Bagaimana Anda mengukur apa yang telah Anda tetapkan
- Analisis akar penyebab untuk mengidentifikasi kemacetan
- Tugas untuk perbaikan
- Pemantauan terus menerus ( kontrol ) sistem
Penyebab tidak tersedianya
Karena kami sepakat bahwa manajemen operasional yang akan mencakup manajemen infrastruktur fisik apa pun, harus dilakukan oleh para profesional, saya akan menyentuh penyebab lain ketidaktersediaan demi kelengkapan. Ketersediaan IMO juga harus mencakup kurangnya perilaku yang diharapkan, artinya jika pengguna tidak menunjukkan pengalaman yang diharapkan, maka ada sesuatu yang tidak tersedia. Dengan definisi luas tersebut, hal-hal berikut dapat menyebabkan tidak tersedianya: - Kode bug - Insiden keamanan - Masalah kinerja