Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Tahap 2: Desain dan implementasi
Bagian ini membahas mengubah tujuan ketahanan Anda menjadi kenyataan. Anda telah memetakan apa yang paling penting bagi bisnis Anda, dan sekarang saatnya untuk membangunnya. Bagaimana Anda membangun ketahanan tanpa memperlambat inovasi?
Pikirkan layanan yang AWS dikelola sebagai jalan pintas ketahanan. Alih-alih membakar jam teknik yang berharga untuk memelihara infrastruktur, gunakan layanan yang menangani redundansi untuk Anda. Misalnya, pertimbangkan Amazon Simple Storage Service (Amazon S3). Ini secara otomatis menyimpan beberapa salinan data Anda dalam a Wilayah AWS untuk daya tahan. Itu tidak memerlukan kode tambahan atau tugas pager larut malam.
Bagaimana dengan komponen aplikasi inti Anda? Pilihan cerdas dapat melipatgandakan dampak tim Anda. Pertimbangkan database yang merupakan tulang punggung layanan Anda. Alih-alih membangun sistem replikasi Anda sendiri, pertimbangkan untuk menggunakan Amazon Aurora, yang secara otomatis menangani failover. Fitur-fitur ini mungkin lebih mahal, tetapi mereka mengalihkan fokus tim Anda dari memelihara infrastruktur untuk memecahkan masalah bisnis. Biaya ini dapat diimbangi melalui pengiriman fitur yang lebih cepat dan menghindari kehilangan pendapatan selama pemadaman.
Terkadang startup perlu membangun solusi khusus. Itulah sifat dari startup yang inovatif. Ketika Anda melakukannya, tetap sederhana namun cerdas. Sebarkan aplikasi Anda di beberapa Availability Zone dengan menggunakan Elastic Load Balancing dan grup Amazon EC2 Auto Scaling. Tetapkan kapasitas minimum grup Auto Scaling untuk menangani lalu lintas dasar Anda meskipun salah satu Availability Zone gagal. Ini memberikan ketahanan terhadap kegagalan lokal tanpa pola arsitektur yang kompleks. Ketika startup Anda tumbuh dan pelanggan menuntut ketahanan yang lebih tinggi, Anda dapat berevolusi ke pendekatan yang lebih canggih.
Kami menyarankan Anda menjaga lingkungan produksi dan pengembangan Anda secara terpisah Akun AWS. Sangat menggoda untuk mencampurnya saat Anda bergerak cepat, tetapi batas ini adalah jaring pengaman Anda. Ini mencegah eksperimen yang bermaksud baik dari menjatuhkan layanan produksi Anda. Anggap saja sebagai asuransi untuk budaya pengembangan “bergerak cepat dan hancurkan sesuatu” Anda - hancurkan hal-hal dalam pengembangan, jaga produksi tetap stabil.
Jika aplikasi Anda bergantung pada layanan pihak ketiga, rencanakan kegagalannya. Ketika prosesor pembayaran Anda mengalami masalah, dapatkah sistem Anda menanganinya dengan anggun? Bangun opsi pemutus sirkuit dan fallback sederhana. Mungkin mengantri transaksi tersebut alih-alih menampilkan pesan kesalahan. Pelanggan Anda akan menghargai bahwa Anda membuat semuanya berfungsi, meskipun tidak sempurna.
Dokumentasikan saat Anda membangun, tetapi tetap praktis. Fokus pada merekam alasan di balik keputusan penting, dan buat buku pedoman pemulihan sederhana. Sangat penting untuk menyiapkan ini ketika insiden terjadi.
Anda tidak membangun untuk ketahanan yang sempurna; Anda sedang membangun untuk ketahanan yang tepat. Setiap jam yang dihabiskan untuk ketahanan over-engineering adalah satu jam yang tidak dihabiskan untuk fitur yang diminta pelanggan. Gunakan layanan AWS terkelola sebagai fondasi Anda, tambahkan ketahanan yang ditargetkan di tempat yang paling penting, dan buat jalur yang jelas untuk meningkatkan ketahanan seiring pertumbuhan bisnis Anda.
Bab berikutnya membahas bagaimana memvalidasi pilihan desain ini tanpa membakar sumber daya teknik. Untuk startup, pengujian harus menjadi dorongan yang masuk akal dan investasi cerdas dalam ketahanan aplikasi Anda.
