Nagyvállalati rendszerátalakítás mesterfokon

Szerver park

Bár a történet már nem annyira friss (másfél éve történt), összetettségének és bonyolultságának köszönhetően mindenképpen a TOP 5-ben a helye. Nem csak informatikai szempontból volt komoly feladat, de logisztikailag is. Egy dunántúli, több telephelyes bolt hálózat bízott meg minket egy központi szerver rendszer kialakításával, a meglévő rendszereik integrálására, miközben az ehhez szükséges hardvereket és szoftvereket már korábban beszerezték, már csak az ezekhez szükséges tudást kellett „licencelni”.

Pályázati forrásból elnyertek 2db komoly Dell szervert Windows Server 2016 Standard szoftverrel. A meglévő 2db Dell szerverük igencsak koros volt, kb. 8-10 éves, még az R2-es csomag nélküli Windows Server 2008 futott rajtuk. Bár a licenceik lehetővé tették volna és telepítve is volt a szerverre a szerepkör, tartományi rendszert mégsem használtak a szervereknek helyet adó központi telephelyen. Az egyik gép az SAP számára biztosított SQL adatbázis elérést, a másik pedig terminal szerverként üzemelt. A központban és az üzletekben is gyenge minőségű, sávszélességű internet kapcsolatok voltak, ezekre egy-egy régebbi Mikrotik router volt kötve, amin a port továbbítások mellett PPTP alapú VPN elérések is konfigurálva voltak, amin keresztül kapcsolódtak a központhoz az egyes gépek és így érték el a terminal szervert, amin az SAP klienst futtatták. A régi szerverek rendszeres fagyásaival küzdöttek, illetve a lassú és bizonytalan net miatt rendszeresek voltak a kimaradások az üzletekben, ilyenkor a teljes kasszarendszer és a szintén SAP-hoz kapcsolódó mobil adatgyűjtők is lehaltak.

Ez volt tehát a kiindulási állapot, ebből kellett nagyot alkotni. A két szerver már adott volt, ott nem volt sok mozgásterünk, ugyanakkor a felhasználásukban és a rendszer kialakításában szabad kezet kaptunk. Az ügyfél részéről már a legelején felmerült egy szerver parkban történő szerver elhelyezés ötlete, hogy a kimaradásokat a nagyobb rendelkezésre állásnak és a jobb sávszélességnek köszönhetően csökkenteni tudják. Miután személyesen mértük fel az állapotokat, először a hozzánk legközelebb eső telephelyükön, Győrben, majd Sárváron, végül mi magunk is a szerver park ötletét helyeztük előtérbe. Természetesen a hibatűrés és a költséghatékonyság maximális figyelembe vétele mellett. Kiválasztásra került tehát a hosting szolgáltató, ahova elhelyeztük az időközben Hyper-V szerepkörrel telepített 1-es számú Dell szervert. A második szerver a régi központban egy másodlagos DC és fájl szerepkört kapott, így mivel az elsődleges szerverben sokkal komolyabb erőforrásokra volt szükség, ezért ezek egy részét (memória, merevlemez) átszereltük a pesti Dell-be. Telepítettük Hyper-V alá virtuális gépként a sok helyen már bizonyított PfSense rendszert, majd a kialakított virtuális privát, belső hálózatra telepített, azóta már 3db Windows Server rendszert azon keresztül tettük elérhetővé. A tűzfalon kialakítottunk OpenVPN elérést is, és előkészítettük a terepet IPSec site-to-site VPN használatára. Az SAP-t üzemeltető partner cég is megkapta a hozzáférését a pesti rendszerhez, ahol megkezdték az új adatbázis szerver kialakítását és előkészültek a régi szerverről a költözésre.

Ekkor kezdődött meg az átállás második üteme, ugyanis a meglévő 2008-as terminal szerverükön nem szerettek volna szoftvert cserélni, csak az alatta lévő hardvert, így egy P2V migrációval a vidéki szerverről átköltöztetésre került a terminal szerver egy Hyper-V virtuális gépre, a rajta lévő tartományvezérlő szerepkörrel együtt. Ez a manőver egy igen alapos tervezést és kivitelezést igényelt, ugyanis a cég üzletei szombaton délelőtt is nyitva vannak, így szombat délután lehetett csak nekikezdeni a műveletnek, a 60-70GB méretű virtuális lemez neten keresztül történő áttöltése pedig kb. 1 napot vett igénybe. Így gyakorlatilag egyetlen éjszaka maradt a merevlemez képfájlok virtuális gépként történő beüzemelésére. Az itt tapasztalt nehézségek önmagában is megérnének egy külön cikket, nem adta olcsón magát a régi rendszer, de hétfő reggelre némi barkácsolás és pár DNS módosítás után észrevétlenül elkezdhettek Pestről dolgozni. Az elérés és a sebesség már itt sokat javult, de még hátra volt a harmadik ütem.

A rendszer kialakítás utolsó, harmadik ütemében ugyanis egy előre leegyeztetett időpontban útra keltünk, hogy egyetlen nap leforgása alatt az összes telephelyet bekössük IPSec VPN-nel a központra, amihez új Dell Optiplex gépeket vettek PfSense tűzfalrendszerrel telepítve. Az üzletek éppen éves leltárt végeztek, úgy időzítettük a router/tűzfal cserét, hogy internetre és szerver elérésre ugyan szórványosan szükségük volt, de nem volt rajtunk egy esetleges hosszabb kimaradás terhe. Ennek megfelelően remekül sikerült, reggel Győrben fél óra alatt kicseréltük az ottani Mikrotiket az új tűzfalra, a felhasználók észre sem vették a cserét, majd egy ebédszünet után irány Pápa és ott is megismételtük a győri sikert, ezután még az esti órákban Sárváron is a helyére került a másodlagos DC, illetve helyi fájlszerver és az ottani PfSense rendszer is. Így már 3 hálózat kapcsolódott sikeresen a pesti központra IPSec segítségével, a DNS forward rendben működött és zökkenőmentesen ment az átállás. Aznap még egy feladat volt hátra, a sárvári szerverre a DC szerepkör telepítése, majd a pesti DC replikálása a sárvári szerverre, ami azóta így másodlagosként működik. A fájlszerverre pedig elindítottuk a mappák, fájlok másolását, mivel korábban egy NAS-t használtak adattárolásra. Másnap reggel a tartományba léptetéseket követően már meg is jelentek a gépeken az új hálózati meghajtók, ahonnan a korábbi fájljaikat is elérték már.

Másnap reggel a szerver rendszer ellenőrzését és a szolgáltatások működésének áttekintését követően aztán útra keltünk az utolsó állomásra, Szombathelyre, ahol aztán szintén kb. 1 órányi munkát követően már csak a hazaút volt hátra. Az új rendszer a régihez képest lényegesen stabilabb és gyorsabb lett, de a pesti szerver központnak köszönhetően a rendelkezésre állásban következett be a legdrasztikusabb javulás. Később még számos finomhangolást végeztünk a rendszeren, amikor is a korábban erőforrásokkal bőségesen megtámogatott SAP SQL szervertől vettünk el processzort és memóriát, amivel tudtuk növelni a terminal szerver teljesítményét és így lényegesen gyorsabbá tudott válni az a szerver is, amin időközben már közel 40-en dolgoztak folyamatosan egyszerre.

A projekt itt nem állt meg, később megrendelésre került a 2008-as Windows Server frissítése, mivel az új SAP verzió már ezt a régi rendszert nem támogatta, így pedig egy frissen beszerzett Windows Server 2016 és az RDS CAL-ok telepítése volt soron. Mivel már virtuális gépként futott a Windows Server 2008-as terminal server, így a terv az volt, hogy egy snapshot készítést követően elkezdjük helyben a frissítését egy újabb Windows verzióval. Erre egyetlen éjszakánk volt, mivel a boltok pénteken este 7 körül zártak, szombat reggel 8-kor pedig nyitottak és eredeti terv szerint addigra kellett készen lenni, a vészterv a snapshot-ból történő teljes visszaállás lett volna és egy újabb nekifutás más taktikával szombat délután. Végül számos nehézség után és a terminal server szerepkör teljes újrakonfigurálását követően (mivel időközben a Windows Server 2016-ban már RDS-nek hívják és nem migrálható a korábbi szerepkör) kb. 10-15 perccel a boltok nyitása előtt készen lett a teljes frissítés, szombat reggel így már Windows Server 2016 RDS-re csatlakozva probléma és fennakadás nélkül ki tudott nyitni az összes vidéki üzlet.

Ügyfél elégedettség

A rendszer azóta is stabilan teszi a dolgát, szinte fennakadások nélkül, minimális karbantartási igény mellett. A munkálatok sikerét jól mutatja, hogy jövő héten ennek a cégnek a leányvállalatánál egy újabb nagy szerveres projekt keretében bizonyíthatunk az ottani vezetésnek, ahol egy nagy rendrakás részeként szervert és operációs rendszert is cserélünk, illetve integráljuk majd az erőforrásaik egy részét az anyacég rendszerébe. Így javítjuk az együttműködését a két cégnek, növelve az adatbiztonságot és segítünk nekik kiaknázni a Windows Standard változatában rejlő lehetőségeket.

A jó munkának tehát mindig megvan a gyümölcse, az anyacégtől is azért kaphattunk megbízást, mert korábban egy másik cégnél bizonyítottunk, ahova egyébként már szintén ajánlás útján kerültünk be.

Ügyfelek, akik a mi tűzfalmegoldásainkat választották

A PfSense tűzfalmegoldásokkal kapcsolatos cikk kiegészítéseként szerepeljen itt ez a rövid esettanulmány gyűjtemény, a benne szereplő cégek megnevezése nélkül, a kialakított infrastruktúrák főbb jellemzőivel.

PfSense

Egy igazi nagyvállalati infrastruktúra

Kezdjük mindjárt a legnagyobb művünkkel. 2017. végén kaptunk megbízást egy vidéki cégtől, hogy megoldást találjunk a szerver rendszerük gondjaira. Egy hatalmas projekt részeként egy komoly nagykapacitású Dell szervert vásároltak, ami a vidéki internet sávszélességek miatt egy budai szerver parkba került elhelyezésre. Itt alakítottuk ki a központi szerver rendszert, tartományvezérlőt és fájl szervert, SAP adatbázis szervert és egy terminal server kiszolgálót (RDS-t), aminek eléréséhez elengedhetetlen volt egy nagy megbízhatóságú és magas biztonsági szintet nyújtó tűzfal megoldás. A választás ezúttal is a PfSense-re esett, a pesti központban szorítottunk neki helyet a nagy Dell szerveren virtuális gép formájában, ami Hyper-V alapokon fut immáron közel másfél éve, megbízhatóan. A központi telephelyre aztán IPSec alapú site-to-site VPN megoldással összekapcsoltuk a hálózatokat, így elérhetővé vált a címtár, az SAP és néhány tűzfalas trükknek, illetve DNS beállításnak köszönhetően a terminal server szolgáltatásait is kizárólag az IPSec kapcsolaton keresztül érik el. A rendszerbe becsatlakozó bolt hálózat mind a 4 telephelyére beszerzésre került egy Dell Optiplex desktop gép, új i3-as processzorral (a hardveres kriptográfiai képességei miatt), 4GB memóriával és az elérhető legkisebb, 500GB-os merevlemezzel. A központban gigabites sávszélesség áll rendelkezésre, a telephelyeken jellemzően 20-50MBit közötti kapcsolatok, így a központi tűzfal és a telephelyeken lévők is megbírkóznak a legmagasabb AES típusú titkosítás mellett is a feladatokkal. Mivel egy telephely kivételével (ahol a másodlagos domain controller lakik) nem áll rendelkezésre a címtár, ezért az üzletek telephelyein különféle DNS trükköket (feltételes továbbítás, host és domain override, stb.) kellett alkalmazni, hogy mindenhol működőképes legyen a tartományi bejelentkezés.

Telephelyek közti VPN megoldás

A második legnagyobb

Nemrégiben kaptunk felkérést szintén egy nagyobb vidéki cégünktől, ahol a rekord 640 napos uptime-mal rendelkező tűzfalunk üzemelt eddig, hogy építsünk nekik valami hasonlót, mint a másik ügyfélnél, mert több telephelyes céggé alakulnak. A megoldásuk nagyon hasonló a másik vidéki cégéhez, egy pesti szerver parkban elhelyezett gépen virtualizálva található meg a központi PfSense rendszer, ahova a többi telephely tűzfalai csatlakoznak be IPSec megoldással, a központban lévő szerverek pedig szintén egy virtuális Hyper-V LAN-on találhatóak, ahol csak a PfSense tűzfalon keresztül lehet őket elérni. Emellett náluk még jelen van kétféle OpenVPN konfiguráció is, illetve a másik cikkben már részletezett geográfiai szűréseket is alkalmazzuk.

Tűzfal URL szűréssel

Egyik ügyfelünknél a már megszokott geográfiai szűrés mellett szerették volna a felhasználók gépein a netezést is szigorítani, letiltani például a közösségi oldalakat és egyéb nem kívánatos szolgáltatásokat. Mivel már korábban is fix IP-vel rendelkeztek a hálózaton a gépek, ezért a squid+squidguard csomagok használata mellett döntöttünk, amivel egy transzparens proxy megoldást alkottunk. Ezen beállításra került egy VIP és egy nem VIP csoport, amikbe belepakoltuk a fix IP címeket és ez alapján legyártottuk az ügyfél kérésére az URL szűrési szabályokat.

Vidéki önkormányzat törvényi megfeleléssel

Egy vidéki hivatalban a korábban kiadott törvényi előírásoknak megfelelően kellett kialakítani a hálózat biztonságát. Természetesen a PfSense rendszer tudásában minden szigorú feltételnek meg tudott felelni, még ha nem kevés munkaidőt is igényelt egy ilyen bonyolult rendszer kialakítása. Köszönhetően a számos VLAN-nak, a nagyon szigorú tűzfalszabályoknak, a Radius-alapú WIFI hálózat követelményeinek, a pluszban beszerelt 4db hálózati kártyán futó összesen kb. 8 hálózati szegmensnek.

Komoly OpenVPN szerver hardveres tűzfal mellett

Szintén egy vidéki ügyfelünknél került beüzemelésre egy komoly titkosítással bíró OpenVPN szerver, ahol a PfSense Hyper-V virtuális gépként fut, rajta összesen 5db VPN konfigurációval. Ezek közül 2 a régi mobileszközök komptibilitásának biztosítására lazább titkosítással, helyi adatbázisból történő hitelesítéssel működik. A másik 3 esetében LDAP alapú hitelesítést alkalmaztunk, ahol az Active Directory címtárban lévő különböző biztonsági csoportok tagsága alapján dönti el a rendszer egy-egy felhasználóról, hogy engedélyezi-e számára a hálózathoz való hozzáférést. A csatlakozást követően mind az 5 OpenVPN elérés esetében külön hálózati szegmenseket hoztunk létre, amelyekből a forgalom korlátozásra került, aszerint hogy melyik hálózatból érkezik a kliens csak a neki szükséges szervereket és portokat éri el.

Boldog ügyfél

A legtöbb ügyfelünk tehát sima csomagszűrő tűzfalként, vagy OpenVPN szerverként használja ezt a megoldást, ugyanakkor a fentiekből is látszik, hogy komoly, nagyvállalati megoldásokat is lehet belőle építeni némi szaktudás birtokában. Gyakran felesleges pénzkidobás megvenni a méregdrága nagyvállalati megoldásokat, mert a szükséges vagy a használandó szolgáltatások ugyanolyan minőségben elérhetőek ingyenes, Unix alapú tűzfalrendszereken is. Forduljon hozzánk bizalommal hogyha olcsó, de megbízható és biztonságos megoldásra vágyik vagy csak szeretné cégének megtalálni a legoptimálisabb megoldást.

Profi, de hanyag rendszergazda csillagász összegekért?

Jelen cikkünk legyen egyfajta tanulság is néhány cégvezető számára, de egyben gondolatébresztő is, hogy nem minden arany, ami fénylik, illetve az egyébként hozzáértő, de drága rendszergazda sem garancia a jó munkára.

Unatkozó rendszergazda

A történet egy fővárosi nagyvállalatnál játszódik. Sok telephelyes, több tucat szerverrel ellátott környezet, több száz felhasználó. Nagyvállalati eszközök, főként Dell szerverek, storage-ok, Cisco tűzfalak és minden ami egy nagyvállalat fegyvertárában jelen szokott manapság lenni. Mindezek üzemeltetéséhez egy néhány tagú helyi, lelkes IT csapat komoly szerveres szakmai tudás nélkül, jellemzően a helyi kliens problémák megoldására. Időközben egy olyan IT vezetővel kiegészítve, aki a korábbiakhoz képest lényegesen szélesebb látókörrel rendelkezik a nagyvállalati informatika területén, de ahogy mondani szokták egy fecske nem csinál nyarat, egymaga kevés a felmerülő rendszerszintű problémák elhárítására. Kiegészítésükre tehát a cég külső rendszergazdát alkalmaz, egy nagy IT szolgáltatót, akinek már kellő tapasztalata és neve is van a piacon. Ennek megfelelően természetesen a csillagász összegekért általuk ajánlott és felépített infrastruktúrát ugyancsak csillagász összegekért üzemeltetik. Pontos számot nem írnék, mi sem tudjuk, csak azt, hogy nagyon magas ez az összeg. Jóval több annál, mint amire most én vagy Ön gondol. A havonta súlyos milliókból üzemeltetett rendszer mégsem jó, mégsem gyors, és nem is igazán stabil.

Korábban volt szerencsénk belelátni a rendszer működésébe, évekkel ezelőtt, még azelőtt, hogy a jelenlegi cég munkába állt volna, és ma is rálátásunk van sok mindenre, így tudjuk a rendszer gyenge pontjait. Ismerjük azokat a komoly szakmai hibákat, amelyeket mind a mai napig nem javítottak ki és amelyek még jelen pillanatban is keserítik az ott dolgozók életét, habár ezt nem biztos, hogy ők is tudják vagy értik. Mindenesetre azt látják, hogy az ügyviteli programjaik lassúak, a szerverek teljesítménye látszólag gyenge, a szolgáltatások minősége évek alatt nem változott semmit. Pedig költeni költöttek üzemeltetésre eleget.

Csak két konkrét példát említenék erre az esetre, amit egy jó képességű, de hanyag cég elkövethet. Az egyik, hogy évekkel ezelőtt tudomásunkra jutott – és jelezve lett nekik is -, hogy a fióktelephelyeken lévő kis fájlszerverek mindegyikének van valami SOS beavatkozást igénylő problémája. Mentés az ezeken tárolt adatokról jellemzően nincs, pedig fontos lenne, ugyanakkor szinte mindegyik szerverben van kisebb-nagyobb mértékben hibás merevlemez, de van amelyiket ezen felül még más hardver hiba is sújtja. Ez az állapot minimum 5 éve már fennáll, de azóta sem történt semmi előrelépés. Pedig nem a költségvetésen múlik, ahogyan üzemeltetésre is futja bőven, úgy hardver beszerzésre is. Mégsincs megoldva egy évek óta égető probléma. Aztán kiderül, hogy ugyanez a cég két telephely összevonása során képes volt úgy áthelyezni, beüzemelni a másik telephelyen a méregdrága Cisco tűzfalat, hogy a fő telephely számtalan kliens gépe az összes szerver és az internet eléréséhez egyetlen gigabites porton, a tűzfalon keresztül kapcsolódjon. Természetesen szigorúan nem hibatűrő megoldásban, hogy egy tűzfal meghibásodás (ami bőven túl van a garanciaidején) esetén lehetőleg ne csak az internet és a fióktelephelyek kapcsolata szűnjön meg a központtal, hanem a teljes központ minden gépe bénuljon meg. Mindezt azért, mert a tűzfal áthelyezésekor szükség lett volna néhány munkaórára ahhoz, hogy átkonfigurálják a tűzfalat, persze egyszerűbb volt így megoldani. Közben a szerver elérések, az ügyviteli programok dög lassúak, mindenki egyetlen dróton megy mindenhova.

Aztán következzen az a rövid történet, ami ugyancsak az üzemeltető trehányságát, nemtörődömségét tükrözi és ami miatt ezt a cikket a sikertörténetek közé is beteszem – habár külső szakértőként vagyunk kénytelenek az egész vesszőfutást végignézni, miközben ott segítjük az ügyfelet ahol tudjuk – annak ellenére, hogy sajnos tanulságos volt, de mégsem lett igazi siker. Nem lett az, mert az ügyvezető és az őt körülvevők továbbra sem szánták rá magukat a váltásra, viszik tovább a régóta meddő és méregdrága vonalat, mert amúgy az üzemeltetőjük valóban hozzáértő, csak éppen nem teszi rendesen a dolgát. Nekünk ami mégis sikertörténet, hogy ez a cég nemrég akkorát égett, mint a Reichstag, ahogy mondani szokták. Történt ugyanis, hogy az ügyfélnél beszerzésre került egy központi vezérlőegységgel ellátott, nagyvállalati WIFI rendszer. A legfőbb feladata ennek a rendszernek természetesen nem az volt, hogy a dolgozóknak Facebook-ot és privát netezési lehetőséget adjon, legfőképpen azért vásárolták, mert a terepről érkező dolgozóknak mobileszközökről kellett volna egy egyedi fejlesztésű szoftverrel adatcsomagokat beküldeni a központi szerverre. Minden remekül működött a beüzemelt rendszeren, kivéve ezt az egy apróságot, a lefejlesztett szoftver ugyanis küldésnél folyamatosan megakadt. A milliókat kereső rendszergazda természetesen nem vitte ezúttal sem túlzásba a segítségnyújtást, a fejlesztő viszont kénytelen volt a saját idejét nem sajnálva a végére járni a dolognak. Arra jutott, hogy egy pár ezer forintos WIFI routert beüzemelve a rendszerbe a saját szoftvere gond nélkül leküldte az adatokat. Jelezte ezt az ügyfél felé, ahol az ottani IT csapat kérte az üzemeltetőt, hogy segítsen, de az csak széttárta a karját, mondván hogy az eszköz vélhetően rossz és garanciában ki kell cseréltetni. Itt jegyzem meg, hogy az eszközöket tőlünk vették, emiatt kerültünk bele mi is a történetbe végül. Több hibátlan WIFI AP-t is kicseréltettek velünk korábban, amit a jó kapcsolatra tekintettel a nagykereskedés próba nélkül cserélt nekünk újakra, de természetesen a hiba nem lett ezzel megoldva. Végül kb. fél évnyi küszködés után megkeresett minket az ügyvezető, hogyha kell megfizeti nekünk, de menjünk oda és csináljunk vele valamit, leginkább bizonyítsuk be, hogy az eszköz jó. Odamentünk a fejlesztővel karöltve (bár csak a saját rendszergazdájuknak volt megfelelő helyismerete és hozzáférése mindenhez, fél év után sem érezte magáénak a projektet annyira, hogy odajöjjön vagy bármit segítsen) és miután a kontrolleren lévő beállítások nem voltak fontosak úgy kezdtünk neki a feladatnak, ahogy egy valamire való rendszergazdának kéne. Minden alkalommal, amikor egy hardvert kiveszünk a dobozból és beüzemelünk, legyen az szerver, router, tűzfal, switch vagy bármi egyéb első körben szétnézünk a gyártó weboldalán firmware frissítések után. Ennek a logikája igen egyszerű, a már bekonfigurált és élesben futó eszközökön ez nyilván sokkal komplikáltabb, mint a beüzemelés előtt állón. Ezeket a frissítéseket pedig éppen amiatt adják ki, mert hibákat, biztonsági problémákat javítanak bennük. Itt ért minket a megdöbbenés, a WIFI kontrolleren az első megjelenéskor kiadott béta firmware volt, ami már az eszköz beszerzése idején is közel másfél éves volt (valahol sokat állhatott a kontroller egy raktárban), az ominózus helyszíni hibaelhárítás idején pedig már kettővel újabb főverzió volt a firmware-ből, ami nem csak rengeteg hibajavítást tartalmazott a bétához képest, de rengeteg új funkciót is. Ezt az egyébként kb. 5 perces munkát a csilliárdokért üzemelő rendszergazda fél év alatt képtelen volt elvégezni, pedig akár távolról is megtehette volna. A kontroller frissült a legújabb verzióra, megtartva az alapbeállításokat, ezzel együtt leküldött az access pointoknak is egy új verziót a szoftverből és amint újraindultak kezdődhetett a teszt a fejlesztő tabletjén. Láss csodát, az adatküldés azonnal sikeres volt. Kezdhettünk pakolni, bár a fejlesztő maga sem akarta elhinni, hogy ennyi volt az egész, így még számtalan tesztet elvégzett, de a lényeg az egészben, hogy a rendszer azóta is megbízhatóan teszi a dolgát.

Kérdések

A tanulság az egészben, hogyha hozzáértő és esetleg jó nevű is a rendszergazda, a rendszer működésében pedig nem látszanak komoly hibák, ettől még nem feltétlen van minden rendben. Egy havonta gigantikus összegekből üzemeltetett rendszer is lehet nagyon gyenge, ahogy egy szinte fillérekből összerakott és olcsón fenntartott is lehet meglepően jó néha. Számos egyszerűnek tűnő, de kínos kérdést lehet feltenni rendszergazdáknak és persze magunknak is.

  • Megfelelően dokumentálva van a rendszerem? Ha azt, akinek a fejében van minden elüti a villamos lesz aki pár órán belül egy dokumentáció alapján el tud igazodni?
  • Rendben van a mentésem? Ha jön egy zsarolóvírus lesz miből helyreállni?
  • Van aktív vírusvédelem a gépeken? Ha van milyen és biztosan a legjobb ár/érték arányú megoldást használom?
  • Rendszeresen karban vannak tartva a szervereim, munkaállomásaim? Mit ér önmagában egy jól felépített, de elhanyagolt rendszer? Lehet-e annyira jól felépített, hogy önmagát üzemeltesse?
  • Mennyire végzi el a rendszergazda a dolgát? Nekem úgy tűnik minden rendben, de csak a jéghegy csúcsát látom? Rendben, hogy a tudása esetleg megvan hozzá, de valóban végzi is rendesen a dolgát?

És még számos kérdést fel lehetne tenni ezzel kapcsolatban. Hamarosan egy külön weboldalon fogunk segíteni a döntéshozóknak feltenni ezeket a kérdéseket és ellenőrizni a válaszokat, addig is mindenki gondolja végig ezeket, mert bár szélsőséges, de sajnos nem egyedülálló a leírt eset.

Facebook