Egy kis csapatnál a katasztrófa utáni helyreállítás rendszerint egyetlen sor egy olyan dokumentumban, amelyet soha senki nem nyitott meg: a mentések be vannak kapcsolva. Ez az állítás igaz, és mégsem válasz semmire, mert nem mond semmit arról, hogy milyen régiek lennének a visszakapott adatok, mennyi ideig tart egy visszaállítás, és hogy elvégezte-e valaha bárki is egyetlen egyszer.

A mentések megléte és a tényleges visszaállítási képesség közötti résben válik a legtöbb üzemzavarból valódi incidens. Az a mentés, amely létezik, naprakész, és soha nem állították még vissza, csupán egy feltevés, és az a pillanat, amikor először ellenőrzöd, a lehető legrosszabb pillanat arra, hogy kiderüljön: a feltevés hamis volt.

Két szám tesz a véleményből tervet. Mennyi adat elvesztését engedheted meg magadnak, és mennyi ideig állhatsz? Ez a helyreállítási pont és a helyreállítási idő célértéke. Amíg valaki az üzleti oldalról ki nem mondja ezt a két számot, a mentés gyakoriságáról szóló minden technikai vita eldönthetetlen marad, mert nincs olyan mérce, amivel szemben érvelni lehetne.

Az RPO és az RTO egyszerű szavakkal

A recovery point objective, vagyis az RPO azt mondja meg, mennyi adatot veszíthetsz el. Az éjszakai mentés 24 órás RPO-t jelent: egy délután 17 órakor bekövetkező hiba mindent visz, ami az előző éjszaka óta keletkezett. Ha ez elfogadhatatlan, akkor a mentési ütemezés rossz, és bármennyi gondosság bárhol máshol nem hozza vissza az elveszett adatot.

A recovery time objective, vagyis az RTO azt mondja meg, meddig állhatsz. Ebbe minden beleszámít: észrevenni, dönteni, erőforrást kiosztani, visszaállítani, ellenőrizni és a forgalmat visszakapcsolni. A csapatok a visszaállítás lépését becsülik meg, a másik ötről pedig megfeledkeznek, és pontosan ezért tartanak a valódi helyreállítások a vártnak a többszöröséig.

Mindkettő üzleti és nem műszaki döntés, és mindkettő pénzbe kerül, ahogy szorosabbra húzod. Az ötperces RPO folyamatos replikációt igényel. Az egyórás RTO olyan infrastruktúrát igényel, amely automatikusan újraépíthető, mert nyomás alatt senki nem konfigurál kézzel szervert egyetlen óra alatt.

A hasznos beszélgetés a mérlegelésről szól. Mondd meg az üzleti oldalnak, mennyibe kerül az egyes szintek elérése, és hagyd, hogy válasszon, ahelyett hogy mérnöki oldalon kitalálnál egy számot, és reménykednél, hogy illeszkedik olyan elvárásokhoz, amelyeket soha senki nem fogalmazott meg.

A nem tesztelt mentés nem mentés

Azok a hibák, amelyek igazán fájnak, ritkán a mentések hiányából fakadnak. Sokkal gyakrabban olyan mentésekből, amelyek használhatatlannak bizonyulnak pontosan akkor, amikor szükség lenne rájuk.

A tipikus okok, amelyek mind csak a visszaállításkor válnak láthatóvá: a feladat hetek óta némán elhasal, mert senki nem figyeli a sikert ugyanolyan alapossággal, mint a hibát. A dump elkapta a sémát, de az adatokat nem, vagy csak a táblák egy részét, mert valaki egyszer felvette a többit egy kizárási listára. A fájl olyan kulccsal van titkosítva, amelyet éppen azon a gépen tároltak, amelyik meghalt. A mentés ugyanabban a fiókban vagy ugyanabban a régióban él, mint az, amit védenie kellene.

Ez az utolsó pont ma többet nyom a latban, mint korábban. Az a mentés, amely ugyanabban a környezetben van, mint az éles rendszer, hardverhiba ellen véd, és semmi más ellen. Nem éli túl a fiók feltörését, a fiók szintjén elkövetett véletlen törlést, és nem éli túl azt a zsarolóvírust sem, amely mindent elér, amit ugyanazok a hozzáférési adatok elérnek.

Az egyetlen mód arra, hogy megtudd, működik-e a mentés, ha visszaállítod. Vedd fel a naptárba, csináld meg legalább negyedévente, és mérd az időt. Az a mért idő a te valódi RTO-d, szemben azzal, ami a dokumentumban szerepel.

Mit kell lefednie a helyreállításnak

Az adat a nyilvánvaló rész, és ritkán a lassú. Ami elnyújtja a helyreállítást, az szinte mindig az, amit senki nem írt fel a listára.

Az adatbázis, amire mindenki emlékszik. A feltöltött fájlok, amelyek valahol külön élnek, és gyakran egyáltalán nincs róluk mentés. A konfiguráció és a titkok, amelyek sokszor csak a futó gépen léteznek. A DNS és a tanúsítványok, amelyeket nem lehet gyorsan újra létrehozni, ha éppen az a fiók veszett el, amelyik tárolja őket. Maga az infrastruktúra, vagyis a szerverek, a hálózatok és a szabályok, amely gyorsan újraépül, ha kódként van definiálva, és kínosan lassan, ha kattintgatással jött létre.

És annak ismerete, hogyan illeszkedik mindez össze, ami egy kis csapatnál messze a legnagyobb egyedi tényező a helyreállítási időben. Az a rendszer, amelyet egyetlen ember fejből újra tud építeni, pontosan annyi idő alatt áll helyre, amennyi idő alatt az az ember elérhető, és ez nem terv.

A leltárt a terv előtt írd meg. A csapatok többsége már a lista készítése közben talál legalább egy olyan komponenst, amiről egyáltalán nincs mentés, és ezen a módon rátalálni lényegesen olcsóbb, mint a másik lehetőség.

Egy terv, ami elfér egy oldalon

A hosszú dokumentumokat incidens közben senki nem olvassa el. Olyasmire törekedj, amit egy fáradt ember hajnali háromkor is végig tud csinálni anélkül, hogy gondolkodnia kellene rajta.

Ennek kell benne lennie: ki dönti el, hogy a helyreállítás elkezdődött, mert a habozás azon a kérdésen, hogy ez már katasztrófának számít-e, a késedelem egyik leggyakoribb forrása. Hol vannak a mentések, és hogyan lehet hozzájuk férni, beleértve olyan hozzáférési adatokat, amelyek nem függenek a kiesett rendszertől. A visszaállítás lépései sorrendben, elég konkrétan ahhoz, hogy rögtönzés nélkül követhetők legyenek. Hogyan ellenőrzöd, hogy sikerült, vagyis egy kézzelfogható ellenőrzés, nem pedig az az érzés, hogy az oldal betölt. És kit kell értesíteni, házon belül és házon kívül.

Tartsd olyan helyen, amely túléli a hibát. Az a helyreállítási terv, amely kizárólag abban a rendszerben van tárolva, amelyet helyre kellene állítania, visszatérő és teljes mértékben elkerülhető hiba.

Ugyanez a gondolatmenet érvényes a hozzáférésekre is. Ha egyetlen ember birtokolja a tárhelyfiók belépési adatait, a helyreállítási időd attól függ, felveszi-e a telefont. A Linux szerver hardening útmutatónk végigveszi azokat a hozzáférési kontrollokat, amelyeken mindez múlik.

Arányos, nem tökéletes

Egy kis csapatnak nincs szüksége meleg tartalékra egy másik régióban. A költség valós, a bonyolultság pedig saját hibalehetőségeket hoz magával.

Amire a legtöbb kis csapatnak valóban szüksége van, az lényegesen olcsóbb: mentések egy külön fiókban, olyan hozzáférési adatokkal, amelyeket az éles rendszer nem tud használni, ütemezetten tesztelt és megmért visszaállítás, kódként definiált infrastruktúra, hogy régészkedés nélkül újra létre lehessen hozni, és egy egyoldalas terv, amelyet valaki tényleg elolvasott.

Ez a készlet lefedi a hardverhibát, a véletlen törlést, a fiók feltörését és a zsarolóvírust, vagyis nagyjából mindent, ami a valóságban megtörténik. Ami ezen túl van, az arról szóló döntés, mennyit ér a leállási idő további csökkentése, és ez a kérdés az üzleti oldalé, nem a mérnökségé.

A Mecanik a szerver biztonsági elemzés keretében átnézi és felépíti mindezt. Az első kérdés mindig ugyanaz, és nem a technológiáról szól: meddig állhatsz, és ki döntötte ezt el?

Kapcsolódó bejegyzések: Uptime SLA-k, amelyek tényleg jelentenek valamit , Szoftverellátási lánc biztonsága kis csapatoknak , MI-ügynökök a cégben: költségek és buktatók és Fintech szoftverfejlesztés az Egyesült Királyságban: FCA, rails, költségek .

Gyakran ismételt kérdések

Mit jelent az RPO és az RTO? A recovery point objective az az adatmennyiség, amelynek elvesztését megengedheted magadnak, így az éjszakai mentés 24 órás RPO-t jelent. A recovery time objective az az idő, ameddig állhatsz, beleértve az észrevételt, a döntést, az erőforrás kiosztását, a visszaállítást, az ellenőrzést és a forgalom visszakapcsolását. Mindkettő üzleti döntés, és mindkettő többe kerül, ahogy szorosabbra húzod.

Miért nem mentés a nem tesztelt mentés? Mert a hibamódok csak a visszaállításkor válnak láthatóvá. A feladatok hetekig némán elhasalnak, ha senki nem figyeli a sikert ugyanúgy, mint a hibát, a dumpok séma nélkül vagy adat nélkül készülnek, illetve kihagyják a kizárt táblákat, a titkosítási kulcsok a meghalt gépen ülnek, a másolatok pedig ugyanabban a fiókban élnek, mint amit védenek. Állítsd vissza negyedévente, és mérd az időt.

Hol érdemes tárolni a mentéseket? Külön fiókban vagy külön régióban, olyan hozzáférési adatokkal, amelyeket az éles rendszer nem tud használni. Az azonos környezetben tárolt mentés hardverhiba ellen véd, és semmi más ellen: nem éli túl a fiók feltörését, a fiók szintjén végrehajtott törlést, sem azt a zsarolóvírust, amely mindent elér, amit ugyanazok a hozzáférési adatok elérnek.

Mit szoktak kihagyni a helyreállítási tervből? A feltöltött fájlokat, amelyek az adatbázistól külön vannak tárolva, a konfigurációt és a titkokat, amelyek csak a futó gépen léteznek, a DNS-t és a tanúsítványokat egy olyan fiókban, amely maga is elveszhet, a kattintgatással létrehozott és nem kódként definiált infrastruktúrát, valamint annak ismeretét, hogyan áll össze az egész, ha ezt csak egyetlen ember tudja.

Szüksége van egy kis csapatnak meleg tartalékra? Rendszerint nincs. A költség valós, a hozzáadott bonyolultság pedig saját hibalehetőségeket hoz. A külön fiókban tárolt mentés, a tesztelt és megmért visszaállítás, a kódként definiált infrastruktúra és az egyoldalas terv, amelyet valaki elolvasott, lefedi a hardverhibát, a véletlen törlést, a fiók feltörését és a zsarolóvírust, vagyis a történések nagy részét.