Tetapkan batas aman untuk self-healing
SelesaiOtomatiskan tindakan pemulihan yang diketahui dengan kewenangan, verifikasi, dan syarat penghentian yang eksplisit. Pisahkan pemulihan runtime dari perubahan perangkat lunak.
Diterbitkan oleh TaigaCara kami menulis
Periksa pemahaman AndaController telah memulai ulang worker dua kali. Antrean terus bertambah dan database tidak dapat diakses. Apa yang harus dilakukan kebijakan?Kerjakan latihan
Hal yang akan dipelajari
- Bedakan self-healing dari perbaikan perangkat lunak permanen.
- Tentukan kebijakan pemulihan terbatas dan pemeriksaan keberhasilan independen.
- Kenali kapan otomatisasi harus berhenti dan melakukan eskalasi.
Pulihkan kondisi yang diketahui
Self-healing secara otomatis mendeteksi kegagalan yang ditentukan dan mencoba tindakan pemulihan yang diizinkan. Contohnya dapat berupa memulai ulang proses yang gagal atau mengganti instance yang tidak sehat. Tindakan harus sesuai dengan kegagalan dan model state layanan.
Kubernetes dapat mengganti instance workload yang gagal dan menyelaraskan state dengan deklarasinya. Ini tidak memperbaiki logika aplikasi yang keliru atau setiap kegagalan penyimpanan. Pemulihan infrastruktur dan kebenaran perangkat lunak memerlukan pemeriksaan berbeda. Self-healing Kubernetes.
Tentukan sasaran sebelum mekanisme. Memulihkan ekspor berarti pekerjaan yang memenuhi syarat selesai dengan benar. Container yang berjalan hanyalah satu prasyarat.
Pisahkan tiga jenis perubahan
| Perubahan | Contoh | Keputusan yang diperlukan |
|---|---|---|
| Pemulihan runtime | Mengganti satu worker stateless yang gagal | Kebijakan pemulihan yang disetujui sebelumnya dapat mengizinkannya |
| Perbaikan perangkat lunak | Memperbaiki kebocoran memori yang menghentikan worker | Peninjauan, pengujian, kontrol rilis, dan verifikasi produksi |
| Perubahan kebijakan | Menaikkan frekuensi mulai ulang yang diizinkan atau memperluas cakupan akses | Persetujuan eksplisit dari penanggung jawab kebijakan |
Agen dapat mengusulkan perbaikan setelah pemulihan. Usulan itu merupakan perubahan perangkat lunak baru. Usulan tidak boleh mewarisi kewenangan tanpa batas dari controller pemulihan.
Controller juga tidak boleh mengubah kriteria keberhasilannya sendiri ketika pemeriksaan gagal. Jika tidak, sistem dapat melaporkan perbaikan tanpa memperbaiki layanan.
Tulis kebijakan pemulihan sebelum mengaktifkannya
Kebijakan berikut bersifat fiktif. Angkanya menggambarkan pilihan desain, bukan nilai default yang direkomendasikan.
| Bagian kebijakan | Aturan worker ekspor fiktif |
|---|---|
| Pemicu | Heartbeat worker tidak ada selama 90 detik dan terdapat pekerjaan dalam antrean |
| Prasyarat | Worker lain sehat; pemeriksaan dependensi lulus; tidak ada dugaan kompromi atau kegagalan integritas |
| Tindakan yang diizinkan | Ganti satu worker menggunakan artefak yang saat ini disetujui |
| Perlindungan state | Job menggunakan penyimpanan persisten dan kunci idempotensi yang terverifikasi |
| Batas | Maksimal dua penggantian dalam 15 menit; tidak pernah lebih dari satu pada waktu yang sama |
| Waktu jeda | Tunggu lima menit setelah penggantian sebelum mencoba lagi |
| Keberhasilan | Job sintetis selesai dengan benar dan antrean yang terdampak mulai berkurang |
| Hentikan dan eskalasikan | Prasyarat mana pun gagal, batas tercapai, atau keberhasilan tidak dapat diverifikasi |
Gunakan identitas dengan hak minimum. Catat versi kebijakan, bukti pemicu, tindakan, sumber daya, dan hasil. Sediakan cara independen untuk menonaktifkan controller. Tetapkan penanggung jawab manusia yang menerima eskalasi.
Uji jalur kegagalan serta pemulihan yang berhasil
Percobaan ulang dapat mengulang efek samping. Worker mungkin menyimpan file lalu berhenti sebelum mengonfirmasi job. Verifikasi idempotensi sebelum mengizinkan eksekusi berikutnya. Lihat contoh kegagalan cloud native.
Percobaan ulang juga dapat memperberat beban dependensi yang sudah kelebihan beban. Gunakan jumlah percobaan terbatas, timeout, dan backoff yang sesuai. Hindari percobaan ulang serentak di seluruh kumpulan instance. AWS menjelaskan cara backoff dan jitter membantu mengurangi penambahan beban ini. Panduan percobaan ulang.
Uji kebijakan fiktif terhadap tiga kasus. Satu worker yang berhenti seharusnya pulih. Gangguan database seharusnya mencegah penggantian berulang. Kegagalan integritas yang belum pasti seharusnya menghentikan otomatisasi dan meminta keputusan respons.
Periksa juga telemetri yang hilang. Heartbeat yang tidak ada dapat berarti worker gagal atau jalur pengumpulan gagal. Controller memerlukan bukti yang cukup untuk tindakannya, bukan keyakinan pada penjelasan AI.
Ukur apakah kebijakan membantu
Catat pemulihan terverifikasi, percobaan yang gagal, eskalasi, pekerjaan duplikat, dan durasi dampak pada pengguna. Bandingkan dengan metode operasi sebelumnya dalam kondisi serupa.
Pertahankan cacat dasarnya sebagai pekerjaan engineering. Memulai ulang proses yang mengalami kebocoran memori secara berulang dapat mengurangi dampak langsung sementara kebocoran berlanjut. Lanjutkan ke self-improvement untuk menghubungkan pengamatan dengan perbaikan yang bertahan.
Kerjakan latihan
Rancang kebijakan pemulihan untuk worker ekspor fiktif dalam pelajaran ini. Tentukan pemicu, pengecualian, tindakan yang diizinkan, batas percobaan ulang, waktu jeda, pemeriksaan keberhasilan, dan penanggung jawab eskalasi. Uji terhadap gangguan database dan kegagalan integritas data yang belum diketahui.
Unduh lembar kerja (Markdown)Menonaktifkan pilihan ini menghapus seluruh kemajuan yang tersimpan dalam browser.
Kemajuan tetap tersimpan dalam browser ini. Tanpa akun atau pelacakan.
Sumber dan bacaan lanjutan
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗