Az IT konszolidáció buktatói

Egyre többször kerül szóba az IT konszolidáció, hiszen mind több cég igyekszik a régi, 10 évvel ezelőtti hálózati infrastruktúrát és rendszereket a modern kor követelményeinek megfelelőre cserélni. A gyorsabb, biztonságosabb rendszerek beüzemelése, sőt, kiválasztása azonban körültekintő tervezést igényel. 

Mi is régóta foglalkozunk ezzel a témával, így bőven van már gyakorlatunk benne. Éppen ezért arra gondoltunk, megosztjuk eddigi tapasztalatainkat és elmeséljük, milyen buktatói lehetnek egy ilyen váltásnak, mire érdemes figyelni, hogyan érdemes nekifogni, s miért nem célravezető szakértői segítség nélkül belevágni. Igen, ez így elsőre önfényezésnek tűnhet, de a következő bekezdések végén már valószínűleg igazat adnak majd nekünk. 

Mikor és hogyan kezdjünk neki?

Természetesen bármikor, amikor úgy látjuk, hogy az aktuális infrastruktúra már képtelen megfelelni a vállalat elvárásainak. Hozzánk például sokan akkor jönnek fejlesztési igénnyel, amikor 5-10 éven keresztül egy bizonyos rendszert használtak, s belefásultak abba a mókuskerékbe, ami e rendszer életben tartásához szükséges a házon belüli igények kiszolgálásakor. Az ilyenkor felmerülő elvárások: az új megoldás legyen magasabb rendelkezésre állású, folyamatosan üzemeljen (vagy legalábbis nagyon minimális megszakításokkal), legyen biztonságosabb, és nyújtson hatékonyabb megoldást a biztonsági mentések menedzselésére is. Erre viszonylag egyszerű ajánlatot adni, hiszen az esetek többségében ezek az alapvető elemek jöhetnek számításba:

– clusterek

– több host

– több storage

– redundáns hálózat

– több redundáns internet elérés

Egyetlen apró bökkenő szokott ezzel lenni. Míg a fentiek összeállítása és beárazása után a megbízónál az IT részleg kifejezetten boldog a műszakilag tökéletesen megfelelő ajánlattól, addig a pénzügyön ingatják a fejüket, hogy ez így sehogy nem jön össze anyagilag. Ez az állandó ellentét elkerülhető lett volna, ha az ajánlatkérés előtt a cégvezetés, az IT és a pénzügy egyeztetne a tervekről, vagyis még a folyamat elindítása előtt megpróbálnának kompromisszumra jutni, hogy a cég jövőbeli céljainak és lehetőségeinek milyen típusú és ütemezésű fejlesztés felelne meg a leginkább. Ezzel elkerülhető lenne az eleve kigazdálkodhatatlan árajánlatok felesleges bekérése.

Van egyébként másik véglet is, ahol az IT osztály a hasraütés ősi módszerével kigondolja, hogy a fentről kapott büdzséből mit valósítanak majd meg. A gond ezzel is az szokott lenni, hogy a tervezett beszerzés köszönőviszonyban sincs a valós árakkal, ez viszont már csak menet közben derül ki, ami időveszteség. Márpedig az idő pénz, bármennyire közhely e kijelentés. Ilyenkor aztán lehet farigcsálni utólag a költségeket, de ekkor már nehéz kitalálni, melyik ujjába harapjon az ember, ráadásul ezeknek a fránya IT fejlesztéseknek van egy igen ronda jellemzőjük: összefüggnek egymással. Vagyis ha cserélünk egy szervert, jó esélyünk van rá, hogy a környezetét is záros határidőn belül modernizálni kell.

Szóval együttműködés és közös tervezés nélkül a fejlesztéseknek nem lehet nekifogni. Kár mutogatni a másik osztályra. Le kell ülni és összegezni az elvárásokat, lehetőségeket.

Az IT konszolidáció egyébként nem feltétlenül kell, hogy egyetlen lépésben történjen. Megvalósulhat önállóan is a különféle szolgáltatások és környezetek újratervezése és cseréje.

Első buktató: a tervezés

A tervezésnél a fő problémát a fentebb már vázolt keretösszeg vs elvárás ellentét szokta okozni, amit egyébként viszonylag egyszerűen lehet árnyalni, ha a vásárlásra szánt termékek esetében meghatározunk egy fejlesztési időszakot. Így előre láthatjuk, hogy a befektetés hány évre szól. Emellett időszakokra bonthatjuk a fejlesztés folyamatát is, vagyis megadhatjuk, hogy milyen ütemezés szerint, mikor, mit cserélnénk (szerver, wifi, backup rendszer stb.). Itt azonban vigyázni kell, mert akadnak olyan területek amelyek erősen összefüggnek (például a fentebb már említett szerver+hálózat kialakítás). Ha egy fejlesztésnél előre tudni, hogy az nem egy, hanem akár öt-hat évre szól, az rögtön kellemesebben hangzik nagy összegek esetében.

Érdemes figyelni arra is, hogy a tervezett életciklus alatt a bővítések is megoldhatók legyenek, hiszen az új hardverek jellemzően csak egy ideig kompatibilisek visszafelé. Ha hosszabb időre tervezünk, a kifutó modellekre érdemes lehet jó időzítéssel lecsapni, hogy a meglévő infrastruktúrát tudjuk bővíteni és ne kelljen teljesen új alapokra helyezni mindent a tervezett időpont előtt.

A tudásnak ára van

Egy nagyobb fejlesztés általában komoly hardveres és szoftveres változásokkal jár. Az új eszközök szakszerű üzemeltetése szinte mindig új tudás megszerzését is igényli a helyi IT csapatnál. Ilyenkor több lehetőség is adott, ezek közül az egyetlen, amit biztosan ki kell zárnunk: a majd lesz valami életérzés eluralkodása. Ez esetben ugyanis biztosan kudarcra van ítélve az egész projekt, ráadásul immár túl vagyunk a beszerzési és adott esetben a beüzemelési fázison is, ami így hatalmas ráfizetés.

Éppen ezért az IT részlegnek mindenképpen érdemes továbbképzésben gondolkodnia, azonban itt is van lehetőség egyszerűsítésre. Köthető ugyanis támogatói szerződés is, így az  üzemeltetés, karbantartás egy részét vagy akár egészét ki lehet szervezni ahhoz a szolgáltatóhoz, aki az átállásban is eleve segített. Így az IT csoport megússza a nagyobb továbbképzést, de az új rendszer ennek ellenére zökkenőmentesen üzemelhet, hiszen biztos kezekben lesz a support.

Valamiféle rossz beidegződés okán ettől egyébként tartani szoktak az IT-sok, pedig nem az állásukra pályázó külsősöket kellene vizionálniuk, hanem azt, hogy marad idejük a napi teendők ellátására, s ráérősen ismerkedhetnek az új környezettel. Nem kell rohamtempóban átképezni senkit.

Puszta tekintély féltésből nem érdemes ragaszkodni gyártókhoz és termékekhez sem, félve az újdonságoktól. Hosszú távon mégis visszaüt, hiszen lehet, hogy egy alternatív megoldás olcsóbb és hatékonyabb lenne, mint a már megszokott termékcsalád új verziói.

Tapasztalataink alapján kijelenthetjük, hogy a támogatói szerződés szinte mindig remekül beválik, mindkét fél teljes megelégedésére. Gond nélkül összedolgozik a helyi IT és a támogatói csapat, amin mindenki csak nyerhet.

Ha mégis a teljes oktatás mellett dönt egy cég, akkor újabb dilemmát jelenthet, hogy mit válasszanak: a munka melletti oktatás költséghatékony, de közel sem olyan eredményes, mint amikor a gárda beül az “iskolapadba”. Utóbbi viszont jelentős időveszteség munkáltatói oldalról, s persze drágább is.

Felhőben az élet

A felhő alapú szolgáltatások bevezetését vagy a teljes bizalmatlanság övezi a cégeknél, vagy a korlátlan elfogultság, amikor mindent azzal akarnak megoldani és szent meggyőződésük, hogy ez sikerülhet is. A felhő valójában se nem ördögtől való rossz, se nem csodaszer. Okosan és körültekintéssel kell alkalmazni egy cég életében, de ha van olyan szolgáltatás, amely beüzemelhető ily módon, érdemes belevágni a dologba, mert nagyon hatékony és biztonságos megoldást jelenthet. A tervezés tehát itt is nagyon fontos: át kell gondolni a körülményeket és a célokat. Meg kell nézni, hogy a használni kívánt rendszernek mely részei helyezhetők felhőbe. Tapasztalataink szerint a levelezés például a legtöbb helyen ilyen, bár kétségtelen, hogy nem egyszerű feladat egy régebbi levelezőrendszer átültetése felhő alapokra, ráadásul - főleg az előkészítés és az utómunka miatt - sokáig is tarthat. Hosszú távon viszont megéri a befektetett idő.

Szoftveres kérdések

Sajnos egy IT rendszer üzemeltetéséhez nem elegendő a jól összeválogatott hardver park. Szoftverekre is szükségünk lesz. Szerver oldalról ezzel kapcsolatban örömteli, hogy ma már senkit nem kell különösebben győzködni a virtualizáció előnyeiről, legfeljebb az a kérdés, hogy erre a célra melyik technológia kerüljön bevetésre a vállalatnál. A két fő rivális a Microsoft Hyper-V és a VMWare. Mi most nem foglalunk állást egyik mellett sem, hiszen mindegyiknek van előnye és hátránya egyaránt. Ezt a hozzáállást javasoljuk ügyfeleinknek is, mert nem lehet elfogultan megítélni az ilyen rendszereket. Valódi hasznosságuk a tervezés során átgondolható, így később kevesebb meglepetés éri az embert. Az biztos, hogy a virtualizáció elősegíti az erőforrások hatékony kihasználását, a költségek optimalizálását, a változásokhoz való gyors alkalmazkodást, illetve a felügyeletet és az üzemeltetést is.

A fentieken túl egyre többször vetődik fel a nyílt forráskódú, illetve a zárt rendszerek közötti választás dilemmája is. Előbbinél javarészt az ingyenesség szokott lenni a fő szempont, utóbbinál a megbízható támogatás. Itt is mindig helyzettől függ, hogy megtaláljuk az ideális felosztást, hiszen a két rendszer együtt is működik (csak egyszerű példaként: a Hyper-V például támogatja a Linuxot, míg az ingyenes VMware támogatja a fizetős Windows megoldásokat). Lándzsát törni egyik mellett sem érdemes, de az ingyenes változatoknál a megspórolt licenc költséget sokszor übereli az üzemeltetési költség, miközben a verziókövetés értelemszerűen olcsóbb egy ingyenes szoftver esetében (feltéve, hogy a kompatibilitásra is ügyelnek a fejlesztők). A szoftveres környezetek egyik nagy problémája amúgy éppen ez: a régi rendszerek és alkalmazások sok helyen évekig nem kerülnek frissítésre, az idő haladtával viszont elveszítik támogatottságukat, így ha később új verzióra kell váltani, komoly problémákba ütközhet a váltás, mert az új rendszer nem biztos, hogy kompatibilis a régivel. A hazai cégek amúgy is előszeretettel spórolnak a maintenance előfizetéseken, így az előfizetésért cserébe állandóan kapott frissítések helyett azok utólagos megvásárlásával a végén még rá is fizethetnek. A terméktámogatáson és az automatikusan járó frissítéseken megspórolt összeg többszörösét fizethetik ki, ha utólag kell upgradelni mindent.

Mellesleg a support vásárlásakor is fontos szempont lehet, hogy hány évre vesszük meg a terméktámogatást, hiszen ha ezt alulbecsüljük és “félidőben” már nem foglalkozik senki a frissítésekkel, az akár a magas rendelkezésre állás útjába is komoly akadályokat gördíthet. Éppen ezért már a tervezési időszakban érdemes átgondolni a szoftverek “öregedését” is, a lehető legtöbb szempontot figyelembe véve.

Egy migráció esetében az is fontos lehet, hogy milyen utat választunk. Ha mindent upgradelünk, előfordulhat, hogy a friss verziónál licenc problémákba ütközünk, vagy olyan technikai nehézségekbe, amelyeket költséges megoldani. Ezzel könnyen megakaszthatjuk a fejlesztési projektet és a munkát is.

Viszonylag zökkenőmentes átállást biztosíthatunk, ha új rendszert építünk és oda visszük át a szolgáltatásokat. Ez ugyan elsőre több munkának tűnik, viszont cserébe nem akasztjuk meg vele a még működő régi rendszert. A szolgáltatásokat akár egyesével is átvihetjük, tesztelhetjük, majd amikor már minden működik az új platformon, egy viszonylag laza  mozdulattal átállhatunk rá a régi helyett. A problémák nem éles használat közben derülnek ki, ami az adatvesztések kockázatát is jelentősen csökkenti.

Mindent egybevetve a sikeres IT konszolidáció legfőbb alapja a tervezés. Ez vonatkozik a hardveres és szoftveres fejlesztésekre egyaránt. Emellett pedig érdemes kihasználni, hogy a szolgáltatók terméktámogatást is nyújtanak, mivel az átállási folyamatnál és az azt követő üzemeltetési időszakban ezzel nem csak spórolhatunk hosszú távon, de a megfelelő rendelkezésre állást is hatékonyabban biztosíthatjuk így.