Miért nincs probléma nálunk rendszergazdák és fejlesztők között

Először is, nálunk rendszergazda szó szerint nincs is. Leginkább csak mérnökök vannak: megtervezik az egységes szerver konfigokat és egyéb hálózati hardvereket meg a desktop gépeket is, egységes OS-t raknak rájuk, a szerverekre egy orchestration réteget, afölé meg sok-sok szolgáltatás szoftverét. Ez mind sok-sok külön csapat. Egy részük software engineer, más részük site reliability engineer. Meg vannak persze technikusok vagy nem tudom hogy hívják, akik a hardvereket fizikailag pakolgatják, velük még nem találkoztam.

Rendszergazdák egyik kedvenc témája a root jog a desktop gépeken. Nálunk van. Kellhet egyedi szoftvereket telepíteni, szolgáltatásokat állítgatni-indítgatni, hálózatot izélgetni, stb. Sokkal egyszerűbb az élet roottal, anélkül a rendszer szívatna minket. Miért nincs belőle gond? Kártékony szoftverek és magatartás ellen természetesen van védelem, meg policyk, és ha valaki kinyírja a gépét, negyed óra újratelepíteni az egységes image-ből, minimális interakcióval. Tehát ilyen gonddal meg mi nem szívatunk rendszergazdákat.

Másik gyakori dolog, amit rendszergazdáktól hallok, hogy fejlesztői szemétdomb. Ilyen nincs.

Nézzük előbb forrás oldalról. Egységesen Bazel-szerű build rendszer van a reljes forráskód repóban, aminek egyik fő erénye a reprodukálható és izolált buildek. Bármi forrást kicsekkol valaki, az pöccre le fog fordulni. Akár új ember először a csapat projektjét, akár egy random ember egy másik random team projektjét. Láttam már olyat korábbi munka során, ahol a forráskód első buildje egy soklépéses, transzcendentális folyamat volt (ezt másold ide, azt installáld, amazt a scriptet futtasd le, ha valami nem fordult elsőre, akkor másodikra már jó volt, stb.). Egy jó build rendszeren rengeteg minden múlik. Ha leülök egy újonnan telepített gép elé, percek múlva már produktívan kódolni tudok. Meg persze van egységes formázás, automatikusan és folytonosan futó tesztek, code review, stb., tehát nem csak fordul a kód, de működik is.

Ha meg van írva a szoftver, először le kell tesztelni lokálisan. Futtatni akarod? Bazel run és már megy is, lehet neki küldeni a requesteket. Úgy szokás, hogy a build fájlban megvannak azok a default configok, amikkel simán elindul a szolgáltatás. Ehhez nem kell rendszergazdai segítség, sem VM, nem kell még igazi szerveren futtatni sem, lokálisan is már nagyon hasonlít az igazira. Tesztelni akarod? Bazel test és már megy is. Pici unit teszttől durva nagy integrációs tesztig minden fut vele. Mock, fake, másik csapat szervere sandboxban, ez mind elérhető általában. Nagyon egységesen vannak kialakítva az interfészek, nem szokott nagy varázslat lenni, hogy két rendszer beszélgessen egymással.

Most jön a relevánsabb rész, igazi szerveren kell futtatni valamit. Itt is van dev, meg prod, meg ilyesmi környezetek, de hardveresen mind ugyanaz. K8S-szerű orchestration van. Nekem két dolgot kell hozzá csinálni: csomagot a forrásból (Bazel megoldja, kb. statikusan linkelt binárist szül, tehát nem kell hozzá semmi egyéb, hogy fusson rögtön bárhol), és egy config fájlt (amiben benne van, hogy hány példányban fusson, mennyi CPU, RAM, port, stb. kell neki, lokális diszk nincs). Fellövöm és fut. Egyszerű API-ja van, fejlesztőként is triviális használni segítség nélkül. Kapacitás van elég, persze nagyobb dolgokhoz szükséges erőforrást tervezni, de kisebbekhez nem. Devben megnézem, hogy működik-e, illetve lehet rajta load testet csinálni, erőforrás igényeket masszírozni, aztán ha minden jó, mehet prodba. Continuous delivery-szerűség van, ha egyszer elindult, akkor utána már könnyű rávenni, hogy magától frissüljön pl. naponta, prod-ot is beleértve (ha megírtam a kellő magabiztosságot adó automatizált teszteket). A végletekig automatizálva van minden lépés, szinte varázslat (de nem úgy varázslat, hogy bonyolult, vagy néha megy-néha nem), telepítési kézikönyv is pl. tök fölösleges egy ilyen környezetben.

Szintén sima fejlesztőként könnyű hozzá monitoringot, alerteket gyártani. Loggolásra, debuggolásra, teljesítmény mérésére teljesen egységes, beépített megoldások vannak. Tehát egy egyszerűbb szolgáltatás 100% fejlesztőkkel is futni tud. Nagyobb projekteken össze lehet dolgozni egy site reliability engineer csapattal, akik elláthatnak jó tanácsokkal (megbízhatóság, skálázhatóság témakörben főleg), segíthetnek monitoringot beállítani, erőforrást tervezni, vállalhatnak ügyeletet, stb. Nagyjából ezek a felelősségkörök megfelelnek rendszergazdaságnak. (Vagy devops? Én ebben az életben már nem akarom megérteni, hogy mi az.) De inkább egy oldalon állunk, és hardverhez egyikünk se nyúl, csak az egységes production rendszerekkel dolgozunk mindketten. Mivel megvannak a határok, hogy kinek mi a dolga, és a közös cél, ezért nem jellemző, hogy egymásnak keresztbe tennénk véletlenül se.

És még egy fontos dolog: mi van, ha gáz van? Először is, legtöbbször vannak SLO-k és forgatókönyvek, tehát tudjuk, hogy ha valami nem megy, az miért baj, merre kell elindulni, és mikor sikerült megoldani. A kultúra része, hogy nincs ujjal mutogatás (blameless culture). Nincs olyan jellemzően, hogy egy személy az oka valaminek. Ha szar a kód, legalább két ember látta a review miatt. Ha szar a config, azt is, mert az is verziókezelt. Ha valaki egyszemélyesen olyan parancsot adott ki, amitől valami szétesett, az egy szisztematikus probléma (miért létezik ilyen parancs egyáltalán/miért esett szét tőle az a rendszer/miért lehet valami kritikus dolgot review nélkül izélgetni). Tűzoltás után postmortemet írunk, aminek fő célja, hogy minden érintett (vagy más is) tanulhasson belőle, és kiosztjuk a feladatokat, hogy hogyan lehet még megbízhatóbb a rendszerünk.

TLDR: kultúra, kölcsönös bizalom, jól kitalált feladatkörök, igényes technológiai megoldások, automatizálás -> mindenki produktív.