A műszaki kekec

Szinte minden szervezetben van egy ember az akadékoskodó, a folyton aggodalmaskodó műszaki kekeckedő szerepében.

Ő az, aki mindig kérdez.
Ő az, aki nem fogadja el elsőre, hogy „ez így szokott működni”.
Ő az, aki akkor is rákérdez valamire, amikor a többiek már továbblépnének.

Sokszor zavaró szerepnek tűnik. Pedig valójában az egyik legfontosabb.

A rendszerek ritkán ott romlanak el, ahol várjuk

Egy informatikai rendszer, egy ipari hálózat vagy akár egy teljes vállalati infrastruktúra működhet évekig úgy, hogy senki nem érzi a kockázatokat. A napi működés rendben van, a felhasználók dolgoznak, a szerverek futnak.

De a valódi kérdés nem az, hogy ma működik-e a rendszer, hanem az, hogy:

• mi történik, ha egy kritikus komponens kiesik

• valóban visszaállíthatók-e a mentések

• ki fér hozzá a legfontosabb adatokhoz

• van-e egyetlen pont, ahol az egész rendszer megállhat

Ezek a kérdések gyakran kényelmetlenek. Ezért sokszor nem hangzanak el.

Itt jelenik meg a „műszaki kekec”.

A műszaki kekec valójában kockázatfeltáró szakember

A szerepe nem az, hogy mindent kritizáljon.
Hanem az, hogy észrevegye a gyenge pontokat.

A legtöbb projektben háromféle szerep jelenik meg:

Az első kettő mindenhol jelen van. A harmadik viszont gyakran hiányzik.

Pedig a legtöbb komoly hiba abból fakad, hogy senki nem kérdezett rá időben a kritikus részletekre.

A kényelmetlen kérdések értéke

A műszaki kekec nem azért fontos, mert mindenre tudja a választ.
Hanem azért, mert felteszi a jó kérdéseket.

Például:

• mi történik, ha ez a szerver leáll?

• ki tudja újraindítani a rendszert, ha a rendszergazda nincs elérhető?

• valóban működik a mentés, vagy csak feltételezzük?

• mi az a három pont, ahol a rendszer a legsérülékenyebb?

Ezek a kérdések gyakran percek alatt felszínre hozzák a valódi kockázatokat.

Nem a tökéletesség a cél

Egy rendszer soha nem lesz teljesen hibátlan.
A cél nem az, hogy minden kockázat megszűnjön.

A cél az, hogy a kritikus kockázatok láthatóvá váljanak, és a szervezet tudatosan kezelje őket.

Sok esetben néhány egyszerű változtatás – például egy tesztelt mentési rendszer, tiszta jogosultságkezelés vagy egy világos incidenskezelési terv – nagyságrendekkel csökkenti a kockázatot.

A szerencse helyett tudatos működés

Amíg senki nem kérdez rá a gyenge pontokra, addig a rendszer gyakran csak azért működik, mert eddig szerencsénk volt.

A műszaki kekec szerepe pontosan az, hogy ezt a szerencse-faktort csökkentse.

Nem azért, mert pesszimista.
Hanem mert tudja, hogy a megbízható működés alapja a tudatosan átgondolt rendszer.

És ehhez néha szükség van valakire, aki felteszi a kérdést:

„Biztos, hogy ez így jó?”