ugrás a tartalomhoz

Knightmare: A DevOps Cautionary Tale

Joó Ádám · 2016. Jan. 27. (Sze), 23.00
Hogyan vitte az automatizálás hiánya negyvenöt perc alatt csődbe az Egyesült Államok legnagyobb tőzsdei kereskedőjét
 ■
1

Tanulságos. :D Nem mindegy,

inf · 2016. Jan. 28. (Cs), 11.20
Tanulságos. :D Nem mindegy, hogy kiket veszel fel, hogy az informatikai rendszeredet fejlesszék, mert könnyen csődbe vihetnek...
2

Igaz, de itt nem a

Joó Ádám · 2016. Jan. 28. (Cs), 14.05
Igaz, de itt nem a szerencsétlenre, aki elfelejtette felmásolni a kódot, mert a legjobb fejlesztő is véthet hibát, hanem arra, aki a fejlesztési folyamatért végső soron felelős, ugyanis itt a folyamat volt több ponton súlyosan hiányos (a telepítés nem volt automatizálva, a telepített kód nem volt tesztelve, a visszavonás nem volt automatizálva, a figyelmeztető leveleket nem olvasta senki, a szervereket nem tudták leállítani…).
4

Ja én is pontosan így

inf · 2016. Jan. 28. (Cs), 23.43
Ja én is pontosan így gondoltam. Volt egy sorozat a spektrumon repülőgép katasztrófákról. Abban általában levezették, hogy egy-egy katasztrófáért a hibák milyen láncolata volt felelős. Általában egy-egy ilyen hibának nincs hatalmas jelentősége, mert van annyi failsafe egy komolyabb rendszerben, ami képes megakadályozni a komolyabb bajt. Ennél a programozós példánál is ugyanez a helyzet, egy sor szarvashibát követett el a csapat, ezért lett pénzügyi katasztrófa az eredménye.
7

Szórakoztató tud lenni

Joó Ádám · 2016. Jan. 29. (P), 00.03
Szórakoztató tud lenni egyébként a mindennapi életben megfigyelni az önmagukban jelentéktelennek tűnő hibák ilyen láncolatait, amiket úgy tűnik a legtöbb ember nem lát át (különben nem keserítenék meg öntudatlanul a maguk és egymás életét).
3

Eszembe jutott róla egy másik

Joó Ádám · 2016. Jan. 28. (Cs), 15.25
Eszembe jutott róla egy másik rémtörténet: http://weblabor.hu/blogmarkok/133322
5

Itt azért elég korrekten

inf · 2016. Jan. 28. (Cs), 23.51
Itt azért elég korrekten kezelte a cég a helyzetet, hogy nem rúgták ki egyből, meg a srác is elég altruista, hogy magára vállalta a teljes felelősséget. Csak átfutottam, de ami elsőre feltűnt, hogy itt se csak ő volt a hibás, mert hagyták, hogy éles rendszeren kísérletezzen egy újonc úgy, hogy 2 hónapja nincs backup róla...
6

Az nem teljesen tiszta, hogy

Joó Ádám · 2016. Jan. 29. (P), 00.01
Az nem teljesen tiszta, hogy a cégnél ez volt a norma (ezt könnyen hihetővé teszi, hogy lemondták a backupot), vagy csak senkinek nem tűnt fel, hogy a srác rosszul csinálja (de inkább az elsőt erősíti az is, hogy az utolsó juniornak hozzáférése van az éles rendszerhez), de ígyis-úgyis csak a feletteseit terheli ezért a felelősség, szóval én nem mondanám, hogy a legkorrektebbül kezelte a cég helyzetet, mert végül mégiscsak elmenekült.
8

Én sem mondtam, hogy a

inf · 2016. Jan. 29. (P), 02.04
Én sem mondtam, hogy a legkorrektebben kezelte, de azért lehetett volna sokkal rosszabb is...
9

Klasszikus story. Elég nagyot

BlaZe · 2016. Jan. 30. (Szo), 01.53
Klasszikus story. Elég nagyot szólt anno :) Az orosz rulettnek egyszer mindig vége van ;) Hasonlót durrant a CHF pánik 1 éve. Az is magával rántott pár kereskedő céget, meg brókert pár pillanat alatt.

Nem hiszem, hogy a Knight blamája óta bárki is kézzel telepítene pénzügyi rendszereket. Főleg, hogy most már (azt hiszem idén valamikortól kötelező) meg kell tudni mondania a bankoknak és kereskedőknek, hogy mikor mit telepítettek az éles rendszereikre.

Ami a legmeglepőbb a Knight storyjában, hogy nem tudták leállítani a programot, amit ők telepítettek. Azt én valószínűbbnek tartom, hogy a jelenlévők közül senki nem merte azt mondani, hogy lőjük le, vagy nem ismerték fel időben mi a baj. Hogy nem volt olyan a közelben, akinek joga lett volna lekillezni a programo(ka)t, az azért elég meredeken hangzik. Ezeken a helyeken elég komoly reakcióidejű és rendkívül tapasztalt kollégák szoktak dolgozni az üzemeltetésen, akikre a bepánikolás se túl jellemző. Ha ég körülöttük az épület, akkor se megy 80 fölé a pulzusuk :) És nem szokták csak úgy felügyelet nélkül hagyni ezeket a rendszereket. Már csak azért sem, mert ezekbe az algoritmusokba időnként bele kellhet tudni nyúlni menet közben is. Olyan admin felületük van, mint egy Boeing pilótafülkéje :) Persze lehet a Knight kivétel volt ezekben, de azért nem hiszem. Mindezektől függetlenül nagyon csúnyán tökön lőtték magukat, bárhogy is csinálták.

Releasing software should be a repeatable, reliable process.
Automate as much as is reasonable.

Ezeket a mondatokat vérrel írták :) Nálunk szerencsére eléggé adnak erre. Soklépcsős automata, és kézi ellenőrzés van beépítve, a dev környezetek után 5 másikon megy keresztül a telepítés prod előtt, van rollback forgatókönyv és rollback tesztelés, realtime monitoring stb, amik azért elég nagy biztonságot adnak. De a bugok olyanok, hogy szeretik kicselezni a védelmi rendszereket. A rendszert igazán értő szakik nélkülözhetetlenek, akik egy warningra is ráharapnak, ha az gyanús. Ezért is ennyire hihetetlen, hogy nem tudták lelőni időben a Knightnál a rendszert.
10

Igen, én is azért

Joó Ádám · 2016. Jan. 30. (Szo), 16.30
Igen, én is azért blogmarkoltam, hogy ne kelljen keresni legközelebb, amikor el kell magyarázni egy startupnak, hogy mi a baj a hópehely szervereikkel :)

Amikor eredetileg írtam ezt a választ, rosszul értelmeztem a történéseket. Tüzetesen újraolvasva tényleg az tűnik az egyetlen magyarázatnak, hogy senki nem merte vállalni a rendszer teljes lekapcsolását, csak amikor már késő volt.