Ha egy drill megbukik

A leghasznosabb dolog, amit egy drill tesz, amikor félremegy, az, hogy megmondja: melyik fajta félremenésről van szó. A vissza nem állt mentés a helyreállítási helyzetedről szóló megállapítás. Az álló Docker-daemon arról a gépről szóló megállapítás, amelyiken a drill futott. Ugyanazon a parancson keresztül érkeznek, és nem ugyanaz az esemény.

A kilépési kód a szerződés

Kód	Jelentés
0	backup proven restorable
1	recoverability failure (backup, restore, or check)
2	infrastructure error or cancelled
3	usage or setup error
5	evidence record could not be written

Az a riasztási szabály, amelyik az 1-es és a 2-es kódot nem tudja megkülönböztetni, egy hónapon belül el lesz némítva, mert a második fajta gyakori és unalmas, az első pedig egyik sem. Állítsd be őket külön riasztásként a kezdetektől, eltérő sürgősséggel és eltérő gazdával.

Egyenként olvasva

0 — a mentés bizonyítottan visszaállítható. A mentés visszaállt, és minden ellenőrzés átment. Ez időbélyeggel ellátott állítás, nem zöld lámpa egy dashboardon: a rekord elmondja, mi állt vissza, mennyi ideig tartott, és mit ellenőriztünk.

1 — helyreállíthatósági hiba. A visszaállítás megbukott, vagy sikerült, és egy ellenőrzés bukott meg. Kezeld ezt a mentéseidről szóló incidensként, azon a súlyossági szinten, ahogy az elvesztésüket kezelnéd — mert abban az esetben, ami számít, el is vesztetted őket. A rekordban lévő ellenőrzésekből indulj ki: a megbukott healthcheck az archívumra vagy a motorverzióra mutat, a sorok számának megbukott ellenőrzése a forrásra — legtöbbször egy feladatra, ami mást mentett, mint amit feltételeztél.

2 — infrastruktúra-hiba. A drillt nem lehetett befejezni: a konténer-futtatókörnyezet elérhetetlen volt, a sandbox túllépte az időkorlátot, a futást megszakították. Ez semmit nem mond a mentésről. Így is érdemes riasztani rá, alacsonyabb sürgősséggel, mert az a drill, ami minden éjjel hibára fut, olyan drill, ami már semmit nem bizonyít — a veszélyes hiba itt a csend, nem a hibaüzenet.

3 — használat vagy beállítás. A konfiguráció hibás, hiányzik egy flag, egy adapter nincs a path-on. Majdnem mindig egy éppen most elvégzett változtatás.

5 — a rekordot nem sikerült kiírni. A legritkább és a legkényelmetlenebb: lehet, hogy a drill helyesen lefutott, és a bizonyíték veszett el. Kezeld a bizonyítéknaplóról szóló incidensként — betelt lemez, megváltozott jogosultság, elmozdult útvonal —, mert az a drill, aminek a rekordja nem írható ki, meg nem történt drill mindenki számára, aki később a történetet olvassa.

A hiba is bizonyíték

Minden kimenetel rögzül és alá van írva, a hibák is. Ez szándékos, és érdemes megérteni, mielőtt valaki megkérdezi, miért nem csupa zöld a napló.

Az a napló, amiben csak sikerek vannak, nem bizonyítéka a működő helyreállítási helyzetnek. Bizonyítéka vagy egy működő helyreállítási helyzetnek, vagy egy drillnek, amit csendben kikapcsoltak, miután bukni kezdett — és kívülről a kettő megkülönböztethetetlen. A közzétett példanapló pontosan ezért érkezik egy sikerrel, egy hibával és egy hibás futással.

Ne takarítsd tehát a naplót. Egy hibarekord, amit néhány nappal később egy sikeres rekord követ ugyanazon a célponton, erősebb artefaktum, mint a töretlen sikersorozat: azt mutatja, hogy egy problémát megtaláltak és kijavítottak, dátumokkal.

Amikor a javítás a mentésben van, nem a Probaviban

A legtöbb 1 kimenetel máshol oldódik meg — a mentőeszközben, a megőrzési szabályban, a hitelesítő adatokban, a forrás útvonalában. A Probavi mentést nem készít és nem is javít; megmondja, melyikük nem az, aminek hitted, és rögzíti, mit látott az adott pillanatban.

A rekord az átadás: megnevezi a forrásfajtát, a mentés ellenőrzőösszegét és méretét, az adapter és a motor verzióját, és minden ellenőrzést az eredményével. Ez általában elég ahhoz, hogy a hibát kézzel reprodukáld ugyanazon az archívumon, anélkül hogy a körülményeket emlékezetből kellene összeraknod.