Rekomendasi untuk menentukan target keandalan

Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:

RE:04	Tentukan target keandalan dan pemulihan untuk komponen, alur, dan solusi keseluruhan. Visualisasikan target untuk bernegosiasi, mendapatkan konsekuensi, menetapkan harapan, dan mendorong tindakan untuk mencapai keadaan ideal. Gunakan target yang ditentukan untuk membangun model kesehatan. Model kesehatan mendefinisikan seperti apa status sehat, terdegradasi, dan tidak sehat.

Panduan ini menjelaskan rekomendasi untuk menentukan metrik target ketersediaan dan pemulihan untuk beban kerja dan alur penting. Target keandalan diperoleh melalui latihan lokakarya dengan pemangku kepentingan bisnis. Target disempurnakan melalui pemantauan dan pengujian.

Dengan pemangku kepentingan internal Anda, tetapkan harapan realistis untuk keandalan beban kerja sehingga pemangku kepentingan dapat mengomunikasikan harapan tersebut kepada pelanggan melalui perjanjian kontraktual. Harapan realistis juga membantu pemangku kepentingan memahami dan mendukung keputusan desain arsitektur Anda dan mengetahui bahwa Anda merancang untuk memenuhi target yang Anda setujui secara optimal.

Pertimbangkan untuk menggunakan metrik berikut untuk mengukur persyaratan bisnis.

Istilah	Definisi
Tujuan tingkat layanan (SLO)	Target persentase yang mewakili kesehatan komponen dan tingkat keandalan. Semakin tinggi tingkatannya, semakin dapat diandalkan komponennya. SLO Komposit mewakili target agregat dari seluruh beban kerja dan akun untuk SLA komponen.
Indikator tingkat layanan (SLI)	Metrik yang dipancarkan oleh layanan. Metrik SLI diagregasi untuk mengukur nilai SLO.
Perjanjian Tingkat Layanan (SLA)	Perjanjian kontraktual antara penyedia layanan dan pelanggan layanan. Perjanjian mendefinisikan SLA. Kegagalan untuk memenuhi perjanjian mungkin memiliki konsekuensi finansial bagi penyedia layanan.
Rata-rata waktu untuk pulih (MTTR)	Waktu yang diperlukan untuk memulihkan komponen setelah kegagalan terdeteksi.
Waktu rata-rata antara kegagalan (MTBF)	Durasi beban kerja dapat melakukan fungsi yang diharapkan tanpa gangguan, sampai gagal.
Tujuan waktu pemulihan (RTO)	Waktu maksimum yang dapat diterima bahwa aplikasi dapat tidak tersedia setelah insiden.
Tujuan titik pemulihan (RPO)	Durasi maksimum kehilangan data yang dapat diterima selama insiden.

Tentukan nilai target beban kerja untuk metrik ini dalam konteks alur pengguna dan alur sistem. Identifikasi dan nilai alur tersebut dengan seberapa pentingnya persyaratan Anda. Gunakan nilai untuk mendorong desain beban kerja Anda dalam hal arsitektur, peninjauan, pengujian, dan operasi manajemen insiden. Kegagalan untuk memenuhi target akan memengaruhi bisnis di luar tingkat toleransi.

Strategi desain utama

Diskusi teknis tidak boleh mendorong cara Anda menentukan target keandalan untuk alur kritis Anda. Sebaliknya, pemangku kepentingan bisnis harus fokus pada pelanggan saat mereka menentukan persyaratan beban kerja. Pakar teknis membantu pemangku kepentingan menetapkan nilai numerik realistis yang berkorelasi dengan persyaratan tersebut. Ketika mereka berbagi pengetahuan, pakar teknis memungkinkan negosiasi dan konsekuensi bersama tentang SLA yang realistis.

Pertimbangkan contoh cara memetakan persyaratan ke nilai numerik yang terukur. Pemangku kepentingan memperkirakan bahwa untuk alur pengguna penting, satu jam waktu henti selama jam kerja reguler mengakibatkan hilangnya dolar X dalam pendapatan bulanan. Jumlah dolar itu dibandingkan dengan perkiraan biaya merancang aliran yang memiliki ketersediaan SLO 99,95 persen daripada 99,9 persen. Pengambil keputusan harus membahas apakah risiko kerugian pendapatan tersebut melebihi biaya tambahan dan beban manajemen yang diperlukan untuk melindunginya. Ikuti pola ini saat Anda memeriksa alur dan membangun daftar lengkap target.

Ingat bahwa target keandalan berbeda dari target performa. Target keandalan berfokus pada ketersediaan dan pemulihan. Untuk menetapkan target keandalan, mulailah dengan menentukan persyaratan terluas lalu tentukan metrik yang lebih spesifik untuk memenuhi persyaratan tingkat tinggi.

Persyaratan keandalan dan pemulihan tingkat tertinggi dan metrik berkorelasi mungkin termasuk, misalnya, ketersediaan aplikasi 99,9 persen untuk semua wilayah atau target RTO 5 jam untuk wilayah Amerika. Menentukan jenis target ini membantu Anda mengidentifikasi alur kritis mana yang terlibat dalam target tersebut. Kemudian Anda dapat mempertimbangkan target tingkat komponen.

Tradeoff: Kesenjangan konseptual mungkin ada antara batasan teknis komponen beban kerja Anda dan apa artinya bagi bisnis, misalnya, throughput dalam megabit per detik versus transaksi per detik. Membuat model di antara kedua tampilan ini mungkin menantang. Daripada overengineering solusi, cobalah untuk mendekatinya dengan cara yang ekonomis tetapi bermakna.

Metrik ketersediaan

SLA dan SLA

Metrik ketersediaan berkorelasi dengan SLA, yang Anda gunakan untuk menentukan SLA. SLO beban kerja menentukan berapa banyak waktu henti yang dapat ditoleransi dalam periode tertentu, misalnya, kurang dari 1 jam per bulan. Untuk memastikan Anda dapat memenuhi target SLO, tinjau Microsoft SLA untuk setiap komponen. Perhatikan berapa banyak redundansi yang Anda butuhkan untuk memenuhi SLA tinggi. Misalnya, Microsoft menjamin SLA yang lebih tinggi untuk penyebaran multi-wilayah Azure Cosmos DB daripada yang dijamin untuk penyebaran wilayah tunggal.

Catatan

Azure SLA tidak selalu mencakup semua aspek layanan. Misalnya, Azure Application Gateway memiliki SLA ketersediaan, tetapi fungsionalitas Azure Web Application Firewall tidak memberikan jaminan untuk menghentikan lalu lintas berbahaya melewatinya. Pertimbangkan batasan ini saat Anda mengembangkan SLA dan SLA.

Setelah Anda mengumpulkan SLA untuk komponen beban kerja individual, hitung SLA komposit. SLA komposit harus cocok dengan SLO target beban kerja. Menghitung SLA komposit melibatkan beberapa faktor, tergantung pada desain arsitektur Anda. Pertimbangkan contoh berikut.

Catatan

Nilai SLA dalam contoh berikut bersifat hipotetis dan hanya untuk tujuan demonstrasi. Mereka tidak dimaksudkan untuk mewakili nilai saat ini yang didukung oleh Microsoft.

SLA Komposit melibatkan beberapa layanan yang mendukung aplikasi, dengan tingkat ketersediaan yang berbeda. Misalnya, pertimbangkan aplikasi web Azure App Service yang menulis ke Azure SQL Database. Secara hipotetis, SLA ini mungkin:

• App Service aplikasi web = 99,95 persen
• SQL Database = 99,99 persen

Berapa waktu henti maksimum yang dapat Anda harapkan untuk aplikasi ini? Jika salah satu layanan gagal, maka seluruh aplikasi akan gagal. Probabilitas setiap layanan gagal bersifat independen, sehingga SLA komposit untuk aplikasi ini adalah 99,95 persen × 99,99 persen = 99,94 persen. Nilai tersebut lebih rendah dari SLA individual. Kesimpulan ini tidak mengherankan karena aplikasi yang bergantung pada beberapa layanan memiliki lebih banyak titik kegagalan potensial.

Anda dapat meningkatkan SLA komposit dengan membuat jalur fallback independen. Misalnya, jika SQL Database tidak tersedia, masukkan transaksi ke dalam antrean untuk diproses kemudian:

Dalam desain ini, aplikasi masih tersedia meskipun tidak dapat terhubung ke database. Namun, itu gagal jika database dan antrean gagal pada saat yang sama. Persentase waktu yang diharapkan untuk kegagalan simultan adalah 0,0001 × 0,001, jadi berikut adalah SLA komposit untuk jalur gabungan ini:

Database atau antrean = 1,0 − (0,0001 × 0,001) = 99,99999 persen

Total SLA komposit:

Aplikasi web dan (database atau antrean) = 99,95 persen × 99,99999 persen = ~99,95 persen

Pendekatan ini menimbulkan tradeoff:

• Logika aplikasi lebih kompleks.
• Anda membayar antrean.
• Anda perlu mempertimbangkan masalah konsistensi data.

Untuk penyebaran multi-wilayah, SLA komposit dihitung sebagai berikut:

• N adalah SLA komposit untuk aplikasi yang disebarkan di satu wilayah.

• R adalah jumlah wilayah tempat aplikasi disebarkan.

Kemungkinan yang diharapkan bahwa aplikasi gagal di semua wilayah pada saat yang sama adalah ((1 − N) ^ R). Misalnya, jika SLA wilayah tunggal hipotetis adalah 99,95 persen:

• Gabungan SLA untuk dua wilayah = (1 − (1 − 0,9995) ^ 2) = 99,999975 persen

• Gabungan SLA untuk empat wilayah = (1 − (1 − 0,9995) ^ 4) = 99,9999999 persen

Menentukan SLA yang tepat membutuhkan waktu dan pertimbangan yang cermat. Pemangku kepentingan bisnis harus memahami bagaimana pelanggan utama menggunakan aplikasi. Mereka juga harus memahami toleransi keandalan. Umpan balik ini harus menginformasikan target.

Nilai SLA

Tabel berikut mendefinisikan nilai SLA umum.

SLA	Waktu henti per minggu	Waktu henti per bulan	Waktu henti per tahun
99%	1,68 jam	7,2 jam	3,65 hari
99,9%	10,1 menit	43,2 menit	8,76 jam
99,95%	5 menit	21,6 menit	4,38 Jam
99,99%	1,01 menit	4,32 menit	52,56 menit
99,999%	6 detik	25,9 detik	5,26 menit

Ketika Anda memikirkan SLA komposit dalam konteks alur, ingatlah bahwa alur yang berbeda memiliki definisi kekritisan yang berbeda. Pertimbangkan perbedaan ini saat Anda membangun SLA komposit Anda. Alur nonkritis mungkin memiliki komponen yang harus Anda hilangkan dari perhitungan Anda karena tidak memengaruhi pengalaman pelanggan jika tidak tersedia secara singkat.

Catatan

Beban kerja yang menghadap pelanggan dan beban kerja penggunaan internal memiliki SCO yang berbeda. Biasanya, beban kerja penggunaan internal dapat memiliki SLA ketersediaan yang jauh lebih ketat daripada beban kerja yang berhadapan dengan pelanggan.

SLI

Anggap SLI sebagai metrik tingkat komponen yang berkontribusi pada SLO. SLI yang paling signifikan adalah SLI yang memengaruhi alur kritis Anda dari perspektif pelanggan Anda. Untuk banyak alur, SLI mencakup latensi, throughput, tingkat kesalahan, dan ketersediaan. SLI yang baik membantu Anda mengidentifikasi kapan SLO berisiko dilanggar. Menghubungkan SLI dengan pelanggan tertentu jika memungkinkan.

Untuk menghindari pengumpulan metrik yang tidak berguna, batasi jumlah SLI untuk setiap alur. Bidik tiga SLI per alur jika memungkinkan.

Metrik pemulihan

Target pemulihan sesuai dengan metrik RTO, RPO, MTTR, dan MTBF. Berbeda dengan target ketersediaan, target pemulihan untuk pengukuran ini tidak terlalu bergantung pada SLA Microsoft. Microsoft menerbitkan jaminan RTO dan RPO hanya untuk beberapa produk, seperti SQL Database.

Definisi untuk target pemulihan realistis bergantung pada analisis mode kegagalan Anda dan rencana serta pengujian Anda untuk kelangsungan bisnis dan pemulihan bencana. Sebelum Anda menyelesaikan pekerjaan ini, diskusikan target aspirasi dengan pemangku kepentingan dan pastikan desain arsitektur Anda mendukung target pemulihan sebaik mungkin dari pemahaman Anda. Berkomunikasi dengan jelas kepada pemangku kepentingan bahwa setiap alur atau seluruh beban kerja yang tidak diuji secara menyeluruh untuk metrik pemulihan seharusnya tidak menjamin SLA. Pastikan pemangku kepentingan memahami bahwa target pemulihan dapat berubah dari waktu ke waktu saat beban kerja diperbarui. Beban kerja dapat menjadi lebih kompleks saat pelanggan ditambahkan atau saat Anda mengadopsi teknologi baru untuk meningkatkan pengalaman pelanggan. Perubahan ini dapat meningkatkan atau mengurangi metrik pemulihan Anda.

Catatan

MTBF bisa menjadi tantangan untuk didefinisikan dan dijamin. Platform as a service (PaaS) atau software as a service (SaaS) dapat gagal dan pulih tanpa pemberitahuan apa pun dari penyedia cloud, dan prosesnya dapat sepenuhnya transparan bagi Anda atau pelanggan Anda. Jika Anda menentukan target untuk metrik ini, hanya mencakup komponen yang berada di bawah kendali Anda.

Saat Anda menentukan target pemulihan, tentukan ambang batas untuk memulai pemulihan. Misalnya, jika simpul web tidak tersedia selama lebih dari 5 menit, simpul baru secara otomatis ditambahkan ke kumpulan. Tentukan ambang batas untuk semua komponen, mempertimbangkan pemulihan apa yang melibatkan komponen tertentu, termasuk efek pada komponen dan dependensi lain. Ambang batas Anda juga harus mempertimbangan kesalahan sementara untuk memastikan bahwa Anda tidak memulai tindakan pemulihan terlalu cepat. Mendokumentasikan dan berbagi dengan pemangku kepentingan potensi risiko operasi pemulihan, seperti kehilangan data atau gangguan sesi bagi pelanggan.

Membangun model kesehatan

Gunakan data yang Anda kumpulkan untuk target keandalan Anda untuk membangun model kesehatan Anda untuk setiap beban kerja dan alur kritis terkait. Model kesehatan mendefinisikan status sehat, terdegradasi, dan tidak sehat untuk alur dan beban kerja. Status memastikan prioritas operasional yang sesuai. Model ini juga dikenal sebagai model lampu lalu lintas. Model menetapkan hijau untuk sehat, kuning untuk terdegradasi, dan merah untuk tidak sehat. Model kesehatan memastikan bahwa Anda tahu kapan status alur berubah dari sehat menjadi terdegradasi atau tidak sehat.

Bagaimana Anda menentukan status sehat, terdegradasi, dan tidak sehat tergantung pada target keandalan Anda. Berikut adalah beberapa contoh cara Anda dapat menentukan status:

• Status hijau atau sehat menunjukkan bahwa persyaratan dan target utama yang tidak berfungsi sepenuhnya terpenuhi dan sumber daya digunakan secara optimal. Misalnya, 95 persen permintaan diproses dalam <=500 md dengan penggunaan simpul Azure Kubernetes Service (AKS) pada X persen.

• Status kuning atau terdegradasi menunjukkan bahwa satu atau beberapa komponen alur memperingatkan terhadap ambang batas yang ditentukan, tetapi alurnya beroperasi. Misalnya, pembatasan penyimpanan telah terdeteksi.

• Status merah atau tidak sehat menunjukkan bahwa degradasi telah bertahan lebih lama dari yang diizinkan oleh target keandalan Anda atau bahwa alur telah menjadi tidak tersedia.

Catatan

Model kesehatan tidak boleh memperlakukan semua kegagalan sama. Model kesehatan harus membedakan antara kesalahan sementara dan nontransient . Ini harus dengan jelas membedakan antara kegagalan yang diharapkan-sementara tetapi dapat dipulihkan dan status bencana yang sebenarnya.

Model ini bekerja dengan menggunakan strategi pemantauan dan peringatan yang dikembangkan dan dioperasikan berdasarkan prinsip-prinsip peningkatan berkelanjutan. Seiring berkembangnya beban kerja Anda, model kesehatan Anda harus berevolusi dengannya.

Untuk pertimbangan dan rekomendasi desain terperinci untuk model kesehatan aplikasi berlapis, lihat panduan pemodelan kesehatan yang ditemukan di area desain beban kerja misi penting. Untuk panduan terperinci tentang konfigurasi pemantauan dan pemberitahuan, lihat panduan pemantauan kesehatan .

Visualisasi

Untuk menjaga tim operasi dan pemangku kepentingan beban kerja Anda mendapatkan informasi tentang status real-time dan tren keseluruhan model kesehatan beban kerja, pertimbangkan untuk membuat dasbor dalam solusi pemantauan Anda. Diskusikan solusi visualisasi dengan pemangku kepentingan untuk memastikan bahwa Anda memberikan informasi yang mereka nilai dan yang mudah dikonsumsi. Mereka mungkin juga ingin melihat laporan yang dihasilkan setiap minggu, bulanan, atau triwulanan.

Fasilitasi Azure

Azure SLA menyediakan komitmen Microsoft untuk waktu aktif dan konektivitas. Layanan yang berbeda memiliki SLA yang berbeda, dan terkadang SKU dalam layanan memiliki SLA yang berbeda. Untuk informasi selengkapnya, lihat Perjanjian tingkat layanan untuk layanan online.

Azure SLA menyertakan prosedur untuk mendapatkan kredit layanan jika SLA tidak terpenuhi, bersama dengan definisi ketersediaan untuk setiap layanan. Aspek SLA tersebut bertindak sebagai kebijakan penegakan hukum.

Tautan terkait

• Well-Architected Panduan misi penting kerangka kerja untuk pemodelan kesehatan: Pemodelan kesehatan dan pengamatan beban kerja misi penting di Azure

Daftar periksa keandalan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keandalan