( _Franko_ | 2020. 09. 22., k – 11:35 )

Te azt mondod, hogy tesztelni kell _szándékos_ borogatással, én meg azt, hogy a problémát majd kezeljük akkor, ha bekövetkezik, de ne idézzük elő éles környezetben _szándékosan_.

Igen, ezt hívják stressz tesztnek, akár éles üzemben is, mert hát ott is tesztelni kellene. Előszeretettel el szokták hagyni, mert anélkül is "működik". Csak amikor bekövetkezik az, amit az el nem végzett stressz teszt kimutatott volna, akkor megy a papírral nem védett seggek keresése a cégen belül, hogy kit basszanak meg.

Idéznék a Chaos monkey első mondatából, kiemelés tőlem: "Chaos Monkey is responsible for randomly terminating instances in production to ensure that engineers implement their services to be resilient to instance failures."

Én pl. még nem láttam olyan külső sérülékenységvizsgálatot, ahol azt mondta volna a megbízó, hogy a feltárt sérülékenységet tessék kihasználni és megborítani a rendszert.

Nem külső sérülékenységvizsgálatról van szó, hanem egy papíron kritikusnak jelölt rendszer (tudod, amire azt mondják, hogy x perc állás y millió forintos kár) stressz teszteléséről, hogy ne legyen x perces állás sem, ha már kritikusnak van jelölve.

Éles környezetben nem a probléma lehetséges _következményének_ hanem a problémának a bemutatása, feltárása kell legyen a cél. És pl. arra, hogy "egy credential-t hol használunk még" nem a káoszmajom, meg a credential lecserélése, és "ha valakinek fáj, majd szól" az üzletileg elfogadható megoldás, hanem az, hogy felderíteni a logokból, a hálózati forgalomból, a dokumentációkból és az üzemeltetők/alkalmazásgazdák tudásából, hog ymilyen kapcsolatok vannak, hol van még az adott hozzáférés használatban (és miért?), és amikor ebből az iterációból nem jön ki újabb felhasználás, akkor jöhet a kockázatelemzés, hogy szükséges-e ennek a cserélgetése, vagy maradhat fixen beállítva.

Ezektől sehol nem lett megoldva a probléma, csak kilóra lett írva belőle papír meg észrevétel és tonnányi levelezés, száz liter bubis víz, ötven kiló pogácsa, fél emberév végigunatkozott meeting, aztán minden maradt ugyanúgy és a következő menetrend szerinti eszközhalál ugyanúgy okozott x perc leállást és y millió kárt és kezdődött előlről minden.

Ha a rendszer szerves részévé teszed azt, hogy bármelyik komponens újraindulhat, leállhat, elromolhat, belassulhat, hibázhat, akkor működni fog, mert üzemszerűen fel van rá készítve a rendszer. Nem évente egy BCP teszt van, amiről mindenki tud előre fél évvel és előtte egy hónappal megáll az élet, mert mindenki a BCP-re készül, hanem bármikor bekövetkező hibákra van rutinszerű és/vagy automatizált élő BCP folyamat, és tényleg nem áll meg semmi.

Olvasnivaló: https://en.wikipedia.org/wiki/Chaos_engineering