# 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 bandwidth jaringan yang memadai untuk pusat data Anda. Dengan AWS, sebagian besar persyaratan mendasar ini sudah digabungkan atau ditangani sesuai kebutuhan. Cloud dirancang agar menjadi hampir tidak terbatas, sehingga AWS bertanggung jawab untuk memenuhi persyaratan jaringan dan kapasitas komputasi yang memadai, yang mengizinkan Anda 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 Service Quotas? | | --- | | Untuk arsitektur beban kerja berbasis cloud, ada Service Quotas (kuota layanan) (yang juga disebut sebagai batas layanan). Kuota ini ada untuk mencegah penyediaan sumber daya lebih yang tidak disengaja melebihi kebutuhan Anda dan untuk membatasi tingkat permintaan di operasi API sehingga melindungi layanan dari penyalahgunaan. Ada juga kendala-kendala sumber daya, misalnya, laju Anda dapat mendorong bit di kabel serat optik, atau jumlah penyimpanan di diska secara fisik. | | REL 2:  Bagaimana cara merencanakan topologi jaringan Anda? | | --- | | Sering kali beban kerja ada di beberapa lingkungan. Ini termasuk beberapa lingkungan cloud (baik yang dapat diakses publik maupun privat) dan kemungkinan infrastruktur pusat data Anda yang ada sekarang. Rencana harus mencakup pertimbangan jaringan seperti konektivitas di dalam dan antarsistem, pengelolaan alamat IP publik, pengelolaan 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 gunakan. AWS SDK menyediakan API dengan bahasa khusus untuk layanan-layanan AWS, sehingga pengodean menjadi lebih mudah. SDK ini, dengan pilihan banyak bahasa, memperkenankan para developer 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 andal dan dapat diskalakan dengan mudah menggunakan arsitektur berorientasi layanan (SOA) atau arsitektur layanan mikro. Arsitektur berorientasi layanan (SOA) adalah praktik untuk membuat komponen perangkat lunak dapat digunakan ulang lewat antarmuka layanan. Arsitektur layanan mikro melangkah lebih jauh untuk 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 terlepas latensi atau hilangnya data yang terjadi di jaringan-jaringan ini. Komponen dari sistem terdistribusi harus beroperasi dengan cara yang tidak secara negatif memengaruhi beban kerja atau komponen-komponen lain. Berbagai 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 terlepas latensi atau hilangnya data pada jaringan-jaringan ini. Komponen dari sistem terdistribusi harus beroperasi dengan cara yang tidak secara negatif memengaruhi beban kerja atau komponen-komponen lain. Berbagai praktik terbaik ini memungkinkan beban kerja bertahan dari stres atau kegagalan, lebih cepat pulih darinya, dan memitigasi dampak gangguan tersebut. Hasilnya yakni peningkatan dalam 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 ini mencakup semua hal yang terjadi pada beban kerja seperti lonjakan permintaan, dan juga perubahan-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 memasukkan server tambahan seiring dengan bertambahnya pengguna dalam beban kerja. Anda dapat mengatur pemberian izin terkait siapa 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 luar biasa untuk mendapatkan wawasan mengenai kondisi beban kerja Anda. Anda dapat mengonfigurasikan beban kerja Anda untuk memantau log dan metrik serta mengirimkan notifikasi ketika ambang batas terlampaui atau ada peristiwa signifikan yang terjadi. Pemantauan memungkinkan beban kerja Anda untuk mengenali ketika ambang batas kinerja rendah terlampaui atau ada kegagalan yang terjadi, sehingga pemulihan dapat terjadi secara otomatis untuk menanggapinya. | | 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 mengeluarkan sumber daya secara otomatis sehingga sangat sesuai dengan permintaan saat ini pada titik waktu tertentu. | | REL 8:  Bagaimana cara mengimplementasikan perubahan? | | --- | | Perubahan terkontrol diperlukan untuk melakukan deployment fungsionalitas baru, dan untuk memverifikasi 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, maka akan sulit untuk memprediksi efek dari perubahan-perubahan tersebut, atau untuk mengatasi masalah yang timbul sebagai akibatnya. | Ketika Anda merancang beban kerja agar otomatis menambahkan dan menghapus sumber daya sebagai respons atas perubahan permintaan, ini tidak hanya meningkatkan keandalan, tetapi juga memvalidasi bahwa keberhasilan bisnis tidak akan menambah beban. Dengan menerapkan pemantauan, tim Anda secara otomatis dapat mengetahui ketika KPI menyimpang dari perilaku yang diharapkan. Pencatatan otomatis log perubahan lingkungan memperkenankan Anda mengaudit dan dengan cepat mengidentifikasi tindakan yang mungkin berdampak terhadap keandalan. Kendali dalam manajemen perubahan akan memastikan bahwa Anda dapat menerapkan aturan untuk memberikan keandalan yang Anda butuhkan. # Manajemen kegagalan Dalam sistem apa pun yang memiliki kompleksitas wajar, kegagalan biasanya 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 menginisiasi tindakan otomatis untuk memperbaiki masalahnya. 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 menjalankan versi sementara dari keseluruhan sistem 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 Anda untuk sasaran waktu pemulihan (RTO) dan sasaran titik pemulihan (RPO). | | REL 10:  Bagaimana cara menggunakan isolasi kesalahan untuk melindungi beban kerja Anda? | | --- | | Isolasi kesalahan membatasi dampak kegagalan komponen atau sistem ke batas yang ditentukan. Dengan isolasi yang baik, komponen-komponen yang ada di luar batas ini tidak terpengaruh oleh kegagalan. Menjalankan beban kerja Anda di beberapa batas isolasi kesalahan dapat membuatnya lebih tahan terhadap kegagalan. | | REL 11:  Bagaimana cara mendesain beban kerja Anda agar bertahan dalam kegagalan komponen? | | --- | | Beban kerja yang membutuhkan ketersediaan tinggi dan waktu rata-rata untuk pemulihan (MTTR) rendah harus didesain dan dikonfigurasi agar tangguh. | | REL 12:  Bagaimana cara menguji keandalan? | | --- | | Setelah Anda mendesain beban kerja Anda agar tangguh terhadap tekanan produksi, pengujian adalah satu-satunya cara untuk memverifikasi bahwa beban kerja akan beroperasi sesuai desain, dan memberikan ketangguhan yang Anda harapkan. | | REL 13:  Bagaimana cara merencanakan pemulihan bencana (DR)? | | --- | | Memiliki cadangan dan komponen beban kerja berlebih adalah permulaan dari strategi DR Anda. [RTO dan RPO adalah sasaran](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) pemulihan beban kerja Anda. Tetapkan ini berdasarkan kebutuhan bisnis. Implementasikan sebuah strategi untuk memenuhi tujuan-tujuan ini, sambil mempertimbangkan lokasi dan fungsi data dan sumber daya beban kerja. Probabilitas gangguan dan biaya pemulihan juga merupakan faktor penting yang akan membantu menginformasikan nilai bisnis dari penyediaan pemulihan bencana untuk beban kerja. | Cadangkan data dan uji file cadangan Anda secara rutin untuk memastikan bahwa Anda dapat melakukan pemulihan dari kesalahan fisik dan logis. 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 secara aktif KPI, dan juga 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 dijalankan dengan baik sebagaimana proses produksi normal Anda.