Weblabor

A rendszergazda és fejlesztő örök ellentétét feloldani hivatott összevont szakmát modern szóval DevOps-nak (Development and Operations) hívják. Ez nem csak azt jelenti, hogy mindkét szakterületet ismerni kell, hanem mindkettő gondolkodásmódját egybe kell ötvözni. Egy részletes leírás természetesen egy könyvet is kimerítene, de nézzünk néhány sarokpontot.

Monitorozás

Az első és egyben legfontosabb pont a monitorozás. Ebből két félét szoktunk használni: a riasztást és a mérést. A riasztás lényege, hogy a rendszer valamilyen elváltozása esetén riasztjuk az ügyeletest. Ez lehet számszerű elváltozás (például a feliratkozók száma az elmúlt 10 percben) vagy egy adott szolgáltatás elérhetetlensége. Erre célszerű egy SMS küldő rendszert kötni vagy ha 24/7 ügyfélszolgálatunk van, a riasztást rájuk bízni. (Ez utóbbiról még lesz szó később.) A mérés hosszú távú adatgyűjtést jelent a rendszer számszerű adatairól. Ilyen lehet például a feliratkozók száma, az oldal betöltési ideje, stb. Semmiképpen ne keverjük össze ezt az üzleti statisztikával.

A monitorozás legnehezebb része azt kitalálni, hogy mit monitorozzunk. Erre nincs általános recept, ezt alkalmazásonként kell kitalálni. Nem érdemes minden lehetséges adatot monitorozni, hiszen akkor megfulladunk az adatmennyiségben. A legfontosabb az, hogy ha egy téves riasztás van vagy valami elromlik anélkül, hogy észrevennénk, addig finomítsuk a monitorozási stratégiánkat, amíg pontos nem lesz. A lehető legrosszabb az, ha elsiklunk az ismert téves riasztások felett.

Noha úgy tűnik, hogy a monitorozás a rendszergazda feladata, fejlesztőként is sokat tehetünk azért, hogy az alkalmazásunkat könnyebb legyen üzemeltetni. Először is tanuljunk meg a monitorozó rendszerhez kiegészítőket írni. Egy Munin vagy Nagios plugin 10-20 sorból megvan és a kedvenc programnyelvünkben írható, ezzel megkönnyítve a rendszerhez való kapcsolódást. Arra is figyeljünk, hogy a rendszerünk komponenseiről, különösképpen a külső szolgáltatókról (Twitter API, banki kapcsolódás, stb) legyen egy pontos leltárunk és egy funkcionális ellenőrzésünk. Nem elég azt ellenőrizni, hogy az adott szolgáltatáshoz lehet-e kapcsolódni, hanem ellenőrizni kell, hogy valóban működik-e, ezt pedig csak a programkódból lehet hatékonyan megtenni.

Természetesen senkinek nincs korlátlan ideje, így a felsorolás szintjéig nézzünk néhány nyílt forrású monitorozó szoftvert:

• Nagios: első sorban riasztásra használatos, de lehetőség van mérésekre is. A megjelenítő felület meglehetősen... impresszionista. Az egyszerű telepítés kedvéért érdemes megnézni az OMD-t is.
• Munin: mérésekre alkalmas. Távoli gépekről szed össze meghatározott időpontokban információkat és grafikont készít belőlük. Sajnos meglehetősen erőforrás igényes és alapbeállításon csak 5 perces felbontást tud produkálni.
• Zabbix: mind mérésre, mind riasztásra alkalmas. Meglehetősen jó a megjelenítő felülete és a dokumentációja is.
• collectd: meglehetősen pontos adatgyűjtő, sokkal részletesebb felbontást tesz lehetővé, mint az előbb említett Munin.

Ezen kívül természetesen kis millió rendszer van. Ezekről a Wikipedián van egy elég jó összehasonlító táblázat.

Monitorozó felület

Arra is érdemes időt áldozni, hogy egy olyan monitorozó felület álljon elő, amely szemlélteti a számunkra fontos dolgokat logikailag csoportosítva. Mivel egy rendszerhez több monitorozó szoftver is szükséges lehet, érdemes egy saját programot készíteni, amely az ezekből érkező adatokat megjeleníti. Nagyon fontos, hogy ez a felület írja ki a legutóbbi frissítés időpontját, hiszen nincs rosszabb, mint ha elavult adatokat látunk.

A megjelenítendő adatok között lehetnek például a legutóbbi mérési adataink grafikonjai, a fizikai és virtuális gépeinket, valamint rajtuk levő a szolgáltatások állapotait színekkel feltüntetve.

Ha a költségvetésünk engedi, a monitorozás eredményét jelentessük meg az irodában egy különálló képernyőn. Munka közben kevesen nézik a monitorozó rendszereket, így ez elősegíti a hibák felismerését. Erre a feladatra célszerű egy barebone PC-t üzembe állítani.

A DotRoll monitorozó felülete. Az első képernyőn a Muninból kinyert grafikonok vannak HighCharts-al rajzolva, mellette pedig az ügyeleti beosztás. Alul a support chat kérés jelzőikonja és egy óra. A második képernyőn a virtuális gépek gazdagépei és a fizikai gépek, ezek egészségi állapotai szinekkel jelölve, valamint az aktuális riasztások és a Syslog. A képekért köszönet a DoclerWeb Kft-nek.

Készenlét/ügyelet

Lazán kapcsolódik a monitorozáshoz az ügyelet intézménye, hivatalos nevén a készenlét. A magyar munkajog szerint egy hónapban legfeljebb száznyolcvan óra készenlét rendelhető el, az ügyeleti beosztást pedig egy hónappal előre ismertetni kell. A készenlét részleteiről a 1992. évi XXII. törvény rendelkezik.

Tapasztalatom szerint a készenlétet úgy érdemes beosztani, hogy mindig a hét közepén legyen váltás, hiszen így elkerülhetők a hosszú hétvégékkel kapcsolatos csereberék. A rendszerünket mindenképp úgy építsük ki, hogy a rendszert felügyelő személy vagy monitorozó rendszer mindenképpen legyen tisztában az ügyeletes személyével illetve hogy milyen telefonon lehet elérni, hiszen ha valakit a készenléti idején kívül zavarunk folyamatosan, az jelentős stressztényező lehet. Mindenképpen tegyük lehetővé, hogy a készenlét alatti munkavégzés után elegendő pihenőidő álljon rendelkezésre, hiszen ha valamelyik munkatársunk nem pihente ki magát rendesen, hibákat fog csinálni és egy nagy rendszernél a figyelmetlenségek könnyen komoly problémához vezethetnek.

Dependency map

Mind a rendszergazdáknak, mind a fejlesztőknek tisztában kell lenniük a munkájuk következményeivel, ezért érdemes a rendszerre egy szolgáltatás-szintű függőségi gráfot készíteni. Ezen fel kell tüntetni, hogy mely szolgáltatás leállása mely további szolgáltatásokat érint. Ez könnyen izolálhatóvá teszi azokat a problémákat, amelyek a monitorozó rendszerben több tucat szolgáltatás riasztását idézik elő.

Vegyük például az egyik legsarkallatosabb szolgáltatást, a DNS feloldást. Ha ez leáll, akkor valamennyi olyan szolgáltatás, amely domain név alapján kapcsolódik, riasztani fog. Szerencsétlen esetben ez akár több száz szolgáltatás is lehet. Amennyiben olyan személynek kell megkeresnie a hibát, aki nincs tisztában a rendszer működésével, akár több óra is eltelhet, amíg megtalálja az okát.

Szerver/szolgáltatás nyilvántartás

A függőségi gráfhoz könnyen hozzákapcsolható egy nyilvántartás arról, hogy milyen gépeken milyen szolgáltatások milyen címen futnak. Ez praktikus akkor, ha a rendszerben keresünk valamit, hiszen egy nagy terhelésű rendszerben egy adott IP cím nem feltétlenül csak egy gépen van és senkinek nem káptalan a feje. A szolgáltatásoknál mindenképpen jelezzük, hogy mennyire redundáns és milyen esetben kell riasztani a készenlétben lévőt. Műszakilag semmi bonyolultat nem kell elképzelni, elegendő, ha ezeket az adatokat egy közös Excel fileba visszük fel.

Logolás

A monitorozás mellett a logolás is nagy mértékben elősegíti egy rendszer üzemeltetését. Gondoskodjunk tehát róla, hogy a rendszerünk syslogot használjon és az adatok egy központi logszerverre érkezzenek. Az alkalmazásunk és a futtatókörnyezet is logoljon ide. Ha valamelyik komponens stack tracet (hívásfát) készít, azt mentse le a helyi gépre és a trace file neve kerüljön be a logüzenetbe.

Ügyeljünk arra, hogy a log áttekinthető maradjon. Mint a monitorozásnál is, itt is menjünk utána a hibáknak és takarítsuk ki a logot. A logüzeneteket típus szerint válogassuk szét és külön mentsük őket. Készítsünk egy megjelenítő felületet, ahol a fejlesztők ellenőrizni tudják a logot.

Biztonság

Évekig lehet egy szolgáltatást üzemeltetni úgy, hogy nem frissítjük a szoftvereinket és nem törik fel. Erre azonban semmi garancia nincs, hiszen ha elég nagyra növünk, akkor könnyen problémát jelenthet. Ez különösen kínos akkor, ha a rendszerünk ezekre a régi verziókra épít és senki nem meri frissíteni, mert elromlik valami. Az ökölszabály tehát az, hogy minden rendszert azonnal frissíteni kell, ha valamilyen sebezhetőség nyilvánosságra kerül akkor is, ha ezért a szolgáltatást le kell állítani.

Ami a saját rendszereink biztonságát illeti, béreljünk egy külső szolgáltatótól egy virtuális gépet és írjunk egy scriptet, amely naponta végig futtatja az nmap programot az általunk használt IP címeken. A script vesse össze az előző napi adatokkal és amennyiben változást tapasztal a nyitott portokban, mindenképpen riasszon.

Ezen felül rendszeresen ellenőrizzük az alkalmazásokat sebezhetőség scannerekkel. Ehhez rengeteg eszköz áll rendelkezésre, a legegyszerűbbek Firefox pluginként érkeznek, mint például az XSS Me vagy az SQL Inject Me.

A rendszerünkbe mindenképpen építsünk audit-jellegű logolást és ne legyünk restek a jelszóvédelmet úgy megírni, hogy ne legyen könnyű scriptelni. A legtöbb támadást ún. script kiddie-k végzik a netről letölthető eszközökkel, ezek pedig csak egyszerű űrlapokkal boldogulnak. Már az is segít, ha beépítünk egy plusz mezőt, amelyben egy véletlen kulcs van, ami időnként változik. Azt is megtehetjük, hogy bizonyos számú próbálkozás után kidobunk egy captcha-t, mint azt a Google is teszi.

Dokumentáció

Talán szükségtelen lenne mondani, de ha valamilyen nem szabványos megoldást használunk, akkor azt mindenképpen dokumentáljuk és szóban is említsük meg a kollégáknak. Itt gondolok például az olyan megoldásokra, amikor egy szolgáltatást speciális módon kell elindítani.

Általánosságban véve a dokumentációnkat tartsuk egy helyen, ahol bárki a csapatból hozzáférhet. Lehetőleg rendszerezzük egy előre megírt tartalomjegyzék szerint az ismereteket, hogy bárki könnyen bővíthesse. Olyan Wiki szoftvert válassunk, amely egyszerűvé teszi a dokumentáció írást. Ebből a szempontból a Redmine nagyon használhatónak mutatkozott.

Fejlesztői/teszt környezet

A fejlesztői és a teszt környezet kiépítése létfontosságú. Ha a fejlesztők úgy dolgoznak, hogy közvetlenül az éles rendszerbe másolnak ki kódot, bármikor elromolhat bármi és vissza sem tudjuk vonni a változásokat. Készítsünk tehát az éles rendszerrel a legmesszemenőbbekig megegyező környezeteket a fejlesztőknek. Fontos, hogy minden fejlesztőnek legyen saját kódbázisa, adatbázisa, stb. hiszen ha egymás munkájába nyúlnak bele, akkor adott esetben felesleges szellemvadászatnak tesszük ki őket.

Gondoskodjunk róla, hogy a fejlesztőinknek legyen verziókövető rendszere és azt tudják használni. Noha elvárás lenne, de valójában nagyon kevés fejlesztő érti a verziókövető rendszer működését és csak találomra kattintgat a hozzá adott felületen. Tartsunk oktatást, workshopot és hagyjuk, hogy teszt projekteken ténylegesen ki is próbálják a műveleteket. Ha választanunk kell verziókövető rendszert, mindenképpen olyan mellett döntsünk, amely könnyűvé teszi a branchelést, hiszen így könnyű az egyes funkciók fejlesztése között váltani. Ilyen rendszerek például a git vagy a Mercurial.

A tesztkörnyezet kiemelt fontosságú, hiszen itt tudja a vezetés vagy akár a fejlesztők is megtekinteni az aktuális legfrissebb verziót. Gondoskodjunk róla, hogy ide automatikusan mindig kikerüljön a legfrissebb verzió! (Ezt hívják continuous integrationnek.) Ezt könnyebbé teszik az olyan eszközök, mint a Jenkins CI.

Építsünk ezen felül egy második tesztkörnyezetet is, ahová a fejlesztők kézzel élesíthetnek akár egy branchből is, hiszen néha szükséges egy funkció tesztje vagy demója is.

Unit tesztelés

Az egységtesztelés egy érdekes téma. Mindenki beszél róla, de valójában nagyon kevesen csinálják. Alig tudok olyan nagyobb projektről, ahol a teljes teszt lefedettség eléri az 50%-ot. Ennek nagy többségében az az oka, hogy a módosítási kérések túl gyorsan jönnek, túl rövid határidővel, így nehéz a teszteket elkészíteni. A helyes stratégia itt az, hogy ha választanunk kell, a rendszerünk magja legyen letesztelve. Egy-egy önálló funkcionalitást sokkal könnyebb utólag ellátni tesztekkel, mint az üzleti logikánkat, számlázó rendszerünket, stb. amire minden más modul épít.

A teszteknél mindenképpen gondoskodjuk arról, hogy egyszerűen és gyorsan futtathatóak legyenek. Ha egy a tesztek futtatására alkalmas környezet kiépítése órákba telik és még le sincs dokumentálva, akkor senki nem fog teszteket futtatni. Ezt persze könnyebb mondani, mint megcsinálni. A valóság az, hogy a legtöbb projektben a tesztek nagyon nehezen futtathatóak, kell hozzájuk teszt adatbázis vagy teszt adat. Ha mást nem tudunk, akkor mindenkinek biztosítsunk teszt adatbázisokat és dolgozzunk ki egy megoldást, amellyel megbízhatóan ki tudjuk törölni az éles adatbázisról készített mentésben az érzékeny vagy felesleges adatokat a teszteléshez.

Nagyon figyeljünk és hívjuk fel a fejlesztő kollégák figyelmét is arra, hogy a tesztek semmiképpen nem futtathatnak potenciálisan veszélyes műveleteket. Ugyan a rendszergazdák feladata biztosítani, hogy ne eshessen kár az éles adatokban, de az ördög sosem alszik.

Arról is gondoskodjunk, hogy a unit tesztek minden teszt rendszerre történő élesítéskor is fussanak le, az eredményük pedig jelenjen meg a monitorozó felületen jól látható helyen.

Funkcionális tesztelés

A fejlesztés egyik legátkozottabb problémája a tesztelés. Még egy jól megírt kód esetén is előfordul az, hogy véletlenül egy egészen más helyen eltörünk valamit. Ha kellően nagy az alkalmazás, akkor a teljes tesztelése meglehetősen időrabló tevékenység, így legtöbbször kimarad. Szerencsére van erre is megoldás. Webes alkalmazások tesztelésére találták ki a Selenium teszteket, amelyeket akár Firefox böngészőből is futtathatunk. Ha több gépen szeretnénk tesztelni, érdemes egy teszt clustert építeni barebone PC-kből vagy virtuális gépekből és azokat a Bromine nevű szoftverrel távvezérelni. Nagyon fontos szabály, hogy minden fejlesztő saját maga írja meg a teszteket az új felületekhez, különben ez a feladat el fog kallódni.

Mondanom sem kell, ezen tesztek eredménye is kapjon helyet a monitorozó felületen.

Deployment (élesítés)

Ha az alkalmazásunkat az éles rendszerbe szeretnénk helyezni, azt célszerű automatizálni. Tegyük lehetővé bármelyik fejlesztőnek, hogy élesíthessen. Ha bonyolult az élesítés, az egyes funkciók élesítése össze fog torlódni és ezzel megnöveli az esélyt arra, hogy hiba történjen.

Mindenképpen készítsünk egy olyan nyilvántartást, hogy egy adott környezetben milyen adatbázis módosítások futottak már le és melyek még nem. Ez akár egy szövegfájl is lehet, amit a verziókövető rendszerünkben tárolunk és helyileg egy scripttel frissítjük az adatbázist. Ez elősegíti a fejlesztői környezet karbantartását.

Az élesítésre alkalmas például a Capistrano vagy a Phing. Érdekességként érdemes megnézni a Facebook vagy a Twitter megoldását a problémára.

Konfiguráció menedzsment

Ha sok szervert üzemeltetünk, macerás kézzel telepíteni a szervereket és a későbbi újratelepítés is problémás. Éppen ezért érdemes olyan konfiguráció menedzsment szoftvereket használni, mint a cfengine vagy a Puppet. Ezekkel le lehet írni, hogy egy adott szerepkörbe tartozó gépen milyen szoftvereket kell telepíteni.

Természetesen a konfiguráció menedzsment állományait is tartsuk verziókövető rendszerben és egy tesztrendszeren próbáljuk is ki. Mivel a fejlesztéshez különleges beállítások szükségesek, erre érdemes egy külön tesztrendszert készíteni, amely akár szorosan össze is függhet az éles rendszerrel. Ha például clusterről beszélünk, egy gép lehet mindig a prototípus, amelyen kipróbáljuk a frissítéseket, hiszen másképp nem lesz valós forgalom rajta. Ezt a gépet legyen könnyű kivenni a clusterből.

Biztonsági mentés

Mörfi szerint ami tönkre tud menni, az tönkre is megy. Közkeletű tévedés ugyanakkor, hogy a lemezek tükrözése megvéd az adatvesztéstől, hiszen egy betörés esetén ez nem segít. A mentést tehát mindenképpen meg kell csinálni. Több féle jól bejáratott mentő szoftver van, ilyenek például a Bacula vagy az Amanda. Érdemes arra odafigyelni, hogy a mentések ne terheljék túl a rendszert, viszont megfelelően frissek legyenek.

Bizonyos adatok esetén viszont még a mentés sem véd meg az adatvesztéstől. Ilyen például az e-mail tárolás, hiszen ha a levelek az érkezésüket követő pár percben törlik, akkor azok egyetlen mentésben sem lesznek benne. Ilyen esetekre érdemes növekményes adattárolást készíteni, tehát a levelező szerver esetén egy második szerver, amely minden levelet ment.

Adatbázis mentésnél lehetőleg építsünk master-slave replikációt és a slave replikáról készítsünk mentést úgy, hogy az összes táblát zároljuk. Így megnő az esélye, hogy konzisztens mentést kapunk.

Rendszeres karbantartás

A szerverek merevlemezei és a rajta levő fájlrendszereket legalább évente érdemes karbantartásnak alávetni. A karbantartás helyett azonban célszerű lehet a gépeket újratelepíteni, így ugyanis a konfiguráció menedzsment rendszert is tesztelni lehet. Ha már újratelepítjük a rendszer részeit, ne felejtsük el a biztonsági mentéseink visszaállítását is tesztelni.

Oktatás

Egy sikeres DevOps csapatban nem elég egy ember, aki mindkét szerepet el tudja látni, hiszen ennek az embernek is el kell mennie szabadságra. Éppen ezért célszerű tudatosan, akár minden héten péntek délután workshopot tartani. A fejlesztők telepítsenek Linuxot, a rendszergazdák pedig írjanak kódot. Ha a fejlesztők eddig csak PHP-ban fejlesztettek, kezdjenek el kisérletezni Linuxos daemont írni. Vegyük elő a jó öreg Tanenbaum könyvet és saját magunk is tanuljunk.

Bélyegképnek SkinheadSportBiker1 fotóját választottuk.