Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Tahap 1: Tetapkan tujuan
Memahami tingkat ketahanan apa yang dibutuhkan dan bagaimana Anda akan mengukurnya adalah dasar untuk tahap tujuan yang ditetapkan. Sulit untuk meningkatkan sesuatu jika Anda tidak memiliki tujuan dan Anda tidak dapat mengukurnya.
Tidak semua aplikasi membutuhkan tingkat ketahanan yang sama. Ketika Anda menetapkan tujuan, pertimbangkan tingkat yang diperlukan untuk melakukan investasi dan trade-off yang benar. Analogi yang bagus untuk ini adalah mobil: Ini memiliki empat ban tetapi hanya membawa satu ban serep. Peluang mendapatkan beberapa ban kempes selama perjalanan rendah, dan memiliki suku cadang tambahan dapat menghilangkan fitur lain, seperti ruang kargo atau efisiensi bahan bakar, jadi ini adalah trade-off yang masuk akal.
Setelah Anda menentukan tujuan, Anda menerapkan kontrol observabilitas di tahap selanjutnya (Tahap 2: desain dan implementasi dan Tahap 4: Operasikan) untuk memahami apakah tujuan terpenuhi.
Pemetaan aplikasi penting
Mendefinisikan tujuan ketahanan seharusnya tidak secara eksklusif menjadi percakapan teknis. Sebaliknya, mulailah dengan fokus berorientasi bisnis untuk memahami apa yang harus diberikan aplikasi dan konsekuensi dari penurunan nilai. Pemahaman tentang tujuan bisnis ini kemudian mengalir ke bidang-bidang seperti arsitektur, teknik, dan operasi. Tujuan ketahanan apa pun yang Anda tetapkan dapat diterapkan pada semua aplikasi Anda, tetapi cara tujuan diukur seringkali bervariasi tergantung pada fungsi aplikasi. Anda mungkin menjalankan aplikasi yang penting untuk bisnis, dan jika aplikasi ini terganggu, organisasi Anda dapat kehilangan pendapatan yang signifikan atau menderita kerugian reputasi. Sebagai alternatif, Anda mungkin memiliki aplikasi lain yang tidak terlalu penting dan dapat mentolerir beberapa downtime tanpa berdampak negatif pada kemampuan organisasi Anda untuk melakukan bisnis.
Sebagai contoh, pikirkan aplikasi manajemen pesanan untuk perusahaan ritel. Jika komponen aplikasi manajemen pesanan terganggu dan tidak berjalan dengan baik, penjualan baru tidak akan berhasil. Perusahaan ritel ini juga memiliki kedai kopi untuk karyawannya yang berlokasi di salah satu bangunannya. Kedai kopi memiliki menu online yang dapat diakses karyawan di halaman web statis. Jika halaman web ini menjadi tidak tersedia, beberapa karyawan mungkin mengeluh, tetapi itu tidak akan menyebabkan kerugian finansial bagi perusahaan. Berdasarkan contoh ini, bisnis kemungkinan akan memilih untuk memiliki tujuan ketahanan yang lebih agresif untuk aplikasi manajemen pesanan tetapi tidak akan melakukan investasi yang signifikan untuk memastikan ketahanan aplikasi web.
Mengidentifikasi aplikasi yang paling penting, di mana harus menerapkan upaya paling banyak, dan di mana melakukan trade-off sama pentingnya dengan mampu mengukur ketahanan aplikasi dalam produksi. Untuk lebih memahami dampak penurunan nilai, Anda dapat melakukan analisis dampak bisnis (BIA). BIA menyediakan pendekatan terstruktur dan sistematis untuk mengidentifikasi dan memprioritaskan aplikasi bisnis penting, menilai potensi risiko dan dampak, dan mengidentifikasi dependensi pendukung. BIA membantu mengukur biaya downtime untuk aplikasi terpenting organisasi Anda. Metrik ini membantu menguraikan berapa biayanya jika aplikasi tertentu terganggu dan tidak dapat menyelesaikan fungsinya. Pada contoh sebelumnya, jika aplikasi manajemen pesanan terganggu, bisnis ritel bisa kehilangan pendapatan yang signifikan.
Memetakan cerita pengguna
Selama proses BIA, Anda mungkin menemukan bahwa aplikasi bertanggung jawab atas lebih dari satu fungsi bisnis, atau bahwa fungsi bisnis memerlukan banyak aplikasi. Menggunakan contoh perusahaan ritel sebelumnya, fungsi manajemen pesanan mungkin memerlukan aplikasi terpisah untuk checkout, promosi, dan harga. Jika salah satu aplikasi gagal, dampaknya bisa dirasakan oleh bisnis dan oleh pengguna yang berinteraksi dengan perusahaan. Misalnya, perusahaan mungkin tidak dapat menambahkan pesanan baru, memberikan akses ke promosi dan diskon, atau memperbarui harga produk mereka. Fungsi berbeda yang diperlukan oleh fungsi manajemen pesanan ini mungkin bergantung pada beberapa aplikasi. Fungsi-fungsi ini mungkin juga memiliki beberapa dependensi eksternal, yang membuat proses mencapai ketahanan yang berfokus pada komponen murni terlalu kompleks. Cara yang lebih baik untuk menangani skenario ini adalah dengan fokus pada cerita pengguna
Berfokus pada cerita pengguna membantu Anda memahami bagian mana dari pengalaman pelanggan yang paling penting, sehingga Anda dapat membangun mekanisme untuk melindungi terhadap ancaman tertentu. Pada contoh sebelumnya, satu cerita pengguna bisa berupa checkout, yang melibatkan aplikasi checkout dan memiliki ketergantungan pada aplikasi penetapan harga. Kisah pengguna lain bisa melihat promosi, yang melibatkan aplikasi promosi. Setelah Anda memetakan aplikasi yang paling penting dan cerita pengguna mereka, Anda dapat mulai menentukan metrik yang akan Anda gunakan untuk mengukur ketahanan untuk cerita pengguna ini. Metrik ini dapat diterapkan di seluruh portofolio atau ke cerita pengguna individu.
Mendefinisikan pengukuran
Tujuan titik pemulihan (RPO), tujuan waktu pemulihan (RTO), dan tujuan tingkat layanan (SLO) adalah pengukuran industri standar yang digunakan untuk menilai ketahanan sistem tertentu. RPO mengacu pada seberapa banyak kehilangan data yang dapat ditoleransi bisnis jika terjadi kegagalan, sedangkan RTO adalah ukuran seberapa cepat aplikasi harus tersedia lagi setelah pemadaman. Kedua metrik ini diukur dalam satuan waktu: detik, menit, dan jam. Anda juga dapat mengukur jumlah waktu selama aplikasi berfungsi dengan baik; yaitu, ia menjalankan fungsinya sebagaimana dirancang dan dapat diakses oleh penggunanya. SLOs ini merinci tingkat layanan yang diharapkan akan diterima pelanggan dan diukur dengan metrik seperti persentase (%) permintaan yang dilayani tanpa kesalahan dalam waktu respons yang kurang dari satu detik (misalnya, 99,99% permintaan akan menerima respons setiap bulan). RPO dan RTO terkait dengan strategi pemulihan bencana, dengan asumsi bahwa akan ada gangguan dalam operasi aplikasi dan proses pemulihan yang berkisar dari memulihkan cadangan hingga mengarahkan lalu lintas pengguna. SLO ditangani dengan menerapkan kontrol ketersediaan tinggi, yang cenderung mengurangi waktu henti untuk suatu aplikasi.
Metrik SLO umumnya digunakan dalam definisi perjanjian tingkat layanan (SLA), yang merupakan kontrak antara penyedia layanan dan pengguna akhir. SLA biasanya datang dengan komitmen keuangan dan menguraikan hukuman yang perlu dibayar oleh penyedia jika perjanjian ini tidak dipenuhi. Namun, SLA bukanlah ukuran postur ketahanan Anda, dan meningkatkan SLA tidak membuat aplikasi Anda lebih tangguh.
Anda dapat mulai menetapkan tujuan Anda berdasarkan SLO, RPO, dan RTO. Setelah Anda menentukan tujuan ketahanan Anda dan mendapatkan pemahaman yang jelas tentang target RPO dan RTO Anda, Anda dapat menggunakan untuk menjalankan penilaian arsitektur Anda AWS Resilience Hub
Membuat pengukuran tambahan
RPO, RTO, dan SLO adalah indikator ketahanan yang baik, tetapi Anda juga dapat memikirkan tujuan dari perspektif bisnis dan menentukan tujuan di sekitar fungsi aplikasi Anda. Misalnya, tujuan Anda adalah: Pesanan yang berhasil per menit akan tetap di atas 98% jika latensi antara frontend dan backend saya meningkat sebesar 40%.Atau: Aliran yang dimulai per detik akan tetap dalam standar deviasi dari rata-rata bahkan jika komponen tertentu hilang. Anda juga dapat membuat tujuan untuk mencapai pengurangan waktu rata-rata untuk memulihkan (MTTR) di seluruh jenis kegagalan yang diketahui; misalnya: Waktu pemulihan akan berkurang sebesar x% jika salah satu dari masalah yang diketahui ini terjadi. Menciptakan tujuan yang selaras dengan kebutuhan bisnis membantu Anda mengantisipasi jenis kegagalan yang harus ditoleransi aplikasi Anda. Ini juga membantu Anda mengidentifikasi pendekatan untuk mengurangi kemungkinan gangguan pada aplikasi Anda.
Jika Anda berpikir tentang tujuan untuk terus beroperasi jika Anda kehilangan 5% dari instance yang memberi daya pada aplikasi Anda, Anda mungkin menentukan bahwa aplikasi Anda harus di-prescaled atau memiliki kemampuan untuk menskalakan cukup cepat untuk mendukung lalu lintas tambahan yang disebabkan selama acara tersebut. Atau, Anda mungkin menentukan bahwa Anda harus memanfaatkan pola arsitektur yang berbeda, seperti yang dijelaskan di Tahap 2: Bagian Desain dan implementasi.
Anda juga harus menerapkan langkah-langkah observabilitas untuk tujuan bisnis spesifik Anda. Misalnya, Anda dapat melacak tingkat pesanan rata-rata, harga pesanan rata-rata, jumlah rata-rata langganan, atau metrik lain yang dapat memberikan wawasan tentang kesehatan bisnis berdasarkan perilaku aplikasi Anda. Dengan menerapkan kemampuan observabilitas untuk aplikasi Anda, Anda dapat membuat alarm dan mengambil tindakan jika metrik ini melebihi batas yang ditentukan. Observabilitas dibahas secara lebih rinci di bagian Tahap 4: Operate.
