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

Mengurangi MTTR

Setelah kegagalan ditemukan, sisa MTTR waktu adalah perbaikan atau mitigasi dampak yang sebenarnya. Untuk memperbaiki atau mengurangi kegagalan, Anda harus tahu apa yang salah. Ada dua kelompok kunci metrik yang memberikan wawasan selama fase ini: 1/ metrik Penilaian Dampak dan 2/ metrik Kesehatan Operasional. Kelompok pertama memberi tahu Anda ruang lingkup dampak selama kegagalan, mengukur jumlah atau persentase pelanggan, sumber daya, atau beban kerja yang terkena dampak. Kelompok kedua membantu mengidentifikasi mengapa ada dampak. Setelah mengapa ditemukan, operator dan otomatisasi dapat merespons dan menyelesaikan kegagalan. Lihat Lampiran 1 — MTTD dan metrik MTTR penting untuk informasi lebih lanjut tentang metrik ini.

Rute di sekitar kegagalan

Pendekatan tercepat untuk mengurangi dampak adalah melalui subsistem cepat gagal yang mengelilingi kegagalan. Pendekatan ini menggunakan redundansi untuk mengurangi MTTR dengan cepat menggeser pekerjaan subsistem yang gagal ke cadangan. Redundansi dapat berkisar dari proses perangkat lunak, EC2 instance, hingga beberapa, hingga beberapa AZs Wilayah.

Subsistem cadangan dapat mengurangi MTTR turun menjadi hampir nol. Waktu pemulihan hanya apa yang diperlukan untuk mengalihkan pekerjaan ke cadangan siaga. Ini sering terjadi dengan latensi minimal dan memungkinkan pekerjaan selesai dalam yang ditentukanSLA, menjaga ketersediaan sistem. Ini menghasilkan MTTRs yang dialami sebagai penundaan ringan, bahkan mungkin tidak terlihat, daripada periode tidak tersedianya yang berkepanjangan.

Misalnya, jika layanan Anda menggunakan EC2 instans di belakang Application Load Balancer ALB (), Anda dapat mengonfigurasi pemeriksaan kesehatan pada interval sekecil lima detik dan hanya memerlukan dua pemeriksaan kesehatan yang gagal sebelum target ditandai sebagai tidak sehat. Ini berarti bahwa dalam 10 detik, Anda dapat mendeteksi kegagalan dan berhenti mengirim lalu lintas ke host yang tidak sehat. Dalam hal ini, MTTR secara efektif sama dengan MTTD karena segera setelah kegagalan terdeteksi, itu juga dikurangi.

Inilah yang coba dicapai oleh beban kerja ketersediaan tinggi atau ketersediaan berkelanjutan. Kami ingin dengan cepat merutekan kegagalan dalam beban kerja dengan cepat mendeteksi subsistem yang gagal, menandainya sebagai gagal, berhenti mengirim lalu lintas ke mereka, dan sebagai gantinya mengirim lalu lintas ke subsistem yang berlebihan.

Perhatikan bahwa menggunakan mekanisme fail-fast semacam ini membuat beban kerja Anda sangat sensitif terhadap kesalahan sementara. Dalam contoh yang diberikan, pastikan bahwa pemeriksaan kesehatan penyeimbang beban Anda melakukan pemeriksaan kesehatan dangkal atau aktif dan lokal hanya pada instance, bukan menguji dependensi atau alur kerja (sering disebut sebagai pemeriksaan kesehatan mendalam). Ini akan membantu mencegah penggantian instance yang tidak perlu selama kesalahan sementara yang memengaruhi beban kerja.

Observabilitas dan kemampuan untuk mendeteksi kegagalan dalam subsistem sangat penting untuk perutean di sekitar kegagalan untuk berhasil. Anda harus mengetahui ruang lingkup dampaknya sehingga sumber daya yang terkena dampak dapat ditandai sebagai tidak sehat atau gagal dan dikeluarkan dari layanan sehingga dapat dialihkan. Misalnya, jika satu AZ mengalami gangguan sebagian layanan, instrumentasi Anda harus dapat mengidentifikasi bahwa ada masalah yang dilokalkan AZ untuk merutekan semua sumber daya di AZ tersebut hingga pulih.

Mampu merutekan kegagalan mungkin juga memerlukan perkakas tambahan tergantung pada lingkungan. Menggunakan contoh sebelumnya dengan EC2 contoh di belakangALB, bayangkan bahwa instance dalam satu AZ mungkin melewati pemeriksaan kesehatan lokal, tetapi gangguan AZ yang terisolasi menyebabkan mereka gagal terhubung ke database mereka di AZ yang berbeda. Dalam hal ini, pemeriksaan kesehatan load balancing tidak akan menghilangkan instans tersebut dari layanan. Mekanisme otomatis yang berbeda akan diperlukan untuk menghapus AZ dari penyeimbang beban atau memaksa instans untuk gagal dalam pemeriksaan kesehatan mereka, yang bergantung pada identifikasi bahwa ruang lingkup dampaknya adalah AZ. Untuk beban kerja yang tidak menggunakan penyeimbang beban, metode serupa akan diperlukan untuk mencegah sumber daya di AZ tertentu menerima unit kerja atau menghapus kapasitas dari AZ sama sekali.

Dalam beberapa kasus, pergeseran kerja ke subsistem yang berlebihan tidak dapat diotomatisasi, seperti failover database primer ke sekunder di mana teknologi tidak menyediakan pemilihan pemimpinnya sendiri. Ini adalah skenario umum untuk arsitektur AWS Multi-region. Karena jenis kegagalan ini memerlukan sejumlah waktu henti untuk diselesaikan, tidak dapat segera dibalik, dan membiarkan beban kerja tanpa redundansi untuk jangka waktu tertentu, penting untuk memiliki manusia dalam proses pengambilan keputusan.

Beban kerja yang dapat mencakup model konsistensi yang kurang ketat dapat mencapai yang lebih pendek MTTRs dengan menggunakan otomatisasi failover multi-wilayah untuk mengatasi kegagalan. Fitur seperti replikasi lintas wilayah Amazon S3 atau tabel global Amazon DynamoDB memberikan kemampuan Multi-wilayah melalui replikasi yang konsisten. Selanjutnya, menggunakan model konsistensi santai bermanfaat ketika kita mempertimbangkan CAP teorema. Selama kegagalan jaringan yang memengaruhi konektivitas ke subsistem stateful, jika beban kerja memilih ketersediaan daripada konsistensi, itu masih dapat memberikan respons non-kesalahan, cara lain untuk merutekan kegagalan.

Routing seputar kegagalan dapat diimplementasikan dengan dua strategi yang berbeda. Strategi pertama adalah dengan menerapkan stabilitas statis dengan melakukan pra-penyediaan sumber daya yang cukup untuk menangani beban lengkap subsistem yang gagal. Ini bisa berupa satu EC2 contoh atau mungkin kapasitas seluruh AZ. Mencoba menyediakan sumber daya baru selama kegagalan meningkatkan MTTR dan menambahkan ketergantungan ke bidang kontrol di jalur pemulihan Anda. Namun, itu datang dengan biaya tambahan.

Strategi kedua adalah merutekan sebagian lalu lintas dari subsistem yang gagal ke yang lain dan beban menumpahkan kelebihan lalu lintas yang tidak dapat ditangani oleh kapasitas yang tersisa. Selama periode degradasi ini, Anda dapat meningkatkan sumber daya baru untuk menggantikan kapasitas yang gagal. Pendekatan ini memiliki lebih lama MTTR dan menciptakan ketergantungan pada bidang kontrol, tetapi biaya lebih sedikit dalam siaga, kapasitas cadangan.

Kembali ke keadaan baik yang dikenal

Pendekatan umum lainnya untuk mitigasi selama perbaikan adalah mengembalikan beban kerja ke keadaan baik yang diketahui sebelumnya. Jika perubahan baru-baru ini mungkin menyebabkan kegagalan, memutar kembali perubahan itu adalah salah satu cara untuk kembali ke keadaan sebelumnya.

Dalam kasus lain, kondisi sementara mungkin telah menyebabkan kegagalan, dalam hal ini, memulai kembali beban kerja dapat mengurangi dampaknya. Mari kita periksa kedua skenario ini.

Selama penyebaran, meminimalkan MTTD dan MTTR bergantung pada observabilitas dan otomatisasi. Proses penerapan Anda harus terus memperhatikan beban kerja untuk pengenalan tingkat kesalahan yang meningkat, peningkatan latensi, atau anomali. Setelah ini dikenali, itu harus menghentikan proses penerapan.

Ada berbagai strategi penyebaran, seperti penerapan di tempat, penerapan biru/hijau, dan penerapan bergulir. Masing-masing dari ini mungkin menggunakan mekanisme yang berbeda untuk kembali ke keadaan yang diketahui baik. Ini dapat secara otomatis memutar kembali ke keadaan sebelumnya, mengalihkan lalu lintas kembali ke lingkungan biru, atau memerlukan intervensi manual.

CloudFormation menawarkan kemampuan untuk secara otomatis melakukan rollback sebagai bagian dari membuat dan memperbarui operasi tumpukan, seperti halnya. AWS CodeDeploy CodeDeploy juga mendukung penerapan biru/hijau dan bergulir.

Untuk memanfaatkan kemampuan ini dan meminimalkan kemampuan AndaMTTR, pertimbangkan untuk mengotomatiskan semua infrastruktur dan penyebaran kode Anda melalui layanan ini. Dalam skenario di mana Anda tidak dapat menggunakan layanan ini, pertimbangkan untuk menerapkan pola saga dengan AWS Step Functions untuk mengembalikan penerapan yang gagal.

Saat mempertimbangkan restart, ada beberapa pendekatan berbeda. Mulai dari me-reboot server, tugas terpanjang, hingga memulai ulang utas, tugas terpendek. Berikut adalah tabel yang menguraikan beberapa pendekatan restart dan perkiraan waktu untuk menyelesaikan (mewakili urutan perbedaan besarnya, ini tidak tepat).

Meninjau tabel, ada beberapa manfaat yang jelas untuk MTTR dalam menggunakan wadah dan fungsi tanpa server (seperti). AWS Lambda Mereka MTTR adalah urutan besarnya lebih cepat daripada memulai ulang mesin virtual atau meluncurkan yang baru. Namun, menggunakan isolasi kesalahan melalui modularitas perangkat lunak juga bermanfaat. Jika Anda dapat menahan kegagalan pada satu proses atau utas, memulihkan dari kegagalan itu jauh lebih cepat daripada memulai ulang wadah atau server.

Sebagai pendekatan umum untuk pemulihan, Anda dapat berpindah dari bawah ke atas: 1/Restart, 2/Reboot, 3/Re-image/Redeploy, 4/Replace. Namun, setelah Anda mencapai langkah reboot, merutekan kegagalan biasanya merupakan pendekatan yang lebih cepat (biasanya memakan waktu paling lama 3-4 menit). Jadi, untuk paling cepat mengurangi dampak setelah percobaan restart, rute di sekitar kegagalan, dan kemudian, di latar belakang, lanjutkan proses pemulihan untuk mengembalikan kapasitas ke beban kerja Anda.

Diagnosis kegagalan

Bagian dari proses perbaikan setelah deteksi adalah periode diagnosis. Ini adalah periode waktu di mana operator mencoba menentukan apa yang salah. Proses ini mungkin melibatkan kueri log, meninjau metrik Kesehatan Operasional, atau masuk ke host untuk memecahkan masalah. Semua tindakan ini membutuhkan waktu, jadi membuat alat dan runbook untuk mempercepat tindakan ini dapat membantu mengurangi MTTR juga.

Runbook dan otomatisasi

Demikian pula, setelah Anda menentukan apa yang salah dan tindakan apa yang akan memperbaiki beban kerja, operator biasanya perlu melakukan beberapa set langkah untuk melakukannya. Misalnya, setelah kegagalan, cara tercepat untuk memperbaiki beban kerja mungkin dengan memulai ulang, yang dapat melibatkan beberapa langkah yang dipesan. Memanfaatkan runbook yang mengotomatiskan langkah-langkah ini atau memberikan arahan khusus kepada operator akan mempercepat proses dan membantu mengurangi risiko tindakan yang tidak disengaja.