REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan - Pilar Keandalan
Panduan implementasi Sumber daya

REL11-BP01 Memantau semua komponen beban kerja untuk mendeteksi kegagalan

Terus pantau kondisi beban kerja agar Anda dan sistem otomatis Anda langsung mengetahui penurunan kualitas atau kegagalan ketika muncul. Pantau indikator kinerja utama (KPI) berdasarkan nilai bisnis.

Semua mekanisme pemulihan dan penyembuhan harus dimulai dengan kemampuan untuk mendeteksi masalah secara cepat. Kegagalan teknis harus dideteksi terlebih dahulu sehingga dapat diatasi. Namun, ketersediaan didasarkan pada kemampuan beban kerja Anda untuk menghadirkan nilai bisnis, sehingga indikator kinerja utama (KPI) yang mengukurnya perlu menjadi bagian dari strategi deteksi dan perbaikan Anda.

Hasil yang diinginkan: Komponen penting dari suatu beban kerja dipantau secara independen untuk mendeteksi dan memperingatkan adanya kegagalan pada saat dan di bagian mana kegagalan tersebut terjadi.

Antipola umum:

  • Tidak ada alarm yang dikonfigurasi, sehingga pemadaman terjadi tanpa notifikasi.

  • Alarm tersedia, tetapi pada ambang batas yang tidak menyediakan waktu yang cukup untuk bereaksi.

  • Metrik tidak dikumpulkan cukup sering untuk memenuhi sasaran waktu pemulihan (RTO).

  • Hanya antarmuka beban kerja yang terlihat oleh pelanggan yang aktif dipantau.

  • Hanya mengumpulkan metrik teknis, dan mengabaikan metrik fungsi bisnis.

  • Tidak ada metrik yang mengukur pengalaman pengguna beban kerja.

  • Terlalu banyak pemantau yang dibuat.

Manfaat menjalankan praktik terbaik ini: Pemantauan yang sesuai di semua lapisan memungkinkan Anda menghemat waktu pemulihan karena berkurangnya waktu deteksi.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Tinggi

Panduan implementasi

Identifikasikan semua beban kerja yang akan ditinjau untuk pemantauan. Setelah Anda mengidentifikasi semua komponen beban kerja yang perlu dipantau, selanjutnya Anda perlu menentukan interval pemantauan. Interval pemantauan akan berdampak langsung pada seberapa cepat pemulihan dapat dimulai berdasarkan waktu yang diperlukan untuk mendeteksi kegagalan. Rata-rata waktu deteksi (MTTD) adalah lamanya waktu antara terjadinya kegagalan dan ketika operasi perbaikan dimulai. Daftar layanan harus luas dan lengkap.

Pemantauan harus mencakup semua lapisan tumpukan aplikasi termasuk aplikasi, platform, infrastruktur, dan jaringan.

Strategi pemantauan Anda harus mempertimbangkan dampak kegagalan abu-abu. Untuk detail lebih lanjut tentang kegagalan abu-abu, lihat Kegagalan abu-abu di laporan resmi Pola Ketangguhan Multi-AZ Lanjutan.

Langkah implementasi

  • Interval pemantauan Anda bergantung pada seberapa cepat Anda harus pulih. Waktu pemulihan Anda didorong oleh waktu yang diperlukan untuk pulih, sehingga Anda harus menentukan frekuensi pengumpulan dengan cara menghitung waktu ini serta sasaran waktu pemulihan (RTO) Anda.

  • Konfigurasikan pemantauan mendetail untuk komponen dan layanan terkelola.

  • Buat metrik kustom untuk mengukur indikator kinerja kunci (KPI) bisnis. Beban kerja mengimplementasikan fungsi-fungsi bisnis utama, yang harus digunakan sebagai KPI yang membantu mengidentifikasi kapan terjadinya masalah tidak langsung.

  • Pantau pengalaman pengguna untuk mendeteksi kegagalan menggunakan canary pengguna. Pengujian transaksi sintetis (juga disebut pengujian canary, tetapi tidak sama dengan deployment canary) yang dapat menjalankan dan menyimulasikan perilaku pelanggan adalah salah satu proses pengujian yang paling penting. Jalankan pengujian ini secara konstan terhadap titik akhir beban kerja Anda dari beragam lokasi jarak jauh.

  • Buat metrik kustom yang melacak pengalaman pengguna. Jika Anda dapat menginstrumentasi pengalaman pelanggan, Anda dapat menentukan saat pengalaman pelanggan mengalami degradasi.

  • Atur alarm untuk mendeteksi saat ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik, dan untuk menunjukkan kapan harus menskalakan sumber daya secara otomatis. Alarm dapat ditampilkan secara visual di dasbor, mengirimkan peringatan melalui Amazon SNS atau email, dan menggunakan Auto Scaling untuk menaikkan atau menurunkan skala sumber daya beban kerja.

  • Buat dasbor untuk memvisualisasikan metrik Anda. Dasbor dapat digunakan untuk melihat tren, penyimpangan, dan indikator potensi masalah lainnya, atau menyediakan penanda untuk masalah yang ingin Anda selidiki.

  • Buat pemantauan penelusuran terdistribusi untuk layanan Anda. Dengan pemantauan terdistribusi, Anda dapat memahami cara kerja aplikasi Anda dan layanan dasar dalam mengidentifikasi dan memecahkan akar masalah dan galat kinerja.

  • Buat dasbor sistem pemantauan (menggunakan CloudWatch atau X-Ray) dan pengumpulan data di Wilayah dan akun terpisah.

  • Buat integrasi untuk pemantauan Amazon Health Aware untuk memungkinkan visibilitas pemantauan ke sumber daya AWS yang mungkin mengalami degradasi. Untuk beban kerja yang penting untuk bisnis, solusi ini menyediakan akses ke peringatan proaktif dan waktu nyata untuk layanan AWS.

Sumber daya

Praktik terbaik terkait:

Dokumen terkait:

Video terkait:

Contoh terkait:

Alat terkait: