Otomatik kurtarma için güvenli sınırlar belirleyin
TamamlandıBilinen kurtarma işlemlerini açık yetki, doğrulama ve durdurma koşullarıyla otomatikleştirin. Çalışma zamanı kurtarmasını yazılım değişikliğinden ayırın.
Yayımlayan TaigaNasıl yazıyoruz?
Neler öğreneceksiniz?
- Otomatik kurtarmayı kalıcı yazılım düzeltmesinden ayırt edin.
- Sınırları belirli kurtarma politikası ve bağımsız başarı kontrolleri tanımlayın.
- Otomasyonun ne zaman durup konuyu sorumluya iletmesi gerektiğini tanıyın.
Bilinen bir durumu düzeltin
Otomatik kurtarma, yani self-healing, tanımlı hatayı otomatik tespit eder ve yetkilendirilmiş kurtarma işlemini dener. Başarısız süreci yeniden başlatmak veya sağlıksız sunucu örneğini değiştirmek buna örnek olabilir. İşlem, hataya ve hizmetin durum modeline uygun olmalıdır.
Kubernetes, başarısız iş yükü örneklerini değiştirebilir ve bildirilen durumu sağlayabilir. Bu, hatalı uygulama mantığını veya her depolama arızasını düzeltmez. Altyapı kurtarması ile yazılım doğruluğu farklı kontroller gerektirir. Kubernetes otomatik kurtarma.
Mekanizmadan önce hedefi tanımlayın. Dışa aktarmayı geri getirmek, uygun işin doğru tamamlanması demektir. Çalışan konteyner yalnızca bir ön koşuldur.
Üç değişiklik türünü ayırın
| Değişiklik | Örnek | Gerekli karar |
|---|---|---|
| Çalışma zamanı kurtarması | Başarısız, durum tutmayan bir worker’ı değiştirmek | Önceden onaylı kurtarma politikası buna yetki verebilir |
| Yazılım düzeltmesi | Worker’ı durduran bellek sızıntısını düzeltmek | İnceleme, testler, yayın kontrolleri ve üretim doğrulaması |
| Politika değişikliği | İzin verilen yeniden başlatma sıklığını veya erişim kapsamını artırmak | Politika sorumlusunun açık onayı |
Ajan, kurtarmadan sonra düzeltme önerebilir. Bu öneri yeni yazılım değişikliğidir. Kurtarma denetleyicisinden sınırsız yetki devralmamalıdır.
Kontrol başarısız olduğunda denetleyici kendi başarı ölçütlerini de değiştirmemelidir. Aksi hâlde sistem, hizmeti iyileştirmeden iyileşme bildirebilir.
Kurtarma politikasını etkinleştirmeden önce yazın
Aşağıdaki politika kurgusaldır. Sayılar tasarım tercihlerini gösterir; önerilen varsayılan değerler değildir.
| Politika alanı | Kurgusal dışa aktarma worker’ı kuralı |
|---|---|
| Tetikleyici | Worker’dan 90 saniyedir canlılık sinyali gelmez ve kuyrukta iş vardır |
| Ön koşullar | Başka worker sağlıklıdır; bağımlılık kontrolleri geçer; ele geçirilme veya bütünlük hatası şüphesi yoktur |
| İzin verilen işlem | Geçerli onaylı artefaktı kullanarak bir worker’ı değiştirmek |
| Durum koruması | İşler kalıcı depolama ve doğrulanmış idempotency anahtarı kullanır |
| Sınır | 15 dakikada en fazla iki değiştirme; aynı anda asla birden fazla değil |
| Bekleme süresi | Değiştirmeden sonra başka girişimden önce beş dakika beklemek |
| Başarı | Sentetik iş doğru tamamlanır ve etkilenen kuyruk boşalmaya başlar |
| Durdurma ve sorumluya iletme | Herhangi bir ön koşul başarısızdır, sınıra ulaşılır veya başarı doğrulanamaz |
En az ayrıcalıklı kimlik kullanın. Politika sürümünü, tetikleme kanıtını, işlemi, kaynağı ve sonucu günlüğe kaydedin. Denetleyiciyi devre dışı bırakmak için bağımsız yol sağlayın. Bildirimi alacak insan sorumluyu tanımlayın.
Başarılı kurtarma kadar hata yollarını da test edin
Yeniden deneme yan etkiyi tekrarlayabilir. Worker, dosyayı sakladıktan sonra işi onaylamadan durabilir. Başka yürütmeye izin vermeden önce idempotent davranışı doğrulayın. Bulut yerel hata örneğine bakın.
Yeniden denemeler aşırı yüklü bağımlılığı daha da zorlayabilir. Sınırlı girişimler, zaman aşımları ve uygun artan bekleme süreleri kullanın. Tüm sistemde eşzamanlı yeniden denemelerden kaçının. AWS, artan bekleme süresinin ve rastgele gecikmenin bu yük artışını neden azalttığını açıklar. Yeniden deneme rehberi.
Kurgusal politikayı üç duruma karşı test edin. Tek bir durmuş worker kurtarılmalıdır. Veri tabanı kesintisi tekrar tekrar değiştirmeyi önlemelidir. Belirsiz bütünlük hatası otomasyonu durdurmalı ve müdahale kararı istemelidir.
Eksik telemetriyi de kontrol edin. Canlılık sinyalinin yokluğu, worker hatası veya veri toplama yolu hatası anlamına gelebilir. Denetleyicinin, yapay zekâ açıklamasına güvene değil, işlemi için yeterli kanıta ihtiyacı vardır.
Politikanın yarar sağlayıp sağlamadığını ölçün
Doğrulanmış kurtarmaları, başarısız girişimleri, sorumluya iletmeleri, yinelenen işi ve kullanıcı etkisinin sürdüğü zamanı kaydedin. Bunları benzer koşullarda önceki işletim yöntemiyle karşılaştırın.
Temel kusuru mühendislik işi olarak tutun. Bellek sızdıran süreci tekrar tekrar başlatmak, sızıntı devam ederken anlık etkiyi azaltabilir. Gözlemi kalıcı düzeltmeye bağlamak için sürekli iyileştirme ile devam edin.
Alıştırmayı yapın
Bu dersteki kurgusal dışa aktarma worker'ı için kurtarma politikası tasarlayın. Tetikleyicisini, kapsam dışı durumlarını, izin verilen işlemi, yeniden deneme sınırını, bekleme süresini, başarı kontrolünü ve iletilecek sorumluyu belirtin. Politikayı veri tabanı kesintisine ve nedeni bilinmeyen veri bütünlüğü hatasına karşı test edin.
Çalışma sayfasını indir (Markdown)Anladığınızı kontrol edin
Kaynaklar ve ek okumalar
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗
Taiga'dan ilgili okumalar
Bu seçimi kaldırmak, bu tarayıcıda kaydedilmiş tüm ilerlemeyi siler.
İlerleme bu tarayıcıda kalır. Hesap ve takip yok.