Csak a tesztemen keresztül!

Szakmai gondolatok informatikai rendszerek teszteléséről.

Gazda

Friss topikok

  • Akron: @Verhás Péter: Az ügyfeled a cég (vezérigazgatóval, Józsi nénivel) A cég ellenőrzi le és veszi át ... (2018.01.31. 14:09) Miért UAT
  • Verhás Péter: @ hrgy: Egy kicsit felhúztam magam, de sebaj. A lényegi állításokban igazad van, ám a személyekre... (2011.10.09. 00:25) A tesztelés nem mindenható
  • crix: Ez a hozzáállás. Sajnos most is. Aztán csodálkoztak itt a népek, amikor bevállaltam a hétvégi munk... (2011.10.05. 16:56) Újra fizetni kell
  • crix: és milyen specifikáció mentén ment át az ügyfél? elég blind? (2011.10.05. 13:41) Ügyfélteszt
  • fqqdk: fitnesse, concordion, és cucumber integráció lesz? (2011.03.05. 13:42) Automatizált tesztelés és üzleti tesztelés

Társblogok

Vizsgálat a diákok elveszett adatai miatt

2010.02.07. 22:14 | Verhás Péter | 3 komment

index.hu/belfold/2010/02/05/toroltek_a_diakok_adatait/ cikk szerint

Hiba történt csütörtök délután a középiskolás jelentkezéseket kezelő központi szerveren, így a hajnali fél három után rögzített adatok – vagyis a januári középiskolai felvételik és az érettségijelentkezések egy része – elveszett, írja az erettsegi.com.


Az Oktatási Hivatal szerint “a hiba jellege miatt nincs mód a problémával érintett iskolák, diákok körének meghatározására”.

Ne próbáljuk meg kitalálni, hogy mi történhetett, mit rontottak el, csak azt ami ebből az egy mondatból biztosan kikövetkeztethető.

Elvesztek adatok. De nem az összes, csak egy napi adat. Nem valószínű, hogy a tegnapi adatok operatív kópiája másik adatbázisban volt. Tehát van mentés, és ez igen dícséretes. Ez rendben van. Kürt Kft. évek óta teszi a dolgát, és szerencsére lassan van hatása, vannak adatmentések, megtanuljuk félteni az adatainkat.

Viszont folyamatos üzem közben elvesztek az adatok, ami két dolgot jelenthet:

  • hardver hiba történt, és az adattárolási rendszerben single point of failure van, azaz nincs RAID
  • szoftver hiba volt, ami törölte az adatokat.

Az első egy üzemeltetési "hiba". Nem biztos, hogy hiba. Lehet tudatos döntés is. Annak a költsége, hogy két mentés közötti adatmennyiséget újra be kell vinni (egy napi adat) szorozva a hibásodás valószínűségével sokkal kisebb, mint a RAID tároló plusz költsége. Ha ez így van, akkor helyes döntés volt, kisebb a TCO. Csak nehezen tudom elhinni, és félek, hogy itt megint az elszámolással van a gond. Mibe kerül az intézménynek, és mibe kerül nekünk mindannyiunknak. Félek, hogy ha azt a munkát és költséget is belevesszük, amit a diákok tanárok fognak most "ingyen" beáldozni akkor sokkal olcsóbb a rendes tároló eszköz. De ez már politika.

A másik lehetséges hiba: szoftver. És itt jön a tesztelés. (Nah, csak kilyukadtunk oda ahova indultunk....) És persze a tervezés.

(Nem emlékeszem olyan projektre az elmúlt három évben, ahol készítettünk volna olyan adat modellt, amelyik ne emlékezett volna a múltjára. Ha volt egy ZZZ nevű tábla, akkor ott volt egy ZZZ_LOG tábla is, amelyik majdnem ugyanolyan volt, mint a ZZZ, csak kerül bele még egy időpont mező is, és gyűjti azokat a sorokat, amik megváltoznak (pl. törlődnek). És egyszer kellett is.)

Milyenre tervezték ezt a rendszert? Hogyan tesztelték?

 

Amikor írom ezt a bejegyzést (2010-02-08 7:42) az üzemeltető Educatio Kft. honlapján semmilyen információ nincs az esetről. www.educatio.hu/nyilvanossag/hirek_kozlemenyek

Ezt a blogot azért írom, hogy ilyen eset minél kevesebb legyen.

A bejegyzés trackback címe:

https://csakatesztemenkeresztul.blog.hu/api/trackback/id/tr21737813

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

vicziani · http://jtechlog.hu 2010.02.11. 21:55:59

Értem, hogy mit mondasz, de soha ne higyjünk a RAID-nek, szerintem az a hardver gyártók legnagyobb átverése.
Most volt a Plastik-on is, hogy már másodjára fut bele, hogy a RAID nemhogy helyreállítja az elromlott disk-et, hanem mindkettőt elrontja.
Én kétszer láttam ilyent, mikor az első munkahelyemen a forráskód szerver szállt el úgy, hogy egyszerre döglött el a két disk a RAID-ben (kb. 15 perc eltolással). Egy másik helyen kétszer történt meg ugyanez, éles rendszer alatt. Mindkét esetben szalagos mentés került elő. Ahogy hallottam, ez lehet amiatt, hogy egymás után a gyártósorról lekerült winyót pakolnak bele, melyeknek kb. ugyanaz az élettartama. Vagy a vezérlő szál el. Vagy a firmware hibás.
Sajnos a kedvenc nagy hardver gyártóink is trükköznek, hogy ugyanazt a hardvert adják el olcsóbban és drágábban is, és ha az olcsóbbat veszed, kikapcsolnak bizonyos funkcionalitást, ami miatt használhatatlan és low end megoldásod van, hogy upgrade-elj.
A RAID egy üzleti csel.
Szóval mi már inkább másolgatunk másik gépre, vagy szoftveres RAID két különböző gyártójú winyóval.

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2010.02.14. 15:06:25

@Viczi: Azért ezt nem gondolom ennyire végletesen. A RAID nem egy üzleti csel, és erre nem csak az az érvem, hogy hány esetben biztosította (akár csak a személyes gyakorlatomban) a folyamatos üzemet, szemben azzal, hogy hány esetben hasalt el a RAID (is).

Ez kb. olyan, mintha azt mondanánk, hogy az autó légzsák csak egy üzleti csel, mert néhány ember meghalt miatta (pl. nem bírt szabadulni vízbe esett autóból, lenyomta a torkán a pipát (minek pipázik vezetés közben?)).

És volt persze az én gyakorlatomban is olyan esemény, amikor a raid controller ment tönkre, és verte szét a fájl rendszer partíciós táblát (postabank 1994 környékén), és okos rendszergazdák a mentést is ugyanazon a a RAID-en tárolták. Ugye nem hallottál róla, hogy elvesztek volna számla adatok. Bitenként vissza lett hozva a partíciós tábla.

>RAID nemhogy helyreállítja az elromlott disk-et,
>hanem mindkettőt elrontja.

Hát b+ az a raid gyártó. De nem a RAID rontja el, hanem az a konkrét implementáció. A kontroller szoftvere, vagy (!) kontroller szoftver beállítása (pl. van egy gyorsabb mód... ja, hogy akkor nem ellenőrzi a CRC-t?) Szóval ez lehet dokumentáció hiba is, vagy akár üzemeltető hiba is.

>egymás után a gyártósorról lekerült
>winyót pakolnak bele

Ez megint olyan mondás, hogy ez is előfordul persze. De ez vajon a RAID hibája, vagy a diszké, vagy az üzemeltetőé? Ha élettartamon belül esnek így el a diszkek, akkor az típushiba. Vissza kell hívni a diszkeket, mint az autókat. Élettartamon belül nem szabad, hogy diszknek olyan hibája legyen, ami nem örök ifjú valószínűségű.

Ha a garantált élettartamon túl voltak a diszkek, akkor üzemeltetési hiba.

Azon kívül a RAID egyes fajtái gyorsabbak is, mint a sima diszk. És menteni pedig kell. Rendszeresen. És ellenőrizni kell a visszaállíthatóságot is rendszeresen, hogy ne a /dev/null-ba menjen a mentés.

Szóval a RAID nem old meg mindent, de azért túlzás azt állítani, hogy "A RAID egy üzleti csel."

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2010.02.14. 15:11:14

És még az jutott eszembe így konkrétan diszk technológiáról, hogy nagyon ritka az olyan fatális diszk hiba, amit ne előzne meg elég hosszan (hónapok, hetek, de napok biztosan) a diszken bad sector proliferáció. Ezt észre kellett volna venni (ha volt, és valószínűleg volt), és azelőtt cserélni a diszket, hogy beáll. Meg a másikat is, ami 15 perccel később murdelt meg.

[Egy fatál is lehet fatális.]
süti beállítások módosítása