Szabjon biztonságos határokat a self-healingnek
ElvégezveAutomatizáljon ismert helyreállítási műveleteket egyértelmű jogosultsággal, ellenőrzéssel és leállási feltételekkel. Válassza külön a futásidejű helyreállítást a szoftver módosításától.
Kiadó TaigaHogyan írunk
Ellenőrizze, mit értett megA controller kétszer újraindította a workert. A sor tovább nő, és az adatbázis nem érhető el. Mit írjon elő a szabályzat?Végezze el a gyakorlatot
Amit megtanulhat
- Megkülönböztetni a self-healinget a tartós szoftverjavítástól.
- Meghatározni a korlátozott helyreállítási szabályzatot és a siker független ellenőrzéseit.
- Felismerni, mikor kell az automatizálásnak leállnia és eszkalálnia.
Állítson helyre ismert állapotot
A self-healing automatikusan észlel egy meghatározott hibát, és megpróbál végrehajtani egy engedélyezett helyreállítási műveletet. Példa lehet a meghibásodott folyamat újraindítása vagy a hibás példány cseréje. A műveletnek illeszkednie kell a hibához és a szolgáltatás állapotmodelljéhez.
A Kubernetes lecserélheti a meghibásodott munkaterhelés-példányokat, és a deklarált állapothoz igazíthatja a rendszert. Ez nem javítja ki az alkalmazás hibás logikáját vagy az összes tárolóhibát. Az infrastruktúra helyreállításához és a szoftver helyességéhez eltérő ellenőrzések kellenek. Kubernetes self-healing.
A mechanizmus előtt határozza meg a célt. Az export helyreállítása azt jelenti, hogy a jogosult munka helyesen befejeződik. A futó konténer csak az egyik előfeltétel.
Válasszon külön háromféle változást
| Változás | Példa | Szükséges döntés |
|---|---|---|
| Futásidejű helyreállítás | Egy meghibásodott, állapotmentes worker cseréje | Előre jóváhagyott helyreállítási szabályzat engedélyezheti |
| Szoftverjavítás | A worker leállását okozó memóriaszivárgás javítása | Review, tesztek, kiadási kontrollok és éles ellenőrzés |
| Szabályzatváltozás | Az engedélyezett újraindítási gyakoriság vagy hozzáférési kör növelése | A szabályzat felelősének kifejezett jóváhagyása |
Helyreállítás után az agent javítást javasolhat. Ez a javaslat új szoftvermódosítás. Nem örökölhet korlátlan jogkört a helyreállító controllertől.
A controller sikertelen ellenőrzés esetén a saját sikerkritériumait sem módosíthatja. Különben a rendszer javulást jelenthet a szolgáltatás javítása nélkül.
Bekapcsolás előtt írja meg a helyreállítási szabályzatot
Az alábbi szabályzat fiktív. A számok tervezési döntéseket szemléltetnek; nem ajánlott alapértékek.
| Szabályzati mező | Fiktív exportworker-szabály |
|---|---|
| Kiváltó feltétel | A worker életjele 90 másodperce hiányzik, és van várakozó munka |
| Előfeltételek | Egy másik worker működőképes; a függőségi ellenőrzések sikeresek; nincs kompromittálódás vagy integritáshiba gyanúja |
| Engedélyezett művelet | Egy worker cseréje a jelenleg jóváhagyott artifacttal |
| Állapotvédelem | A feladatok tartós tárolást és ellenőrzött idempotenciakulcsot használnak |
| Korlát | Legfeljebb két csere 15 percen belül; egyszerre soha több mint egy |
| Várakozási idő | Csere után öt perc várakozás az újabb próbálkozásig |
| Siker | Egy szintetikus feladat helyesen elkészül, és az érintett sor ürülni kezd |
| Leállítás és eszkaláció | Bármely előfeltétel sérül, elérik a korlátot, vagy a siker nem ellenőrizhető |
Minimális jogosultságú identitást használjon. Naplózza a szabályzat verzióját, a kiváltó feltétel bizonyítékát, a műveletet, az erőforrást és az eredményt. Biztosítson független lehetőséget a controller kikapcsolására. Nevezze meg az eszkalációt fogadó emberi felelőst.
A sikeres helyreállítás mellett a hibautakat is tesztelje
Az újrapróbálkozás megismételhet egy mellékhatást. A worker eltárolhat egy fájlt, majd a feladat nyugtázása előtt leállhat. Újabb végrehajtás engedélyezése előtt ellenőrizze az idempotenciát. Lásd a cloud native hibapéldát.
Az újrapróbálkozások tovább növelhetik egy már túlterhelt függőség terhelését. Használjon korlátozott számú próbálkozást, időkorlátokat és megfelelő backoffot. Kerülje az összes példány egyidejű újrapróbálkozását. Az AWS ismerteti, hogyan csökkenti ezt a felerősítést a backoff és a jitter. Újrapróbálkozási útmutató.
Három esettel tesztelje a fiktív szabályzatot. Egyetlen leállt workernek helyre kell állnia. Az adatbázis-kiesésnek meg kell akadályoznia az ismételt cserét. Bizonytalan integritáshibánál az automatizálásnak le kell állnia, és reagálási döntést kell kérnie.
A hiányzó telemetriát is ellenőrizze. Az életjel hiánya jelenthet workerhibát vagy a gyűjtési útvonal hibáját. A controllernek a művelethez elegendő bizonyítékra van szüksége, nem egy AI-magyarázatba vetett bizalomra.
Mérje meg, segít-e a szabályzat
Rögzítse az ellenőrzött helyreállításokat, a sikertelen próbálkozásokat, az eszkalációkat, a megkettőzött munkát és a felhasználókat érintő időtartamot. Hasonló körülmények között vesse össze ezeket a korábbi üzemeltetési módszerrel.
Az alapul szolgáló hiba maradjon fejlesztési feladat. A memóriát szivárogtató folyamat ismételt újraindítása csökkentheti a közvetlen hatást, miközben a szivárgás folytatódik. Folytassa a self-improvement témával, és kapcsolja a megfigyelést tartós javításhoz.
Végezze el a gyakorlatot
Tervezzen helyreállítási szabályzatot a lecke fiktív exportworkeréhez. Adja meg a kiváltó feltételt, a kizárásokat, az engedélyezett műveletet, a próbálkozási korlátot, a várakozási időt, a sikerellenőrzést és az eszkaláció felelősét. Tesztelje adatbázis-kiesés és ismeretlen adatintegritási hiba esetére.
Munkalap letöltése (Markdown)A kijelölés megszüntetése törli az ebben a böngészőben mentett összes haladást.
A haladás ebben a böngészőben marad. Nincs fiók, nincs követés.
Források és további olvasnivaló
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗