Rekomendasi untuk menentukan target keandalan

Berlaku untuk rekomendasi daftar periksa Keandalan yang Dirancang dengan Baik ini Power Platform :

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

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

Target ditingkatkan melalui pemantauan dan pengujian. Bekerja sama dengan pemangku kepentingan internal Anda untuk menetapkan ekspektasi yang realistis untuk keandalan. Latihan ini juga akan membantu pemangku kepentingan mendukung pilihan desain arsitektur Anda dan memahami bahwa Anda merancang untuk memenuhi target yang Anda sepakati dengan sebaik-baiknya.

Microsoft Power Platform menangani sebagian besar masalah ketersediaan dan keandalan tingkat infrastruktur untuk Anda. Namun, ketersediaan beban kerja yang Anda bangun adalah tanggung jawab bersama. Penting untuk dipahami bahwa bahkan dengan komitmen Microsoft terhadap ketersediaan tinggi, risiko waktu henti sistem tidak pernah nol.

Pertimbangkan untuk menggunakan metrik berikut untuk mengukur persyaratan bisnis.

Istilah	Devinisi
Tujuan tingkat layanan (SLO)	Target persentase yang mewakili kesehatan komponen dan tingkat keandalan. Semakin tinggi tingkatannya, semakin andal komponennya. SLO komposit mewakili target agregat dari seluruh beban kerja dan memperhitungkan SLO komponen.
Indikator tingkat layanan (SLI)	Metrik yang dipancarkan oleh layanan. Metrik SLI digabungkan untuk mengukur nilai SLO.
Perjanjian tingkat layanan (SLA)	Perjanjian kontrak antara penyedia layanan dan pelanggan layanan. Perjanjian tersebut mendefinisikan SLO. Kegagalan untuk memenuhi perjanjian dapat menimbulkan konsekuensi finansial bagi penyedia layanan.
Waktu rata-rata untuk pulih (MTTR)	Waktu yang dibutuhkan untuk memulihkan komponen setelah kegagalan terdeteksi.
Waktu rata-rata antara kegagalan (MTBF)	Durasi di mana beban kerja dapat melakukan fungsi yang diharapkan tanpa gangguan, hingga gagal.
Tujuan waktu pemulihan (RTO)	Waktu maksimum yang dapat diterima bahwa aplikasi 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 sistem. Identifikasi dan nilai alur tersebut berdasarkan seberapa penting alur tersebut terhadap kebutuhan Anda. Gunakan nilai untuk mendorong desain beban kerja Anda dalam hal operasi arsitektur, peninjauan, pengujian, dan manajemen insiden. Kegagalan untuk memenuhi target akan mempengaruhi bisnis di luar tingkat toleransi.

Strategi desain utama

Diskusi teknis seharusnya tidak mendorong cara Anda menentukan target keandalan untuk alur penting Anda. Sebaliknya, pemangku kepentingan bisnis harus fokus pada kebutuhan mereka dan harapan pengguna akhir dari beban kerja. Pakar teknis membantu pemangku kepentingan menetapkan nilai numerik realistis yang memenuhi persyaratan tersebut. Dengan bertukar informasi, para ahli teknis memungkinkan diskusi dan kesepakatan tentang SLO yang layak.

Pertimbangkan contoh cara memetakan persyaratan ke nilai numerik yang terukur. Pemangku kepentingan memperkirakan bahwa untuk aliran pengguna yang penting, satu jam waktu henti selama jam kerja reguler menghasilkan hilangnya pendapatan bulanan sebesar X dolar. Jumlah dolar itu dibandingkan dengan perkiraan biaya merancang aliran yang memiliki ketersediaan SLO 99,95 persen, bukan 99,9 persen. Pembuat keputusan harus mendiskusikan apakah risiko kehilangan pendapatan itu lebih besar daripada biaya tambahan dan beban manajemen yang diperlukan untuk melindungi terhadapnya.

Ikuti pola ini saat Anda memeriksa alur dan membuat daftar lengkap target.

Ingatlah 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 serta metrik yang berkorelasi mungkin mencakup, 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 penting mana yang terlibat dalam target tersebut. Kemudian Anda dapat mempertimbangkan target tingkat komponen.

Metrik ketersediaan

Target ketersediaan sesuai dengan metrik SLO, SLA, dan SLI.

SLO dan SLA

Metrik ketersediaan berkorelasi dengan SLO, 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 bahwa Anda dapat memenuhi target SLO, tinjau SLA Microsoft untuk setiap komponen.

Untuk menetapkan SLO Anda, pikirkan tentang:

• Persyaratan non-fungsional beban kerja Anda (misalnya, tingkat permintaan puncak, pengguna bersamaan) selama 1-2 tahun ke depan.

• Metrik yang tersedia tentang apa yang dapat Anda ukur, selama periode waktu tertentu. Data ini akan menginformasikan SLI apa yang harus ditentukan.

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

Mendefinisikan SLO yang tepat membutuhkan waktu dan pertimbangan yang cermat. Pemangku kepentingan bisnis harus memahami toleransi keandalan. Umpan balik ini harus menginformasikan target.

Nilai SLA

Tabel berikut menentukan 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

Saat Anda berpikir tentang SLA komposit dalam konteks alur pengguna dan sistem, ingatlah bahwa alur pengguna dan sistem yang berbeda memiliki definisi kekritisan yang berbeda. Pertimbangkan perbedaan ini saat Anda membuat SLA komposit Anda. Alur nonkritis mungkin memiliki komponen yang harus Anda hilangkan dari perhitungan karena tidak memengaruhi pengalaman pelanggan jika tidak tersedia sebentar.

SLI

Pikirkan SLI sebagai metrik tingkat komponen yang berkontribusi pada SLO. SLI yang paling signifikan adalah yang memengaruhi aliran kritis Anda dari sudut pandang pelanggan Anda. Untuk banyak alur, SLI menyertakan latensi, throughput, tingkat kesalahan, dan ketersediaan. SLI yang baik membantu Anda mengidentifikasi kapan SLO berisiko dilanggar. Korelasikan SLI dengan pelanggan tertentu jika memungkinkan.

Untuk menghindari pengumpulan metrik yang tidak berguna, batasi jumlah SLI untuk setiap alur. Bidik tiga SLI per aliran 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 yang 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 aspirasional dengan pemangku kepentingan dan pastikan bahwa desain arsitektur Anda mendukung target pemulihan sebaik pemahaman Anda. Komunikasikan dengan jelas kepada pemangku kepentingan bahwa setiap bagian beban kerja yang tidak diuji secara menyeluruh untuk metrik pemulihan seharusnya tidak memiliki SLA yang dijamin. Pastikan pemangku kepentingan memahami bahwa target pemulihan dapat berubah seiring waktu saat beban kerja diperbarui. Beban kerja dapat menjadi lebih kompleks saat Anda mengadopsi teknologi baru untuk meningkatkan pengalaman pengguna. 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. Jika Anda menentukan target untuk metrik ini, hanya mencakup komponen yang berada di bawah kendali Anda.

Membangun model kesehatan

Gunakan data yang Anda kumpulkan untuk target keandalan Anda untuk membangun model kesehatan Anda untuk setiap beban kerja dan alur penting terkait. Model kesehatan mendefinisikan status sehat, terdegradasi, dan tidak sehat* untuk alur dan beban kerja. Negara bagian memastikan prioritas operasional yang tepat. 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 mengetahui kapan status alur berubah dari sehat menjadi terdegradasi atau tidak sehat.

Cara Anda menentukan status sehat, terdegradasi, dan tidak sehat bergantung pada target keandalan Anda. Berikut adalah beberapa contoh cara Anda dapat mendefinisikan status:

• Keadaan hijau atau sehat menunjukkan bahwa persyaratan dan target nonfungsional utama sepenuhnya terpenuhi dan bahwa sumber daya digunakan secara optimal.

• Status kuning atau terdegradasi menunjukkan bahwa satu atau beberapa komponen alur memperingatkan terhadap ambang batas yang ditentukan, tetapi alur 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 menjadi tidak tersedia.

Catatan

Model kesehatan seharusnya tidak memperlakukan semua kegagalan dengan sama. Model kesehatan harus membedakan antara kesalahan sementara dan nontransien . Ini harus dengan jelas membedakan antara kegagalan yang diharapkan sementara tetapi dapat dipulihkan dan keadaan bencana yang sebenarnya.

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

Untuk panduan terperinci tentang konfigurasi pemantauan dan pemberitahuan, lihat panduan pemantauan kesehatan.

Visualisasi

Untuk memberi tahu tim operasi dan pemangku kepentingan beban kerja Anda 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 hargai dan mudah dikonsumsi. Mereka mungkin juga ingin melihat laporan yang dihasilkan mingguan, bulanan, atau triwulanan.

Power Platform Fasilitasi

Power Platform SLA memberikan 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.

Power Platform SLA mencakup prosedur untuk mendapatkan kredit layanan jika SLA tidak terpenuhi, bersama dengan definisi ketersediaan untuk setiap layanan. Aspek SLA itu bertindak sebagai kebijakan penegakan hukum.

Microsoft Business Applications menyediakan kemampuan Kelangsungan Bisnis dan Pemulihan Bencana (BCDR) ke semua lingkungan jenis produksi dalam aplikasi Dynamics 365 dan Power Platform SaaS. Pelajari cara Microsoft memastikan data produksi Anda tangguh selama pemadaman regional.

Penyelarasan organisasi

Cloud Adoption Framework memberikan panduan untuk rekomendasi SLO dan SLI yang terkait dengan pemantauan di seluruh organisasi.

Untuk informasi selengkapnya, lihat SLO pemantauan cloud.

Daftar periksa keandalan

Lihat rangkaian lengkap rekomendasi.

Daftar periksa keandalan