Blog internet-users-lose-it-during-facebook-s-momentary-downtime-65d7047651

Publikálva 2013. március 29 | by j.jetson

A leállások margójára

Nem volt stresszmentes a múlt hét jó néhány public cloud szolgáltatónak, köztük olyan nagyoknak, mind pl. a LinkedIn, a Google vagy éppen a Microsoft, ugyanis egyes szolgáltatásaik kisebb-nagyobb időre bemondták az unalmast. Persze ilyenkor megkondulnak a vészharangok, hogy fúha, most leállt ez, nem tud több millió ember dolgozni, bevétel kiesés stb., így a konklúzió meg szépen az, amit a sajtó mindannyiszor pedzeget is, hogy pont ezért minden, ami public cloud szar. Miért is?

A nyilvánosság jellegéből adódóan egy SaaS szolgáltatást több millióan használnak világszerte. Ha valami történik, több millióan nem fogják tudni használni adott ideig az adott szolgáltatást. Ez persze azonnal cikkforrás a médiának, míg a céges szerverkrach, vagy más kiesés nem sűrűn kerül a vállalat falain kívül. Ők belül szeretnek anyázni, no. Holott végül is ugyanarról van szó: valami elromlik, amit meg kell javítani. Mert ugye senki nem hitte azt a public cloudról, hogy nem tud elromlani?

Pont ezért nem vállalnak a SaaS szolgáltatók 100%-os rendelkezésre állást az SLA-kben, mert nem tudják garantálni őket. A Titanicról azt hitték elsüllyeszthetetlen, csúnya vége lett, nem szabad ugyanezt hinni a cloudról. Akkor viszont miért éri meg valakinek az, hogy cloud szolgáltatónak fizet, ahelyett, hogy a sajátját üzemeltetné?

A válasz egyszerű: mert olcsóbb. olcsóbb a beruházások terén, olcsóbb a HR terén, olcsóbb a befektetett idő terén – lásd előző cikkünket, amiben arról írtunk, hogy az IT büdzsé 72%-a a meglévő rendszer fenntartására megy el.

Matt Prigge az Infoworldön ezt írta egy korábbi Amazon Web Services (IaaS) leállásról. “Ha olyan küldetés-kritikus infrastruktúrával dolgozol, amelyben nem engedheted meg a leállásnak még a gondolatát sem, akkor lennie kell olyan előzetes intézkedésnek, ami megvédi a vállalatod működését a huzamosabb idejű és kiterjed leállástól, pl. egy back – up data center. Ha nem fektettél be  ilyenbe, akkor valószínűleg te úgy döntöttél, hogy a leállás kockázata nem éri  meg azt a pénzt és időt, amibe ezek az előzetes intézkedések kerültek volna.”

Leállások ide vagy oda egy re többen váltanak public cloud szolgáltatásra, melynek a legszélesebb szegmense a SaaS a legdinamikusabban növekvő pedig az IaaS

Mi a trükk a sikeres felhő stratégiához?

A szakértők szerint az, hogy a hibára is tervezni kell. David Linthicum cloud guru szerint: “Fel kell készülni a kiesésre leállásra és nem csak akkor, ha cloudot használsz, hanem akkor is, amikor a saját vasad mondja be az unalmast. Úgy kell hozzáállni az egyes felhő alapú platformokhoz szolgáltatásokhoz, hogy tökéletesen értjük a működésüket és vannak előkalkulációink arra, hogy mennyibe fog nekünk egy esetleges leállás kerülni. Így már ki lehet számolni a kockázat és az átállási szolgáltatások költségét akár a felhőbe készülsz, akár on-premise vagy.”

Ez a kockázati költség persze függ a szolgáltatás típusától is. Ha webshopod van és jön egy leállás, szívás. Az Amazon volt, hogy 4 millió dollárt bukott, amikor leálltak a szerverei, felhasználói szempontból egy 1-2 órás levelezés leállás inkább bosszússág, mint óriási összegek ablakon kidobását jelentené (illetve a károkat nehezebb számszerűsíteni), akár vállalati, akár személyi szinten értelmezzük.

Néhány tipp downtime ellen:

  • Lavírozz a különböző elérhetőségi zónák között: A nyilvános felhő szolgáltatók datacenterei több elérhetőségi zónán, illetve régión keresztül épültek, és némely szolgáltatónál erre van is lehetőség (pl. Amazon Web servies – IaaS). Ha az alkalmazásaidat több különböző ilyen zónából üzemelteted, az egyik leállásánál átirányíthatod a vevőidet egy másikra.

  • Lavírozz különböző szolgáltatók között: pl. IaaS-ból ne csak Amazon Web Services-t használj, hanem Joyentet, Rackspace-t stb., így nem érhetnek meglepetések, ha valamelyik nem működik.

Véleményünk szerint ezek sem 100%-os megoldások, és ugyanúgy nem 100%-os a saját infrastruktúra sem. Amit szerintünk  ilyen esetben tenni lehet, hogy ki kell dolgozni egy protokollt, ami ilyenkor azonnal életbe lép (pl. akkor mindenki telefont használ, értesítenek ezt azt, esetleg hazamennek és később ledolgozzák a héten azt az időt stb.). Mindenképpen érdemes kapcsolatba lépni a szolgáltatóval/informálódni a különböző közösségi platformokon (a publi cloud esetében nagyon hatékonyan és gyorsan ér el a megfelelő információ a megfelelő közeghez).

Egy szervezet belül alkalmazott felhő alapú szoftverénél szükség esetén érdemes ilyenkor telefonon értesíteni  az ügyfeleket is a megváltozott helyzetről.  Webshopos leállás esetében szintén jól jöhetnek a közösségi csatornák, valamilyen eladásösztönzéses akció (pl. feliratkozás kedvezményes kuponra, játékra, sorsolásra) a leállás idejére, hogy ezzel ellensúlyozzák a kiesett forgalmat.

Forrás

Címkék: , , , , , , ,


A szerzőről

Sziasztok j.jetson vagyok, egyébként Dettinek hívnak. Szeretek új dolgokat kipróbálni, főleg, ha technológiával kapcsolatosak és még nyomkodni is lehet őket, ezért vállaltam el ennek a blognak az írását is. Másrészről pedig hiszek abban, hogy az újra való nyitottság lendíti előre a világot, és a blogban is ezt az eszmét próbálom becsempészni a bejegyzéseimbe. Mindemellett tök átlagos emberek, tök átlagos gyereke vagyok.



Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.

Vissza az elejére ↑
  • Hírlevél


  • Beta Testereket keresünk!

  • Twitter