Mengurangi MTTR

Setelah kegagalan ditemukan, sisa waktu MTTR adalah perbaikan aktual atau mitigasi dampak. Untuk memperbaiki atau mengurangi kegagalan, Anda harus tahu apa yang salah. Ada dua kelompok utama 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 — Metrik kritis MTTD dan MTTR untuk informasi selengkapnya tentang metrik ini.

Aturan 9

Observabilitas dan instrumentasi sangat penting untuk mengurangi MTTD dan MTTR.

Rute di sekitar kegagalan

Pendekatan tercepat untuk mengurangi dampak adalah melalui subsistem gagal-cepat yang rute di sekitar kegagalan. Pendekatan ini menggunakan redundansi untuk mengurangi MTTR dengan cepat menggeser pekerjaan subsistem yang gagal ke cadangan. Redundansi dapat berkisar dari proses perangkat lunak, instans EC2, hingga beberapa AZ, hingga beberapa Wilayah.

Subsistem cadangan dapat mengurangi MTTR hingga hampir nol. Waktu pemulihan hanya apa yang diperlukan untuk mengalihkan pekerjaan ke cadangan siaga. Hal ini sering terjadi dengan latensi minimal dan memungkinkan pekerjaan untuk menyelesaikan dalam SLA didefinisikan, menjaga ketersediaan sistem. Ini menghasilkan MTTR yang dialami sedikit, bahkan mungkin tidak terlihat, penundaan, daripada periode tidak tersedianya yang berkepanjangan.

Misalnya, jika layanan Anda menggunakan instans EC2 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 gagal-cepat semacam ini membuat beban kerja Anda sangat sensitif terhadap kesalahan sementara. Dalam contoh yang diberikan, pastikan bahwa pemeriksaan kesehatan penyeimbang muatan Anda melakukan pemeriksaan kesehatan dangkal atau liveness dan lokal hanya pada instans, 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 routing sekitar kegagalan untuk menjadi sukses. Anda harus mengetahui ruang lingkup dampaknya sehingga sumber daya yang terpengaruh dapat ditandai sebagai tidak sehat atau gagal dan dikeluarkan dari layanan sehingga dapat dialihkan. Misalnya, jika satu AZ mengalami gangguan layanan sebagian, 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 instans EC2 di belakang ALB, 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 mengambil instance tersebut keluar dari layanan. Mekanisme otomatis yang berbeda akan diperlukan untuk menghapus AZ dari load balancer atau memaksa instance untuk gagal memeriksa kesehatan mereka, yang bergantung pada identifikasi bahwa ruang lingkup dampaknya adalah AZ. Untuk beban kerja yang tidak menggunakan penyeimbang muatan, 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 failover ini memerlukan sejumlah waktu henti untuk diselesaikan, tidak dapat segera dibalik, dan meninggalkan beban kerja tanpa redundansi untuk jangka waktu tertentu, penting untuk memiliki manusia dalam proses pengambilan keputusan.

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

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

Strategi kedua adalah mengarahkan beberapa lalu lintas dari subsistem yang gagal ke yang lain dan memuat 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 MTTR yang lebih panjang dan menciptakan ketergantungan pada bidang kontrol, tetapi biaya lebih murah dalam siaga, kapasitas cadangan.

Kembali ke keadaan baik yang diketahui

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 menyebabkan kegagalan, dalam hal ini, memulai ulang beban kerja dapat mengurangi dampaknya. Mari kita periksa kedua skenario ini.

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

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

CloudFormationmenawarkan kemampuan untuk secara otomatis rollback sebagai bagian dari operasi create dan update stack, seperti halnya AWS CodeDeploy. CodeDeployjuga mendukung biru/hijau dan penyebaran bergulir.

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

Saat mempertimbangkan restart, ada beberapa pendekatan berbeda. Ini berkisar dari me-reboot server, tugas terpanjang, untuk 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).

Mekanisme pemulihan kesalahan	Perkiraan MTTR
Luncurkan dan konfigurasikan server virtual baru	15 menit
Menyebarkan ulang perangkat lunak	10 menit
Reboot server	5 menit
Mulai ulang atau luncurkan kontainer	2 detik
Memanggil fungsi tanpa server baru	100 nona
Mulai ulang proses	10 nona
Mulai ulang utas	10 μs

Meninjau tabel, ada beberapa manfaat yang jelas bagi MTTR dalam menggunakan kontainer dan fungsi tanpa server (seperti). AWS Lambda MTTR mereka adalah urutan besarnya lebih cepat daripada me-restart mesin virtual atau meluncurkan yang baru. Namun, menggunakan isolasi kesalahan melalui modularitas perangkat lunak juga bermanfaat. Jika Anda dapat berisi kegagalan untuk satu proses atau thread, memulihkan dari kegagalan itu jauh lebih cepat daripada me-restart kontainer 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, perutean di sekitar kegagalan biasanya merupakan pendekatan yang lebih cepat (biasanya memakan waktu paling lama 3-4 menit). Jadi, untuk mengurangi dampak paling cepat setelah percobaan restart, rutekan kegagalan, dan kemudian, di latar belakang, lanjutkan proses pemulihan untuk mengembalikan kapasitas ke beban kerja Anda.

Aturan 10

Fokus pada mitigasi dampak, bukan penyelesaian masalah. Ambil jalur tercepat kembali ke operasi normal.

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, sehingga 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 langkah untuk melakukan itu. Misalnya, setelah kegagalan, cara tercepat untuk memperbaiki beban kerja mungkin untuk memulai ulang, yang dapat melibatkan beberapa langkah yang diurutkan. Memanfaatkan runbook yang mengotomatiskan langkah-langkah ini atau memberikan arah khusus kepada operator akan mempercepat proses dan membantu mengurangi risiko tindakan yang tidak disengaja.