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 status 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. Anda harus memperoleh target keandalan dari latihan lokakarya dengan pemangku kepentingan bisnis. Kemudian perbaiki target tersebut dengan memantau dan menguji beban kerja Anda.

Tetapkan ekspektasi realistis dengan pemangku kepentingan internal Anda tentang keandalan beban kerja. Kemudian mereka dapat menggunakan perjanjian kontraktual untuk mengomunikasikan harapan tersebut kepada pelanggan. Harapan realistis juga membantu pemangku kepentingan memahami dan mendukung keputusan desain arsitektur Anda dan mengetahui bahwa Anda merancang untuk secara optimal memenuhi target yang Anda setujui.

Pertimbangkan untuk menggunakan metrik berikut untuk mengukur persyaratan bisnis Anda.

Term	Definisi
Tujuan tingkat layanan (SLO)	Ukuran performa dan keandalan beban kerja atau aplikasi. SLO adalah target spesifik dan terukur yang Anda tetapkan untuk interaksi pelanggan tertentu. Ini adalah target yang Anda tetapkan untuk beban kerja atau aplikasi Anda berdasarkan kualitas layanan yang diharapkan pelanggan Anda terima.
Indikator tingkat layanan (SLI)	Pengukuran kuantitatif dari aspek tertentu dari performa layanan. Anda dapat menggunakan SLI untuk mengukur kepatuhan beban kerja Anda dengan SLO.
Service-level agreement (SLA)	Perjanjian kontraktual antara penyedia layanan dan pelanggan layanan. 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 hingga 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.

Strategi desain utama

Target keandalan mewakili tujuan kualitas beban kerja yang diinginkan, seperti yang dijanjikan kepada penggunanya dan pemangku kepentingan bisnis. Tujuan tersebut mencakup ketersediaan dan pemulihan beban kerja. Perlu diingat bahwa target keandalan berbeda dari target performa, tetapi Anda harus menyertakan target performa dalam target keandalan. Pertimbangkan target keandalan berikut:

• Target ketersediaan menentukan standar kualitas agar sistem tetap dapat diakses dan berfungsi. Jika tidak memenuhi standar ini, sistem dianggap tidak dapat diandalkan. Gunakan SLO untuk membantu memeriksa apakah sistem Anda memenuhi standar ini. Pemangku kepentingan bisnis dan teknis berkolaborasi untuk menetapkan SCO realistis dan mempertimbangkan faktor-faktor seperti analisis komparatif, pengalaman pengguna, dan profil beban kerja.

• Target kebenaran memastikan bahwa beban kerja melakukan fungsinya dengan benar dengan kualitas yang konsisten. Untuk mengukur kebenaran, kuantifikasi indikator beban kerja sehingga Anda dapat menggabungkannya menjadi skor objektif terpadu.

• Target pemulihan sesuai dengan metrik RTO, RPO, MTTR, dan MTBF, yang mengukur efektivitas rencana dan pengujian Anda untuk kelangsungan bisnis dan pemulihan bencana.

Untuk menetapkan target keandalan, pemangku kepentingan bisnis menentukan persyaratan yang luas. Kemudian, para ahli teknis menilai status beban kerja saat ini dan bekerja untuk mencapai dan memelihara target melalui pemantauan dan pemberitahuan. Kedua belah pihak harus menyetujui target realistis.

Identifikasi dan nilai alur pengguna dan sistem berdasarkan kepentingannya terhadap kebutuhan bisnis Anda. Gunakan skor ini untuk memandu desain, ulasan, pengujian, dan manajemen insiden beban kerja Anda. Tetapkan target keandalan untuk alur ini, dan pahami bahwa gagal memenuhi target tersebut dapat secara signifikan memengaruhi bisnis Anda.

Tradeoff: Anda mungkin memiliki kesenjangan antara batas teknis sistem Anda dan dampak bisnisnya, seperti throughput versus transaksi per detik. Menjeda kesenjangan ini bisa sulit. Bertujuan untuk solusi praktis dan hemat biaya alih-alih overengineering.

Mengatur tujuan ketersediaan

SLO keseluruhan beban kerja mencerminkan kualitas holistik , termasuk semua dependensinya. Deklarasi SLO yang matang harus menunjukkan target bisnis keseluruhan untuk beban kerja tersebut, bukan hanya komposit dari dependensi tersebut. Misalnya, jika pelanggan mengharapkan ketersediaan 99,99%, SLO keseluruhan harus bertujuan untuk tujuan tersebut, bahkan jika satu bagian hanya mencapai 99,80%.

Pemangku kepentingan mengevaluasi pengalaman pelanggan dan mempertimbangkan bagaimana waktu henti memengaruhi pendapatan. Mereka membandingkan kerugian ini dengan biaya merancang dan mengoperasikan alur bisnis. Pembuat keputusan kemudian memutuskan apakah mereka harus menghabiskan lebih banyak uang untuk keandalan untuk menghindari kehilangan pendapatan dan mempertahankan reputasi mereka.

Pemilik beban kerja menggunakan tujuan keuangan untuk menentukan tujuan. Persyaratan bisnis dipetakan ke metrik yang terukur. Tujuannya adalah untuk mengidentifikasi serangkaian faktor yang memengaruhi kualitas pengalaman pelanggan.

Arsitek beban kerja membuat banyak keputusan teknis berdasarkan SCO. SLO dapat:

• Berfungsi sebagai input penting ke dalam keputusan arsitektur ketika Anda mempertimbangkan dependensi lain.

• Berikan tampilan hampir real-time dan pemahaman bersama tentang kesehatan beban kerja untuk mengaktifkan diskusi objektif. Mereka juga membantu tim beban kerja memprioritaskan upaya untuk meningkatkan keandalan dan mengembangkan fitur baru.

• Bertindak sebagai sinyal utama untuk operasi penyebaran, yang mendorong putar kembali otomatis jika masalah terjadi dan memberikan validasi bahwa perubahan mencapai peningkatan yang diharapkan pada pengalaman pelanggan.

• Percepat remediasi dan pemulihan dengan berfokus pada tujuan, dorong pemberitahuan otomatis masalah kepada pelanggan, dan bangun kepercayaan antar tim di organisasi Anda.

Penting

Anda harus mengetahui perbedaan antara SLA dan SLA. Meskipun SLA dan SLA mungkin menggunakan atau bahkan menyajikan data serupa, niatnya berbeda. SLA adalah kontrak formal antara organisasi dan pelanggannya, dan memiliki implikasi keuangan dan hukum langsung jika organisasi gagal memberikan janjinya. Organisasi menggunakan SLO untuk mengevaluasi apakah potensi waktu henti berada dalam batas yang dapat ditoleransi.

SLA dan SLA berbagi hubungan bisnis dan harus dikontrol secara independen. Jika SLA berfungsi sebagai taktik bisnis, organisasi mungkin sengaja mengaturnya ke nilai tinggi berdasarkan tujuan pemilik bisnis. Sebaliknya, SCO bisa lebih tinggi. Pertimbangkan beban kerja misi penting sebagai contoh. Kelas beban kerja ini tidak mampu menurunkan waktu henti yang lama karena efeknya, termasuk kerugian finansial dan bahkan ancaman terhadap keselamatan manusia, sangat signifikan. Oleh karena itu, SCO biasanya menargetkan waktu aktif 99,999%, biasanya disebut sebagai lima sembilan. Jika SLA tidak memenuhi target tersebut, organisasi harus bereaksi cepat untuk mengurangi kegagalan dan mencegah hasil SLA yang gagal.

Contoh dalam artikel ini menetapkan SLA tinggi untuk mendukung tujuan bisnis.

Platform cloud dan penyedia teknologi menerbitkan SLA pada penawaran mereka. Anda harus mempertimbangkan SLA sebagai bagian dari perhitungan SLO, tetapi Anda tidak boleh menggunakannya apa adanya tanpa memahami cakupan cakupan SLA. Untuk informasi selengkapnya, lihat Menilai dampak Microsoft SLA.

Pertimbangkan SCO umum dan faktor-faktor yang berpengaruh

Setiap SLO menargetkan kriteria kualitas tertentu. Pertimbangkan SCO umum ini untuk keandalan. Daftar ini tidak lengkap. Tambahkan SLO berdasarkan kebutuhan bisnis Anda.

• Tingkat keberhasilan mengukur keberhasilan permintaan dan proses relatif terhadap permintaan yang mengembalikan kesalahan atau gagal dalam tugasnya.

• Latensi mengukur waktu antara ketika permintaan operasi dimulai dan ketika hasilnya tersedia atau proses selesai.

• Kapasitas mengukur penggunaan bersamaan, seperti jumlah respons berbasis pembatasan.

• Ketersediaan mengukur waktu aktif dari perspektif pelanggan.

• Throughput mengukur tingkat transfer data minimum selama sejumlah waktu tertentu. Throughput diukur sebagai unit laju data, seperti transaksi per detik (TPS) atau permintaan per detik (RPS).

Pahami skenario dan toleransi untuk beban kerja Anda di Azure. Layanan Azure dan komponen aplikasi memengaruhi beban kerja SLO. Gabungkan respons dari tabel berikut untuk mendapatkan SLO keseluruhan. Gunakan pertanyaan-pertanyaan ini sebagai contoh untuk mengevaluasi utilitas komponen beban kerja.

Karakteristik komponen	Interaksi pelanggan	Faktor lain
- Apakah mengekspos API permintaan atau respons? - Apakah memiliki API kueri? - Apakah itu komponen komputasi? - Apakah itu komponen pemrosesan pekerjaan?	- Kontrol sarana dan akses sarana manajemen untuk layanan Azure yang menghadap publik. - Akses sarana data, misalnya operasi buat, baca, perbarui, dan hapus (CRUD).	- Apakah proses rilis Anda melibatkan waktu henti? - Apa kemungkinan memperkenalkan bug? Jika beban kerja terintegrasi dengan sistem lain, Anda mungkin perlu mempertimbangkan bug integrasi. - Bagaimana operasi rutin seperti patching memengaruhi target ketersediaan? Apakah Anda memperhitungkan dependensi mitra? - Apakah staf Anda cukup untuk mendukung darurat konstan dan pencadangan darurat pada rotasi panggilan? - Apakah aplikasi memiliki tetangga yang berisik di luar cakupan kontrol Anda yang berpotensi menyebabkan gangguan?

Menentukan cakupan SLO

Anda dapat mengatur SCO di berbagai tingkatan, seperti untuk setiap aplikasi, beban kerja, atau alur tertentu, dalam sistem Anda. Atur SCO khusus tingkat sehingga Anda dapat menyesuaikan SCO berdasarkan kepentingan setiap komponen.

Dalam solusi software as a service (SaaS), ukur SLO per pelanggan untuk mengoptimalkan pengalaman setiap pelanggan. Pelanggan mungkin memiliki sumber daya infrastruktur yang berbeda di segmen mereka. Untuk kasus seperti itu, SLO di seluruh sistem yang menggabungkan semua sumber daya di seluruh segmen pelanggan mungkin tidak masuk akal. Sebagai gantinya, ukur SCO yang selaras dengan konteks spesifik setiap pelanggan. Untuk informasi selengkapnya, lihat Model penyewaan untuk solusi multipenyewa.

Menentukan target SLO komposit

SLO harus dapat diukur dan diukur dalam jendela pengamatan.

SLO sering kali merupakan persentase seperti 99,90%, tetapi juga dapat menjadi pernyataan. Gunakan kedua metode untuk mendapatkan nilai numerik yang mencakup semua faktor.

SLO terdiri dari SLI terukur yang menentukan faktor yang dapat diterima. SLI adalah metrik dengan ambang yang ditetapkan yang dapat diperingatkan. Anda dapat mengumpulkannya dari platform atau aplikasi. Komponen yang berbeda memancarkan SLI yang relevan. Saat Anda memilih SLI, pertimbangkan faktor-faktor yang memengaruhi SLO.

Misalnya, untuk menghitung SLO untuk alur yang menggunakan RESPONS dan API permintaan, ukur latensi server dan waktu pemrosesan permintaan. Throughput dan tingkat kesalahan tidak berlaku untuk lingkungan komputasi berkelanjutan seperti komputer virtual (VM), set skala, atau Azure Batch.

Untuk akses sarana kontrol, pertimbangkan tingkat kesalahan dan latensi untuk respons API dan operasi yang berjalan lama seperti pembuatan sumber daya. Akses sarana data tergantung pada API yang digunakan, masing-masing dengan target SLO mereka sendiri.

SLI yang baik menunjukkan kapan Anda mungkin melanggar SLO. Biasanya diukur dalam persentil. Berikut adalah beberapa persentil yang umum digunakan dan perkiraan waktu ketidakpatuhan terhadap ketersediaan yang diharapkan.

Tujuan	Ketidakpatuhan per minggu	Ketidakpatuhuran per bulan	Ketidakpatuhan per tahun
99%	1,68 jam	7,20 jam	3,65 hari
99,90%	10.10 menit	43.20 menit	8,76 jam
99,95%	5 menit	21,60 menit	4,38 Jam
99,99%	1,01 menit	4,32 menit	52,56 menit
99,999%	6 detik	25,90 detik	5,26 menit

Penting

Nilai SLO komposit adalah distribusi produk dari faktor-faktor yang berkontribusi.

Contoh SLO komposit adalah 99,95% × 99,99999% = ~99,95%.

Saat Anda membuat SCO komposit untuk alur yang berbeda, pertimbangkan berbagai kekritisan dan relevansinya. Alur mungkin memiliki komponen yang Anda anggap sebagai noncritical dan menghilangkan dari perhitungan Anda. Anda dapat membenarkan kelalaian mereka berdasarkan apakah tidak tersedia singkat mereka memengaruhi pengalaman pelanggan. Dalam beberapa kasus, komponen mungkin tidak relevan dengan kasus penggunaan yang Anda pertimbangkan untuk SLO. Anda juga dapat menghilangkan komponen-komponen ini dari perhitungan.

Prinsip yang sama berlaku untuk operasi. Operasi tertentu mungkin menimbulkan risiko atau memengaruhi SLO, dan yang lain tidak signifikan. Keputusan harus eksplisit dan dibangun berdasarkan konsekuensi.

Untuk contoh ilustrasi tentang cara menentukan dan mengukur SLA dan SLI, lihat bagian Contoh .

Menilai dampak SLA Microsoft

Microsoft SLA memberikan wawasan tentang ketersediaan area yang diterapkan Microsoft. SLA tidak menjamin penawaran secara keseluruhan. Saat Anda mengevaluasi SLA, memiliki pemahaman yang baik tentang cakupan yang disediakan di sekitar persentil yang diterbitkan.

Pertimbangkan Web Apps, fitur Azure App Service. Fitur ini dianggap tersedia saat mengembalikan status 200 OK dalam kasus penggunaan tertentu. Dalam konteks dan jangka waktu tertentu, tidak mencakup jaminan yang didukung secara finansial pada ketersediaan fitur seperti Easy Auth atau peralihan slot. Anda harus mempertimbangkan area yang tidak disebutkan secara eksplisit dalam perjanjian sebagaimana tersedia oleh upaya terbaik platform.

Jadi, jika beban kerja Anda bergantung pada slot penyebaran, Anda tidak dapat memperoleh SLO Anda hanya dari App Service SLA. Sebagai tim beban kerja, Anda perlu melakukan hedge dan memprediksi ketersediaan waktu aktif. Namun, prediksi ini bisa tidak pasti, itulah sebabnya mengikat SLO Anda dengan SLA platform bisa bermasalah.

Pertimbangkan contoh lain. Jika Azure Front Door memiliki ketersediaan 99,99%, desain Anda harus mematuhi kriteria tertentu yang diterbitkan dalam perjanjian. Misalnya, back end Anda harus menyertakan penyimpanan, Anda memerlukan GET operasi yang dapat mengambil file berukuran setidaknya 50 KB, dan Anda perlu menyebarkan agen di beberapa tempat di setidaknya lima lokasi yang beragam secara geografis. Kasus penggunaan sempit Azure Front Door ini tidak menjamin fitur seperti penembolokan, aturan perutean, atau firewall aplikasi web. Aspek-aspek ini berada di luar cakupan SLA.

Menerapkan target multiregion

Dari perspektif keandalan, penyebaran multiregion adalah implementasi prinsip redundansi. Tujuannya adalah untuk mengurangi risiko pemadaman regional atau penurunan kinerja. Strategi ini, ketika dirancang dengan benar, dapat meningkatkan SLO karena menambahkan wilayah sekunder untuk tujuan failover.

Ada dua kasus penggunaan utama:

• Pola ketersediaan tinggi, di mana Anda mendistribusikan beban di seluruh wilayah untuk lebih banyak kapasitas. Ketersediaan tinggi tidak membatasi pengguna beban kerja ke suatu wilayah, dan seluruh performa sistem berkontribusi pada SLO.

• Pola massal, di mana Anda membatasi pelanggan ke wilayah tertentu untuk mengesegmentasinya. Dalam kasus seperti itu, perlakukan penyebaran multiregion sebagai penyebaran terpisah, atau stempel, di setiap wilayah. Ukur kesehatan setiap stempel secara terpisah, dengan SLI yang sesuai dengan beban kerja Anda. Pertimbangkan SLO beban kerja Anda secara keseluruhan berdasarkan kesehatan setiap stempel. Jika Anda dapat melakukan failover di antara stempel, maka beban kerja keseluruhan SLO Anda lebih tinggi karena kegagalan dalam satu stempel dapat dipulihkan melalui failover ke stempel lain.

Tradeoff: Tentukan apakah pengurangan risiko sepadan dengan kompleksitas tambahan. Target multiregion juga memperkenalkan kompleksitas operasional, seperti mengoordinasikan penyebaran, memastikan konsistensi data, dan menangani latensi. Operasi tersebut signifikan selama pemulihan. Tim Anda harus menimbang kompleksitas ini terhadap peningkatan ketahanan.

Perhatikan berapa banyak redundansi yang Anda butuhkan untuk memenuhi SLA tinggi. Misalnya, Microsoft menjamin SLA yang lebih tinggi untuk penyebaran multiregion Azure Cosmos DB daripada yang dijamin untuk penyebaran wilayah tunggal.

Menentukan metrik pemulihan

Definisi untuk target pemulihan realistis, seperti metrik RTO, RPO, MTTR, dan MTBF, bergantung pada analisis mode kegagalan Anda dan rencana Anda dan pengujian untuk kelangsungan bisnis dan pemulihan bencana. Ketika Anda menentukan target ini, faktor dalam jaminan pemulihan yang disediakan platform. Microsoft menerbitkan RTO dan RPO hanya menjamin untuk beberapa produk, seperti Azure SQL Database.

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 bahwa pemangku kepentingan memahami bahwa target pemulihan dapat berubah dari waktu ke waktu saat beban kerja diperbarui. Beban kerja dapat menjadi lebih kompleks saat Anda menambahkan pelanggan atau saat Anda mengadopsi teknologi baru untuk meningkatkan pengalaman pelanggan. Perubahan ini dapat meningkatkan atau mengurangi metrik pemulihan Anda.

Catatan

MTBF dapat menjadi tantangan untuk menentukan dan menjamin. Model Platform as a service (PaaS) atau 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 kontrol Anda.

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

Memantau dan memvisualisasikan target

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. Ketika status berubah, model harus memperingatkan pihak yang bertanggung jawab. Untuk pertimbangan dan rekomendasi desain terperinci, lihat Panduan pemodelan kesehatan.

Untuk menjaga tim operasi dan pemangku kepentingan beban kerja Anda mendapatkan informasi, buat visualisasi yang mencerminkan status real-time dan tren keseluruhan model kesehatan beban kerja. Diskusikan solusi visualisasi dengan pemangku kepentingan untuk memastikan bahwa Anda memberikan informasi yang mereka nilai dan 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 produk dalam layanan memiliki SLA yang berbeda. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

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

Jelajahi dasbor Azure Monitor untuk sistem visualisasi Anda.

Contoh

Contoso, Ltd. merancang pengalaman seluler baru untuk sistem tiket acara mereka. Berikut adalah arsitektur tingkat tinggi.

Diagram arsitektur dengan berbagai komponen Azure. Perangkat pemindaian tiket seluler terhubung ke Azure Front Door, yang memiliki Keamanan Lapisan Transportasi (TLS), kebijakan firewall aplikasi web (WAF), dan aturan. Azure Front Door terhubung ke Container Apps melalui koneksi Azure Private Link. VM agen build terhubung ke Azure DevOps, Aplikasi Kontainer, dan titik akhir privat. SQL Managed Instance berada dalam kotak berlabel *Tim eksternal*. Kotak platform pengamatan beban kerja berisi ruang kerja di Azure Monitor Logs, Application Insights, Azure Managed Grafana, pemberitahuan, dan pengaturan diagnostik. Arsitektur ini juga memperlihatkan ikon untuk Azure DNS, ID Microsoft Entra, Azure Key Vault, dan identitas terkelola.

Logo Grafana adalah merek dagang dari perusahaannya masing-masing. Tidak ada dukungan yang tersirat oleh penggunaan tanda ini.

Komponen

Berikut adalah beberapa komponen yang menggambarkan konsep definisi SLO. Ada komponen dalam arsitektur ini yang tidak disertakan dalam daftar berikut. Misalnya, meskipun Key Vault adalah bagian dari alur permintaan penting, itu bukan bagian dari kasus penggunaan respons. Jika Key Vault tidak tersedia, aplikasi terus berfungsi dengan menggunakan rahasia yang dimuat selama startup. Namun, jika aplikasi perlu menskalakan, ketersediaan Key Vault menjadi penting karena simpul baru perlu dimuat dengan rahasia. Dalam contoh ini, operasi penskalakan tidak dipertimbangkan. Komponen lain dihilangkan untuk brevity.

• Azure Front Door adalah titik masuk tunggal yang mengekspos API yang digunakan pelanggan untuk mengirim permintaan.

• Azure Container Apps adalah lingkungan yang dimiliki dan digunakan tim beban kerja untuk menjalankan logika bisnis untuk aplikasi.

• SQL Managed Instance dimiliki dan dikelola oleh tim lain dan merupakan dependensi penting dari beban kerja.

• Azure Private Link menyediakan konektivitas privat antara Azure Front Door dan penyebaran Container Apps. SQL Managed Instance juga diekspos ke aplikasi melalui titik akhir privat.

Dalam arsitektur ini, tim API mendefinisikan target SLO awal untuk alur penting dalam aplikasi. Mereka mengadopsi strategi yang dijelaskan dalam Faktor-faktor yang memengaruhi SLA. Mereka bertujuan untuk menentukan tujuan yang mencakup fungsionalitas inti tanpa terlalu menekankan fitur tambahan. Mereka mengukur kesehatan tiga alur pengguna penting, yang melibatkan semua fungsionalitas cloud inti dan menjalankan kode di seluruh penyebaran. Namun, alur ini tidak mencakup semua kode atau akses data. Berikut adalah faktor-faktor yang berpengaruh.

Menghitung SLO komposit

• SLO ketersediaan Azure: SLA komitmen keuangan untuk Azure berfungsi sebagai proksi untuk menilai keandalan platform.

  Komponen Azure	Cakupan SLA yang berlaku	Tidak tercakup oleh SLA	SLO yang Disesuaikan
  Azure Front Door	99.99% untuk operasi HTTP GET yang berhasil	Penembolokan, mesin aturan	99.98%
  Aplikasi Kontainer	99,95% berdasarkan aplikasi yang disebarkan yang dapat dijangkau oleh ingress bawaan	Kemampuan autoscaling, penyimpanan token	99,95%
  Instans Terkelola SQL	99,99% berdasarkan koneksi ke instans SQL Server	Performa, retensi data	99,80%
  Private Link	99,99% berdasarkan seluruh menit ketika jaringan titik akhir privat tidak menerima lalu lintas atau ketika lalu lintas tidak mengalir antara titik akhir dan layanan Private Link	Kegagalan individu berlangsung kurang dari satu menit	99,99%

  Penyesuaian didasarkan pada beberapa faktor yang bergantung pada janji tim beban kerja terhadap tujuan mereka. Salah satu faktornya mungkin keyakinan pada kemampuan platform berdasarkan pengalaman sebelumnya. Misalnya, untuk Container Apps dan Private Link, tim merasa nyaman mengambil nilai SLA apa adanya.

  Ada juga faktor bernuansa. Misalnya, tim menurunkan nilai SLO untuk SQL Managed Instance menjadi 99,80% untuk memperhitungkan potensi kegagalan dalam operasi data mereka, seperti perubahan skema dan mengambil cadangan.

  Tim menetapkan SLO komposit dengan menghitung dampak nilai SLO individual yang disesuaikan. Nilai ini adalah 99,72%.

  Ada faktor penyumbang lainnya. Arsitektur bergantung pada komponen jaringan Azure seperti jaringan virtual dan grup keamanan jaringan (NSG) yang tidak memiliki SLA yang diterbitkan. Tim beban kerja memutuskan untuk mempertimbangkan faktor-faktor tersebut dengan ketersediaan 99,99% untuk setiap komponen.

  SLO komposit berdasarkan ketersediaan platform yang diprediksi: 99,68% per bulan.

• SLO kode aplikasi: Tim mengakui bahwa bug dalam kode aplikasi atau prosedur tersimpan dapat memengaruhi ketersediaan sistem, dan mereka mengalokasikan satu jam waktu henti bulanan untuk memperhitungkan kesalahan terkait kode.

  Mereka menggunakan persentil waktu henti umum untuk memperkirakan SLO untuk faktor individu seperti cacat kode, masalah penskalaan, dan pertimbangan terkait kode lainnya.

  SLO komposit berdasarkan kode dan ketersediaan data: 99,86% per bulan.

• SLO konfigurasi sumber daya dan aplikasi: Tim mengenali bahwa sumber daya cloud dan kode aplikasi harus dikonfigurasi dengan benar. Target ini termasuk menyiapkan aturan penskalaan otomatis, menyebarkan aturan NSG, dan memilih ukuran SKU yang benar. Untuk memperhitungkan kesalahan konfigurasi, mereka menganggarkan waktu henti bulanan selama 10 menit, yaitu ketersediaan sekitar 99,98%.

  SLO komposit berdasarkan ketersediaan konfigurasi: 99,95% per bulan.

• Operasi SLO: Tim beban kerja mengembangkan budaya DevOps yang baik dengan mengikuti prinsip Kerangka Kerja Yang Dirancang Dengan Baik untuk Keunggulan Operasional. Mereka menyebarkan sumber daya cloud, konfigurasi, dan kode setiap sprint.

  Tim menganggap penyebaran sebagai risiko karena dapat merusak sistem yang sedang berjalan. Mungkin ada kesalahan sebagai akibat dari pembaruan sertifikat TLS, perubahan DNS, atau kesalahan alat. Tim juga mempertimbangkan potensi waktu henti yang disebabkan oleh perbaikan darurat. Mereka menganggarkan total 20 menit waktu henti bulanan, yang ketersediaannya sekitar 99,95%.

  Jendela pemeliharaan adalah periode waktu yang ditentukan selama pemeliharaan atau pembaruan sistem terjadi. API sebagian besar tidak digunakan selama sekitar empat jam setiap hari. Untuk mengurangi risiko tidak tersedia, tim dapat menjadwalkan tugas pemeliharaan selama jam yang kurang aktif tersebut. Pendekatan ini mengarah ke SLO yang lebih tinggi, tetapi tim memutuskan untuk tidak menyertakan jendela pemeliharaan sebagai bagian dari SLO mereka.

  SLO komposit berdasarkan ketersediaan operasi: 99,95% per bulan.

• Dependensi eksternal SLO: Tim menganggap SQL Managed Instance sebagai dependensi utama, yang sudah memiliki ketersediaan 99,80% yang diperhitungkan dalam ketersediaan platform secara keseluruhan. Tidak ada dependensi eksternal lain yang dipertimbangkan.

  SLO komposit berdasarkan dependensi eksternal: Tidak berlaku.

Tentukan hasil SLO komposit keseluruhan

Target SLO komposit keseluruhan ditetapkan pada 99,45%, yang setara dengan sekitar empat jam waktu henti per bulan.

Untuk memenuhi target SLO hanya empat jam tidak tersedia per bulan, tim beban kerja menetapkan rotasi saat panggilan. Dukungan pelanggan dan pemantauan transaksi sintetis dapat memanggil dukungan rekayasa keandalan situs panggilan (SRE) untuk segera memulai langkah-langkah pemulihan untuk mengatasi masalah SLO.

Mengatur SLA beban kerja

SLA untuk beban kerja adalah ketersediaan 99,90% per bulan.

Departemen hukum dan keuangan tim beban kerja menetapkan SLA untuk beban kerja pada ketersediaan 99,90% per bulan, yang melebihi target SLO 99,45%. Mereka membuat keputusan ini setelah menganalisis pembayaran keuangan versus proyeksi pertumbuhan pelanggan berdasarkan SLA yang menarik. SLA mencakup dua alur pengguna inti dan mencakup pertimbangan performa, bukan hanya ketersediaan. Ini adalah risiko terhitung yang diambil oleh tim bisnis untuk menguntungkan bisnis, dan tim teknik menyadari komitmen tersebut.

Mengatur SLO kebenaran

Alur pengguna inti aplikasi harus tersedia dan dapat digunakan, atau bahkan kompetitif, responsif. Tim menetapkan waktu respons SLO khusus untuk API, tidak termasuk waktu pemrosesan klien dan traversal jaringan internet. Mereka mengevaluasi SLO ini hanya selama periode ketersediaan. Mereka memilih persentil ke-75 sebagai target SLO dan pengukuran performa, yang menangkap pengalaman pelanggan umum dan mengecualikan skenario terburuk.

Tautan terkait

Pemodelan kesehatan dan pengamatan beban kerja misi penting di Azure

Daftar periksa keandalan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keandalan