# Praktik terbaik **Topics** + [Fondasi](rel-found.md) + [Arsitektur beban kerja](rel-workload-arch.md) + [Manajemen perubahan](rel-chg-mgmt.md) + [Manajemen kegagalan](rel-failmgmt.md) # Fondasi Persyaratan mendasar memiliki cakupan yang lebih luas dari satu beban kerja atau proyek. Sebelum merancang sistem apa pun, persyaratan mendasar yang memengaruhi keandalan harus diterapkan. Misalnya, Anda harus memiliki bandwith jaringan yang memadai untuk pusat data Anda. Dengan AWS, sebagian besar persyaratan mendasar ini sudah digabungkan atau ditangani sesuai kebutuhan. Cloud didesain agar menjadi hampir tidak terbatas, ini adalah tanggung jawab AWS untuk memenuhi persyaratan jaringan dan kapasitas komputasi yang memadai, agar Anda dapat dengan leluasa mengubah alokasi dan ukuran sumber daya sesuai permintaan. Pertanyaan berikut ini berfokus pada semua pertimbangan untuk keandalan. (Untuk melihat daftar pertanyaan keandalan dan praktik terbaik, buka [Lampiran](a-reliability.md).). | REL 1:  Bagaimana cara mengelola pembatasan dan kuota layanan? | | --- | | Untuk arsitektur beban kerja berbasis cloud, terdapat kuota layanan (yang juga disebut sebagai batas layanan). Kuota ini ada agar penyediaan sumber daya tidak melebihi yang Anda butuhkan dan untuk membatasi tingkat permintaan di operasi API serta melindungi layanan dari penyalahgunaan. Selain itu, terdapat beberapa hal yang membatasi sumber daya, misalnya, rasio yang dapat menurunkan bit di kabel serat optik, atau jumlah penyimpanan di dalam disk fisik. | | REL 2:  Bagaimana cara merencanakan topologi jaringan Anda? | | --- | | Beban kerja sering kali ada di beberapa lingkungan. Termasuk beberapa lingkungan cloud (baik yang dapat diakses publik maupun privat) dan kemungkinan juga di infrastruktur pusat data Anda yang ada. Rencana harus mencakup pertimbangan jaringan seperti konektivitas di dalam dan antarsistem, manajemen alamat IP publik, manajemen alamat IP privat, dan resolusi nama domain. | Untuk arsitektur beban kerja berbasis cloud, terdapat kuota layanan (yang juga disebut sebagai batas layanan). Kuota ini ada untuk agar penyediaan sumber daya tidak melebihi yang Anda butuhkan dan untuk membatasi tingkat permintaan di operasi API serta melindungi layanan dari penyalahgunaan. Beban kerja sering kali ada di beberapa lingkungan. Anda harus memantau dan mengelola kuota tersebut untuk semua lingkungan beban kerja. Termasuk beberapa lingkungan cloud (baik yang dapat diakses secara publik maupun privat) dan bisa juga termasuk infrastruktur pusat data Anda yang ada. Rencana harus mencakup pertimbangan jaringan, seperti konektivitas di dalam sistem dan antarsistem, manajemen alamat IP publik, manajemen alamat IP privat, dan resolusi nama domain. # Arsitektur beban kerja Beban kerja yang andal dimulai dengan desain perangkat lunak dan infrastruktur yang diputuskan sejak awal. Pilihan arsitektur Anda akan memengaruhi perilaku beban kerja Anda di semua pilar Well-Architected. Untuk keandalan, terdapat beberapa pola tertentu yang harus diikuti. Dengan AWS, developer beban kerja dapat memilih bahasa dan teknologi yang akan mereka digunakan. SDK AWS menyediakan API dengan bahasa khusus untuk layanan AWS, sehingga pengodean menjadi lebih mudah. SDK ini, dengan pilihan banyak bahasa, memungkinkan developer untuk mengimplementasikan praktik terbaik keandalan yang tercantum di sini. Para developer juga dapat membaca dan belajar dari cara Amazon membangun dan mengoperasikan perangkat lunak, di dalam [Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp). Pertanyaan berikut ini berfokus pada semua pertimbangan untuk keandalan. | REL 3:  Bagaimana cara mendesain arsitektur layanan beban kerja Anda? | | --- | | Bangun beban kerja yang mudah diskalakan dan andal menggunakan arsitektur berorientasi layanan (SOA) atau arsitektur layanan mikro. Arsitektur berorientasi layanan (SOA) merupakan praktik pembuatan komponen perangkat lunak yang dapat digunakan ulang lewat antarmuka layanan. Arsitektur layanan mikro melakukan hal yang lebih dengan membuat komponen menjadi lebih kecil dan lebih sederhana. | | REL 4:  Bagaimana cara mendesain interaksi di dalam sistem terdistribusi untuk mencegah kegagalan? | | --- | | Sistem terdistribusi mengandalkan jaringan komunikasi untuk membuat interkoneksi komponen, seperti server atau layanan. Beban kerja Anda harus beroperasi secara andal walaupun terdapat latensi atau kehilangan data di jaringannya. Komponen sistem terdistribusi harus beroperasi tanpa memberikan dampak secara negatif kepada komponen dan beban kerja yang lain. Praktik terbaik ini mencegah kegagalan dan meningkatkan waktu rata-rata antara kegagalan (MTBF). | | REL 5:  Bagaimana cara mendesain interaksi dalam sistem terdistribusi untuk mitigasi atau bertahan dari kegagalan? | | --- | | Sistem terdistribusi mengandalkan jaringan komunikasi untuk membuat interkoneksi komponen (seperti server atau layanan). Beban kerja Anda harus beroperasi secara andal walaupun terdapat latensi atau kehilangan data di jaringannya. Komponen sistem terdistribusi harus beroperasi tanpa memberikan dampak secara negatif kepada komponen dan beban kerja yang lain. Berbagai praktik terbaik ini memungkinkan beban kerja bertahan dari tekanan atau kegagalan, pulih dengan lebih cepat, serta memitigasi dampak gangguan tersebut. Hasilnya adalah peningkatan waktu rata-rata untuk pemulihan (MTTR). | # Manajemen perubahan Perubahan beban kerja atau lingkungannya harus diantisipasi dan diakomodasi guna mencapai operasi beban kerja yang andal. Perubahan mencakup semua yang terjadi ke beban kerja seperti lonjakan permintaan, serta perubahan dari dalam, seperti deployment fitur dan patch keamanan. Menggunakan AWS, Anda dapat memantau perilaku beban kerja dan mengotomatiskan respons untuk KPI. Misalnya, beban kerja dapat menambahkan server tambahan seiring dengan bertambahnya pengguna dalam beban kerja. Anda dapat mengatur pemberian izin untuk siapa saja yang dapat membuat perubahan beban kerja dan mengaudit riwayat perubahan ini. Pertanyaan berikut ini berfokus pada semua pertimbangan untuk keandalan. | REL 6:  Bagaimana cara memantau sumber daya beban kerja? | | --- | | Log dan metrik merupakan alat yang sangat andal untuk mendapatkan wawasan tentang kondisi beban kerja. Anda dapat mengonfigurasikan beban kerja untuk memantau log dan metrik serta mengirimkan notifikasi ketika ambang batas terlampaui atau terjadi peristiwa yang signifikan. Dengan pemantauan, beban kerja Anda dapat mengidentifikasi saat ambang batas kinerja rendah terlampaui atau kegagalan terjadi, sehingga dapat bereaksi dengan melakukan pemulihan otomatis. | | REL 7:  Bagaimana cara merancang beban kerja Anda agar dapat beradaptasi dengan perubahan dalam permintaan? | | --- | | Beban kerja yang dapat diskalakan memberikan elastisitas untuk menambahkan atau menghapus sumber daya secara otomatis sehingga sangat sesuai dengan permintaan yang sedang berjalan pada titik waktu tertentu. | | REL 8:  Bagaimana cara mengimplementasikan perubahan? | | --- | | Perubahan terkontrol diperlukan untuk melakukan deployment fungsionalitas baru, serta memastikan bahwa beban kerja dan lingkungan operasi menjalankan perangkat lunak yang dikenal dan dapat di-patch atau diganti dengan cara yang dapat diprediksi. Jika perubahan-perubahan ini tidak terkontrol, akan sulit untuk memprediksi efek dari perubahan-perubahan tersebut, atau untuk mengatasi masalah yang ditimbulkannya. | Ketika Anda merancang beban kerja agar otomatis menambahkan dan menghapus sumber daya sebagai respons atas perubahan permintaan, ini tidak hanya meningkatkan keandalan tetapi juga memastikan bahwa keberhasilan bisnis tidak menambah beban. Dengan menerapkan pemantauan, tim Anda secara otomatis dapat mengetahui ketika KPI menyimpang dari perilaku yang diharapkan. Pencatatan otomatis log perubahan lingkungan memungkinkan Anda untuk mengaudit dan dengan cepat mengidentifikasi tindakan yang mungkin berdampak terhadap keandalan. Kontrol dalam manajemen perubahan memastikan bahwa Anda dapat menerapkan aturan untuk memberikan keandalan yang Anda butuhkan. # Manajemen kegagalan Dalam sistem apa pun yang memiliki kompleksitas wajar, kegagalan diperkirakan akan terjadi. Keandalan hanya dapat terwujud jika beban kerja Anda dapat mengidentifikasi kegagalan yang terjadi dan mengambil tindakan untuk menghindari dampaknya terhadap ketersediaan. Beban kerja harus mampu bertahan dari kegagalan serta secara otomatis memperbaiki masalah. Dengan AWS, Anda dapat memanfaatkan otomatisasi untuk memberikan reaksi terhadap data pemantauan. Misalnya, ketika metrik tertentu melewati ambang batas, Anda dapat memicu tindakan otomatis untuk memperbaiki masalah. Selain itu, daripada berupaya untuk mendiagnosis dan memperbaiki sumber daya gagal yang merupakan bagian dari lingkungan produksi, Anda dapat menggantinya dengan yang baru dan melakukan analisis terhadap sumber daya yang gagal tersebut di luar jaringan. Karena cloud memungkinkan Anda untuk menggunakan versi sementara dengan harga yang rendah, Anda dapat menggunakan pengujian otomatis untuk memverifikasi proses pemulihan penuh. Pertanyaan berikut ini berfokus pada semua pertimbangan untuk keandalan. | REL 9:  Bagaimana cara mencadangkan data? | | --- | | Cadangkan data, aplikasi, dan konfigurasi untuk memenuhi persyaratan untuk sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO). | | REL 10:  Bagaimana cara menggunakan isolasi kesalahan untuk melindungi beban kerja Anda? | | --- | | Batas isolasi kesalahan membatasi efek kegagalan di dalam beban kerja untuk jumlah komponen yang terbatas. Komponen di luar batas ini tidak terpengaruh oleh kegagalan tersebut. Dengan beberapa batas isolasi kesalahan, Anda dapat membatasi dampak pada beban kerja Anda. | | REL 11:  Bagaimana cara mendesain beban kerja Anda agar bertahan dalam kegagalan komponen? | | --- | | Beban kerja dengan persyaratan ketersediaan tinggi dan waktu rata-rata untuk pemulihan (MTTR) rendah harus dirancang agar tangguh. | | REL 12:  Bagaimana cara menguji keandalan? | | --- | | Setelah Anda merancang beban kerja agar tangguh terhadap tekanan produksi, pengujian adalah satu-satunya cara untuk memastikan bahwa beban kerja akan beroperasi sesuai desain, dengan ketangguhan yang diharapkan. | | REL 13:  Bagaimana cara merencanakan pemulihan bencana (DR)? | | --- | | Memiliki cadangan dan komponen beban kerja berlebih adalah awal strategi DR Anda. [RTO dan RPO adalah sasaran](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) untuk pemulihan beban kerja Anda. Atur hal ini berdasarkan kebutuhan bisnis. Implementasikan strategi sesuai sasaran ini, dengan mempertimbangkan lokasi dan fungsi data serta sumber daya beban kerja. Probabilitas gangguan dan biaya pemulihan juga merupakan faktor penting yang membantu memahami nilai bisnis dari penyediaan pemulihan bencana untuk beban kerja. | Cadangkan data dan uji file cadangan Anda secara rutin untuk memastikan bahwa Anda dapat memulihkan kesalahan fisik dan logisnya. Kunci untuk mengelola kegagalan adalah pengujian beban kerja secara rutin dan otomatis dengan cara menyebabkan kegagalan, kemudian mengamati bagaimana pemulihan dilakukan. Lakukan hal ini secara terjadwal serta pastikan bahwa pengujian serupa juga dilakukan setelah perubahan beban kerja yang signifikan. Lacak KPI secara aktif, serta sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO), untuk mengukur ketangguhan beban kerja (terutama dalam skenario uji kegagalan). Pelacakan KPI akan membantu Anda mengidentifikasi dan memitigasi titik kegagalan tunggal. Sasarannya adalah untuk menguji secara keseluruhan proses pemulihan beban kerja Anda sehingga Anda yakin bahwa Anda dapat memulihkan semua data dan terus melayani pelanggan, bahkan saat menghadapi masalah yang berlanjut. Proses pemulihan Anda harus terlatih dengan baik sebagaimana proses produksi normal Anda.