Jira Cloud mentés: mit állít vissza a natív eszköz

A Jira Cloud mentés kérdése a legtöbb magyar fejlesztőcsapatnál akkor kerül elő először, amikor már baj van. Az Atlassian üzemelteti az infrastruktúrát és gondoskodik a rendelkezésre állásról; az viszont, hogy mi történik az Ön munkaelemeivel azután, hogy valaki törölte őket, már az Ön oldalán van. A rövid válasz három tény, mindhárom az Atlassian saját dokumentációjából: a törölt projekt 60 napig a kukában marad és visszaállítható, az egyesével törölt munkaelemnek viszont egyáltalán nincs kukája, a teljes exportfájl pedig 30 nap után lejár, és kizárólag üres Jira-környezetbe tölthető vissza. Külön-külön mindegyik ésszerű. Együtt viszont pontosan ott hagynak lyukat, ahol a napi adatvesztés történik.

Mit őriz meg a Jira Cloud natívan

Két mechanizmus, két teljesen különböző szinten.

A törölt projekt a kukába kerül. Az Atlassian dokumentációja egyértelmű: a terek a munkaelemeikkel, komponenseikkel, csatolmányaikkal és verzióikkal együtt 60 napig érhetők el a kukában, ezt követően véglegesen törlődnek. (Az Atlassian dokumentációja mostanra a tér kifejezést használja arra, amit a legtöbb csapat továbbra is Jira-projektnek hív.) Ez alatt a 60 nap alatt a tartalom félállapotban van: a keresési találatok között nem jelenik meg, közvetlen hivatkozással viszont elérhető, szerkeszteni pedig nem lehet.

Az egyesével törölt munkaelem viszont nem. Egyetlen törölt feladatnak nincs kukája. A munkaelemek szintű kuka évek óta nyitott fejlesztési kérés az Atlassian saját, nyilvános hibakövetőjében — JRACLOUD-36415 —, és amíg nem valósul meg, a Jira Cloudban a munkaelem törlése azonnali és végleges. Nincs visszavonás, nincs 30 napos ablak, és nincs adminisztrátori helyreállítási út sem.

Ez az aszimmetria a legfontosabb tudnivaló a Jira Cloud mentésről, mert pontosan a fordítottja annak, amit a csapatok feltételeznek. Ami katasztrofálisnak látszik — valaki törölt egy egész projektet —, az a visszaállítható eset. Ami hétköznapi, az a visszaállíthatatlan: egy fejlesztő rendet rak a boardon, egy automatizálási szabály a tervezettnél tágabb JQL-szűrőre fut rá, egy távozó alvállalkozó kitakarítja a „saját” jegyeit, vagy egy tömeges módosítás 30 helyett 300 munkaelemet érint.

A Backup Manager export és a 30 napos óra

Az Atlassian másik mechanizmusa az adminisztrációs felületen elérhető Backup Manager, amely teljes körű exportot készít a Jira-adatokról. Valóban hasznos — és valóban nem archívum, egyetlen dokumentált okból: a mentés 30 napig tárolódik az Atlassian tárhelyén, utána lejár, és nem állítható vissza. A dokumentáció a másik irányból is kimondja: a mentéstől számítva 30 nap áll rendelkezésre az adatok visszaállítására.

A natív export tehát egy gördülő 30 napos ablak. Ha októberben érkezik kérdés arról, hogy egy Jira-munkaelem mit tartalmazott februárban — ügyfélvita, auditkérés, belső vizsgálat, vagy egy szerződéses nézeteltérés arról, hogy pontosan mit és mikor fogadtak el —, a Backup Manager erre nem ad választ. Az a példány, amelyben a válasz szerepelt volna, hét hónapja lejárt.

Van egy második kitétel is, amelyet érdemes elolvasni, mielőtt az exportra építi a helyreállítási tervét: az Atlassian szerint nem minden adattípus kerül bele a mentésbe és nem mindegyik állítható vissza. Az export nem bitpontos másolat a környezetről, és a hiányok jellemzően abban az integrációs rétegben vannak, amelyre a csapatok a folyamataikat építik.

A visszaállítás mindent vagy semmit

Itt tér el a leginkább a Jira Cloud mentés attól, amit a „mentés” szó az IT többi területén jelent. Két dokumentált korlát épül egymásra.

Az első a bemeneti oldalon: nem lehet egyes projekteket vagy tereket külön menteni — a mentés minden projektet és teret tartalmaz. Szelektív mentés nem létezik.

A második a kimeneti oldalon, és ez fáj igazán. A visszaállítás célkörnyezete nem tartalmazhat felhasználó által létrehozott adatot: sem aktív, sem törölt, sem archivált tartalmat. A visszaállítás tehát üres Jira-környezetbe megy — nem abba, amelyet a cége éppen használ.

Gondolja végig, mit jelent ez a gyakorlatban. Egyetlen törölt munkaelem natív mentésből való visszanyeréséhez létre kell hoznia egy különálló, üres Jira-környezetet, abba vissza kell töltenie a teljes mentést, meg kell keresnie benne az elemet, majd kézzel vagy CSV-importtal újra létre kell hoznia az éles rendszerben. Amit nem tehet meg — mert az üres célkörnyezet szabálya kizárja —, az az, hogy a visszaállított adatot visszafésülje az éles környezetbe. Egy jegy esetén ez kellemetlen. Annál a 300-nál, amelyet múlt kedden egy automatizálási szabály csendben törölt, ez már önálló projekt.

Hogyan néz ki ez a gyakorlatban

A három tényt összerakva a hibaforgatókönyvek jól előrejelezhetők.

A rutinszerű törlés. Valaki munkaelemeket töröl, nem projektet. A kuka ezeket soha nem látja, mert a kuka csak projekteket tárol. Ha a törlés régebbi a legutóbbi exportnál, nincs hová visszanyúlni.

A múltra vonatkozó kérdés. A jogi terület, egy hatóság vagy egy ügyfél azt kérdezi, mit tartalmazott egy jegy egy évvel ezelőtt. A 30 napos exportablak ezt nem éri el.

A kompromittált adminisztrátor. Egy támadó — vagy egy elégedetlen fiókhasználó — projekttörlési joggal olyan tempóban dolgozik, amelyet a 60 napos kuka még elnyel, az alatta lévő munkaelem-törléseket azonban nem, és egy mindig csak 30 napos mélységű export már a kárt is tartalmazhatja. A mentés ezt nem akadályozza meg; azt dönti el, hogy utána vissza tudja-e tenni az adatokat.

A távozó csapat. Fut a kiléptetési folyamat, változnak a jogosultságok, és egy takarítószkript azt teszi, amit a takarítószkriptek szoktak.

Ha a kép Confluence- és Bitbucket-felét is látni szeretné: azoknak saját dokumentált korlátaik vannak — a Confluence Cloud mentés oldalkukája másként működik, mint a Jiráé, a Bitbucket egyetlen dokumentált helyreállítási útja pedig az Ön által készített git klón. Hogy a három hogyan illeszkedik egymáshoz, azt az Atlassian Cloud natív korlátairól szóló írásunk foglalja össze.

Mit kell tudnia egy független Jira Cloud mentésnek

Ne funkciólistához mérje a megoldásokat, hanem a fenti konkrét hiányokhoz:

• Állítson vissza egyetlen munkaelemet az éles környezetbe — kommentekkel, csatolmányokkal, állapottal együtt, üres környezet és CSV-kerülőút nélkül.
• Tárolja a másolatokat a tenanttól függetlenül, hogy egy adminisztrátori szintű kompromittálódás vagy egy téves tömeges törlés ne vigye magával a helyreállítási példányt is.
• Őrizze meg az adatokat 30 és 60 napon túl is, az Ön tényleges kötelezettségének megfelelő ideig — és tegye bizonyíthatóvá a megőrzést.
• Kezelje együtt a Jirát, a Confluence-t és a Bitbucketet, mert egy kiadási folyamat mindhármat érinti, a félig visszaállított kiadási folyamat pedig nem visszaállított folyamat.
• Tegye módosíthatatlanná a másolatot, hogy a megőrzési idő alatt ne lehessen szerkeszteni vagy törölni. A módosíthatatlan mentés pontos fogalom, és érdemes megnézni, egy adott megvalósítás mit ért alatta.
• Legyen tesztelve. Az a visszaállítás, amelyet még soha nem hajtottak végre, csak feltételezés.

A legtöbb csapat ugyanabba az irányba téved: abban bízik, hogy az Atlassian 60 napos kukája a védőháló, és nem veszi észre, hogy éppen azokra a törlésekre nem terjed ki, amelyek statisztikailag a legvalószínűbbek.

Hol érdemes kezdeni

Kezdje azzal, hogy végiggondolja: mit tenne, ha ma reggel valaki törölt volna 50 munkaelemet. Ha az őszinte válaszban szerepel egy második Jira-környezet felállítása, megtalálta a hiányt. Segítünk kiválasztani, melyik mentési megközelítés illik az Ön Atlassian-környezetéhez, és segítünk bevezetni és ellenőrizni is — beleértve az első tesztvisszaállítást, hogy a helyreállítás ne papíron létező képesség legyen.

Töltse ki ingyenes felmérésünket, és feltérképezzük a Jira Cloud helyreállítási hiányait a tényleges megőrzési kötelezettségeihez mérve. Arról, hogy pontosan mit fedünk le, az Atlassian Cloud oldalunkon olvashat bővebben.