Négy környezet, négy egészen más feladat — ugyanazzal az alappal
Az alábbi négy környezet valós, megvalósult projekt. Mindegyiknél az szerepel, hogy mi volt a kiinduló helyzet, mit kellett megoldani, és milyen technikai döntés döntötte el a végeredményt. Az ügyfelek nevétnem tesszük közzé — a megoldott feladat a főszereplő.
4 környezeta médiaszolgáltatótól az izolált kutatólaborig
20+ évvállalati IT üzemeltetési tapasztalat mögötte
1 ügyfél = 1 hálózatmind a négy környezet dedikált szegmensen fut
2 helyszínbudapesti adatközpont, egymástól függetlenül
A négy környezet egy nézetben
Egy médiaszolgáltató, egy kutatólabor, egy pénzügyi szolgáltató és több kereskedelmi cég nem ugyanazt kéri. Az alábbi táblázat azt mutatja, hol tér el a feladat — a részletes leírás mindegyikhez lejjebb olvasható.
Működő, országos szolgáltatás egy meglévő környezetben, amit át kellett venni és át kellett költöztetni.
Teljes belső hálózati, web- és adatinfrastruktúra kialakítása, migrációval és folyamatos üzemeltetéssel.
Párhuzamos építés és teszt-migráció, redundáns 2×10 Gbps gerincen.
02Biotechnológiai kutatólabor
Nagy adatmennyiséget kezelő kutatási terhelés olyan adaton, ami nem lehet kitéve az internetnek.
Teljesen izolált, az internetről nem elérhető IT infrastruktúra.
Privát alhálózat saját switchen, dedikált VPN-endpoint, out-of-band management.
03Pénzügyi szolgáltató országos fiókhálózattal
Kifelé nyitott publikus felület és a legérzékenyebb adat ugyanabban a rendszerben.
Kétszintű, szegmentált alkalmazás-stack.
Az adatbázis- és alkalmazásréteg élesen elválasztva a publikus szolgáltatásoktól.
04Kereskedelmi és szolgáltató cégek
Évek óta működő, de dokumentálatlan rendszer, egyetlen kolléga tudásán.
Web-, fájl- és címtárkörnyezetek kiszervezett üzemeltetése.
Átvétel dokumentálással, monitorozás, stabilizálás, napi mentés-ellenőrzés.
A négy környezet részletesen
Minden eset ugyanazt a szerkezetet követi: mi volt a helyzet, mit tettünk, és mi ebből a lényeg. A technikai részletek lenyithatók, a hivatkozások pedig oda visznek, ahol az adott megoldás általánosan is le van írva.
Működő országos szolgáltatás alatt cseréltük ki az infrastruktúrát
A feladat a teljes belső hálózati, web- és adatinfrastruktúra kialakítása és üzemeltetése volt — de nem üres lapról. A rendszer működött, országos lefedettséggel, és a költöztetés alatt is működnie kellett. Egy ilyen szolgáltatónál a leállás nem üzemeltetési kellemetlenség: kieső szolgáltatás.
Ezért az új környezet nem a régi helyén épült fel, hanem mellette. Előbb állt fel teljesen, mielőtt bármi átkerült volna rá; a teszt-migráció után jött csak az éles átállás, egyeztetett időablakban, visszaállási forgatókönyvvel. A terhelés nagy erőforrás- és tárigényű, a gerinchálózat ezért itt is a redundáns 2×10 Gbps kiépítés — egy uplink vagy egy switch kiesése nem jelent szolgáltatáskiesést.
A projekt nem az átállással ért véget: a környezet azóta is a mi üzemeltetésünkben fut, felügyelettel, mentéssel és dokumentációval együtt.
A migráció akkor sikerült, ha a nézőnek fel sem tűnt, hogy volt.
Olyan környezet, amely felé az internet felől nem vezet útvonal
Nagy adatmennyiséget kezelő kutatási terhelések, olyan adaton, amelynek a jellege nem enged internetes elérhetőséget. Ilyenkor nem az a kérdés, hogy elég erős-e a tűzfalszabály, hanem az, hogy van-e egyáltalán szabály, amit el lehetne rontani.
A megoldás teljesen izolált infrastruktúra: privát alhálózat, saját virtuális vagy fizikai switchen, publikált szolgáltatás nélkül. Az internet felől nincs útvonal a környezetbe — nem tiltás miatt, hanem mert nincs mit tiltani. A hozzáférés dedikált VPN-endpointon keresztül történik, a kezelőfelület pedig az out-of-band management hálózaton áll, ami szintén nem elérhető kívülről.
Ez ma nem terv nálunk, hanem működő gyakorlat: az érzékeny adatot kezelő ügyfeleink környezete így fut.
Az izoláció itt nem beállítás, hanem topológia. A beállítást el lehet rontani, a topológiát nem.
Két szint, hogy a publikus oldalról ne legyen út az adatig
Egy pénzügyi szolgáltatónál a rendszer legkitettebb és legérzékenyebb pontja ugyanaz a rendszer: a publikus felületnek kívülről elérhetőnek kell lennie, az adatnak viszont a lehető legvédettebbnek. Lapos hálózaton ez a kettő egy ugrásnyira van egymástól.
Ezért a stack kétszintű: az adatbázis- és alkalmazásréteg élesen elválasztva a publikus szolgáltatásoktól. A környezet előtt ügyfelenként dedikált átjáró áll, saját tűzfal-, NAT- és VPN-szabályokkal, és saját publikus IPv4-címmel a mi címtartományunkból — így a szolgáltatás és a levelezés IP-reputációja nem függ attól, mit csinál egy másik ügyfél.
A gyakorlati következmény egyszerű: ha a publikus réteg egy komponense elesik, az egy komponens elvesztése marad. Nem nyílik meg vele az adatbázis.
Nem az a kérdés, bejut-e valaha a támadó az első gépre. Az, hogy onnan meddig jut el.
A rendszer működött. Csak épp egyetlen ember tudta, hogyan
Ez a negyedik eset nem egyetlen nagy projekt, hanem több cég ugyanabban a helyzetben: web-, fájl- és címtárkörnyezet, ami évek óta megy, de dokumentálatlanul. A tudás egy fejben van, a mentésről senki nem tudja biztosan, hogy visszaállítható, a jogosultságokról pedig már régen nem tudja senki, ki mihez fér hozzá.
Az átvétel ilyenkor nem költöztetéssel kezdődik, hanem felméréssel: mi fut, min fut, mi hiányzik. Utána jön a dokumentálás, a monitorozás bevezetése, majd a stabilizálás — a feltárt hiányosságok javítása: hiányzó frissítések, mentési hézagok, elavult jogosultságok. Csak ezután lesz a rendszerből folyamatosan üzemeltetett környezet, rendszeres riporttal.
Ahol a hardvernek a telephelyen kell maradnia — mert oda köti egy gyártásvezérlő, egy mérőműszer vagy egy adatkezelési szabály —, ott nem költöztetünk. Ugyanazt az eljárásrendet visszük ki a helyszínre.
A kulcsemberfüggőség nem akkor derül ki, amikor a kolléga dolgozik. Hanem amikor nem.
Webkörnyezet: web- és levelezőkiszolgálók a publikus rétegen, TLS-tanúsítványok lejárat-figyeléssel
Átvétel: állapotfelmérés és kockázati lista, majd dokumentált átadás-átvétel — akár a távozó kollégával egyeztetve
Stabilizálás: az első hetekben a feltárt hiányosságok javítása: frissítések, mentési hézagok, jogosultságok
Üzemeltetés: monitorozás, helpdesk, frissítéskezelés, napi mentés-ellenőrzés, rendszeres riport
Ami mind a négy környezetben ugyanaz
A négy feladat nagyon különbözik egymástól, az alap viszont nem. Ez nem opció egy árlistán, hanem az a kiindulás, amiről minden környezet indul nálunk — a többi ehhez képest a testreszabás.
Ezért nem kell külön „biztonsági csomagot” rendelnie: az alap nem felár, hanem a kiindulás. A részletek a Technológia és a Biztonságoldalon állnak.
Mit kap papíron
Egy projekt akkor ér valamit, ha a végén nem csak működik valami, hanem le is van írva. Az alábbi dokumentumok mind a négy környezetben ugyanúgy elkészültek — ezek azok, amelyek egy auditnál, egy szolgáltatóváltásnál vagy egy incidens után számítanak.
Dokumentum
Mit tartalmaz
Mikor keletkezik
Állapotfelmérés és kockázati lista
Szerverek, hálózat, munkaállomások, licencek, mentés és a feltárt kockázatok — konkrétan, nem becsléssel.
A döntés előtt. A felmérés nem kötelezettségvállalás.
Célarchitektúra, RPO és RTO
Rendszerenként meghatározva, mennyi állásidő és mennyi adatvesztés fogadható el.
Az ajánlat előtt.
Migrációs terv és visszaállási forgatókönyv
Ütemezés, sorrend, teszt-migráció, és az is, mi történik, ha vissza kell lépni.
Az átállás előtt. Kritikus rendszer élesben, előkészítés nélkül nem költözik.
Szolgáltatási szerződés (SLA)
Rendelkezésre állás, reakcióidő, karbantartási ablakok, mentési és megőrzési szabályok — írásban.
A szolgáltatás indulásakor.
Rendszerdokumentáció
A működő környezet átadható leírása. Ez az a pont, ahol a tudás kikerül egyetlen ember fejéből.
Átvételkor, majd változáskövetéssel folyamatosan.
Visszaállítási jegyzőkönyv
A mentésből valóban elindul-e a rendszer — elkülönített tesztkörnyezetben, minősítéssel.
A visszaállítási teszt után, önálló szolgáltatásként.
Üzemeltetési riport
Mi történt a környezetében, és mire érdemes a következő időszakban készülni.
Az üzemeltetés alatt, ütemezetten.
Miért kezdünk mindig felméréssel
A négy környezet közül egyiknél sem az volt az első lépés, hogy ajánlatot adtunk. Előbb fel kell térképezni, mi fut ma, min fut, mi hiányzik, és mi az, ami holnap reggel eltörhet. Enélkül az ajánlat becslés lenne, a migrációs terv pedig találgatás.
szerverek, alkalmazások, adatmennyiség, hálózat és a valós erőforrás-igény
a mentés tényleges állapota — nem az, hogy elindul-e, hanem hogy visszaáll-e
jogosultsági struktúra és a hozzáférések nyilvántartása
rendszerenként RPO és RTO: mennyi állásidő és mennyi adatvesztés fogadható el
Ez ritkán kerül szóba egy ajánlatkérésnél, pedig ez méri le a legjobban, mennyire átlátható egy üzemeltető. Nálunk a környezet dokumentált és átadható, a jogosultságok nyilvántartottak, a mentések visszaállíthatósága pedig jegyzőkönyvvel igazolt.
naprakész rendszerdokumentáció — nem az üzemeltető fejében
változáskövetés: mi módosult a környezetben, mikor és miért
hozzáférési és eszkalációs útvonalak leírva
az adat minden esetben az Öné — mi tárolási és üzemeltetési szolgáltatást adunk hozzá
Ezek azok a mondatok, amelyeket a felméréseken a leggyakrabban halljuk. Mindegyik mögött ugyanaz áll: egy kockázat, amiről a cégen belül mindenki tud, csak épp senkinek nem az ő dolga. A jobb oldali hivatkozás odavisz, ahol ezt már megoldottuk.
Amit ma tapasztal
Mit jelent ez
Hol néztük ezt már meg
„Működik, de csak egy kolléga tudja, hogyan.”
Kulcsemberfüggőség. A tudás nincs dokumentálva, tehát nem is átadható.
Ha a felsorolásból több sor is ismerős, az nem kivétel: a legtöbb környezetben ezek együtt járnak. A GYIK oldalon a leggyakoribb kérdésekre — köztük arra is, hogy ki fér hozzá az adataihoz — rövid válaszok állnak.
Amit erről az oldalról szándékosan kihagytunk
Egy esettanulmány-oldalon a legkönnyebb dolog túlígérni. Ezért kimondjuk azt is, mi az, amit nem írunk le — ez ugyanolyan információ, mint a többi.
Nem írunk ki ügyfélnevet
Egy üzemeltetőnél az, hogy ki a partnere, önmagában is információ — arról, hol áll az adott cég infrastruktúrája, és kinél van hozzá kulcs. Ezt nem tesszük ki egy honlapra. Ha a döntéséhez referencia kell, kérdezzen rá a felmérésen: megnézzük, mit tudunk az érintett partner hozzájárulásával megosztani.
Nem írunk ki számot, amit nem mértünk
Nincs ezen az oldalon megspórolt óra, százalékos gyorsulás vagy elért rendelkezésre állás. Ami szám itt szerepel — 20+ év, két adatközponti helyszín, 2×10 Gbps —, az mind visszakereshető a honlap többi oldalán is. A vállalt rendelkezésre állás és reakcióidő a szolgáltatási szerződésbe való, nem egy esettanulmányba.
Az esettanulmány nem árlista
A leírt megoldás az adott környezetre készült. Nem sablonokat árulunk: az infrastruktúrát és az üzemeltetési szolgáltatást is az adott igényekhez szabjuk, tehát abból, hogy egy hasonló cégnél mi vált be, még nem következik az Ön ajánlata.
Nem állítjuk, hogy minden projekt sima volt
Egy migrációnál mindig van olyan, ami nem a terv szerint alakul. Éppen ezért készül hozzá visszaállási forgatókönyv, és ezért nem élesben próbálunk ki semmit először. A különbség nem az, hogy nincs meglepetés, hanem hogy van rá válasz.
* A fenti négy környezet valós, megvalósult projekt. Ügyfeleink nevét nem tesszük közzé — sem itt, sem a honlap más oldalán. Egy üzemeltetőnél az, hogy ki a partnere, önmagában is információ arról, hol áll az adott cég infrastruktúrája; ezt nem hozzuk nyilvánosságra. A leírások ezért az ágazatot és a megoldott feladatot nevezik meg, a céget nem. Ugyanezen okból nem szerepel az oldalon mért teljesítmény-, méret- vagy megtakarítási adat. A Rólunk oldalon szereplő számok — 20+ év tapasztalat, két budapesti adatközponti helyszín, redundáns 2×10 Gbps gerinchálózat — a saját infrastruktúránkra vonatkoznak, nem az ügyfelek környezetére.
Az ötödik eset lehet az Öné
Kezdjük ugyanott, ahol a másik négyet: egy felméréssel. A végén kap egy dokumentált állapotképet és egy kockázati listát — akkor is, ha nem velünk dolgozik tovább.
