Szeptember 11. informatikai szemmel

New York, 2001. szeptember 11.
New York, 2001. szeptember 11.

Holnap lesz az évfordulója az ikertornyok elleni támadásnak.

Van az eseményeknek néhány informatikai tanulsága is…

 

Az akkori események megrázták a világot.

Az emberek nagy része máig pontosan emlékszik arra,
hol hallotta meg a hírt.
Hogy éppen mit csinált akkor.

Én éppen egy megbeszélésre készültem a munkahelyemen.
A megbeszélés elmaradt.
Helyette a hazai és külföldi adók, hírprtálok híreit kezdtük bújni.

Az eseménynek közép és hosszú távú hatásai is jelentősek voltak.
A világgazdaság lassult,
légitársaságok kerültek nehéz helyzetbe,
de sok más cég is érintett volt valamilyen módon.

Nem mellékesen két háború is követte az eseményeket.
Meg további merényletek (pl. Madrid)

A barrikádokkal körbevett nagykövetségek azóta is világszerte emlékeztetnek az eseményekre,
de a biztonsági átvizsgálásnál alsógatyára vetkőztetett légiutasok is érzik:
a világ megváltozott azóta.

Van azonban az eseménynek néhány olyan tanulsága,
amely informatikai vonatkozású.

Egész pontosan olyan tanulságok,
amelyeknek van köze az informatikához,
de a nap végén azt határozzák meg,
hogy egy cég egy ilyen esemény után életben marad-e
egyáltalán.

És ez még azokra a cégekre is igaz,
akik az események során a keselyű szerepét töltötték be…

1. Az Impulzus hatás

 

Ha emlékszel az első pillanatokra,
ahogy igyekeztél kideríteni, hogy mi történt,
akkor arra is emlékszel,
hogy az internetes oldalak elérhetetlenné váltak
a terhelés miatt.

Mit tettél ekkor?

Mentél a következő oldalra.
És ezt addig folytattad, amíg nem találtál egy olyant, ami működött.

És ezt követően ez az oldal lett az elsődleges online hírforrásod.
Mint vevő, átáltál a konkurenciához.

A híroldal akkor vesztett legtöbb “ügyfelet”,
amikor az ügyfelek leginkább nála akartak “vásárolni”.

És nem kell neked az Index-nek, Origo-nak, vagy a CNN-nek lenned, hogy így járj!

Ez veled is megtörténhet!

  • Ha van egy olyan terméked, ami “divat” lesz és megrohanják érte a webáruházadat…
  • Ha biztosítási alkusz vagy, és az éves kötelező biztosítást 1 hónap alatt kötöd meg, nagyrészt online…
  • Van egy blogod, vagy közösségi oldalad, és azon olyan hírrel jössz elő, amelyet hirtelen felkap az internet…

Ebben az esetben a rendszered össze fog dőlni,
ha csináltál egy “túl jól sikerült” marketing akciót.

Hogy ezt elkerüld,
úgy kell megtervezned informatikai rendszereidet,
hogy azok kibírják az ilyen impulzus szerű terheléseket.

De hogy ez ne legyen túl drága,
érdemes olyan megoldást kialakítanod,
amely alapvetően az átlagos terhelést szolgálja ki,
de csúcsidőszakban a nagyobb (akár tízsszeres) terhelést is elviselje.

Ennek érdekében a rendszer tervezésénél
úgynevezett skálázható megoldásokat kell kialakítanod.

Ha ez megvan,
így nem fogsz a sikerbe belehalni!


2. Katasztrófa tűrés

 

Az ikertornyok összedőlése után volt néhány cég,
aki másnap csődöt jelentett
,
míg mások másnap pár utcával arrébb ugyan,
de folytatták tevékenységüket.

A két cég közt nem az volt a különbség,
hogy előbbiek elveszítették munkatársaikat,
míg utóbbiak nem.

A csődbe ment cégek közül sokan
céges adataik elvesztése miatt húzták le a rolót.

Egy másik csoport pedig azért,
mert nem volt felkészülve egy katasztrófára.
Ők maguk is a káosz részévé váltak.

 

Informatikai szempontból az ilyen helyzetek
kezelhetőek!


A katasztrófa helyzetekre fel lehet készülni,
azok hatását minimalizálni lehet.

De ez a felkészülés csak akkor lehet sikeres,
ha a cég vezetése tisztában van a felkészülés jelentőségével,
és maga is mögé (vagy az élére 😉 ) áll az ilyen kezdeményezéseknek.

A felkészülésnek két szintje van:

  • Megelőzés. Amikor úgy alakítjuk ki az informatikai rendszereket, hogy azok elviseljék a meghibásodást.
    Ilyen, ha:

      • 2 processzor van a szerverben,
      • a winhesterek tükrözve vannak (van ennél takarékosabb, de ugyanilyen megbízható módszer is!)
      • ha a szerverek fürtözve vannak
      • ha két független internet elérés van
      • ha két független áramellátás biztosított
      • ha az egész infrastruktúrának van egy tartalék rendszere

     

  • Kár csökkentés. Amikor tervet dolgozunk ki arra, hogy katasztrófa esetén hogy tudunk:
    • átmenetileg, csökkentett kapacsitással is, vagy a tevékenységek egy részében, de tovább dolgozni,
    • a lehető legrövidebb időn belül visszaállni a régi kerékvágásba.

 

Mit tehet egy cégvezető,
hogy a túlélők közt legyen a cége?

 

Csőtörés, elektromos zárlat, tűz, vírus támadás bármikor, bármelyik céget érheti.

Különbségek csak a valószínűségekben vannak.
Na meg abban, hogy ha mégis beüt a ménkű, akkor az mekkora kárt okoz.

A kezedben számos eszköz van a teljes csőd elkerülésére.
Használj ezekből minél többet:

  • A szerverek beszerzésénél figyelj, hogy az általa ellátott feladat fontosságának megfelelő redundanciát tartalmazzon.
  • Legyen mentés. És ezt ne a szerver tetején tárold, hogy azzal együtt éghessen le, vagy lophassák el. Minimum vidd haza (vagy inkább helyezd el egy lopás és tűzbisztos trezorban a cégtől távol) a heti mentést.
  • Készítsetek katasztrófa (havária) terveket. Ha alaposak vagytok ez két kérdést külön feszeget:
    • Mit tesztek a kritikus erőforrások kiesése esetén, hogy azokat a lehető leggyorsabban pótoljárok?
      (Ezt hívják a szakemberek Katasztrófa visszaállítási tervnek (DRP – Disaster Recovery Plan))
    • Hogy működtök addig, amíg ezek az erőforrások kiesése (vagy bármilyen más ok miatt) a folyamatokat nem tudjátok a szokott módon vinni. /Ez NEM INFORMATIKAI feladat!/
      (Ennek pedig Üzletmenet folytonossági terv (BCP – Business Continouty Plan) a hivatalos neve.)

 

A túléléshez inkább sok sikert kívánok,
mint sok szerencsét!

 


Comments

comments

Szeptember 11. informatikai szemmel” bejegyzéshez ozzászólás

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.