Szerződéssel és kóddal marad kézben a felhőüzemeltetés

Röviden

• Sepsy Károly szerint a kontrollt a szerződés és az infrastruktúra mint kód adja.
• A vezetés így mérhető RTO, RPO és változáskezelés mellett kezeli a kockázatot.
• Nyitott kérdés a hibrid üzem és a megfelelés ritmusának összehangolása.

Ki irányít, ki dönt, és ki viszi el a felelősséget, amikor a felhőben megáll egy üzleti rendszer? Ezt a kérdést nem lehet tovább tolni. Magyar cégeknél ez pénz, kockázat és idő egyben. A DIG-IT Podcast vendége, Sepsy Károly, a TC2 üzletfejlesztési vezetője arról beszélt, hogy a tényleges kontroll nem ígéret, hanem dokumentált működés. Szerinte a bizonyíték a szerződés és a kód, mert ezekben lehet rögzíteni a mérés, az engedélyezés és a visszakereshetőség rendjét.

Előbb a szerződés és a kód, csak utána a felhő

Sepsi elmondása szerint a TC2 kétnapos, külső átvilágításon ment át, így lett AWS Managed Service Provider minősítésük. Ezt a működés következetessége és a dokumentált folyamatok alapján adják, nem kapcsolati alapon. A kontroll ott kezdődik, hogy a helyreállítási célok számmal élnek. Rendelkezésre áll a helyreállítási idő cél (RTO) és az adatvesztési cél (RPO), és ezek vállalhatók a költség szempontjából is.

Az infrastruktúra mint kód megközelítés (IaC) teszi láthatóvá a változást. A módosítás jegyhez és jóváhagyáshoz kötött, a kód verziókezelt helyen él, és a bevezetés lépései automatizáltak. Ennek hiányában elsodródik a valóság a leírt állapottól, ezt hívják driftnek. Sepsi szerint a kódalapú üzemeltetés csökkenti a személyfüggést, és bizonyíthatóvá teszi, ki mit kért és mi változott. A kilépési terv is itt nyer értelmet, mert átadhatóvá válik a környezet, nem emberek fejében lakik. A modern felhős fejlesztésnél ehhez kapcsolódik a folyamatos integráció és telepítés (CI/CD) pipeline is, amely az élesítési lépéseket szabályozott keretek közé viszi.

Az adásban szóba került egy friss minősítés is, a Partner-led Support. A műsorvezető jelezte, hogy a részletekről az adás későbbi részében lesz szó. Az üzenet így is egyértelmű. A szolgáltatói címke önmagában nem elég, a lényeg a rögzített működés és az átlátható felelősség. Sepsi szerint globálisan kétszáznál kevesebb MSP partner van, de ezt érdemes külön ellenőrizni.

Költség és kockázat két lépésben

Az üzleti döntéshez számok kellenek. Sepsi szerint a költségbecslés két lépcsőben működik jól. Az első a meglévő rendszerek felmérése és az ésszerű méretezés, akár egyszerű átemeléssel. Már itt lehet licenc- és kapacitásoptimalizálást találni, ha a valós terheléshez igazítják a méretet. A második lépcső a belépési környezet és a bizonyítási célú prototípusok (PoC), ahol menedzselt adatbázis, konténerizálás vagy szerver nélküli minta adhat pontosabb képet a valós költségről.

A felhőben a mozgó célpont sokszor az adatforgalom költsége. Sepsi tapasztalata szerint ez jellemzően tíz százalék alatt marad, gyakran három százalék körül. A megfelelés nem külön projekt, hanem a napi működés része. A beszélgetésben említett migrációgyorsítási program (Migration Acceleration Program) azt célozza, hogy az értékek és a kockázatok az elejétől számszerűsítve legyenek. Ide tartozik az RTO és az RPO vállalható szintje is, mert a túl szigorú cél nagyon megdrágít mindent.

Üzemeltetés a gyakorlatban hibridben és AI-val

A jó üzemeltetés mérésből él. Egyszerű példa a tárhely telítettségének jelzése, amely 80 százaléknál tervezett beavatkozást, 95 százaléknál azonnali lépést igényel. A fejlettebb réteg az anomáliafelismerés a hálózati és alkalmazásprogramozási felület (API) naplókban. Sepsi és a műsorvezetők szerint az AI itt nem helyettesít, hanem előszűr. Leszedi a zajt, hogy az elemző arra az esetre koncentráljon, ahol tényleges kockázat látszik, például gyanús bejelentkezési mintáknál.

Aki még saját szervertermekben működik, vegyes képet mutat. Monitoring szinte mindig van, de a minőség és a használat sokféle. A nagyvállalati valóság emiatt gyakran hibrid. Sepsi szerint ez teljesen ésszerű, mert a felhő rugalmas kapacitást és katasztrófa utáni helyreállítási teret (DR) ad. Ha az RTO engedi, elég lehet egy takarékláng jellegű megoldás, ahol a mentések és az alapok élnek a felhőben. A teljes környezet az infrastruktúra mint kód alapján gyorsan felépíthető, és amíg nincs rá szükség, alig kerül pénzbe.

Az induláshoz szükséges alapokat a TC2 egy előre összerakott környezetben adja. Ezt landing zone-nek hívják, náluk Lazy a termékcsalád neve. Ebben többféle rendszer is helyet kaphat, és gyorsan futtathatók a próbakörök. A cél, hogy a döntéshez ne hit, hanem mért eredmény álljon rendelkezésre. A pénzügyi oldal ehhez transzparens költségfigyelést igényel, különben a vezetés csak utólag látja a túlfutásokat.

A DIG-IT olvasata szerint a felhő nem önmagában dönt, a működés dönt. A vezetés akkor van kézben, ha szerződésben rögzíti az RTO és RPO célokat, a szolgáltatási szint megállapodás (SLA) céljait, és a változáskezelés kódalapú rendjét. Ugyanilyen fontos a kilépési terv is. Szerintünk a költségfegyelemhez segít a felhőpénzügyi szemlélet (FinOps), ezt a beszélgetés nem részletezte. Ezzel nem beszállítót, hanem bizonyítható működést választ. Aki marad a hibajavítás-alapú szemléletben, az a költséget és a kockázatot is nehezebben tudja előre látni.

DIG-IT Podcast szerkesztőség - All rights Reserved.