Sok szó esik az utóbbi években a DevOps-ról, amely a fejlesztők és üzemeltetők közti nagyon szoros együttműködést jelenti. Noha ez a cikk nem a DevOps-ról fog szólni, e rövidítés jól kifejezi a két nagy klasszikus terület kapcsolódását egy IT-részlegen belül: Development és Operations. A Development valamivel népszerűbb, és méltán az, hiszen döbbenetes mennyiségű fejlesztőre van szükség. Ráadásul ez még csak a kezdet: az USA-ban már a kamionsofőröket képzik át programozókká… No, de nem lehet mindenki fejlesztő, még az informatikusok közül sem. Ám nem is akar mindenki naphosszat kódolni. Lehet, hogy téged is jobban érdekel az Operations, csak esetleg még nem tudsz róla. :)
Erről ugyanis általában kevesebb szó esik, talán mert hajlamosak vagyunk azt gondolni, hogy az IT-infrastruktúra az csak úgy van és működik. Telepítesz egy operációs rendszert, arra egy adatbázist és egy alkalmazásszervert, azután az egész megy magától. Ez igaz is mondjuk a laptopodon. De mi történik akkor, ha nem egy gép áll a rendelkezésedre, hanem mondjuk száz, ugyanennyi operációs rendszerrel, ötszáz adatbázissal és ezer felhasználóval? Itt már nem biztos, hogy működik a DevOps. Ehhez már kell egy külön, dedikált Ops csapat. Az Ops viszi a vállán az infrastruktúrát, biztosítja a stabil működését, és adott esetben együttműködik a Dev csapattal is, információt kér tőlük vagy éppen tanácsokkal látja el őket. Ez egy szerteágazó, érdekes és kihívásokban gazdag terület.
Mit csinál egy DBA?
Én kicsit több mint öt éve dolgozom az Ops világban, ezen belül is főleg DB Ops-ként, avagy DB-adminisztrátorként, röviden DBA-ként. Most ezt a világot szeretném megmutatni egy kicsit közelebbről. Mit is csinál egy DBA? Egy adatbázis nem csak annyi, hogy feltelepítjük, elindítjuk, aztán adatokat teszünk bele meg olvasunk ki belőle? Nem egészen.
Először is az adatbázist valamilyen céllal hozzuk létre, ehhez kapacitást kell tervezni és a telepítéskor ennek megfelelően elvégezni a konfigurációt. Ezt követően ki kell alakítani benne a felhasználási célhoz szükséges struktúrákat, beállítani a felhasználókat, a jogosultságokat, stb. Ha ezek elkészültek, akkor mehetnek bele az adatok, indulhat a használata. Mindez többnyire a DBA feladata.
Ha sok felhasználó konkurensen használ egy adatbázist, azok munkamenetei bizony néha összeakadnak, még akkor is, ha a beépített zárolási technikák alapvetően biztosítják a tranzakciók izolációját (és az adatok konzisztenciáját, lásd: ACID). Egy ilyen összeakadás megoldása például a DBA feladata: a felhasználókkal együttműködve kell találni egy gyors megoldást, hogy az üzletmenet ne akadjon meg nagyon. Emellett, adott esetben az alkalmazás, a lekérdezések áttervezésében is segédkeznie kell.
Idővel előkerül az a probléma is, hogy az adatbázis teljesítménye nem megfelelő. Ennek számos oka lehet, a megnövekedett adatmennyiségtől kezdve az átmeneti terhelésnövekedésen át a nem megfelelő használtig. A hatékony megoldás megtalálásához a DBA-nak ismernie kell az adatbázis-kezelő rendszer belső lelki világát, amely igen-igen komplex. Évek, mire az ember kezdi tényleg érteni, mi történik a motorháztető alatt. Ez a tudás szükséges ahhoz, hogy meg tudja javítani magukat a lekérdezéseket is, amelyek a fejlesztőktől jönnek, hiszen sokszor a nem megfelelően megírt SQL-utasítások, adatbázisban tárolt programok okozzák a lassú működést.
A fejlesztéshez is érteni kell
A fentiekből talán látszik, hogy a a DB Ops-nak a DB Dev-hez is elég jól kell értenie. Bár egy DBA nem ismeri teljes egészében az adatbázis belső működését, és általában nincs ideje teljes egészében megérteni az üzleti logikát sem, a két terület információit kombinálva kell a legjobb tudása szerint tippelnie és megoldást nyújtania. Olyan rendszereket kell átlátnia, amelyeket nem ő írt, de csak éppen addig a szintig, ami a megoldáshoz elegendő.
Az adatbázis-kezelő szoftvert is frissen kell tartani, biztonsági szempontból és funkcionálisan egyaránt. Ha mindezt úgy kell elvégezni, hogy közben nem engedélyezett kiesés a működésben, vagy csak egy szűk időablakot dedikál erre az üzlet, az már komolyabb előkészületet igényel. Ha az elvárttól eltérő, bug-gyanús működést észlel a DBA, akkor fel kell vennie a kapcsolatot a gyártóval, és az ottani mérnökökkel együttműködve kell megoldást keresnie a problémára.
És eddig még csak egyetlen adatbázisról volt szó. Egy komolyabb cégnél ennél sokkal szélesebb körű tudásra van szükség. Hibatűrő megoldások kellenek, nagy rendelkezésre állást kell tudni biztosítani, adatokat kell szállítani egyik adatbázisból a másikba. Komplex mentési stratégiát kell kidolgozni. Érzékeny adatok esetén biztonsági szempontból auditálni kell az adatbázisban zajló tevékenységet. Végül az adatbázisokat több szempontból monitorozni kell. Ezek mind-mind különálló technológiák, még akkor is, ha egy cég szállítja őket.
Láthatatlanság = profi teljesítmény
Azon túl, hogy naprakész ismeretei vannak a DBA-nak a különböző adatbázis-technológiákból, és az operációs rendszer alapjait jól ismeri (ez szinte mindig Linux, vagy ehhez hasonló rendszer), ezt a tudást éles helyzetekben is be kell tudni vetnie. A legnagyobb kihívás talán az, amikor egy éles rendszerhez kell hozzányúlni és gyors, hatékony megoldást adni. Ilyenkor elég egy pici mellényúlás, és órákra megbénul a rendszer. De ha a DBA mindent jól csinál, akkor tényleg azt hihetik a többiek, hogy az infrastruktúra ezen része csak úgy magától működik.
Most ennyi fért ebbe a cikkbe. Ha érdekesnek találtál valamit a fentiekből, ha örömmel lennél egy olyan csapatnak a része, akik a stabil informatikai hátteret biztosítják, akkor jelentkezz az ingyenes DBA-oktatásra, ahol részletesebb áttekintést kapsz az adatbázis-adminisztráció alapjairól.