Nagy terhelésű rendszerek fejlesztése 4. – Üzemeltetés
![Nagy terhelésű rendszerek fejlesztése 4. – Üzemeltetés](http://weblabor.hu/misc/fs/nagy-terhelesu-4-ikon.jpg)
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
A sorozatban megjelent
- Nagy terhelésű rendszerek fejlesztése 1. – Alkalmazás-evolúció
- Nagy terhelésű rendszerek fejlesztése 2.
- Nagy terhelésű rendszerek fejlesztése 3.
- Nagy terhelésű rendszerek fejlesztése 4. – Üzemelteté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.
■![janoszen arcképe](/misc/userfaces/3563.jpg)
DevOps meetup
Hozzászólás
Nincs kérdés, nagyon hasznos
Jó kis összefoglaló! A unit
A unit tesztelős rész sajnos nagyon igaz...például nagyon sok álláshirdetésbe beleírják a cégek (itt Nagy-Britanniában is), hogy értened kell a unit teszteléshez. Végül mindig kiderül, hogy nem is használják se itt, se ott. De komolyan hangzik...
A Selenium-ra mutató link hibás a szövegben.
Adatbázis mentés
Ha szabad belebeszélnem...
Sajnos csak Oracle-lel van tapasztalatom (meg nagyon kevés DB2), ott nincs szükség replikációra (ha nem gond egy esetleg hosszabb kiesés - ha gond, akkor is van több megoldás), pusztán az archive log módot kell bekapcsolni és... Ha érdekel valakit, pár sorban összefoglalhatom, de tartok tőle, aki itt Oracle-t használ, az ért is hozzá ennyire.
Írd le nyugodtan.
Webes rendszerek
Elterjedtek, de nem
Egyébként könnyen lehet, hogy előítélet (így hirtelen megindokolni sem tudnám), de amit eddig láttam a mysql-ből, nem biztos, hogy jó szívvel bíznék rá komoly terhelést kibíró és 7x24 rendelkezésre állást igénylő rendszert. De nem mélyedtem el benne, csak amennyire a PHP tanulmányozásához, meg most a django-hoz szükségem volt rá.
Biztosan előítélet, a top 5
Jó, bennem még élénken élnek
(különösen azt nézve, hogy
Semmibe? Nem kötelező supportot vásárolni hozzá.
Másrészt valószínűleg az alacsonyabb belépési küszöb miatt terjedt el jobban.
MySQL licenc
Zárt szoftver esetén meg kell venned az Oracle-től a MySQL licencet, amivel mentesítheted magad a forrásos nyílttá való tétele alól.
Ha eladod
Critication needed
És a GPL fordítási egységről nyilatkozik, tehát minden további nélkül terjeszthetek zárt forráskódú szoftver mellett MySQL-t, hiszen két külön szoftver lesz a memóriában futtatva. Az, hogy a szoftveremnek MySQL-re van szüksége a helyes működéshez, az egy dolog.
Ami érdekes kérdés még, az a libmysql, hiszen az már nem ilyen kényelmes. Viszont ezt nem GPLv2, hanem LGPLv2 alatt terjesztik (mint ahogy a libeket általában), pont az ilyen esetek miatt, hisz különben egy átlag lib használhatatlan lenne egy zárt szoftverben.
Arról nem is beszélve, hogy a GPL csak a szoftver terjesztéséről nyilatkozik. Ergo, ha nincs terjesztés (és ebbe beletartozik a bérfejlesztés is, hiszen, ott a rendszer nem a fejlesztő anyagi tulajdona, hanem a megrendelőé), akkor semmit sem kötelező kiadni (ellenkező esetben a Google és a Facebook lenne az egyik legnagyobb GPL csaló.)
Természetesen, az egész dolog változik, amennyiben magában a MySQL-ben végzek módosításokat ÉS terjeszteni akarom. Ilyenkor a Community Edition (amely GPL alatt licencelődik) kötelez arra, hogy kiadjam a kódot.
(Mgj.: mit ne mondjak, MySQL-t jellemzően szolgáltatás részeként és nem mint termékként használnak. Innen kezdve maga a GPL sok esetben csődöt mond weben és nem váltja be az eredeti elképzeléseket.)
A kereskedelmi licenc az egy külön téma és AFAIK az is inkább általában a supportról szól.
offtopic:ha a mysql agpl
ha a mysql agpl lenne, akkor meg kepes lenne halozaton keresztul is "fertozni", de itt ugye nem errol van szo.
Tyrael
Minden alkalommal, amikor a
Legyünk már reálisak, a Facebook nagyon nem úgy használja a MySQL-t, mint ahogy a tipikus kisebb méretű oldalak (mondjuk elfér egy gépen az adatbázis). Másrészt, ha ott tűnik el egy post egy noderól, nem gáz, van még máshol is, majd leszinkronizálódik. Ha egy webshopból tűnik el egy rendelés, azért picit nagyobb a hiszti. Vagy elérhetetlen az oldal, mert épp backupol. Vagy hasonló :)
Semmi akadálya
Ami a cikket illeti, a webes rendszerek többsége tapasztalatom szerint MySQL-t használ azon egyszerű oknál fogva, hogy elterjedt, rengeteg dokumentáció van hozzá és egy új fejlesztő jó eséllyel ismeri.
Praktika
Teszteles
Szerintem a teszteles/buildeles temakoret kicsit alaposabban korul lehetne jarni, vagy kikerni a temaban jartas szakember velemenyet.
A CI legfontosabb aspektusa nem az, hogy mindig a legujabb verzio kerul a tesztkornyezetbe. Ez egy kvazi elokovetelmeny. A CI gyakorlati lenyege az, hogy rakenyszeriti a fejlesztot, hogy olyan kodot commitoljon be, ami nem rontja el a buildet. A build triggereli az acceptance tesztek lefutasat is, igy ha azok elbuknak, akkor a build sem sikeres. Ez egy early testing. Ha elbukik a build, akkor azonnal javitani kell a hibat.
Teny, hogy a tesztelok mindig a legfrissebb snapshot verziot tesztelik, de szerintem a CI kapcsan a legfontosabbak a nightly tesztek es a nightly buildek. Ezzel eselyt adunk a System Testnek is, hiszen minden nap frissen integralt rendszert tudnak tesztelni.
A tesztek kapcsan. Itt csak a komponens/unit tesztrol es csak a function tesztrol volt szo, azert az integration test es a system test is eleg fontos.
Szinten fontos szerintem kihangsulyozn, hogy melyik resz kinek a feladata. A unit teszteket tipikusan a fejlesztok irjak, es a lokalis build soran le is futtatjak. Letezik egy Jenkins plugin, ami a Sonar nevre hallgat, es code quality analizis mellett meg lefedettseget is mer. Ha mar szoba kerult a Jenkins.
A function teszt viszont NEM A FEJLESZTOK FELADATA. Ezen a szinten mar szukseg van a fuggetlenseg magasabb szintjere (lsd. ISTQB tananyag). A function teszt tipikusan black-box jellegu, tehat kovetelmeny alapu. Mint ahogy code review-t sem magamnak csinalok, itt is fontos, hogy egy/tobb masik szempar jarjon utana, hogy a kovetelmenyeknek megfelel-e a fejlesztett funkcio.
A selenium egy GUI teszt eszkoz, de a TestNG pl. jol hasznalhato (nehany kiegeszitessel ellatva) function teszt automatizalasra.
A Jenkinsbe egyebkent vissza lehet riportolni az automatikus teszt eredmenyeket; termeszetesen valami test management szoftverre szukseg lehet ezen felul is, ahol a futasi eredmenyeket lehet monitorozni. Szerintem nincs olyan termek, ami mindenki szemlyre szabott igenyeit kielegiti, ezert altalaban sajat toolt szoktak fejleszteni a jobb cegek erre a feladatra, de persze itt mar izlesek es pofonok.
Meg egy megjegyzes, ha mar DevOps:
Azert az Electric Cloudot ilyen korokben illik megemliteni. :)
Gyakorlat
Gyakorlat mas szemszogbol
A legtobb kis magyar ceg tenyleg nem aldoz (eleget) tesztelesre. En pont olyan cegnel dolgozom ahol ez szerencsere nem igy van. Es nalunk flottul mukodnek a dolgok. Lehet kivetelesen atomkiraly cegnel dolgozom. :)
A tesztelhetoseget is requirementkent kell kezelni. Tesztelheto alkalmazas fejlesztese nem extra energiabefektetes, hanem puszta megfeleles alapveto konvencioknak. Ha valami nem tesztelheto az nem jo, hiszen nem tudod bizonyitani, hogy az. Szerintem ezt diktalja az alatalad is emlitett jozan paraszti esz.
A teszteles kerdese nem lehet cegmeret kerdese. Persze ma Magyarorszagon lehet, de a cikk cime nem az volt, hogy "Nagy Terhelesu Rendszerek Fejlesztese Magyarorszagon."
Itthon sajnos meg el kell telnie nehany evnek, hogy felismerjek a magyar cegek (multiknal mar regen felismertek itthon is), hogy a teszteles kulon szakma, amit meg kell tanulni. A legtobb fejleszto nem is ert hozza...
A "konyvekrol" altalanossagban nem tudok nyilatkozni, szerintem nem is lehet... (nem tudom elkepzelni, ahogy valaki kidobja Dennis Ritchie C-konyvet, mondvan az o szoftverfejleszto cegere nem alkalmazhato.) Azt hiszem egy konyvre hivatkoztam a megjegyzesemben, de ott sem a konyvon van a hangsuly. A funkcioteszt by definition specifikacio alapu teszt, leginkabb black-box teszt. Ez vitan felul all. Nem lehet igy vagy ugy ertelmezni jozan paraszti esz ide vagy oda. A konkret kod iroja nem tud black-box tesztelni. Ahogy - mint mar irtam - code review-t sem tud maganak tartani. A Word se mondja azt, hogy spellcheckelj magadnak...
Korulmenyek
Szerintem, a tesztelhetoseg olyan kerdes, mint a biztonsag. Attol, hogy egy biztonsagi szakembert odaultetnek, a fejlesztok nem fognak biztonsagos kodot irni. Attol, hogy egy tesztelot odaultetnek, nem lesz tesztelheto a kod. Persze lehet, hogy ha sokadszor szolnak, akkor elkezd mukodni a dolog, de mindenkeppen hasznos, ha a fejlesztonek van alapos fogalma arrol, hogy hogyan keszul egy tesz. Ki lehet fejlodni odaig, hogy erre mar nincs szukseg. Fel lehet egy olyan cegkulturat is epiteni, ahol ez mukodik, semmi ketseg.
Ha valaki egy friss, ehhez nem szokott csapattal kezd neki, akkor viszont sok surlodas lesz ebbol, eppen ezert nem mernek olyan tanacsot adni, hogy persze, alkalmazz egy tesztelot es akkor minden jo lesz, mert ez nem igy mukodik.
Egyebkent ha nalatok aldoznak a tesztelesre, akkor tenyleg nem rossz cegnel dolgozol, ha van lehetoseg ra, egy alkalmas idopontban szivesen meglatogatnalak benneteket.
Tesztelo vs. Multifunkcios ember
A 10% mindig egy jo arany, de ennel is inkabb a tobb a jobb. Barki aki fejlesztett egyutt 6-8 emberrel, tudja, hogy a hibak gyakran csak keson jonnek elo, es olyankor mar sokmindent erintenek, burjanzanak, es megfertozik a kod amugy egeszseges reszeit. Egyre dragabbak lesznek. Tankonyvi klisenek hangzik, hogy minel kesobb derul feny a hibara, annal dragabb javitani, de az 'early testing' kifejezes az olyan a tesztelo agyaban, mint az ehes embereben a 'mikor eszunk.' A fejlesztoknek a tesztiras meg rosszabb mint a doksiiras.
Ha nincs tesztelo, mert nincs ra keret, meg kis ceg vagyunk, akkor se magamnak fogok tesztelni, mert az nonszenz... Ha mar vagyunk ketten a cegben, akkor tudjuk egymas kodjat tesztelni. Ha meg egyedul vagyok, akkor nem allok neki nagy terhelesu rendszert fejleszteni, hanem maradok a zankai onkormanyzat honlapjanal. Azt meg - torjon le a kezem, de - letesztelem magamnak. :)
Meg egy dolog:
Aki nem kepes tesztelheto kodot irni magatol, az meg az a fajta ember, aki ne hivja magat fejlesztonek, programozonak... a fejlesztok/programozok johirenek erdekeben. Hulyet kapok a wannabe webmesterektol, akiket 'az elet tanitott' es 'nem kell neki egyetem/foiskola' mert o autodidakta modon gyoker. Bocsanat. Az ilyen nem fogja lekezelni rendesen a kiveteleket se, nem fog logolni, az osszes valtozojanak max ketbetus nevet ad, stb.
20 fős IT-nál is
egy pozitiv pelda
Celkozonseg
Irhatnanak
kérdőív?
Blogpost
monit
Biztonságnál pedig említeném a naxsi-t, nginx-be fordítható.
monit
Ettől persze még hasznos eszköz.
Monitoring
- Graphite (Van sajat lekerdezo nyelve, fel ora alatt tok fasza custom graph dashboard-t raksz ossze)
- New Relic (ez is baromi jo)
- OpsView (elmegy egynek... :-))
Meg mindig monitoring
http://www.cacti.net/