Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast hetedik epizódja!

A mai témánk egy kis előzetes sztorival kezdődik, ugyanis az életben igen sok szakmából lehet példákat venni, mivel a szoftverfejlesztés mint olyan egész újnak számít. Mondjuk a példa, amit hozni akarok nem egészen a legjobb, mert nem ezeréves múltra tekint vissza, de szerintem mindenképp tanulságos.

Repülés.

Erről mindenki egyből a szabadságra asszociál, holott rengeteg szabály köti a pilótákat és szinte minden repülési helyzetre megvan az előírás, amit követni kell. Vegyük mondjuk a motorindítást, erre a légcsavarod gépeknél kétféle helyzet is van, hidegen - tehát aznap először -, vagy melegen, mikor valaki nemrég tette le a gépet.

A kabintető csukva, pedálok beállítva, övek becsatolva, légcsavar kis szögön, gáz levéve, parkfék behúzva. Ezután főkapcsoló fel, strobe light be, üzemanyagpumpa be és innen jön majd az indítás. Mindennek megvan az oka a listában. Ha a kabintető nincs csukva, a légcsavar szele leviheti, a pedálokat azért állítjuk be előre, mert később, ha már be vagyunk csatolva akkor nem érjük el. Becsatolva azért vagyunk, mert a levegőben macerás lenne már megtenni, a légcsavart kis szögre azért állítjuk, mert motorindításhoz ez hatékonyabb, nem fojtja le a motort, gázt levesszük, mert később a hideg-meleg indítás függvényében állítjuk, a parkfék pedig azért, hogy ne kelljen lábbal fékezni a repülőt és véletlenül sem tudunk elgurulni így. A főkapcsoló kell, hogy bármilyen elektromos rendszert elérjünk, a strobe light jelzi, hogy motorindításhoz készülünk, az üzemanyagpumpa pedig egy kis terhet levesz a motor válláról.

Na most ebből a listából is kihagytam valamit, mivel ha indításkor fogyasztók vannak bekapcsolva, akkor az indítás okozta áramingadozás akár kárt is tehet bennük, ezért azokat is le kell kapcsolni. Na de miért mondom én el ezeket? Azért, mert ezek a checklistek léteznek a fejlesztésben is. Vegyünk pl valaminek az élesítését, ott is egy meghatározott sorrendiséget kell tartani, különben valami nem lesz az igazi. Az adatbázis sémát frissíteni kell a deploy előtt, ha adat kell bele akkor azt bele kell tolni az új verzió kikerülése előtt. Tesztelni is ezután kell majd a tesztelőknek és így tovább. Persze ez egyáltalán nem újdonság, hiszen ezt sokan már most is checklistek mentén végzik. Na de amiről inkább beszélnék az az, hogy mi a helyzet azzal, ami nem tartozik bele a “normal operations”-be, azaz nem egy hétköznapi dologról van szó. Mi a teendő ilyenkor? Mit teszünk, ha érkezik az xy pagerduty, miszerint az oldal elszáll ötszázas hibával.

Ha visszatérünk a repüléshez, ott léteznek úgynevezett emergency checklistek is, tehát ha valami gond van, akkor megvan a protokoll arra, hogy hogy is tudjuk abból a helyzetből a legkisebb veszteséggel kihozni magunkat. Mindennek megvan az oka itt is.

Mi a teendő ha motortűz van? Üzemanyagcsapot elzárjuk, üzemanyagpumpát lekapcsoljuk, teljes gáz és a kabinfűtést is kikapcsoljuk. Mivel a motortérben a legfőbb éghető anyag az olaj és az üzemanyag, ezért megpróbáljuk elzárni azt a tűz elől. Elzárjuk a csapot, ami a motortérbe vezet és teljes gázt adunk, hogy minél hamarabb elhasználjuk ami még ott van. A pumpát lekapcsoljuk, hiszen nem akarunk odapumpálni semmit, a kabinfűtés pedig a motortérből szivja a levegőt a kipufogó körül, így ha lekapcsoljuk, akkor a mérgező gázokat nem szívjuk be a kabinba. Ezután pedig elkezdjük a kényszerleszállást. Megvannak a lépések, megvan a sorrend is és megvan mit miért csinálunk. Nincs sok idő cselekedni, de ha valamit kihagyunk, akkor könnyen halálos következménye lehet.

Na és mi a helyzet a legtöbb tech cégben, ha valami gond van? Vakon lövöldözünk. Ez sok esetben még érthető is, hiszen az iménti példában pont az a lényeg, hogy ezek már felmerült problémák, volt idő kitalálni mi is az optimális eljárás rá. De vajon ez a helyzet nálunk is?

Nem tudnánk jól dokumentálni mindezt, hogy legközelebb, ha ilyen történik, akkor meglegyen a megoldás rá? Persze jó lenne, ha meg tudnánk oldani, hogy mindez ne fordulhasson elő, lévén egy szoftvert könnyebb módosítani, mint egy legyártott repülőt.

Sajnos akadnak helyzetek, amiket nem lehet. Sokszor lesz olyan, hogy csak odamegyünk, újraindítjuk és megjavul. Viszont ha ezt leírnánk, lenne aki meg tudja mindezt csinálni a leírás alapján, akkor nem lennénk bentebb egy lépéssel?

Azért mondom mindezt, mert már vannak cégek, ahol pl nem lehet megoldani azt, hogy a rendszer ne tudjon inkonzisztens állapotba kerülni. Ez lehet a rendszer jellege, esetleg az adott domain miatt, a lényeg, hogy a saját szememmel láttam ilyet élesben. Jött a pagerduty alert és rendesen, lépésenként dokumentálva ott volt, hogy is tudod kielemezni az adott problémát és megoldani azt. A korábbi root cause analysisoknak ez volt a kimenete, egy dokumentum, hogy ha legközelebb ez a probléma előfordul, akkor hogy kell megoldani. Egyszerűbb rendszereknél ez lehet egy sima indítsd újra ezt a szart, de már ezzel is segítünk annak, aki helyettünk, vagy ha elhagytuk a helyet, akkor utánunk találkozik azzal a hibával.

Ez volt a minicube podcast, találkozunk legközelebb!

Hosted on Acast. See acast.com/privacy for more information.