REL11-BP06 Kirim pemberitahuan saat acara memengaruhi ketersediaan - AWS Kerangka Well-Architected
Panduan implementasi Sumber daya

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

REL11-BP06 Kirim pemberitahuan saat acara memengaruhi ketersediaan

Notifikasi dikirimkan setelah pelanggaran ambang batas terdeteksi, bahkan apabila peristiwa yang menyebabkan masalah tersebut sudah diatasi secara otomatis.

Pemulihan otomatis menjadikan beban kerja Anda andal. Namun demikian, kemampuan ini juga menyembunyikan masalah dasar yang perlu diatasi. Implementasikan pemantauan peristiwa yang baik agar Anda dapat mendeteksi setiap pola masalah, termasuk masalah-masalah yang ditangani oleh pemulihan otomatis, sehingga Anda dapat mengatasi akar penyebab masalahnya.

Sistem yang tangguh dirancang sedemikian rupa sehingga setiap terjadi peristiwa degradasi langsung dikomunikasikan kepada tim yang tepat. Notifikasi ini harus dikirim melalui satu atau banyak saluran komunikasi.

Hasil yang diinginkan: Peringatan segera dikirim ke tim operasi ketika ambang batas dilanggar, seperti tingkat kesalahan, latensi, atau metrik indikator kinerja kunci penting lainnya (KPI), sehingga masalah ini diselesaikan sesegera mungkin dan dampak pengguna dihindari atau diminimalkan.

Anti-pola umum:

  • Mengirimkan terlalu banyak alarm.

  • Mengirimkan alarm yang tidak dapat ditindaklanjuti.

  • Mengatur ambang alarm terlalu tinggi (terlalu sensitif) atau terlalu rendah (kurang sensitif).

  • Tidak mengirimkan alarm untuk dependensi eksternal.

  • Tidak mempertimbangkan kegagalan abu-abu saat merancang pemantauan dan alarm.

  • Melakukan otomatisasi pemulihan, tetapi tidak memberikan notifikasi kepada tim yang tepat bahwa pemulihan diperlukan.

Manfaat membangun praktik terbaik ini: Pemberitahuan pemulihan membuat tim operasional dan bisnis sadar akan degradasi layanan sehingga mereka dapat segera bereaksi untuk meminimalkan waktu rata-rata untuk mendeteksi (MTTD) dan waktu rata-rata untuk memperbaiki (MTTR). Notifikasi peristiwa pemulihan juga menjamin bahwa Anda tidak mengabaikan masalah yang jarang terjadi.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Sedang. Kegagalan mengimplementasikan mekanisme pemantauan dan notifikasi peristiwa secara tepat dapat mengakibatkan terjadinya kegagalan dalam mendeteksi pola masalah, termasuk masalah yang ditangani oleh pemulihan otomatis. Sebuah tim hanya akan menyadari adanya degradasi sistem ketika pengguna menghubungi layanan pelanggan atau secara kebetulan.

Panduan implementasi

Saat menetapkan strategi pemantauan, alarm yang dipicu adalah sebuah peristiwa umum. Peristiwa ini kemungkinan berisi pengidentifikasi untuk alarm, status alarm (seperti IN ALARM dan OK), dan detail tentang apa yang memicunya. Dalam banyak kasus, sebuah peristiwa alarm seharusnya dideteksi dan email notifikasi dikirimkan. Ini adalah contoh tindakan pada alarm. Notifikasi alarm sangat penting dalam hal observabilitas karena notifikasi ini memberi tahu orang yang tepat bahwa ada masalah. Namun demikian, ketika tindakan terhadap peristiwa sudah matang di dalam solusi observabilitas Anda, tindakan tersebut dapat secara otomatis memperbaiki masalah tanpa memerlukan campur tangan manusia.

Setelah alarm KPI pemantauan ditetapkan, peringatan harus dikirim ke tim yang sesuai ketika ambang batas terlampaui. Peringatan tersebut juga dapat digunakan untuk memicu proses otomatis yang akan mencoba memperbaiki degradasi.

Untuk pemantauan ambang batas yang lebih kompleks, alarm gabungan harus dipertimbangkan. Alarm komposit menggunakan sejumlah alarm KPI pemantauan untuk membuat peringatan berdasarkan logika bisnis operasional. CloudWatchAlarm dapat dikonfigurasi untuk mengirim email, atau untuk mencatat insiden di sistem pelacakan insiden pihak ketiga menggunakan SNS integrasi Amazon atau Amazon. EventBridge

Langkah-langkah implementasi

Buat berbagai jenis alarm berdasarkan cara yang digunakan untuk memantau beban kerja, seperti:

  • Alarm aplikasi digunakan untuk mendeteksi ketika ada bagian dari beban kerja Anda yang tidak berfungsi dengan baik.

  • Alarm infrastruktur menunjukkan kapan Anda harus menskalakan sumber daya. Alarm dapat ditampilkan secara visual di dasbor, mengirim peringatan melalui Amazon SNS atau email, dan bekerja dengan Auto Scaling untuk menskalakan sumber daya beban kerja masuk atau keluar.

  • Alarm statis dapat dibuat untuk memantau ketika sebuah metrik melanggar ambang batas statis selama periode evaluasi tertentu.

  • Alarm gabungan dapat memperhitungkan alarm-alarm kompleks dari berbagai sumber.

  • Setelah alarm dibuat, buatlas peristiwa-peristiwa notifikasi yang sesuai. Anda dapat langsung memanggil Amazon SNS API untuk mengirim pemberitahuan dan menautkan otomatisasi apa pun untuk remediasi atau komunikasi.

  • Integrasikan pemantauan Amazon Health Aware untuk memungkinkan pemantauan visibilitas ke AWS sumber daya yang mungkin mengalami degradasi. Untuk beban kerja penting bisnis, solusi ini menyediakan akses ke peringatan proaktif dan real-time untuk layanan. AWS

Sumber daya

Praktik terbaik Well-Architected terkait:

Dokumen terkait:

Alat terkait: