Perjalanan keandalan adalah proses langkah demi langkah di mana setiap tahap dibangun pada tahap sebelumnya untuk memastikan sistem tetap tersedia dan memenuhi harapan pengguna. Model kematangan ini dimaksudkan untuk membantu Anda menilai status Anda saat ini dan menawarkan jalur terstruktur untuk perbaikan.
Fondasi dimulai dengan memulai kemampuan keandalan dasar yang ditawarkan oleh Azure dengan menggunakan fitur keandalan bawaan Azure seperti redundansi zona untuk peningkatan langsung tanpa beban pengoptimalan yang luas.
Secara kontraintuitif, cara untuk mencapai keandalan tinggi adalah dengan menerima kegagalan tidak dapat dihindari. Daripada mencoba mencegah setiap masalah, lebih efektif untuk merencanakan bagaimana sistem Anda akan merespons ketika masalah terjadi. Persyaratan bisnis Anda membantu menentukan risiko mana yang layak ditangani secara proaktif. Tim berinvestasi dalam kemampuan pemantauan tingkat lanjut dengan pengamatan terstruktur, memperluas mitigasi kegagalan untuk menyertakan kekhawatiran tingkat aplikasi, dan mulai menguji langkah-langkah ketahanan.
Selanjutnya, tim mengintegrasikan wawasan bisnis dengan keterampilan teknis. Teams menerapkan pemodelan kesehatan, melakukan analisis mode kegagalan, dan menyiapkan rencana pemulihan bencana yang komprehensif. Tahap ini memastikan akuntabilitas melalui tujuan yang terukur dan persiapan sistematis untuk berbagai skenario kegagalan.
Setelah sistem ditayangkan, penekanan bergerak untuk mengelola tantangan lingkungan produksi, termasuk manajemen perubahan dan menangani pertumbuhan data dan kompleksitas operasional, dan bagaimana hal ini memengaruhi keandalan sistem Anda.
Tingkat akhir berjalan tanpa batas waktu, dan tetap tangguh adalah tujuannya. Tingkat ini mewakili evolusi di luar kontrol teknis untuk kemampuan beradaptasi arsitektur. Tingkat ini berfokus pada memungkinkan sistem untuk menahan risiko baru dan tak terduga saat beban kerja berevolusi dan tumbuh.
Model ini disusun menjadi lima tingkat kematangan yang berbeda, masing-masing dengan tujuan utama dan serangkaian strategi inti. Gunakan tampilan bertab di bawah ini untuk menjelajahi setiap tingkat. Pastikan juga untuk meninjau kompromi yang disorot dan risiko terkait dengan seiring kemajuan Anda.
Membangun dasar yang solid untuk ketahanan dalam infrastruktur dan operasi beban kerja, daripada menghabiskan waktu untuk tugas pengoptimalan.
Model kematangan tingkat 1 dirancang untuk membantu tim beban kerja membangun fondasi yang kuat untuk keandalan sistem. Fokusnya adalah pada bootstrapping, yang merupakan proses pengembangan dasar untuk keputusan keandalan di masa depan. Tahap ini sebagian besar melibatkan implementasi fungsional dengan ekstensi kecil untuk praktik saat ini.
Tahap ini termasuk meneliti, mendapatkan wawasan, dan membuat inventarisasi sistem Anda. Ini juga menggunakan fitur keandalan bawaan di Azure, seperti mengaktifkan redundansi zona untuk peningkatan segera.
Dengan menetapkan dasar-dasar ini, Anda dapat mempersiapkan tim Anda untuk maju melalui tingkat model kematangan keandalan untuk secara progresif meningkatkan ketahanan dan performa sistem Anda.
Strategi utama
✓ Mengevaluasi peluang untuk membongkar tanggung jawab operasional
Strategi ini pada dasarnya adalah pendekatan build dibandingkan dengan beli atau mengandalkan. Keputusan tergantung pada berapa banyak tanggung jawab yang dapat dikelola pada tahap ini sambil tetap mendukung pengembangan di masa depan. Anda ingin menggunakan sumber daya yang relevan dengan beban kerja, tetapi Anda harus selalu mencari peluang untuk mengalihkan pemeliharaannya. Berikut adalah beberapa kasus penggunaan klasik di mana Anda mungkin ingin menerapkan pendekatan ini.
Membongkar tanggung jawab ke platform cloud dengan memilih solusi platform as a service (PaaS). Mereka menyediakan solusi siap pakai untuk kebutuhan ketahanan umum seperti replikasi, failover, dan penyimpanan cadangan. Ketika Anda mengambil pendekatan ini, penyedia cloud menangani hosting, pemeliharaan, dan peningkatan ketahanan.
Misalnya, penyedia cloud mereplikasi data di beberapa simpul komputasi dan mendistribusikan replika di seluruh zona ketersediaan. Jika Anda membangun solusi Anda sendiri pada komputer virtual (VM), Anda perlu mengelola aspek-aspek ini sendiri, yang dapat memakan waktu dan kompleks.
Mengalihkan tanggung jawab untuk operasi yang tidak terkait langsung dengan tujuan bisnis dari beban kerja. Beberapa operasi khusus, seperti manajemen dan keamanan database, berpotensi memengaruhi keandalan beban kerja Anda. Jelajahi kemungkinan memiliki tim, teknologi, atau keduanya yang berpengalaman menangani tugas-tugas tersebut.
Misalnya, jika tim Anda tidak memiliki keahlian database, gunakan layanan terkelola untuk membantu mengalihkan tanggung jawab ke penyedia. Pendekatan ini dapat berguna ketika Anda memulai karena memungkinkan tim Anda untuk fokus pada fungsionalitas beban kerja. Banyak perusahaan telah berbagi layanan yang dikelola secara terpusat. Jika tim platform tersedia, gunakan untuk menangani operasi ini. Namun, pendekatan ini mungkin menambahkan dependensi dan kompleksitas organisasi.
Atau, jika tim Anda memiliki keahlian yang tepat, Anda mungkin membuat keputusan eksplisit untuk menggunakan keterampilan mereka dan memilih layanan yang tidak menyertakan kemampuan manajemen.
Mengalihkan tanggung jawab kepada vendor non-Microsoft. Pilih produk di luar rak sebagai titik awal. Bangun solusi yang disesuaikan hanya ketika berkontribusi pada nilai bisnis dari beban kerja Anda.
Risiko: Jika opsi beli atau mengandalkan sebagian memenuhi kebutuhan Anda, Anda mungkin perlu menerapkan ekstensi kustom. Metode ini dapat mengakibatkan situasi "penguncian kustomisasi", di mana pembaruan dan modernisasi menjadi tidak praktis. Tinjau kebutuhan Anda secara teratur dan bandingkan dengan kemampuan solusi. Kembangkan strategi keluar ketika ada penyimpangan yang signifikan antara keduanya.
Skenario yang berlawanan juga merupakan risiko. Meskipun opsi beli atau andal mungkin tampak lebih sederhana pada awalnya, mungkin perlu evaluasi ulang dan desain ulang nanti jika batasan layanan PaaS, solusi vendor, atau sumber daya milik platform tidak memenuhi granularitas atau tingkat otonomi yang diperlukan untuk beban kerja.
✓ Identifikasi alur pengguna dan sistem penting
Memecah beban kerja menjadi alur sangat penting pada tahap ini. Fokus pada alur pengguna dan sistem . Alur pengguna menentukan interaksi pengguna, dan alur sistem menentukan komunikasi antara komponen beban kerja yang tidak terkait langsung dengan tugas pengguna.
Misalnya, dalam aplikasi e-niaga, pelanggan melakukan aktivitas front-end seperti penjelajahan dan pemesanan. Sementara itu, transaksi back-end dan proses yang dipicu sistem memenuhi permintaan pengguna dan menangani tugas lain. Alur berbeda tersebut adalah bagian dari sistem yang sama, tetapi melibatkan komponen yang berbeda dan melayani tujuan yang berbeda.
Mulai bangun katalog alur pada tahap ini. Amati interaksi pengguna dan komunikasi komponen. Mencantumkan dan mengategorikan alur, menentukan titik awal dan akhir, dan mencatat dependensi. Dokumentasikan hasil dan pengecualian dengan menggunakan diagram untuk kejelasan. Katalog ini dapat berfungsi sebagai alat penting untuk percakapan awal dengan pemangku kepentingan bisnis untuk mengidentifikasi aspek terpenting dari perspektif mereka. Percakapan ini dapat menginformasikan tingkat prioritas pertama.
Mengklasifikasikan alur sebagai kritis dengan mengevaluasi risiko dan dampak pada aktivitas bisnis utama. Jika Anda mengharapkan gangguan, degradasi terkontrol bertujuan untuk mempertahankan alur kritis ini. Dalam contoh e-niaga, alur penting mencakup pencarian produk, menambahkan item ke keranjang, dan proses pembayaran karena tugas-tugas ini esensial bagi bisnis. Proses lain, seperti memperbarui data produk dan memelihara gambar produk, tidak terlalu penting. Pastikan bahwa aliran kritis tetap beroperasi selama pemadaman untuk mencegah kehilangan pendapatan dengan memungkinkan pengguna untuk terus mencari produk dan menambahkan item ke kelir.
Nota
Proses bisnis bisa sangat penting meskipun tidak sensitif terhadap waktu. Kekritisan waktu adalah faktor kunci. Misalnya, memenuhi persyaratan audit adalah proses penting, tetapi Anda mungkin tidak perlu segera menyajikan data untuk audit. Prosesnya tetap penting, tetapi keandalannya tidak bergantung pada waktu karena pemulihan dalam beberapa jam dapat diterima.
Untuk informasi selengkapnya, lihat Azure Well-Architected Framework: Mengoptimalkan desain beban kerja dengan menggunakan alur.
✓ Pilih model desain, sumber daya, dan fitur yang tepat
Anda harus menerapkan strategi ini pada tingkat berikut:
Arsitektur: Desain beban kerja harus memperhitungkan ekspektasi keandalan di berbagai lapisan infrastruktur. Keputusan awal Anda mungkin menjadi pilihan antara kontainerisasi atau PaaS untuk menghosting aplikasi. Atau, Anda mungkin mempertimbangkan konfigurasi jaringan seperti model hub dan spoke atau satu jaringan virtual.
Anda juga harus mengatur batasan yang membuat segmentasi berdasarkan fungsionalitas. Misalnya, alih-alih menghosting semuanya di satu VM dengan disk virtual zona tunggal, pertimbangkan untuk memisahkan komputasi dan penyimpanan data dan menggunakan layanan khusus.
Perhatian
Dalam skenario migrasi, mengadopsi pendekatan lift-and-shift tanpa meninjau peluang baru dapat menyebabkan manfaat terlewat dan ketidakefisienan. Penting untuk meneliti modernisasi lebih awal untuk menghindari terjebak dengan pengaturan yang sulit diubah dan untuk memanfaatkan opsi dan peningkatan yang lebih baik.
Layanan Azure: Gunakan pohon keputusan untuk membantu Anda memilih layanan yang tepat untuk desain Anda. Pilih komponen yang memenuhi kebutuhan Anda saat ini, tetapi tetap fleksibel sehingga Anda dapat beralih layanan saat beban kerja Anda berkembang dan membutuhkan lebih banyak fitur.
SKU atau tingkatan dalam layanan Azure: Tinjau fitur setiap SKU dan pahami jaminan ketersediaan platform. Evaluasi perjanjian tingkat layanan untuk memahami cakupan yang diberikan terkait persentil yang diterbitkan.
Fitur yang mendukung keandalan: Pilih layanan cloud-native untuk meningkatkan ketersediaan melalui konfigurasi sederhana tanpa mengubah kode. Penting untuk memahami opsi dan dengan sengaja memilih konfigurasi, seperti meningkatkan redundansi zona atau mereplikasi data ke wilayah sekunder.
✓ Sebarkan dengan tingkat redundansi dasar
Dalam setiap bagian solusi Anda, hindarilah titik kegagalan tunggal, seperti instans tunggal. Buat beberapa instans untuk redundansi sebagai gantinya. Layanan Azure sering menangani redundansi untuk Anda, terutama dengan layanan PaaS, yang biasanya mencakup redundansi lokal secara default dan opsi untuk meningkatkan. Sebaiknya, gunakan redundansi zona untuk menyebarkan instans tersebut di beberapa pusat data Azure. Jika tidak, setidaknya pastikan redundansi lokal, tetapi metode ini memiliki risiko yang lebih tinggi. Di tingkat mendatang, Anda mengevaluasi apakah persyaratan keandalan Anda mungkin terpenuhi dengan memperluas solusi dengan komponen geo-redundan.
Trade-off: Salah satu trade-off yang signifikan adalah peningkatan biaya redundansi. Selain itu, komunikasi lintas zona dapat memperkenalkan latensi. Untuk aplikasi warisan yang membutuhkan latensi minimal, redundansi dapat menurunkan performa.
Risiko: Jika aplikasi tidak dirancang untuk lingkungan beberapa instans, aplikasi mungkin berjuang dengan beberapa instans aktif, yang dapat menyebabkan data yang tidak konsisten. Selain itu, jika aplikasi dibangun untuk penyiapan lokal yang memiliki latensi rendah, menggunakan zona ketersediaan mungkin mengganggu performanya.
✓ Aktifkan metrik, log, dan jejak untuk memantau alur
Pilih alat asli platform seperti Azure Monitor untuk memastikan visibilitas metrik, log, dan jejak. Gunakan fitur bawaan untuk mengatur pemberitahuan untuk potensi masalah. Anda harus memiliki pemberitahuan dasar untuk mengirim pemberitahuan dan mendapatkan pemberitahuan. Manfaatkan kemampuan platform Azure yang menunjukkan perubahan status kesehatan layanan, seperti:
Siapkan grup tindakan Azure Monitor untuk infrastruktur dan aplikasi.
Trade-off: Saat mengumpulkan lebih banyak log, Anda perlu mengelola peningkatan volume, yang memengaruhi biaya terkait penyimpanan log tersebut. Gunakan kebijakan retensi untuk mengelola volume. Gunakan Azure Monitor untuk mengatur batas harian di ruang kerja. Untuk informasi selengkapnya, lihat Rekomendasi konfigurasi untuk Keandalan.
Mulai membangun pengamatan pada lapisan berikut.
Infrastruktur
Mulailah dengan mengaktifkan log diagnostik dan pastikan Anda mengumpulkan metrik asli dari komponen platform untuk analisis. Kumpulkan informasi tentang penggunaan sumber daya, seperti CPU, memori, input/output, dan aktivitas jaringan.
Aplikasi
Kumpulkan metrik tingkat aplikasi, seperti konsumsi memori atau latensi permintaan, dan aktivitas aplikasi log. Lakukan operasi pengelogan dalam utas atau proses yang terpisah dari utas aplikasi utama. Pendekatan ini tidak menyebabkan pengelogan memperlambat tugas utama aplikasi.
Selain itu, periksa pengujian ketersediaan dasar di Application Insights.
Data Informasi
Untuk memantau database pada tingkat dasar, kumpulkan metrik utama yang dikeluarkan sumber daya database. Mirip dengan komponen infrastruktur, lacak penggunaan sumber daya dalam konteks penyimpanan data, seperti metrik jaringan. Mengumpulkan data tentang bagaimana koneksi dikumpulkan penting untuk meningkatkan efisiensi pada tahap selanjutnya.
Untuk keandalan, penting untuk melacak metrik koneksi, seperti memantau koneksi aktif dan gagal. Misalnya, di Azure Cosmos DB, kode status 429 dikembalikan ketika jumlah permintaan melebihi unit permintaan dan koneksi yang dialokasikan mulai gagal.
✓ Mulai membangun panduan mitigasi kegagalan
Kegagalan berkisar dari kegagalan sementara yang sedikit lebih lama hingga kegagalan besar.
Di Tingkat 1, fokus pada kegagalan platform. Meskipun berada di luar kendali Anda, Anda harus tetap memiliki strategi untuk menanganinya. Misalnya, mengatasi pemadaman zona dengan menggunakan zona ketersediaan. Antisipasi kesalahan sementara di tingkat platform dan tangani di beban kerja Anda.
Proses penanganan kegagalan ini bervariasi berdasarkan kompleksitas. Mulai dokumentasikan potensi kegagalan tingkat platform, risiko terkait, dan strategi mitigasi. Latihan ini terutama bersifat teoritis dan matang dengan otomatisasi pada tingkat selanjutnya.
Anda harus mendokumen kegagalan, termasuk faktor-faktor seperti kemungkinan, dampak, dan strategi mitigasinya. Gunakan skala kekritisan yang selaras dengan tujuan beban kerja Anda. Skala Anda mungkin mencakup:
Tinggi. Pemadaman sistem lengkap yang menyebabkan kerugian finansial yang signifikan dan penurunan kepercayaan pengguna.
Sedang. Gangguan sementara yang memengaruhi bagian dari beban kerja dan menyebabkan ketidaknyamanan pengguna.
Rendah. Masalah perangkat lunak kecil yang memengaruhi fitur aplikasi yang tidak penting dan menyebabkan waktu henti minimal bagi pengguna.
Berikut adalah contoh templat:
| Masalah |
Risiko |
Sumber |
Tingkat Keparahan |
Kemungkinan |
Mitigasi |
| Kegagalan jaringan sementara |
Klien kehilangan koneksi mereka ke server aplikasi. |
Platform Azure |
Tinggi |
Sangat mungkin |
Gunakan pola desain dalam logika sisi klien, seperti logika coba lagi dan pemutus sirkuit. |
| Gangguan di Zona |
Pengguna tidak dapat menjangkau aplikasi. |
Platform Azure |
Tinggi |
Tidak mungkin |
Aktifkan ketahanan zona pada semua komponen. |
| Kedaluwarsa sertifikat Keamanan Lapisan Transportasi (TLS) |
Klien tidak dapat membuat sesi TLS dengan aplikasi. |
Kesalahan manusia |
Tinggi |
Mungkin |
Gunakan manajemen sertifikat TLS otomatis. |
| Penggunaan CPU atau memori mencapai batas yang ditentukan dan menyebabkan server gagal. |
Permintaan melebihi batas waktu. |
Aplikasi |
Menengah |
Mungkin |
Menerapkan mulai ulang otomatis. |
| Komponen tidak tersedia selama pembaruan. |
Pengguna mengalami kesalahan yang tidak tertangani dalam aplikasi. |
Penyebaran atau perubahan konfigurasi |
Kurang Penting |
Sangat mungkin selama implementasi dan tidak mungkin pada waktu lain |
Menangani komponen dalam logika sisi klien. |
Pada Tingkat 1, jangan berusaha mencapai kelengkapan karena selalu ada contoh kegagalan yang tidak terduga. Jika Anda mengalami pemadaman tak terduga, dokumentasikan penyebab dan mitigasi di dalam buku panduan. Perlakukan aset ini sebagai dokumen hidup yang Anda perbarui dari waktu ke waktu.
✓ Tambahkan mekanisme untuk pulih dari kegagalan sementara
Di lingkungan cloud, kegagalan sementara umum terjadi. Mereka menunjukkan masalah jangka pendek yang coba lagi biasanya dapat diselesaikan dalam hitungan detik.
Gunakan SDK dan konfigurasi bawaan untuk menangani kesalahan ini agar sistem tetap aktif. Konfigurasi bawaan sering kali merupakan pengaturan default, sehingga Anda mungkin perlu menguji untuk memvalidasi implementasi. Selain itu, terapkan pola yang dirancang untuk menangani kegagalan sementara dalam arsitektur Anda. Untuk informasi selengkapnya, lihat Pola desain arsitektur yang mendukung keandalan.
Masalah yang terus-menerus mungkin menunjukkan kegagalan yang tidak sementara atau awal pemadaman. Skenario ini memerlukan lebih dari sekadar memperbaiki masalah yang dilokalkan dalam aplikasi. Ini melibatkan pemeriksaan pengguna dan alur sistem kritis dengan menambahkan teknik perlindungan diri dan upaya pemulihan. Metode ini adalah praktik matang yang dijelaskan Tingkat 2.
✓ Jalankan tes dasar
Integrasikan pengujian keandalan dasar pada tahap awal siklus hidup pengembangan perangkat lunak. Cari peluang untuk melakukan pengujian, dimulai dengan pengujian unit untuk memvalidasi fungsionalitas dan konfigurasi.
Selain itu, kembangkan contoh pengujian sederhana untuk masalah yang Anda identifikasi dalam playbook mitigasi risiko. Fokus pada dampak yang lebih tinggi, mitigasi upaya yang lebih rendah. Misalnya, mensimulasikan pemadaman jaringan atau masalah konektivitas yang terputus-putus untuk melihat bagaimana logika coba ulang Anda mengatasi gangguan tersebut.
Risiko: Pengujian sering memperkenalkan gesekan dalam siklus pengembangan. Untuk mengurangi risiko ini, buat pengujian keandalan dapat dilacak bersama tugas pengembangan.
Pengembangan fitur adalah prioritas, dan pengujian dapat memperkenalkan gesekan dalam siklus pengembangan. Lebih mudah untuk mulai menguji sebelum pengembangan fitur selesai. Merancang aspek nonfungsi aplikasi di awal memungkinkan Anda memperluasnya saat Anda menambahkan kemampuan fungsional, daripada membangun backlog masalah untuk ditangani nanti. Meskipun pendekatan ini membutuhkan lebih banyak upaya pada awalnya, pendekatan ini dapat dikelola dan mencegah masalah yang lebih besar nanti.
Pastikan bahwa sistem tetap fungsional dan stabil dengan menggabungkan kemampuan pelestarian diri dan memiliki rencana pemulihan dasar untuk mengelola kegagalan.
Kegagalan di cloud tidak dapat dihindari. Strategi ketahanan Anda harus berusaha untuk menjaga sistem tetap berfungsi dalam semua kondisi. Tingkat 1 memperkenalkan metode untuk mengatasi kegagalan sementara. Tingkat 2 berfokus pada penggabungan strategi pelestarian diri untuk mencegah, mendeteksi, dan memulihkan dari kegagalan yang tahan lama. Jika dibiarkan tidak terselesaikan, masalah ini dapat berubah menjadi pemadaman penuh.
Alur kritis yang Anda identifikasi di Tingkat 1 diprioritaskan. Mereka memerlukan peningkatan upaya ketahanan dan pemulihan untuk semua komponen, termasuk aplikasi, layanan, dan database. Harap sesuaikan ukuran provisi awal, jumlah instans, dan kebijakan penskalaan otomatis Anda untuk memitigasi risiko keandalan.
Pada tingkat ini, bersikaplah aktif dalam praktik pemantauan dan pengujian Anda. Gunakan teknik pemantauan tingkat lanjut yang selaras dengan kebutuhan teknis dan dilingkupkan ke tim pengembangan. Perluas playbook sederhana untuk mencakup komponen arsitektur yang Anda kembangkan dan miliki, seperti kode aplikasi.
Strategi utama
✓ Mengevaluasi keadaan ketahanan saat ini untuk melindungi dari kegagalan
Apakah tingkat redundansi cukup baik untuk menahan kegagalan? Tentukan strategi redundansi yang menentukan jumlah sumber daya redundan untuk dipertahankan. Tentukan tempat untuk menempatkan sumber daya ini, baik secara lokal, di seluruh zona, atau di lokasi yang didistribusikan secara geografis. Evaluasi pengaturan platform cloud dan pilih tingkat yang memenuhi kebutuhan bisnis dan trade-off yang dapat diterima.
Apakah komponen beban kerja cukup terisolasi untuk menangani kegagalan mereka? Pola seperti pola Bulkhead membantu membangun ketahanan dan isolasi kesalahan. Pola Bulkhead mempartisi sistem menjadi komponen-komponen terisolasi, yang dikenal sebagai sekat, untuk mencegah kegagalan berantai ke bagian lain dari sistem.
Apakah komponen pada jalur kritis berkomunikasi secara asinkron? Jika tidak, gunakan metode komunikasi, seperti antrean. Pendekatan ini menjaga sistem tetap beroperasi meskipun komponen hilir gagal. Ini juga mencegah sistem memasuki status yang tidak ditentukan. Jelajahi opsi Azure, termasuk Azure Service Bus untuk antrean dan Azure Event Hubs untuk aliran peristiwa.
Trade-off: Komunikasi asinkron dapat membantu mencegah kegagalan bertingkat dengan memisahkan proses. Namun, ini menambahkan latensi di jalur komunikasi, yang dapat menimbulkan masalah untuk komponen penting. Evaluasi dampak performa sebelum Anda membuat perubahan pola desain.
Apakah operasi dirancang untuk konsistensi? Aset seperti rahasia aplikasi dan sertifikat dapat kedaluwarsa dan memerlukan refresh reguler. Inkonsistensi dalam pembaruan rutin dapat mengakibatkan masalah keandalan.
Idealnya, identifikasi dan hilangkan tugas yang dioperasikan manusia yang sedang berlangsung karena rawan kesalahan dan dapat menyebabkan inkonsistensi yang menimbulkan risiko keandalan. Membongkar tugas operasional sebanyak mungkin ke penyedia cloud. Misalnya, gunakan identitas terkelola yang disediakan microsoft Entra ID dan sertifikat Keamanan Lapisan Transportasi (TLS) yang dikelola Azure Front Door.
Pemantauan diperlukan untuk tindakan proaktif, seperti melacak kedaluwarsa sertifikat dan menerima pemberitahuan. Aplikasi harus mencatat peristiwa penting, seperti sertifikat TLS mendekati kedaluwarsa. Menggunakan beberapa metode untuk memeriksa potensi kegagalan membantu memastikan bahwa tindakan yang diperlukan diambil.
✓ Tambahkan kemampuan teknis dalam sistem pemantauan Anda
Pada Tingkat 1, Anda mengumpulkan data pemantauan dari komponen beban kerja, dengan fokus pada infrastruktur. Analisis dasar selesai dan pemberitahuan dasar diatur. Penyiapan ini sangat penting untuk memahami performa dasar komponen beban kerja dan mengidentifikasi perilaku anomali.
Tingkat 2 mengambil pemantauan selangkah lebih jauh dengan menambahkan kemampuan pengamatan tingkat lanjut ke sumber daya beban kerja Anda dan mengadopsi pendekatan yang lebih terstruktur untuk menganalisis data pemantauan. Manfaatkan alat analitik yang disediakan layanan cloud Anda. Misalnya, alat wawasan Azure Monitor, seperti wawasan VM dan wawasan jaringan, memberikan visualisasi kesehatan dan performa di seluruh dependensi.
Rencanakan kemampuan pengamatan pada lapisan berikut.
Aplikasi
Merespons pengujian status kesehatan. Aktifkan aplikasi untuk menanggapi permintaan pemeriksaan kondisi dari penyelidikan. Aplikasi harus memiliki titik akhir khusus untuk pemeriksaan kesehatan yang memberikan informasi status, seperti sehat atau tidak sehat, minimal. Pendekatan ini memungkinkan sistem pemantauan untuk menilai apakah aplikasi berfungsi dengan baik dan dapat menangani permintaan, atau jika ada masalah yang perlu ditangani.
Layanan penyeimbangan beban Azure, seperti Azure Front Door, Azure Traffic Manager, Azure Application Gateway, dan Azure Load Balancer, mendukung pemeriksaan kesehatan. Pemeriksaan kesehatan mengirim permintaan pemeriksaan kesehatan ke aplikasi.
Lanjutkan ke pengelogan semantik. Sertakan informasi terstruktur tentang peristiwa dan tindakan dalam aplikasi. Dengan pengelogan terstruktur, data log dicatat dalam format yang konsisten dengan menggunakan skema yang ditentukan dengan baik. Skema ini memudahkan untuk membangun otomatisasi, pencarian, dan analisis di tahap selanjutnya. Sertakan bidang tertentu seperti tanda waktu dan kode kesalahan untuk membantu mengidentifikasi dan memecahkan masalah dengan cepat.
Menerapkan pelacakan terdistribusi. Ketika permintaan mengalir melalui komponen sistem yang berbeda, penting untuk mengambil data pelacakan di seluruh batas. Data ini berguna untuk mendapatkan wawasan tentang perilaku aplikasi dan mengidentifikasi penyempitan performa, kesalahan, dan masalah latensi. Azure Monitor mendukung pengumpulan data berbasis OpenTelemetry dengan Application Insights.
Data Informasi
Lacak durasi kueri, kueri yang gagal, dan metrik relevan lainnya. Kueri yang berjalan lama dapat menunjukkan batasan sumber daya dan mungkin kebutuhan untuk menyesuaikan desain skema.
Pada tahap ini, database Anda telah beroperasi selama beberapa waktu. Perhatikan tingkat pertumbuhan data, terutama dalam tabel yang tumbuh secara tak terduga dengan cepat. Informasi ini sangat penting untuk merencanakan kebutuhan penyimpanan di masa mendatang dan mengatasi masalah performa lebih awal.
Pantau status replikasi database dengan menggunakan alat dan dasbor yang disediakan sistem manajemen database. Misalnya, jika Anda menggunakan Azure Cosmos DB, gunakan wawasan Azure Cosmos DB. Untuk Azure SQL Database atau Azure SQL Managed Instance, pertimbangkan untuk menggunakan pengamat database untuk mendapatkan detail diagnostik tentang database Anda.
Seiring bertambahnya database, masalah skema mungkin menjadi lebih jelas, yang memengaruhi performa. Untuk mengoptimalkan efisiensi kueri, pertimbangkan untuk menambahkan indeks atau memodifikasi skema karena perubahan ini dapat memengaruhi keandalan.
Operasi
Tingkat 1 berfokus pada lapisan sebelumnya. Pada Tingkat 2, Anda mulai membangun operasi di sekitar sistem pemantauan.
Simpan log untuk durasi yang cukup lama sehingga dapat memperoleh wawasan. Dari perspektif keandalan, konfigurasikan durasi retensi sehingga Anda dapat mengumpulkan cukup data untuk mendeteksi pola kegagalan, memecahkan masalah, dan melakukan analisis akar penyebab.
Memantau proses pencadangan dan pemulihan. Pastikan bahwa cadangan berhasil disimpan di lokasi seperti yang direncanakan dan bahwa data beban kerja dipulihkan dalam jangka waktu yang wajar. Memantau proses tersebut penting untuk mengatur garis besar untuk metrik tujuan titik pemulihan (RPO) Anda di tingkat selanjutnya.
✓ Memperluas buku panduan mitigasi kegagalan Anda
Tingkat 1 berfokus pada kegagalan platform yang diharapkan. Di Tingkat 2, Anda mengatasi titik kegagalan pada komponen dan operasi dalam beban kerja Anda sendiri. Saat kode Anda berjalan pada platform, titik interaksi antara platform dan aplikasi meningkat. Harapkan kegagalan akibat bug pada kode Anda, implementasi yang gagal, dan kesalahan manusia. Mitigasi masalah ini dengan menggunakan taktik pelestarian diri atau pemulihan.
Perluas playbook mitigasi kegagalan Anda untuk menyertakan bug dan masalah penyebaran. Tabel berikut ini dibangun pada templat dari Tingkat 1:
| Masalah |
Risiko |
Sumber |
Tingkat Keparahan |
Kemungkinan |
Mitigasi |
| Kode tidak menangani pengiriman pesan setidaknya sekali. |
Pemrosesan duplikat pesan dari bus menyebabkan kerusakan data. |
Aplikasi |
Tinggi |
Mungkin |
- Desain ulang untuk menggunakan pembagian bus dan menerapkan idempotensi dalam proses.
- Beralih dari model konsumen yang bersaing, yang membuat kinerja menjadi kompromi. |
| Skrip pencadangan penyimpanan harian gagal dijalankan. |
RPO dilanggar karena data lebih lama dari 24 jam. |
Proses otomatis |
Tinggi |
Tidak mungkin |
Siapkan pemberitahuan tentang proses pencadangan. |
| Pengguna reguler dan lonjakan penggunaan setelah rilis baru. |
Performa aplikasi menurun dan permintaan pengguna kedaluwarsa. |
Aplikasi |
Tinggi |
Tidak mungkin |
Mengonfigurasi operasi peluasan skala berbasis jadwal. |
| Terdapat bug konkurensi dalam kode. |
Perilaku yang tidak dapat diprediksi dan kemungkinan kerusakan data. |
Aplikasi |
Tinggi |
Mungkin |
Gunakan bentuk konkurensi yang aman dan hindari penanganan kontrol konkurensi secara manual. |
| Kegagalan tak terduga selama penyebaran membuat lingkungan dalam keadaan tidak konsisten. |
Gangguan aplikasi. |
Pipa Penyebaran |
Menengah |
Mungkin |
Gunakan penyebaran biru-hijau, penyebaran kenari, atau pendekatan lain untuk meluncurkan perubahan secara progresif. |
Latihan ini bisa menjadi membebani jika Anda mencoba mempertimbangkan setiap kemungkinan kegagalan. Untuk mempermudah, fokus pada komponen yang merupakan bagian dari alur pengguna penting. Dokumen hidup ini terus berkembang seiring dengan kematangan beban kerja.
✓ Mengembangkan rencana pemulihan dasar
Dasar dari playbook mitigasi kegagalan adalah untuk membuat rencana pemulihan dasar. Strategi mitigasi dapat mencakup implementasi pola desain, penyesuaian konfigurasi platform, manajemen insiden situs langsung, pengujian otomatis, dan personel pelatihan untuk mendeteksi masalah selama tinjauan kode.
Mulailah dengan strategi degradasi yang anggun, yang mencakup perbaikan sementara ketika bagian sistem tidak berfungsi dengan baik. Tujuannya adalah untuk terus melayani pengguna meskipun ada kegagalan dengan menonaktifkan bagian yang tidak berfungsi dan menyesuaikan pengalaman pengguna. Misalnya, jika database tidak berfungsi, aplikasi dapat menonaktifkan fitur yang terpengaruh dan memberi tahu klien bahwa layanan sementara tidak tersedia dengan menggunakan kode status HTTP.
Agar fungsi degradasi anggun bekerja, mengisolasi komponen-komponen sistem agar hanya bagian yang terpengaruh mengalami masalah, sementara komponen-komponen lainnya terus berfungsi. Gunakan pola Bulkhead untuk mencapai isolasi kesalahan.
Ambil kesempatan ini untuk meninjau kembali pilihan desain yang mungkin memperlambat proses pemulihan. Misalnya, mengarahkan rekaman Sistem Nama Domain (DNS) langsung ke aplikasi Anda di Azure App Service dapat menyebabkan penundaan selama pemulihan karena penyebaran DNS. Gunakan layanan khusus seperti Azure Front Door sebagai titik masuk untuk konfigurasi ulang yang lebih mudah selama langkah-langkah pemulihan.
Harapkan rencana dasar ini berkembang menjadi rencana pemulihan bencana penuh pada tingkat yang lebih matang.
✓ Buat rencana pengujian
Buat rencana pengujian dengan mensimulasikan pemadaman dan masalah yang diidentifikasi dalam playbook mitigasi risiko. Tambahkan langkah-langkah mitigasi tersebut dengan kasus uji sederhana untuk memastikan bahwa mereka berfungsi seperti yang diharapkan dan dapat diterapkan. Verifikasi bahwa fitur-fitur ini beroperasi dengan benar, dan lakukan pengujian degradasi untuk melihat performa sistem saat komponen tertentu gagal. Jaga agar hasilnya tetap sederhana dengan memastikan bahwa pengujian gagal atau lulus.
Gunakan alat pengujian seperti kerangka kerja tiruan untuk menyuntikkan kesalahan ke dalam permintaan HTTP, yang membantu Anda menguji kebijakan coba lagi secara lebih eksplisit. Azure Chaos Studio menyediakan rangkaian pengujian komprehensif untuk mensimulasikan pemadaman komponen dan masalah lainnya, yang menjadikannya layanan yang berharga untuk dijelajahi. Anda dapat secara bertahap mengadopsi Chaos Studio saat Anda terbiasa dengan fitur-fiturnya.
✓ Menilai dampak operasi penskalaan terhadap keandalan
Untuk menangani lonjakan beban, komponen penting harus dapat meluaskan skala atau meningkatkan skala secara efisien. Manfaatkan kemampuan penskalaan otomatis yang disediakan Azure. Kemampuan ini menyesuaikan batas kapasitas layanan berdasarkan konfigurasi yang telah ditentukan sebelumnya. Penyesuaian ini memungkinkan Anda untuk meningkatkan atau menurunkan skala layanan sesuai kebutuhan.
Identifikasi potensi hambatan dan pahami risiko yang mungkin timbul. Misalnya, throughput tinggi tidak boleh menyebabkan gangguan aliran.
Pahami pola beban. Pola penggunaan statis dapat membuat hambatan kurang penting, tetapi perubahan dinamika penggunaan dan konsumsi dapat memperburuk risiko.
Nota
Mungkin ada komponen yang tidak dapat memperluas skala, seperti database monolitik dan aplikasi warisan. Pantau kurva beban secara proaktif untuk memungkinkan arsitek ulang jika diperlukan.
Tentukan batas penskalaan yang wajar berdasarkan persyaratan performa dan keandalan. Untuk masalah performa, peningkatan skala secara bertahap adalah yang paling umum. Namun, masalah keandalan untuk alur kritis mungkin memerlukan penskalaan yang lebih cepat untuk menghindari pemadaman. Dalam kedua kasus, hindari penskalakan tak terbatas.
Risiko: Ketika Anda menangani masalah terkait performa, penskalaan dapat menjadi strategi mitigasi yang berguna. Namun, penskalakan adalah perbaikan sementara dan bukan solusi. Selidiki dan selesaikan masalah yang mendasarinya, seperti kebocoran memori atau proses pelarian. Jika tidak, Anda berisiko menerapkan mitigasi yang sama sekali lagi di titik kritis lain dan membayar sumber daya yang tidak Anda butuhkan. Dengan mengatasi akar penyebabnya, Anda dapat memastikan stabilitas jangka panjang dan efisiensi biaya.
Tetapkan tujuan dan target keandalan untuk menjaga tim tetap akuntabel pada prosedur pemulihan.
Pada tingkat awal, tim Anda berfokus pada kemenangan mudah dan kemampuan dasar. Mereka dimulai dengan peningkatan kecil, memecahkan masalah sederhana untuk membangun fondasi yang kuat sambil mengandalkan sebagian besar kemampuan keandalan Azure. Seiring pertumbuhan tim Anda, mereka menangani lebih banyak tantangan teknis yang terkait dengan aset dan proses mereka sendiri.
Pada Tingkat 3, tim Anda harus mengintegrasikan wawasan bisnis dan keterampilan teknis untuk perencanaan pemulihan. Mereka menetapkan tujuan dan merencanakan proses pemulihan dengan menggunakan pemantauan tingkat lanjut. Pendekatan ini membantu teknisi keandalan situs (SRE) memenuhi target keandalan dengan cepat.
Strategi utama
Tujuan keandalan membantu menetapkan akuntabilitas untuk tim beban kerja. Penting untuk melakukan percakapan kolaboratif dengan pemangku kepentingan bisnis untuk membahas waktu dan biaya pemulihan, dan untuk membuat kompromi yang selaras dengan tujuan bisnis. Kumpulkan para pemangku kepentingan dan lakukan diskusi ini sebagai lokakarya. Pertimbangkan poin-poin berikut untuk agenda lokakarya:
Jelaskan metrik di balik tujuan. Mulailah dengan menjelaskan metrik utama yang digunakan untuk menentukan tujuan seperti tujuan tingkat layanan, tujuan waktu pemulihan (RTO), dan tujuan titik pemulihan (RPO). Memperlihatkan bagaimana metrik tersebut selaras dengan tujuan bisnis. Fokus pada alur pengguna penting. Misalnya, dalam aplikasi e-niaga, RTO untuk memperbarui preferensi email kurang penting daripada pengguna yang memeriksa keranjang belanja.
Komunikasikan kompromi. Pemangku kepentingan sering mengharapkan lebih dari apa yang dapat dicapai. Jelaskan bagaimana memperluas cakupan memengaruhi anggaran, persyaratan operasional, dan performa.
Mengusulkan target tujuan. Berdasarkan pengalaman arsitektur dan desain beban kerja, rekomendasikan target seperti waktu aktif 99,9%, dengan RPO dan RTO ditetapkan pada empat jam. Memfasilitasi diskusi bagi pemangku kepentingan untuk memberikan umpan balik dan melakukan penyesuaian. Pastikan bahwa pemangku kepentingan bisnis dan teknis menjaga agar tidak memiliki harapan yang tidak realistis. Pendekatan diskusi dengan pola pikir kolaboratif.
Mencapai konsensi atau keputusan. Bertujuan untuk konensus, tetapi jika itu tidak memungkinkan, minta pembuat keputusan menyelesaikan target untuk memastikan kemajuan.
✓ Pantau secara proaktif dengan menggunakan model kesehatan Anda
Pada Tingkat 1, data pemantauan dikumpulkan dari komponen beban kerja, termasuk layanan platform dan aplikasi. Analisis dan pemberitahuan dasar diatur untuk menetapkan performa dasar dan mengidentifikasi anomali. Di Tingkat 2, fokus bergeser untuk mendapatkan data pengamatan dari komponen beban kerja, seperti kode aplikasi.
Tingkat 3 meningkatkan pemantauan dengan menambahkan konteks bisnis ke alur penting dan menentukan status sehat, tidak sehat, dan terdegradasi melalui pemodelan kesehatan. Perjanjian pemangku kepentingan diperlukan untuk menentukan kompromi pengalaman pengguna yang dapat diterima dan harus digunakan sebagai input untuk menentukan status kesehatan.
Pemodelan kesehatan membutuhkan kematangan operasional dan keahlian dalam alat pemantauan. Tim Anda meninjau data mentah, tingkat performa, dan log untuk membuat metrik dan ambang kustom yang menentukan status kesehatan alur. Mereka harus memahami bagaimana nilai-nilai ini berkaitan dengan kesehatan sistem secara keseluruhan. Berkomunikasi definisi dan ambang yang jelas kepada pemangku kepentingan.
Visualisasikan model kesehatan di dasbor untuk membantu SRE dengan cepat menentukan masalah dengan berfokus pada alur yang tidak sehat atau terdegradasi.
Model kesehatan mendefinisikan status aplikasi dan alur kritis. Hijau menunjukkan bahwa semua alur kritis beroperasi seperti yang diharapkan. Merah menunjukkan kegagalan. Dan kuning cenderung menunjukkan masalah. Iterasi melalui versi model kesehatan memastikan keandalan dan akurasi tetapi membutuhkan upaya yang signifikan untuk aplikasi besar.
Perubahan status kesehatan harus dikonfigurasi sebagai pemberitahuan. Namun, untuk mengatur peringatan agar tetap sesuai tujuan, kritisitas komponen harus dipertimbangkan.
Untuk informasi selengkapnya, lihat Well-Architected Framework: Pemodelan kesehatan.
✓ Mengatur pemberitahuan yang dapat ditindakkan
Untuk meningkatkan efisiensi respons, tentukan pemberitahuan dengan jelas dan berikan informasi yang cukup untuk tindakan cepat. Nama dan deskripsi pemberitahuan terperinci dapat membantu menghemat waktu dan upaya selama pemecahan masalah. Konfigurasikan tingkat keparahan, nama, dan deskripsi dengan hati-hati, dengan perhatian khusus pada tingkat keparahan. Tidak setiap peristiwa adalah keadaan darurat. Dengan cermat menilai tingkat keparahan dan menetapkan kriteria untuk setiap tingkat, seperti apakah lonjakan CPU dari 80% hingga 90% memenuhi syarat sebagai keadaan darurat. Atur ambang yang sesuai untuk memastikan bahwa pemberitahuan ditentukan secara efektif.
Manajemen pemberitahuan yang efektif memastikan bahwa pemberitahuan memberi tahu orang yang tepat pada waktu yang tepat. Pemberitahuan yang sering dan mengganggu menunjukkan perlunya penyesuaian dan dapat menjadi kontraproduktif saat diabaikan. Kurangi pemberitahuan yang tidak perlu dengan mengatur ambang yang sesuai untuk memfilter alarm palsu. Identifikasi peluang di mana otomatisasi dapat memicu prosedur operasional.
Buat satu halaman arahan yang memiliki informasi yang diperlukan untuk memecahkan masalah peringatan secara efisien. Pendekatan ini menghemat waktu dibandingkan dengan masuk ke portal Microsoft Azure dan mencari metrik. Jika fitur bawaan Azure Monitor tidak sepenuhnya memenuhi kebutuhan Anda, pertimbangkan untuk mengembangkan dasbor kustom.
✓ Melakukan analisis mode kegagalan
Di tingkat sebelumnya, Anda membuat panduan mitigasi kegagalan sederhana untuk setiap komponen. Pada tingkat ini, kembangkan playbook tersebut menjadi kegiatan analisis mode kegagalan formal (FMA). Tujuan dari latihan ini adalah untuk secara proaktif mengidentifikasi potensi mode kegagalan.
FMA mengharuskan Anda mengidentifikasi titik kegagalan potensial dalam beban kerja Anda dan merencanakan tindakan mitigasi, seperti pemulihan mandiri atau pemulihan bencana (DR). Untuk memulai, pantau peningkatan tingkat kesalahan dan deteksi dampak pada aliran kritis. Gunakan pengalaman sebelumnya dan uji data untuk mengidentifikasi potensi kegagalan dan menilai radius ledakan mereka. Prioritaskan masalah besar seperti pemadaman di seluruh wilayah.
Penting untuk mengklasifikasikan tindakan sebagai pencegahan atau reaktif. Tindakan pencegahan mengidentifikasi risiko sebelum menyebabkan pemadaman, yang mengurangi kemungkinan atau tingkat keparahannya. Tindakan reaktif mengatasi masalah untuk mengurangi status kesehatan yang terdegradasi atau pemadaman.
Dalam aplikasi contoh e-niaga, tim beban kerja ingin melakukan FMA untuk mempersiapkan diri untuk acara besar. Salah satu alur pengguna utama adalah menambahkan item ke ke troli. Komponen yang merupakan bagian dari alur adalah front end, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB, dan Azure Event Hubs.
| Masalah |
Risiko |
Sumber potensial |
Tingkat Keparahan |
Kemungkinan |
Tindakan |
| Jumlah pesanan yang diterima turun di bawah 100 per jam, tanpa penurunan aktivitas sesi pengguna yang sesuai |
Pelanggan tidak dapat melakukan pemesanan, meskipun aplikasi tersedia. |
CartAPI, PaymentsAPI |
Tinggi |
Tidak mungkin |
Tindakan reaktif:
- Tinjau model kesehatan atau data pemantauan untuk mengidentifikasi masalah.
- Uji aplikasi untuk memvalidasi fungsionalitasnya.
- Jika terjadi pemadaman komponen, lakukan failover ke sekumpulan infrastruktur lain.
Tindakan pencegahan:
- Lakukan perintah sintetis untuk memverifikasi bahwa alur berfungsi.
- Meningkatkan pemantauan untuk memastikan bahwa alur end-to-end dipantau dengan baik. |
| Peningkatan beban yang tidak terduga menyebabkan batas waktu saat menyimpan pesanan ke Azure Cosmos DB |
Pelanggan tidak dapat melakukan pemesanan atau mengalami performa yang tidak memuaskan jika mereka memang dapat melakukan pemesanan. |
Azure Cosmos DB |
Tinggi |
Tidak mungkin |
Tindakan reaktif:
- Verifikasi beban berdasarkan telemetri aplikasi.
- Tingkatkan unit permintaan Azure Cosmos DB untuk sementara.
Tindakan pencegahan:
- Mengonfigurasi skala otomatis.
- Tinjau kembali beban yang diharapkan dan hitung ulang aturan skala.
- Pindahkan beberapa aktivitas ke proses latar belakang untuk mengurangi beban database dari alur ini. |
| Layanan rekomendasi benar-benar offline |
Halaman keranjang belanja gagal dimuat karena pengecualian yang memanggil layanan rekomendasi. |
Aplikasi |
Menengah |
Tidak mungkin |
Tindakan reaktif:
- Terapkan strategi degradasi yang anggun untuk menonaktifkan fungsionalitas rekomendasi atau menampilkan data rekomendasi yang dikodekan secara permanen di halaman keranjang belanja. Terapkan pendekatan ini ketika pengecualian terjadi saat Anda menilai layanan. |
| Penghentian sementara yang berkala terjadi saat mengakses pricing API dari halaman keranjang belanja dalam kondisi beban berat. |
Kegagalan sementara terjadi di halaman keranjang belanja karena kegagalan mengakses layanan keranjang. |
Aplikasi |
Menengah |
Kemungkinan besar (saat beban kerja berat) |
Tindakan reaktif:
- Terapkan nilai harga cache di penyimpanan data keranjang belanja, bersama dengan tanda waktu kedaluwarsa cache.
- Akses API harga hanya ketika cache data harga kedaluwarsa. |
FMA rumit dan dapat memakan waktu, jadi bangun analisis Anda secara progresif dari waktu ke waktu. Proses ini berulang dan terus berkembang pada tahap selanjutnya.
Untuk informasi selengkapnya, lihat Rekomendasi RE:03 untuk melakukan FMA.
✓ Menyiapkan rencana DR
Di Tingkat 2, Anda membuat rencana pemulihan yang berfokus pada kontrol teknis untuk memulihkan fungsionalitas sistem. Namun, bencana memerlukan pendekatan yang lebih luas karena kehilangan atau kegagalan yang sifatnya katastrofik. Rencana DR berbasis proses. Mereka mencakup komunikasi, langkah-langkah pemulihan terperinci, dan berpotensi menyertakan artefak teknis seperti skrip.
Pertama, identifikasi jenis bencana yang akan di rencanakan, seperti pemadaman wilayah, kegagalan di seluruh Azure, gangguan infrastruktur, kerusakan database, dan serangan ransomware. Kemudian, kembangkan strategi pemulihan untuk setiap skenario dan pastikan mekanisme tersedia untuk memulihkan operasi. Persyaratan bisnis, RTO, dan RPO harus memandu rencana DR. RTO dan RPO rendah memerlukan proses otomatis eksplisit, sementara RTO dan RPO yang lebih tinggi memungkinkan metode pemulihan yang lebih sederhana dan analisis manual.
DR terutama mencakup tindakan berikut:
Beri tahu pihak yang bertanggung jawab. Penting untuk memiliki kejelasan tentang siapa yang harus dilibatkan dan kapan. Pastikan tim Anda menggunakan proses yang benar, memiliki izin yang tepat, dan memahami peran mereka dalam pemulihan. Beberapa tanggung jawab, seperti CEO yang melaporkan ke pasar atau menangani persyaratan peraturan, harus diidentifikasi lebih awal.
Idealnya, Anda harus memiliki peran pemulihan dan komunikasi terpisah, dan menetapkan orang yang berbeda untuk setiap peran. Awalnya, orang operasi TI yang menemukan masalah mungkin menangani kedua peran. Tetapi ketika situasi meningkat, personel senior mungkin menangani pemulihan teknis sementara orang bisnis mengelola komunikasi.
Buat keputusan bisnis. Selama bencana, tingkat stres bisa tinggi, yang membuat pengambilan keputusan yang jelas penting. Rencana DR yang terstruktur dengan baik memerlukan diskusi berkelanjutan antara tim teknis dan pemangku kepentingan bisnis untuk menentukan opsi keputusan awal. Misalnya, pertimbangkan apakah sumber daya beban kerja harus berjalan di satu wilayah Azure dengan cadangan di wilayah lain, atau apakah aset IaC harus disiapkan terlebih dahulu untuk membuat sumber daya baru atau memulihkan dari cadangan selama failover.
Tindakan yang diambil sesuai dengan rencana DR dapat merusak atau memiliki efek samping yang signifikan. Sangat penting untuk memahami opsi, menimbang pro dan kontra mereka, dan menentukan waktu yang tepat untuk menerapkannya. Misalnya, menilai apakah pemulihan ke wilayah yang berbeda diperlukan jika wilayah utama diharapkan beroperasi dalam jangka waktu yang dapat diterima.
Pulihkan operasi sistem. Selama bencana, fokusnya harus pada pemulihan operasi dan bukan pada mengidentifikasi penyebabnya. Untuk pemulihan teknis, terutama dalam failover wilayah, putuskan terlebih dahulu tentang pendekatan seperti aktif-aktif, aktif-pasif, siaga hangat, atau siaga dingin.
Siapkan langkah-langkah pemulihan tertentu berdasarkan pendekatan yang dipilih. Mulailah dengan daftar langkah-langkah konkret untuk memulihkan operasi. Saat proses matang, bertujuan untuk mendefinisikan rencana DR sebagai skrip dengan interaksi manual minimal. Gunakan kontrol versi dan simpan skrip dengan aman untuk akses yang mudah. Pendekatan ini membutuhkan lebih banyak upaya di muka tetapi meminimalkan stres selama insiden aktual.
Untuk informasi selengkapnya, lihat Penerapan aktif-pasif untuk Pemulihan Bencana.
Lakukan analisis pasca-insiden. Identifikasi penyebab insiden dan temukan cara untuk mencegahnya di masa mendatang. Buat perubahan untuk meningkatkan proses pemulihan. Latihan ini mungkin juga mengungkap strategi baru. Misalnya, jika sistem beralih ke lingkungan sekunder, tentukan apakah lingkungan utama masih diperlukan dan proses failback apa yang seharusnya.
Rencana DR adalah dokumen yang terus berkembang dan menyesuaikan dengan perubahan pada beban kerja Anda. Perbarui rencana DR Anda saat komponen dan risiko baru muncul. Sempurnakan rencana berdasarkan wawasan yang diperoleh dari latihan atau bencana nyata dengan mengumpulkan informasi yang realistis dari operator DR.
Mengontrol risiko yang berasal dari perubahan teknis dan operasional, dan memprioritaskan manajemen insiden.
Di tingkat sebelumnya, tim beban kerja Anda berfokus pada pembangunan fitur dan membuat sistem beroperasi. Pada Tingkat 4, fokus bergeser untuk menjaga sistem tetap andal dalam produksi. Manajemen insiden menjadi sama pentingnya dengan memastikan bahwa setiap perubahan yang diperkenalkan diuji secara menyeluruh dan disebarkan dengan aman untuk menghindari membuat sistem tidak stabil.
Proses ini memerlukan perbaikan dalam kontrol operasional, seperti berinvestasi dalam tim khusus untuk mengelola insiden keandalan. Ini juga memerlukan kontrol teknis untuk meningkatkan keandalan sistem di luar komponen penting yang diperkuat di tingkat sebelumnya. Karena sistem terus berjalan dalam produksi, pertumbuhan data mungkin memerlukan desain ulang, seperti partisi, untuk memastikan akses dan pemeliharaan yang andal.
Strategi utama
✓ Manajemen perubahan yang andal
Risiko keandalan terbesar terjadi selama perubahan, seperti pembaruan perangkat lunak, penyesuaian konfigurasi, atau modifikasi proses. Peristiwa ini sangat penting dari sudut keandalan. Tujuannya adalah untuk meminimalkan kemungkinan masalah, pemadaman, waktu henti, atau kehilangan data. Setiap jenis perubahan memerlukan aktivitas khusus untuk mengelola risiko uniknya secara efektif.
Pada Tingkat 4, Keandalan bersinggungan dengan praktik penyebaran yang aman yang dijelaskan dalam Keunggulan Operasional, dalam mempertahankan lingkungan yang stabil saat mengelola perubahan. Manajemen perubahan yang andal adalah persyaratan untuk mencapai stabilitas beban kerja. Pertimbangkan aspek utama berikut:
Bereaksi terhadap pembaruan platform. Layanan Azure memiliki mekanisme yang berbeda untuk memperbarui layanan.
Biasakan diri Anda dengan proses pemeliharaan dan perbarui kebijakan setiap layanan yang Anda gunakan. Pahami apakah layanan mendukung peningkatan otomatis atau manual dan jangka waktu untuk pembaruan manual.
Untuk layanan yang telah merencanakan pembaruan, kelola pembaruan ini secara efektif dengan menjadwalkannya selama waktu berdampak rendah. Hindari pembaruan otomatis dan tunda hingga Anda menilai risikonya. Beberapa layanan memungkinkan Anda mengontrol waktu, sementara layanan lain memberikan masa tenggang. Misalnya, dengan Azure Kubernetes Service (AKS), Anda memiliki waktu 90 hari untuk ikut serta sebelum pembaruan menjadi otomatis. Uji pembaruan dalam kluster nonproduksi yang mencerminkan penyiapan produksi Anda untuk mencegah regresi.
Terapkan pembaruan secara bertahap. Bahkan jika pengujian menunjukkan bahwa pembaruan aman, menerapkannya ke semua instans secara bersamaan dapat berisiko. Sebagai gantinya, perbarui beberapa instans sekaligus dan tunggu di antara setiap set.
Periksa pemberitahuan secara teratur tentang pembaruan, yang mungkin tersedia di log aktivitas atau saluran khusus layanan lainnya.
Pantau perubahan mendadak atau bertahap setelah pembaruan diterapkan. Idealnya, model kesehatan Anda harus memberi tahu Anda tentang perubahan ini.
Pengujian menyeluruh dengan otomatisasi. Integrasikan lebih banyak pengujian ke dalam alur build dan penyebaran saat Anda meluncurkan perubahan. Cari peluang untuk mengonversi proses manual ke bagian otomatis dari alur Anda.
Lakukan pengujian komprehensif dengan menggunakan kombinasi berbagai jenis pengujian pada berbagai tahap untuk mengonfirmasi bahwa perubahan berfungsi seperti yang diharapkan dan tidak memengaruhi bagian lain dari aplikasi. Misalnya, pengujian positif dapat memverifikasi bahwa sistem beroperasi seperti yang diharapkan. Ini harus memvalidasi bahwa tidak ada kesalahan dan bahwa lalu lintas mengalir dengan benar.
Saat Anda merencanakan pembaruan, identifikasi gerbang pengujian dan jenis pengujian yang akan diterapkan. Sebagian besar pengujian harus terjadi dalam tahap pra-penyebaran, tetapi pengujian asap juga harus dilakukan di setiap lingkungan saat Anda memperbaruinya.
Ikuti praktik penyebaran yang aman. Gunakan topologi penyebaran yang mencakup jendela validasi dan praktik penyebaran yang aman. Terapkan pola penyebaran yang aman, seperti penyebaran kenari dan biru-hijau, untuk meningkatkan fleksibilitas dan keandalan.
Misalnya, dalam penerapan kanari, subset kecil pengguna menerima versi baru terlebih dahulu. Proses ini memungkinkan pemantauan dan validasi sebelum penyebaran ke seluruh basis pengguna. Teknik seperti bendera fitur dan peluncuran gelap memfasilitasi pengujian dalam produksi sebelum merilis perubahan pada semua pengguna.
Perbarui paket DR Anda. Perbarui rencana DR Anda secara teratur agar tetap relevan dan efektif. Hindari instruksi yang kedaluarsa. Pendekatan ini memastikan bahwa rencana mencerminkan keadaan terkini sistem Anda yang dikerahkan ke lingkungan produksi dan dipercaya oleh pengguna. Menggabungkan pelajaran yang dipelajari dari latihan dan insiden aktual.
Untuk informasi selengkapnya, lihat Keunggulan Operasional Tingkat 4
✓ Berinvestasi dalam tim khusus untuk menangani insiden
Awalnya, tim pengembangan mungkin terlibat pada saat insiden. Pada Tingkat 4, berinvestasi dalam rekayasa keandalan situs (SRE) untuk manajemen insiden. SREs berspesialisasi dalam masalah produksi dan ahli dalam efisiensi, manajemen perubahan, pemantauan, respons darurat, dan manajemen kapasitas. Tim SRE yang mafisien dapat secara signifikan mengurangi dependensi pada tim teknik.
Berikan SRI alat, informasi, dan pengetahuan yang diperlukan untuk menangani insiden secara independen. Persiapan ini mengurangi dependensi pada tim teknik. SRE harus dilatih dalam playbook dan model kesehatan beban kerja yang dikembangkan di tingkat sebelumnya untuk dengan cepat mengenali pola umum dan memulai proses mitigasi.
Tim teknik harus memiliki waktu untuk merefleksikan masalah berulang dan mengembangkan strategi jangka panjang, alih-alih mengatasinya secara individual setiap kali.
✓ Mengotomatiskan proses penyembuhan diri
Pada tingkat sebelumnya, strategi penyembuhan diri dirancang dengan menggunakan pola redundansi dan desain. Setelah tim Anda memiliki pengalaman dengan penggunaan dunia nyata, Anda dapat mengintegrasikan otomatisasi untuk mengurangi pola kegagalan umum dan mengurangi dependensi pada tim teknik.
Trade-off: Automasi dapat memakan waktu dan mahal untuk diterapkan. Fokus pada mengotomatiskan tugas yang paling berdampak terlebih dahulu, seperti tugas yang sering terjadi atau cenderung menyebabkan pemadaman.
Mengonfigurasi tindakan berdasarkan pemicu dan mengotomatiskan respons dari waktu ke waktu untuk membangun playbook otomatis untuk SRE. Salah satu pendekatan adalah memperkaya playbook dengan skrip yang menerapkan langkah-langkah mitigasi. Jelajahi opsi asli Azure, seperti menggunakan grup tindakan Azure Monitor, untuk menyiapkan pemicu yang secara otomatis memulai berbagai tugas.
✓ Memperpanjang ketahanan terhadap tugas latar belakang
Sebagian besar beban kerja mencakup komponen yang tidak secara langsung mendukung alur pengguna tetapi memainkan peran penting dalam alur kerja keseluruhan aplikasi. Misalnya, dalam sistem e-niaga, ketika pengguna melakukan pemesanan, sistem menambahkan pesan ke antrean. Tindakan ini memicu beberapa tugas latar belakang, seperti konfirmasi email, finalisasi biaya kartu kredit, dan pemberitahuan gudang untuk persiapan pengiriman. Tugas-tugas ini beroperasi secara terpisah dari fungsi yang melayani permintaan pengguna di situs web, yang mengurangi beban dan meningkatkan keandalan. Sistem juga mengandalkan tugas latar belakang untuk pembersihan data, pemeliharaan rutin, dan pencadangan.
Setelah Anda mengevaluasi dan meningkatkan alur pengguna utama Anda, pertimbangkan tugas latar belakang. Gunakan teknik dan infrastruktur yang sudah ada, dan tambahkan peningkatan untuk tugas latar belakang.
Terapkan titik pemeriksaan. Titik pemeriksaan adalah teknik untuk menyimpan status proses atau tugas pada titik tertentu. Titik pemeriksaan sangat berguna untuk tugas atau proses jangka panjang yang mungkin terganggu karena masalah tak terduga seperti kegagalan jaringan atau crash sistem. Ketika proses dimulai ulang, proses dapat dilanjutkan dari titik pemeriksaan terakhir yang disimpan, yang meminimalkan dampak gangguan.
Pertahankan proses yang idempotensi. Pastikan idempotensi dalam proses latar belakang sehingga jika tugas gagal, instans lain dapat mengambilnya dan melanjutkan pemrosesan tanpa masalah.
Pastikan konsistensi. Cegah sistem memasukkan status yang tidak konsisten jika tugas latar belakang berhenti selama pemrosesan. Baik pemeriksaan titik kendali maupun idempoten tingkat tugas adalah teknik untuk memungkinkan konsistensi yang lebih besar di seluruh operasi tugas latar belakang. Jalankan setiap tugas sebagai transaksi atomik. Untuk tugas yang mencakup beberapa penyimpanan data atau layanan, gunakan idempotensi tingkat tugas atau transaksi kompensasi untuk memastikan bahwa tugas tersebut selesai.
Integrasikan tugas latar belakang ke dalam sistem pemantauan dan praktik pengujian Anda. Mendeteksi kegagalan dan mencegah gangguan yang tidak disadari yang dapat mengakibatkan konsekuensi fungsional dan nonfungsi. Sistem pemantauan Anda harus mengambil data dari komponen ini, mengatur pemberitahuan untuk gangguan, dan menggunakan pemicu untuk mencoba kembali atau melanjutkan proses secara otomatis. Perlakukan aset ini sebagai bagian dari beban kerja, dan lakukan pengujian otomatis dengan cara yang sama seperti yang Anda lakukan untuk komponen penting.
Azure menyediakan beberapa layanan dan fitur untuk pekerjaan latar belakang, seperti Azure Functions dan Azure App Service WebJobs. Tinjau praktik dan batas terbaiknya saat Anda menerapkan alur yang berfokus pada keandalan.
Tetap tangguh saat arsitektur beban kerja berkembang, yang memungkinkan sistem untuk menahan risiko baru dan tak terduga.
Pada Tingkat 5, fokus untuk meningkatkan keandalan solusi Anda menjauh dari penerapan kontrol teknis. Infrastruktur, aplikasi, dan operasi Anda harus cukup dapat diandalkan agar tahan terhadap pemadaman dan pulih darinya dalam waktu pemulihan target.
Gunakan data dan tujuan bisnis di masa mendatang untuk mengakui bahwa jika bisnis Anda perlu memajukan, perubahan arsitektur mungkin diperlukan. Saat beban kerja Anda berkembang dan fitur baru ditambahkan, upayakan untuk meminimalkan pemadaman yang terkait dengan fitur tersebut sambil mengurangi pemadaman lebih lanjut untuk fitur yang ada.
Strategi utama
✓ Gunakan wawasan keandalan untuk memandu evolusi arsitektur
Pada tingkat ini, buat keputusan bekerja sama dengan pemangku kepentingan bisnis. Pertimbangkan faktor berikut:
Analisis metrik yang menunjukkan berapa kali sistem Anda melewati ambang keandalan dalam periode waktu tertentu dan apakah itu dapat diterima. Misalnya, mengalami lima pemadaman besar dalam satu tahun dapat memicu penilaian ulang desain sistem dan praktik operasional.
Mengevaluasi kekritisan bisnis sistem. Misalnya, layanan yang mendukung alur kerja kritikal misi mungkin memerlukan desain ulang untuk penerapan tanpa waktu henti dan failover instan, bahkan jika meningkatkan biaya atau kompleksitas. Sebaliknya, layanan dengan penggunaan terbatas mungkin mendapat manfaat dari standar tingkat layanan yang lebih longgar.
Menilai bagaimana perubahan pilar lain memengaruhi keandalan. Misalnya, peningkatan langkah-langkah keamanan mungkin memerlukan mitigasi keandalan untuk hop keamanan tambahan, yang dapat memperkenalkan titik kegagalan potensial.
Menilai biaya operasional untuk menjaga keandalan. Jika biaya ini melebihi batasan anggaran, pertimbangkan perubahan arsitektur untuk mengoptimalkan dan mengontrol pengeluaran.
Untuk membantu pemangku kepentingan, insinyur, dan manajer produk membuat keputusan berdasarkan informasi, pertimbangkan untuk memvisualisasikan poin data sebelumnya bersama dengan wawasan tambahan. Pendekatan ini memberikan gambaran lengkap tentang keandalan.
✓ Jalankan pengujian terkontrol dalam produksi
Pada tingkat ini, pertimbangkan eksperimen terkontrol dalam produksi hanya jika beban kerja memerlukan jaminan ketahanan tertinggi. Praktik pengujian ini dikenal sebagai rekayasa chaos. Pengujian memvalidasi bahwa sistem dapat pulih dengan anggun dan terus berfungsi dalam kondisi buruk.
Pertimbangkan contoh kasus penggunaan berikut:
Analisis alur dependensi: Kasus penggunaan umum adalah menguji aplikasi yang dirancang sebagai layanan mikro. Anda dapat menonaktifkan instans layanan mikro acak untuk memastikan bahwa kegagalan tidak merambat atau mengganggu pengalaman pengguna. Anda dapat memperluas pendekatan ini ke alur sistem dengan menonaktifkan komponen tertentu untuk menganalisis bagaimana sistem hilir bereaksi. Tujuannya adalah untuk mengidentifikasi coupling yang ketat atau dependensi tersembunyi dan menguji performa rencana redundansi sistem.
Pengujian degradasi bertahap: Evaluasi bagaimana sistem berjalan dengan fungsionalitas yang berkurang selama kegagalan. Misalnya, Anda dapat menyembunyikan fitur non-kritis jika mesin rekomendasi gagal.
Simulasi kegagalan pihak ketiga: Nonaktifkan atau batasi panggilan ke API eksternal untuk melihat cara sistem Anda beroperasi dan apakah fallback atau percobaan ulang diterapkan dengan benar.
Rekayasa chaos adalah standar emas untuk menguji ketahanan. Namun, terapkan praktik ini untuk sistem yang matang dan tim yang menangani beban kerja. Pastikan bahwa perlindungan tersedia untuk membatasi radius ledakan dan mencegah dampak pengguna.
Bersiaplah dengan menjalankan hari permainan. Mulailah di lingkungan nonproduksi yang mensimulasikan kondisi dunia nyata dengan menggunakan pengaturan berisiko lebih rendah dengan transaksi sintetis. Pendekatan ini membantu mengidentifikasi celah proses, jalur kesalahan manusia, dan kelemahan arsitektur.
Ketika pengujian nonproduksi berhenti menghasilkan wawasan yang berharga, mungkin sudah waktunya untuk pindah ke produksi jika Anda yakin. Pastikan untuk mencantumkan semua kekhawatiran, mengevaluasi ketahanan, dan mengatasi masalah apa pun sebelum Anda bertransisi.
Batasi cakupan eksperimen. Misalnya, Anda hanya dapat mematikan satu instans. Tentukan dengan jelas tujuan pengujian. Pahami apa yang Anda uji dan mengapa.
Pengujian ini harus mematuhi perjanjian tingkat layanan dengan beroperasi dalam batas yang telah ditentukan dan anggaran kesalahan. Pilih jangka waktu yang sesuai untuk eksperimen ini. Biasanya, melakukannya selama hari kerja memastikan bahwa tim sepenuhnya diisi dan memiliki sumber daya yang cukup untuk menanggapi insiden apa pun yang mungkin terjadi.
✓ Melakukan latihan pemulihan bencana
Rekayasa chaos menguji ketahanan kontrol teknis. Latihan pemulihan bencana (DR) menilai ketahanan kontrol proses. Tujuan drill DR adalah untuk memvalidasi efektivitas prosedur, koordinasi, dan tindakan manusia ketika sistem Anda pulih dari kegagalan besar atau bencana.
Untuk beban kerja peraturan, persyaratan kepatuhan dapat menentukan frekuensi latihan DR untuk memastikan catatan upaya. Untuk beban kerja lain, melakukan latihan ini secara teratur disarankan. Interval enam bulan memberikan kesempatan yang baik untuk menangkap perubahan beban kerja dan memperbarui prosedur DR yang sesuai.
Latihan DR harus lebih dari latihan rutin. Ketika dilakukan dengan benar, latihan DR membantu melatih anggota tim baru dan mengidentifikasi kesenjangan dalam alat, komunikasi, dan tugas terkait latihan lainnya. Mereka juga dapat menyoroti perspektif baru yang mungkin diabaikan.
Pertimbangkan metode utama berikut untuk melakukan latihan DR, masing-masing bervariasi dalam risiko dan kepraktekkan:
Sepenuhnya disimulasikan: Latihan ini sepenuhnya berbasis papan tulis dan mencakup panduan prosedural tanpa memengaruhi sistem apa pun. Mereka cocok untuk pelatihan dan validasi awal. Namun, mereka tidak memberikan wawasan tentang insiden nyata.
Latihan nyata di lingkungan nonproduksi: Latihan ini memungkinkan Anda memvalidasi otomatisasi, skrip, dan proses tanpa risiko bisnis apa pun.
Latihan nyata dalam produksi: Latihan ini memberikan tingkat kepercayaan diri dan realisme tertinggi. Lakukan latihan ini hanya setelah Anda menguji dua metode sebelumnya. Strategi perencanaan dan pembatalan menyeluruh sangat penting untuk meminimalkan risiko. Jangan lanjutkan jika ada kemungkinan menyebabkan pemadaman.
Terlepas dari jenis drill DR, tentukan dengan jelas skenario pemulihan beban kerja. Lakukan latihan seolah-olah mereka insiden nyata. Pendekatan ini memastikan bahwa tim mengikuti daftar periksa yang dipahami dengan baik. Dokumentasikan dan klasifikasikan temuan untuk mendorong peningkatan berkelanjutan. Persiapan DR Anda mungkin mencakup proses berikut:
Pahamilah sistem manajemen insiden, dan pastikan bahwa tim dilatih mengenai prosedur eskalasi.
Cantumkan alat komunikasi untuk kolaborasi dan pembaruan status, termasuk alternatif jika sistem utama terpengaruh.
Berikan materi keterampilan tentang skenario pengujian yang relevan untuk beban kerja.
Lacak perbedaan untuk menangkap masalah yang dihadapi selama implementasi.
Trade-off: Latihan ini biasanya tidak mengganggu, tetapi membutuhkan waktu. Untuk memaksimalkan efektivitasnya, fokus pada aspek utama dan hindari tugas yang tidak perlu. Pastikan untuk mengalokasikan waktu untuk praktik ini di backlog Anda.
Saat Anda membuat rencana DR atau melakukan latihan DR, khususnya untuk beberapa latihan pertama, pertimbangkan untuk menyertakan keahlian khusus. Input mereka tentang desain multiregion, strategi failover dan failback, serta layanan atau alat sangat berharga. Jika organisasi Anda memiliki tim Cloud Center of Excellence, pastikan untuk menyertakannya dalam proses perencanaan.
✓ Evaluasi model dan segmen data Anda jika perlu
Data bersifat dinamis dan terus berkembang. Tidak seperti komponen lain dalam arsitektur Anda, data biasanya tumbuh saat pengguna berinteraksi dengan sistem Anda. Memantau pola data dari waktu ke waktu dan menilai dampaknya pada bagian lain dari arsitektur Anda sangat penting. Pada tingkat ini, pertimbangkan teknik yang menyederhanakan manajemen data dan meningkatkan performa untuk meningkatkan keandalan secara keseluruhan. Pemartisian adalah strategi utama untuk mencapai hasil ini.
Jelajahi teknik seperti partisi panas-dingin, yang membagi data berdasarkan pola akses dan menyimpannya secara terpisah. Gunakan kriteria seperti frekuensi akses atau relevansi untuk memutuskan apa yang harus dipartisi.
Partisi panas-dingin dapat dikombinasikan dengan sharding, yang merupakan proses membagi database besar menjadi unit yang lebih kecil yang disebut shard. Setiap pecahan menyimpan sebagian data, dan bersama-sama membentuk himpunan data lengkap. Pendekatan ini memungkinkan manajemen data independen.
Trade-off: Menyeimbangkan shard memerlukan proses operasional untuk mengevaluasi dan mengonfirmasi distribusinya. Pendekatan ini membantu menghindari partisi panas di mana satu partisi terlalu banyak digunakan. Namun, ini juga membutuhkan upaya dan sumber daya yang berkelanjutan untuk menjaga keseimbangan.
Saat Anda memilih teknik partisi, pertimbangkan manfaat keandalan berikut:
Performa yang ditingkatkan: Dengan mendistribusikan permintaan di beberapa partisi, Anda dapat mengurangi beban pada masing-masing toko. Ketika diimplementasikan secara efektif, sharding memungkinkan sistem untuk memproses jutaan permintaan tulis per hari. Strategi ini meningkatkan performa dan meminimalkan latensi.
Pemartisian dapat menyederhanakan penskalaan horizontal. Misalnya, sharding dapat membagi pengguna atau pelanggan menjadi kelompok yang berukuran kira-kira sama.
Manajemen data yang disempurnakan: Pemartisian panas-dingin memungkinkan berbagai tingkat manajemen data diterapkan ke setiap tingkat penyimpanan. Misalnya, memindahkan data arsip ke penyimpanan terpisah membantu mencegah perlambatan dalam operasi dan pencadangan. Demikian pula, tidak semua data log perlu disimpan dalam database relasional. Ini dapat disimpan di penyimpanan data lain sementara data beban kerja aktif tetap relasional.
Kebijakan keandalan yang disesuaikan: Kebijakan keandalan yang berbeda dapat diterapkan untuk membantu memastikan bahwa setiap partisi memiliki tingkat ketahanan yang tepat dan mencegah penyimpanan tunggal menjadi hambatan. Partisi panas dapat sepenuhnya redundan, termasuk zona-redundansi dan geo-redundansi, sementara partisi dingin mengandalkan cadangan. Manfaat keandalan tambahan adalah Anda dapat mengurangi radius ledakan dari beberapa jenis kegagalan. Misalnya, jika kegagalan memengaruhi satu shard, shard lainnya mungkin tidak terpengaruh.
Trade-off: Mungkin sulit untuk mempertahankan atau memodifikasi partisi karena interdependensi yang kuat antara partisi data yang berbeda. Perubahan ini dapat memengaruhi kemampuan untuk memverifikasi konsistensi dan integritas data, terutama jika dibandingkan dengan satu penyimpanan data. Ketika jumlah partisi meningkat, kebutuhan akan proses yang kuat untuk menjaga integritas data menjadi lebih penting. Tanpa tindakan ini, keandalan mungkin terganggu.