(ez a post a folytatása az Üzemeltetés belülről címűnek, szintén kevéssé rendezett struktúrával)
Az automatizálás az egyik legfontosabb fegyver az üzemeltető kezében, mivel ahhoz, hogy gép csináljon meg valamit, előbb formalizálnia kell az embernek az elvárásokat, és ha eddig nem tette volna, szisztematikusan végiggondolni. Ezek az automatizálások teremtik meg az időt és energiát a színvonalas, minőségi üzemeltetéshez. Természetesen ez eleinte többletmunkát jelent, de általában lehet apránként haladni, bár mindig érdemes egy átfogó stratégiát építeni: mi mindent kell/lehet automatizálni – lehet, hogy némi körültekintéssel ugyanazt a scriptet több feladatra is alkalmassá tehetjük.
Mindezek mellett/után a másik nagy feladat: kommunikáció. Derítsük ki jó előre, mi fog történni, szóljunk hozzá (konstruktívan), véleményezzünk. Az ideális az, amikor a tervezési fázisban bevonják az üzemeltetést, a struktúrát is már véleményezhetik, javasolhatnak. Erre most sokan azt mondják, hogy nálunk ez sosem működne. Én azt mondom, hogy lehet, hogy így van, de én például most két év után kezdem érezni, hogy megtérül az így befektetett munkám, a fejlesztő megkérdezi, hogy mi volna a leghatékonyabb megoldás szerintünk.
A kommunikáció akkor is fontos, amikor mi (nem) csinálunk valamit, és például szolgáltatáskiesés van. Sokkal jobban érzik magukat az emberek, ha kapnak egy levelet, hogy ez és ez történt/történik, ekkorra lesz megoldva, illetve ezt és ezt tervezzük a jövőben, hogy ne forduljon ez elő még egyszer.
Volt menedzseremnek a két alapkérdése a következő volt: mi történt, mit tehetünk, hogy ez még egyszer ne forduljon elő. Ezt mondenki úgy könyvelte el, mint okoskodó kérdéseket, pedig alapvetően nagyon fontos és jó kérdések minden szolgáltatási problémánál. Ezúton is szeretném megkövetni Gozót, hogy mindenféle érdekes, ámde kevéssé kellemes helyekre kívántam, amikor ezekkel a kérdésekkel közelített az asztalomhoz.
Van, amikor nekünk kell(ene) változást kezdeményeznünk. Például lassú egy alkalmazás, és nyilvánvalóan az alkalmazás hibája (külön téma, hogy ezt mi alapján mondod meg biztosan), és valamit kellene tenni ellene. Néha az embernek bele kell nyúlnia az alkalmazásba – nekem például kényszerem van az SQL kódok piszkálására. Az ilyen változtatásokat végig kell nyomni az egész telepítési láncon utána: élesen és az összes teszten, beleértve a fejlesztő saját környezetét. Lehet, hogy neki nincs teljesítményproblémája a kétfelhasználós rendszerben, de ha módosít a lekérdezésen, és mi felülcsapjuk az optimalizált kódot az övével, akkor nekünk lesz.
Az üzemeltetés által kezdeményezett módosítás másik esete az infrastruktúra patch/upgrade. Ezzel sokszor nem foglalkozunk, pedig ez olyan, mint a fogorvos: előbb-utóbb meg kell tenni, és ritkán lesz jobb attól, hogy halogattuk. Nem azt mondom, hogy mindig upgrade-eljünk, hanem, hogy ezt ne hanyagoljuk el. A munkahelyemen például valószínűleg ki fogjuk hagyni az SQL 2008-at mint globál platformot, és SQL 2010/11 lesz majd a következő teljes váltás, de addig a SQL 2005-öt patcheljük rendesen. Az infrastruktúra projektek szoktak kimaradni a keretből a leggyakrabban, mert az üzleti projektek sokkal fontosabbak. Legyünk ügyesek: csomagoljuk be az ilyeneket “ez most tulajdonképpen neked lesz jó” papírba: a jövőben az üzlet sokkal csicsásabb alkalmazásokat készíttethet, sokkal megbízhatóbb lesz az egész, sokkal több levelet küldhet és fogadhat, sokkal egyszerűbb lesz az élete. Mellesleg a miénk is, de ez tényleg csak egy mellékhatás.
És minden változtatáshoz a legfontosabb: tesztelni, tesztelni, tesztelni. Teszteld, hogy fel lehet-e telepíteni, le lehet-e venni, hogyan reagál arra, ha valami komponens/paraméter hiányzik (ez hülyeségnek tűnik addig, amíg egyszer nem találkozol azzal, hogy a távoli webservice elérhetetlenségét konfigurációs hiba történt hibaüzenettel közli egy alkalmazás). A megfelelő tesztelés a megfelelő tesztkörnyezettel kezdődik: ha gagyi a tesztkörnyezet, a tesztelés megbízhatósága sem lesz különb. Minél inkább hasonlítson a teszt az élesre. Lényegtelennek tűnő részletek nagyon is tudnak számítani, pl. szoftververziók – SQL 2000 SP3 vagy SP4 vagy post-SP4? 64 vagy 32 bites oprencer/szoftver? A komponensek ugyanazon a gépen vannak-e vagy úgy szétszórva, mint az éles környezetben? Milyen joga van a futtató accountnak? És még sok más hasonló kérdés van, amire figyelnünk kell. Ja, és ráadásul utána karban is kell tartanunk a tesztkörnyezetet…
Talán mégis van fontosabb, mint a tesztelés: a tervezés. Tervezzük meg a munkát, elejétől a végéig, gondoljuk végig, hogy mit hogyan csinálunk majd, mi mindenhez nyúlunk. Én egy elektronikus papír fölött gondolatban végigcsinálom a munkát, és leírom, hogy mi mindent kell tenni. Aztán másnap megint végiggondolom, és beírom azt, ami kimaradt. A teszt jó támpont, de sok dolog nem úgy van a tesztrendszerben, például nem okozunk szolgáltatáskiesést, és nem kell kommunikálni az üzleti arcokkal. Aztán megkérem a többieket, hogy nézzék meg – mindig van jó hozzászólás. Vagy ők jók, vagy én vagyok béna. Szerintem ők nagyon jók.
Hát ennyi. Most kijött belőlem a nagyja annak, ami már régóta kikívánkozott, de azért még van 1-2 gondolat a fejemben.
