Saját felhő 50 felhasználóra EU-s szerveren: mi van a csomagban, mit kíván az üzemeltetés
A döntés rendszerint nem technikai kérdésen múlik: ki fér hozzá a szerződésekhez, a HR-mappákhoz és az ügyféladatokhoz, és melyik országban van a szerver, amin ezek vannak? A legtöbb kkv-nál a válasz három részből áll (valami egy ingyenes fájlmegosztón, valami egy-egy kolléga gépén, valami e-mail-csatolmányokban), és egyikre sincs jó válasz.
Nálunk erre egy saját felhő lett a megoldás: nyílt forráskódú platform egy EU-s szerveren, 50 felhasználóra méretezve, 10–12 konténerben. Ez a cikk azt írja le, mi van a csomagban, mit ad a dobozos szolgáltatáshoz képest, mit kíván az üzemeltetés a mindennapokban, és mikor nem éri meg belevágni. Adatvédelmi kérdésekben ez nem jogi tanácsadás: a konkrét megfelelést érdemes adatvédelmi szakemberrel átnézetni.
Miért saját felhő, ha van ingyenes fájlmegosztó?
Előre a legfontosabb: az ingyenes fájlmegosztó nem rossz eszköz. A probléma többnyire a használat módja: magánfiókokból összeálló megosztás-háló, amelyben senki nem tudja megmondani, melyik dokumentumnak hol van a hiteles példánya. A váltás valódi tárgya ezért a rend, és csak másodsorban a technológia.
Három ok szokott elég erős lenni ahhoz, hogy egy kkv saját felhőt üzemeltessen. Egyik sem ideológiai.
1. Tudni kell, hol van az adat. Ha a szerződések, a bérpapírok és az ügyféladatok egy ingyenes fiókban vannak, az adatkezelési tájékoztatóba nehéz őszinte mondatot írni arról, hol tárolják őket és ki fér hozzájuk. Saját felhőnél a válasz egy mondat: egy megnevezett európai adatközpontban, ezeken a jogosultságokon, ezzel a megőrzési idővel.
2. A hozzáférés legyen visszakereshető. Nem az a kérdés, hogy ki tud belépni, hanem hogy ki lépett be, mit látott, és mi történik, amikor valaki kilép a cégtől. Egy céges felhőben a csoportjogosultság és a megosztások listája adminisztrálható; egy magánfiókokból összeálló megosztás-hálóban nem.
3. A feltételek ne változhassanak a fejünk fölött. Az ingyenes és olcsó csomagok kvótát szűkítenek, funkciót vonnak meg, árat emelnek. Saját felhőnél a korlátot a saját döntésünk szabja meg, cserébe a karbantartás is a miénk.
Amit a saját felhő nem ad meg automatikusan: a megfelelést. Attól, hogy a szerver EU-ban van, a jogosultságok még lehetnek rendetlenek, a mentés hiányozhat, és a törlési határidők betartatlanok maradhatnak. Az adatszuverenitás előfeltétel, nem pipa. A GDPR-oldali részleteket (jogalap, adatkezelési nyilvántartás, adatfeldolgozói szerződés) érdemes szakemberrel átnézetni; ez a cikk az üzemeltetésről szól.
Mi van a csomagban: 10–12 konténer, egy tanúsítvány, egy mentés
A platform nyílt forráskódú (Nextcloud), és konténerekben fut egy EU-s szerveren. A telepítés 10–12 konténerből áll, és ez a szám önmagában is tanulságos: aki egyetlen programnak képzeli a saját felhőt, annak az első frissítés megmutatja a valóságot.
| Mit kell megoldani | Dobozos szolgáltatásnál | Saját felhőnél |
|---|---|---|
| Fájltárolás, megosztás | A csomag része, kvótával | Az alkalmazás-konténer és a tárhely; a kvóta a mi döntésünk |
| Naptár, névjegyzék | A szolgáltató saját alkalmazásában | Szabványos protokollon, a kollégák megszokott naptár-alkalmazásából |
| Adatbázis, gyorsítótár, keresés | Nem látszik, nem a mi gondunk | Külön konténerek; a keresés és az előnézet-készítés eszi a legtöbb erőforrást |
| Titkosított kapcsolat (tanúsítvány) | Adott | Automatikus megújítás; ezen áll vagy bukik, hogy két év múlva is működik-e |
| Mentés | A szolgáltató ígérete, korlátozott visszaállítással | Saját mentés, saját visszaállítási próbával |
| Felhasználó- és jogosultságkezelés | Adminisztrációs felület | Ugyanúgy felület, de a kilépő kollégák kivezetése a mi folyamatunk |
| Frissítés, biztonsági javítás | Magától történik | Ütemezett feladat, előtte mentéssel, utána ellenőrzéssel |
Az utolsó két sor a döntő. A saját felhő attól lesz jó, hogy a tanúsítvány magától megújul, a mentés magától lefut, és van, aki a frissítés után ránéz. Ez a folyamatos figyelem az a költség, amit a tárhelyár mellett a legtöbben elfelejtenek beárazni; erről az üzemeltetési havidíj cikkünkben írtunk tételesen.
A mentés külön fejezet. Saját felhőnél a mentés is a mi felelősségünk, és ugyanaz a három láb kell hozzá, mint bármely más rendszernél: teljes helyi másolat, verziózott rendszer-mentés egy másik köteten, és egy távoli, titkosított másolat. A negyedik, ami mindhármat hitelesíti, a visszaállítási próba. A receptet a mentés három lábon cikkben írtuk le.
Ami a dobozos szolgáltatásban nincs: gépi hozzáférés a saját adathoz
A saját felhő legkevésbé emlegetett előnye az, hogy az adat géppel is elérhető. Nálunk a platformhoz 110-nél több művelet érhető el programozott felületen: fájl és mappa létrehozása, megosztás kiosztása és visszavonása, naptárbejegyzés írása és olvasása, felhasználó- és csoportkezelés. Ez az a pont, ahol a felhő tárhelyből munkaeszközzé válik.
Néhány gyakorlati példa arra, mit lehet erre építeni:
- Dokumentum a helyére. Egy generátor elkészíti a havi kimutatást vagy a nyomdakész anyagot, és a kész PDF magától a megfelelő ügyfél- vagy hónap-mappában landol, a megfelelő csoport jogosultságával.
- Közös erőforrások naptára. A foglalások egy közös naptárba kerülnek, és a foglalórendszer ugyanazon a szabványos protokollon dolgozik, amit a kollégák telefonja is ért. Ennek a bevezetésnek az őszinte mérlegét a foglalórendszer-cikkben írtuk meg.
- Automatizálási munkafolyamatok bemenete és kimenete. A folyamat-motor (nálunk n8n) ugyanarról a tárhelyről olvas, ahova a kollégák dolgoznak, így nincs külön „automatizálási mappa”, amiről senki nem tud. Az eszközről külön írtunk: n8n magyarul.
Egy fontos korlát, amit magunkra is kötelezőnek tartunk: a gépi hozzáférés alapból olvasás. Írni csak kifejezett kérésre, kontrollált úton és naplózva írunk, és minden automata a saját, korlátozott jogú fiókjával dolgozik, nem egy mindenhatóval. Ha egy automata elszáll, az a különbség, hogy egy mappát ír-e el vagy az egész felhőt.
Ez a platformválasztás egyik legerősebb és legritkábban mérlegelt érve. Egy dobozos szolgáltatásnál azt tudja automatizálni, amit a szolgáltató engedélyez, és annyi hívást, amennyit a csomagja tartalmaz. Saját felhőnél a korlát a szerver és a saját fegyelem. Ha a cégnél az automatizálás folyamatosan növekvő réteg, ahol több tucat ütemezett feladat is dolgozhat egymás kimenetéből, akkor ez a szempont önmagában eldöntheti a kérdést.
Az üzemeltetés valódi arca: három tanulság a gyakorlatból
A telepítés egy nap. Az üzemeltetés az, ami utána jön, és saját felhőnél ez a munka nagyobbik fele. Három tanulság, amit érdemes a bevezetés előtt végiggondolni.
1. A kézi változtatás a rendszernek szabályos. Egy közös naptárban, egy megosztott mappában vagy egy jogosultsági csoportban bárki elvégezhet olyan módosítást, amit a platform szabályos állapotváltozásként rögzít. Egy törölt időpont, egy visszavont megosztás, egy átmozgatott mappa: mindegyik engedélyezett művelet, tehát nem keletkezik belőle hibaüzenet, amire a hibariasztás ráépülhetne. Ezért érdemes eltérés-ellenőrzést építeni a rendszer mellé: egy ütemezett feladat rendszeresen összeveti a bejegyzések valódi állapotát a szándékolttal, és eltérésnél jelez. Ezt a fajta ellenőrzést egy dobozos szolgáltatás nem tudja megadni, mert nem ismeri a szándékot; saját felhőnél viszont a szándék is a mi adatunk, tehát össze lehet vetni vele. Ugyanez az elv áll a jogosultságokra: érdemes listát vezetni arról, melyik csoportnak mihez kell hozzáférnie, és a valós állapotot rendszeresen ehhez mérni.
2. A kézi munkáról vezetett napló többet ér, mint amennyibe kerül. Egy bevezetés első heteiben sok olyan beavatkozás történik, ami a rendszer saját naplóiban vagy nem hagy nyomot, vagy olyan technikai sorként landol, amit utólag senki nem tud értelmezni: egy jogosultság kézi átállítása, egy mappa átmozgatása, egy bejegyzés javítása. Egy egyszerű, dátum–művelet–felelős formátumú lista elsőre felesleges adminisztrációnak tűnik, egészen addig, amíg egyszer meg nem kell mondani, mi okozott egy eltérést. A napló melléktermékének pedig rendszerint nagyobb a haszna, mint a fő céljának: kiderül belőle, hogy a kollégák egy része más úton használja a rendszert, mint ahogy a folyamat leírja, és emiatt a beépített ellenőrzések egy része kimarad. Az ilyen kerülőutakra sem hibaüzenet, sem kimutatás nem világít rá, csak az, hogy valaki leírta, mit csinált. A napló ráadásul a legjobb bemenet a következő automatizálási körhöz: ami háromszor szerepel rajta ugyanabban a formában, azt érdemes gépre bízni.
3. A nyitott tételek attól kezelhetők, hogy nyilván vannak tartva. Minden élő rendszerben van egy-két nyitott sor: egy komponens, ami többet fogyaszt a kelleténél, egy átmenetinek szánt beállítás, egy frissítés, ami várat magára. A kérdés ezért az, hogy ezek nevesítve vannak-e. Egy használható nyilvántartásban minden tételnek van egymondatos leírása, gazdája, hatásbecslése (érinti-e az éles működést, az adatot, a felhasználót), és egy döntése arról, hogy javítjuk, kiváltjuk vagy tudatosan együtt élünk vele. Ezt a listát érdemes az üzemeltetési beszámoló részévé tenni, mert így nem merül feledésbe, és így derül ki időben, ha egy apró tétel közben komollyá vált. A nyilvántartás mellékhatása az is, hogy a szolgáltatóváltás vagy az üzemeltető-váltás nem nulláról indul: az új gazda egy listát kap, nem egy találgatást.
A három tanulságnak közös nevezője van: saját felhőnél az üzemeltetés nem esemény, hanem rutin. A telepítés látványos, a napi rutin nem az, és mégis az utóbbi dönti el, hogy két év múlva is működik-e a rendszer. Ezért érdemes már a bevezetéskor eldönteni, ki nézi a frissítéseket, hova érkezik a riasztás, milyen gyakran fut a visszaállítási próba, és hol vezetjük a nyitott tételek listáját. Ez a négy döntés többet ér, mint bármelyik platform-összehasonlító táblázat.
Mikor NEM éri meg saját felhőt üzemeltetni
Az őszinte válasz: az esetek jó részében. A saját felhő akkor jó döntés, ha van érzékeny adat, van elég felhasználó ahhoz, hogy megérje, és van gazdája az üzemeltetésnek. Ha ezek közül bármelyik hiányzik, a dobozos szolgáltatás olcsóbb és biztonságosabb.
| Szempont | Dobozos szolgáltatás jobb, ha… | Saját felhő jobb, ha… |
|---|---|---|
| Létszám | Néhány fő, egy iroda | Több tucat felhasználó, több telephely, csoportjogosultságok |
| Adat érzékenysége | Nincs különösebben érzékeny adat | Szerződés, HR-anyag, ügyfél-személyes adat, orvosi vagy pénzügyi dokumentum |
| Üzemeltetői kapacitás | Nincs, aki a frissítést és a tanúsítványt figyelje | Van saját vagy külsős üzemeltető, nevesített felelőssel |
| Integráció | Elég a böngésző és a mobilalkalmazás | Automaták írnak és olvasnak, a felhő egy folyamat része |
| Kilépés a szolgáltatótól | Nem probléma, az adat exportálható | Fontos, hogy a platform és az adatformátum nyílt maradjon |
| Költségszemlélet | Előfizetés, kiszámítható havidíj | Szerverbérlet plusz figyelem; ez utóbbi a nagyobb tétel |
És van egy szempont, ami minden technikai érvnél erősebb: be fognak-e lépni. Egy másik bevezetésünknél a fiókok közel fele egyszer sem lépett be, és ahol nem lépett be senki, ott a papír és a telefon maradt a rendszer. Két párhuzamos rendszer pedig rosszabb, mint egy. A teljes, számokkal alátámasztott mérleget a foglalórendszer-bevezetés tanulságai cikkben írtuk meg. Érdemes elolvasni, mielőtt bárki platformot vált.
A legdrágább hiba nem a rossz platformválasztás. Az, ha a saját felhő gazdátlanul marad: a tanúsítvány lejár, a frissítés elmarad, a mentés csendben leáll, és három hónap múlva senki nem meri hozzányúlni. Ekkor a saját felhőből kockázat lesz, nem eszköz.
Gyakori kérdések
Mi az a saját felhő, és miben más, mint egy fájlmegosztó szolgáltatás?
A saját felhő egy nyílt forráskódú platform (nálunk Nextcloud), amit a cég a saját, bérelt szerverén futtat. Ugyanazt adja, mint a dobozos szolgáltatás — fájl, megosztás, naptár, névjegyzék —, de a tárolás helye, a jogosultságok, a mentés és a frissítés a cég döntése és felelőssége.
Attól GDPR-megfelelő lesz, hogy EU-s szerveren van?
Nem. Az EU-s tárolás előfeltétel, nem pipa. A megfeleléshez jogalap, rendezett jogosultságok, megőrzési és törlési határidők, valamint adatfeldolgozói szerződés kell a szerver-szolgáltatóval, és a legtöbb kkv-nál adatkezelési nyilvántartás is (a GDPR 250 fő alatti mentessége rendszeres adatkezelésnél nem él). Ez nem jogi tanácsadás; konkrét esetben egyeztessen adatvédelmi szakemberrel.
Hány embernek éri meg saját felhőt üzemeltetni?
Nálunk 50 felhasználóra méretezett telepítés fut, és ebben a nagyságrendben már bőven megéri. Néhány fős cégnél jellemzően nem: ott a dobozos szolgáltatás olcsóbb és biztonságosabb. A fordulópontot nem a létszám adja meg önmagában; az számít, van-e érzékeny adat és van-e üzemeltetői kapacitás.
Mi kell egy saját felhő üzemeltetéséhez?
Egy EU-s szerver, konténeres futtatókörnyezet, automatikusan megújuló tanúsítvány, működő mentés visszaállítási próbával, és egy nevesített ember, aki a frissítéseket és a riasztásokat figyeli. A tárhely ára a kisebbik tétel; a figyelem a nagyobbik.
Lehet a saját felhőre automatizálást építeni?
Igen, ez az egyik fő előnye. Nálunk 110-nél több művelet érhető el programozott felületen: fájl- és mappakezelés, megosztások, naptárbejegyzések, felhasználók. Az automaták alapból csak olvasnak, írni kizárólag kifejezett kérésre, saját korlátozott jogú fiókkal és naplózva írnak.
Mi történik, ha elvész a szerver?
Attól függ, van-e mentés a fájlokról és a konfigurációról is. A fájlokra mindenki gondol, a beállításokra ritkábban, pedig a visszaállításnál a beállítások újraépítése viszi el a legtöbb időt. Ezért a mentési tervben a konfiguráció külön sor, saját visszaállítási próbával.
A következő lépés: négy kérdés a döntés előtt
Nem kell rögtön platformot váltani. Elég négy kérdést megválaszolni, és a döntés jellemzően magától adódik.
- Hol vannak ma a szerződések, a bérpapírok és az ügyféladatok? Írja le egy lapra, ki melyik fiókban tartja őket. A lista maga a diagnózis.
- Mi történik, ha holnap kilép valaki? Kinél marad megosztás, kinél marad helyi másolat, és ki veszi el a hozzáférést — van erre folyamat, vagy csak szándék?
- Ki lesz az üzemeltetés gazdája? Név, nem szerepkör. Ha nincs ilyen név, a saját felhő ne induljon el.
- Mi a mentés és a visszaállítás terve? Ha erre nincs válasz, először a mentést tegye rendbe; az bármelyik platformon a legjobb befektetés. A receptünk a mentés három lábon cikkben van.
Ha a négy válasz alapján a saját felhő indokolt, a bevezetés felméréssel kezdődik: mely mappák és folyamatok kerülnek át, milyen jogosultsági csoportokba, és melyik automata fog rá dolgozni. Ezt nálunk a folyamat-audit fedi le; a menetét és az árát az AI-audit árak oldalon írtuk le, az automatizálás teljes ívét pedig az AI-automatizálás útmutatóban. Ha csak a nagyságrend érdekli, a megtakarítás-kalkulátor két perc alatt ad egy első számot.