Tiszta infrastruktúra, 1. rész — Ha fáj, csináld gyakrabban! — Refaktor Magazin

Amellett, hogy ez egy bevezető cikk és nem óhajtok mindjárt mindent a kedves olvasó nyakába önteni, ezek olyan dolgok, amiket sajnos sikerült megtapasztalnom mindenféle rendszerek auditja kapcsán.

* Élesítés/deployment frekevencia: itt pont az üzlet az, ahol sokszor szembe jön az, hogy jó lenne élesíteni, de mindig egy hatalms erőfeszítés és kell hozzá rendszergazda, satöbbi, és éppen ezért vannak gigareleasek havonta egyszer, amik egész embernapokat emésztenek fel. Lássuk be, ha Te ITIL-el dolgozol és van rendes release folyamatod, akkor ez számodra nem egy fájó pont, mert tudod, hogy hogy kell csinálni, ergó ez rád nem vonatkozik. Rengeteg cégnél, rendszerben ez sajnos azonban megoldatlan probléma és igenis szükség van azokra az olyan mankókra, hogy 4 után ne élesíts, mert jó eséllyel valaki szívni fog. (Erre egyébként lehetne egy kérdés itt a hupon, hogy ki dolgozik release folyamatokkal.)

* Élesítés/deployment automatizálása: nincs azzal baj, ha valaki felelős a release-ért. Akkor van gond, ha a release maga sok manuális (és ezáltal elrontható) munkával van összekapcsolva, pl. el kell készíteni a tar.gz-t, meg kell kérdezni a fejlesztőt, hogy melyik adatbázisokban mit kell módosítani, stb. Ez az esetek jó részében ahhoz fog vezetni, hogy kimegy élesbe, és valami nem működik. Ha gyakrabban csinálod, jó eséllyel automatizálod azokat a részeket, amik problémásak, sok hibát okoznak. Megint csak egy olyan dolog, ami meglepően sok enterprise-grade rendszerben is előfordul. Plusz azt ne felejtsük el, hogy elég sok cég erőforrás-hiányos környezetben dolgozik, messze nincs annyi üzemeltető amennyire szükség lenne. Ha nekik kell asszisztálni minden egyes releasehez, ez még inkább rontja a helyzetet, mert nem lesz idejük az olyan dolgokra, hogy ne futtassunk már fél éves lukas kernelt.

* Szerver újraindítás: alapvetően ez nem feltétlenül disaster recovery kérdés, sokkal inkább a lappangó SPOF-ok kérdése. (Itt megint nem enterprise rendszerekről beszélek, bár ott is vannak csúnyaságok.) Rengeteg rendszerben vannak "szent" gépek, amikhez nem szabad hozzányúlni, nem szabad újraindítani, mert azokon valami van. Jobb esetben tud róla az üzemeltetés, rosszabb esetben nincs is tisztában vele.

* Gép újratelepítés: nálam az automatizálás eljutott arra a pontra, hogy ha új szoftver verzió van, simán felhúzok egy új gépet 30 másodperc alatt, és azon tesztelem a szoftvert. Ez nem feltétlenül jelenti a production gép leváltását, de erre is van példa. Ami a Dockert illeti, az szép és jó, hogy van Docker, de azt a problémát nem oldja meg, hogy a Dockerben futó szoftvernek is szüksége van mindenféle konfigurációra, stb. amit nem elég egyszer legyártani és utána idők végezetéig az adott containert használni. Éppen ezért a Dockerről lesz még szó a későbbiekben, hogy mit érdemes csinálni, és mit nem.

Összegezve: a cikkben olyan problémákat próbálok felhozni példaként, amik tipikusan sokszor előfordulnak, amit a legtöbb olvasó tud valahova kötni. Az remélhetőleg egyértelmű, hogy nem mindenkire alkalmazható egyformán, és nem lehet mindenre kitérni. Az olyan módszerekről, mint az ITIL, meg kifejezetten kevesen hallottak, és még kevesebben tudják, hogy az micsoda. Ha ez nem így lenne, nem lenne igény a cikkeinkre. (Bárcsak így lenne!)

Ha van kedved írni egy OP-ED-et vagy kritikát, azt természetesen szívesen közöljük. Vagy megvárod a későbbi cikkeket, ahol jobban kitérünk a dolgok gyakorlati oldalára.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin