Sokan úgy gondolják, hogy csak azok a nagy, fontos és drága rendszerek alkotják az informatikát, amelyeket a számítóközpontok bombabiztos falai mögé rejtünk. Pedig azok a rendszerek sem kevésbé fontosak, amiket a felhasználóink kezébe adunk napi használatra: az ő számukra ugyanis nagyrészt az az informatika és a kapott megoldás minősége döntően meghatározza a véleményüket – a mi munkánkról. A következő cikkben arra keresek választ, - főleg IT vezetői szemszögből - milyen szempontok alapján érdemes a kliens környezetet megtervezni, miért célszerű a hagyományos, nagy, statikus és zárt rendszer helyett, kisebb egységekből felépülő, kompozit egységeket létrehozni.
Az kliens stratégia választás során felmerülő első kérdés mindjárt az, hogy milyen részekből áll(hat) ez a kliens stratégia és ezek hogyan függenek össze az egyes területek egymással. Íme, egy koránt sem teljes lista és a leggyakoribb kérdések:
Hardver választás
- Egy vagy több gyártó? (Az egyszerűbb garanciális ügyintézés ér többet vagy az olcsóbb ár?)
- Mennyire legyen egységes a géppark? 3-5 év alatt ez mennyibe kerül, fenntartható-e egyáltalán?
- Valóban mindenkinek egyforma gép kell? Mi kerül többe, túl erős gépeket adni vagy többfélét felügyelni?
- Mi legyen a VIP igényekkel? (A “trendi” eszközök kezelése: Mac-ek, tabletek és egyéb kütyük)
Operációs rendszer választás
- A drága az olcsóbb, vagy az olcsó a drágább? Olcsó-e az ingyen operációs rendszer, ha senki sem ért hozzá a cégnél? Számít-e, mérik-e a kliens támogatásra fordított időt?
- Hány operációs rendszer generációt támogassunk egyszerre? Milyen gyors lehet egy átállás (megvárjuk-e az SP1-et)?
Lemezkép startégia
- Mennyi lemezkép optimális egy cégnél? Létezik-e univerzális image?
- Vékony, félkövér vagy vastag lemezkép? (Melyik, mit is jelent?)
Alkalmazások
- Tudjuk-e egyáltalán, milyen alkalmazásokat használnak munkatársaink? Mennyiért fizetünk, amit nem használ senki? Miből van sok vagy éppen kevés?
- Alkalmazáskatalógus és portfólió (A “jövő-levő-menő” alkalmazások dilemmája és ezek finanszírozása)
- Van-e értelme (legalább egy riport erejéig) kimutatni, ki mit használ?
Felhasználói adatok
- Hol a helyük? Helyi vagy központi tárolás?
- Bizalmasság és adatvédelem – együtt vagy egymás ellen?
- Ki a tulajdonos -az egyén vagy a vállalat?
A lista koránt sem teljes, inkább csak szemléltetésnek szántam, hogy lássuk: valóban összetett kérdésről van szó. Mielőtt azonban részletesebben körüljárnánk a felvetett területeket, következzék egy kis közgazdasági kitérő.
A kliens stratégia választás vitathatatlanul komoly következményekkel járó döntés, mindenképpen célszerű számokkal alátámasztani pl. a lehetséges megtakarítások, az élőmunka ráfordítás vagy a munkaidő kiesés vonatkozásában. Persze egyáltalán nem mindegy, mit mérünk és hogyan. A klasszikus vicc jutott erről eszembe:
“Gépház! Mennyi? Háromszázhúsz. Mi háromszázhúsz? Mi mennyi?”
Elméletileg lehet egy olyan mutató, ami segíthet az egyes megoldások összehasonlításában, úgy hívják TCO (Total Cost of Ownership). Gyakorlati alkalmazása, kiszámítása azonban egyáltalán nem gyerekjáték, lássuk mik a fontosabb fenntartások a TCO-val kapcsolatban.
A leggyakorlatiasabb kifogás az, hogy annyiféle paraméterét kell(ene) ismernünk az informatikai ökoszisztémánknak (ugye, milyen szép, tudományos kifejezés?), ami az esetek döntő többségében nem áll rendelkezésre. A hardver és szoftver költségeket a számlák alapján még csak-csak össze tudjuk gyűjteni. De van-e adatunk arra, hogy mennyi élőmunkát kell egy-egy számítógépre fordítani évente? Ennek az élőmunkának milyen a szakmai mélysége és ebből következően a költsége? Tíz-húsz incidens, amit egy kezdő technikus is el tud hárítani valószínűleg lényegesen kevesebbe, kerül, mintha egy rendszermérnök dolgozik egy-két órát (történetesen a főnök) notebook-ján. Tudjuk-e számszerűsíteni azt a veszteséget, amit a munkakiesés okoz egy-egy számítógép üzemképtelensége alkalmával? Egy elvesztett hordozható gép tényleg csak annyit ér, amennyi a főkönyvi értéke? Tudjuk-e mérni az elvesztett adatok értékét (reprodukálás költsége, esetleges üzleti hátrányok, presztízsvesztés stb.)?
Aztán ha a jelenlegi költségekkel meg is vagyunk, hogyan derítsük fel az alternatívaként felmerülő megoldások költségeit (ezeket jelenleg nem üzemeltetjük, tehát hiányosak a bemenő adataink), és hogyan biztosítsuk, hogy ezek összevethetők legyenek egymással? Meg tudjuk-e előre mondani, mennyibe fog kerülni egy másfajta technológiai megoldás? Hogyan kezeljük a bevezetés többletköltségeit (mert ilyenek biztosan lesznek)?
Ha pedig megszületik valamiféle összehasonlítás, még mindig szembesülhetünk azzal a ténnyel, hogy a TCO, mint egyedüli mutató torzíthat is. Ha kicsit közgazdászosabbra vesszük (bár, megjegyzem, nem vagyok az): ha a kapitalizmusban minden gazdasági vállalkozás profitjának maximalizálására törekszik, akkor csak a fele utat teszi meg a sikerhez az előállítási költségek minimalizálásával. Az út másik fele, a bevétel maximalizálása pl. monopolhelyzet, versenyelőny, piaci trend kihasználásával.
Röviden lefordítva a mi kérdéskörünkre: a leghatékonyabb kliens stratégia az, amelyik a teljes költség (TCO) és az üzleti eredmény között a legnagyobb különbséget képes kialakítani. Hiába alacsony a TCO, ha az adott technológiai megoldás nem segíti az üzletet az eredményességben, viszont egy drágább technológia bevezetésének is lehet értelme, ha extra magas profit megszerzését segíti elő.
A közgazdaságtanról mára ennyit.
Mi lehet akkor az értékelés módja? Mit tegyünk, ha nem tudunk, nem akarunk valódi TCO-t számolni? Az egyszerűsített modell lehet például rangsorolás: állítsuk sorba az egyes technológiai területeken felmerülő megoldásokat, majd a helyezéseket összesítsük. A legkisebb helyezési számú megoldáscsoport lehet a nyertes. A modellt bonyolíthatjuk azzal, hogy jelöljük azokat a technológiákat, amik műszaki okokból vagy költségességük miatt nem alkalmazhatók együtt. Az eredmény akár grafikusan is ábrázolható, ha jól választottunk szempontokat, akkor a legkisebb területet lefedő technológiai megoldás lehet a számunkra optimális. Az illusztrációként készített ábrához nem is teljesen önkényesen választottam értékelési szempontokat: a rugalmasság, az időráfordítás, a reprodukálhatóság és a helyreállíthatóság négy jelentős tényező, amikor választanunk kell, de ezekről essék szó a technológiai részleteknél.
ábra 10: A négy fontos tényező
A kliens stratégia természetesen nem lineáris, folyamatosan előrehaladó tervezési folyamat eredményeként születik. A cikk elején található lista elemeit többször, újra át kell gondolni, hogy valamennyi függőséget és azok kihatásait átlássuk. Az átláthatóság megteremtésében lehet segítségünkre a Microsoft Desktop Optimization (MDOP) megoldása, ami - a remek technológiai megoldások mellett - módszertani segítséget is nyújt a sikeres stratégia kidolgozásához.
A rendrakást kezdjük azzal, hogy számba vesszük, mire is fogják használni a felhasználók a nekik biztosított informatikai eszközöket (szigorúan maradjunk az üzletileg indokolt tevékenységeknél)! Igyekezzünk a felhasználói igényeket néhány tipikus kategóriába sorolni! A kategóriák felállításánál használhatjuk az MDOP dokumentáció öt kategóriáját (feladat munkás, irodista, szerződéses munkaerő, mobil felhasználó, távmunkás) vagy létrehozhatjuk a saját típusainkat. A felhasználói típusokhoz keressük meg a számukra optimálisnak tekinthető kliens megoldást. Az átláthatóság kedvéért ebből akár táblázatot is készíthetünk, amiben a cikk elején felsorolt szempontokat is feltüntethetjük.
Természetes, ha a táblázat egyes celláit nem tudjuk azonnal és habozás nélkül kitölteni, minden egyes döntésünk mögött rengeteg megfontolandó szempont állhat. Sőt, akár több ilyen táblázatunk is lehet, amiben a részterületek optimális kombinációit keresgéljük. Mintaként vezessük most végig a fenti táblázatban látható példát!
A feladat munkásoknak vékony klienst szánunk, hiszen ők kevés féle, de gyakran ismétlődő feladatot végeznek, folyamatosan a hálózathoz csatlakozva. A feladataik nem igényelnek különösebb számítási kapacitást és a grafikus megjelenítés minősége sem szempont. A vékony kliensektől nagyobb megbízhatóságot (nincs mozgó alkatrész) és kisebb karbantartási igényt várunk el (noha ez a tévhitekkel ellentétben nem nulla!). A másik oldalon a vékony kliensekkel természetesen szembe kell állítani valamilyen központi szolgáltatást, amit használhatnak, ez most legyen Remote Desktop Services, mert nagyságrendekkel olcsóbb, mint egy virtualizált deszktop. Az alkalmazásokat az RDS kiszolgálókra APP-V csomagok formájában juttathatjuk el (Windows Server 2008 kompatibilitás ellenőrizendő!), mert ebben a formában jelentősen jobb lehet az RDS szerverünk kihasználtsága – az alkalmazások frissítése nem igényli a kiszolgáló újraindítását. A felhasználóknak szinte nincsenek is a munkájukhoz kapcsolódó tárolandó adataik, ehhez mérten adhatunk nekik tárkapacitást a fájlszerverünkön.
A táblázat egy ágát végigjárva, már látszik az a sajátosság, hogy pl. a kliens formátum (esetünkben a vékony kliens) megválasztása hogyan szűkítheti be a további választási lehetőségeket az operációs rendszer vagy az alkalmazásterítés vonatkozásában.
A második csoport a mobil felhasználók csoportja, és a csoport neve már tartalmazza specifikus igényüket: munkájuk végzése során gyakran nem kapcsolódnak közvetlenül a helyi hálózathoz és lehetnek olyan feladataik, amelyek számítási és/vagy grafikus teljesítményt igényelnek az általuk használt eszközben. Szolgáljuk ki az ő igényeiket a lehető legkevesebb új komponens bevonásával! Megtarthatjuk az alkalmazás virtualizációt, mint alkalmazásterítési technológiát, hiszen van lehetőségünk az alkalmazások cache-be töltésére, amikor a felhasználó a hálózathoz csatlakozik (akár Internet-en keresztül is) vagy MSI csomag formájában adathordozóra is tehetjük virtualizált alkalmazásainkat. Operációs rendszernek válasszuk a Windows 7-et, egyrészt az offline mappák hatékonyabb kezelése, másrészt a Bitlocker miatt. A lemezképet se bonyolítsuk túl: akár Windows Deployment Services-t (WDS), akár Microsoft Deployment Toolkit-et (MDT) vagy éppen System Center Configuration Manager-t (SCCM) használunk az operációs rendszer terítésére, van lehetőségünk arra, hogy a szükséges eszközvezérlő készletet dinamikusan csatoljuk az operációs rendszer gyári telepítő készletéhez. Alkalmazásból pedig mindössze kettő kell: az APP-V kliens és a vírusirtó. Ezeket MDT-vel vagy SCCM-mel telepíthetjük, viselkedésüket pedig házirendekkel központilag szabályozhatjuk. A felhasználói adatokat a mappa átirányítási csoportházirendekkel tereljük át fájlszerverre, ezzel egyszerűsödik mentésük és nem veszítjük el őket, ha notebooknak nyoma vész. (Zárójelben jegyezzük meg, hogy az operációs rendszer választás kihatással van a hardver választásra: még beleszaladhatunk raktárkészletről, nagy kedvezménnyel árult, ámde Windows 7-re nem minősített hardverrel!)
Irodai munkásaink kapjanak mostani példánkban hagyományos PC-t (ezt megszokták, szeretik és tegyük fel szükségük is van rá)! Tartsuk meg hozzá a meglévő vékonyka Windows 7 lemezképünket, persze egészítsük ki a szükséges eszközvezérlőkkel! Telepítsük az operációs rendszert, ahogy a notebook-okét, telepítsük az alkalmazásokat, ahogy a notebook-okra! Kezeljük a felhasználói adatokat, ahogy eddig mindenkiét (legfeljebb adjunk nagyobb kvótát a fájlszerveren, mint szegény feladat munkásoknak). Ezzel a csoporttal bizony nem sok dolgunk akadt, kiszolgálásukhoz minden rendelkezésre állt már.
Az utolsó két felhasználói típus nálunk egyelőre még nem túl gyakori, akár össze is vonhatjuk őket, mert sokban hasonlítanak egymásra. Példánkban sem a szerződéses munkatársnak, sem a távmunkásnak nem biztosítunk hardver eszközt. A szerződő (megbízott) az őt bérbe adó cég gépét használja, a távmunkás a sajátját. Ebből következően hálózati hozzáférésüket a minimálisra szeretnénk csökkenteni, nem is engedünk nekik mást csak RDP használatát (és lehetőleg azt is Network Access Protection mellett). Az esetek többségében biztosan elegendő lesz munkájukhoz, ha egy RDS kiszolgálón biztosítjuk számukra a szükséges alkalmazásokat (mi mással, ha nem ismét APP-V-vel, hiszen adott az infrastruktúra, sőt akár az alkalmazáscsomagok is). Ritkább esetekben, például ha szerződéses vagy távmunkás munkatársunk egy új alkalmazást fejleszt és ehhez rendszergazdai jogokra van szüksége, ráadásul gyakran kell újraindítania a gépét, biztosítsunk számára egy virtualizált deszktopot. Ehhez ismét használhatjuk a korábban létrehozott vékonyka Windows 7-es lemezképünket, ha Hyper-V virtualizációt használunk, már az eszközvezérlőkre sincs gondunk. Az alapvető alkalmazásokat ide is küldhetjük APP-V-vel, az egyedi dolgok telepítését bízhatjuk a felhasználóra (ha nem boldogul vele, akkor nem indokolt számára a VDI kliens J).
Ha visszatekintünk a táblázatra láthatjuk, hogy többféle felhasználói igényt egészen kis számú technológia rugalmas kombinálásával és újrahasznosításával is ki tudunk elégíteni és igazából még csak egyet jártunk végig a lehetséges kombinációk közül. Az ilyen kis részrendszerek kialakítása és fenntartása – bármilyen technológiai szempontból korrekt kombinációban - lényegesen olcsóbb lehet, mint a statikus nagy rendszerek hosszas elkészítése és nehézkes karbantartása, miközben megnyerjük a rugalmas alkalmazkodás képességét a változó üzleti igényekhez.