Új hozzászólás Aktív témák
-
Különösen ha a cég folyamatai lehetővé teszik, hogy egyetlen ember ekkora borulást okozzon. Ööö... Vagy akkor nem is egyetlen ember hibás, hanem azok a menedzserek is, akik a folyamat szabályzásáért lettek volna felelősek? Mind az időzítés, mind az előzetes tesztelés, mind az ellenőrzés, mind a visszaállítás el volt itt kefélve, és ezeknek mind-mind egyenként felelőse kellene, hogy legyen.
Vagy ilyen alapon egy takarítónő is lekapcsolhatja a szerverközpont teljes betápját, hogy legyen hová dugnia a porszívót? Értem, hogy az USÁban nincsen mákosbejgli, de én bármilyen beavatkozást a karácsonyi csúcs helyett a bejglievés utáni józanodás idejére időzítettem volna.
A tej élet, erő, egészség.
-
anulu
félisten
pontosan. azt a managert csapdosnám szívlapáttal hátba, aki ezt engedélyezte. főleg, mikor mindenki tisztában van azzal, h mennyire kritikus az időszak.
"Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 14Pro 256GB | iPad Pro 2017 64GB
-
FlekkeN
aktív tag
Egy rendszernek mindig lesznek gyengeségei bárhogy is tervezed meg. Ezek a balesetek segítenek jobbá tenni a szolgáltatást, terméket. Most, hogy felbukkant a hiba kijavítják és áttervezik, hogy ne forduljon elő.
Mindenhol így csinálják, mivel rejtett hibák lehetnek. A Natgeo "Légikatasztrófák" sorozatban meg lehet figyelni hogyan is csinálják repülőgépeknél. -
szepi79
őstag
-
azbest
félisten
Korrekt összefoglaló
Mondjuk az utóbbi évek alapján általában virginiában történnek problémák. Valószínűleg azért is fordulhat ez elő, mert ott érhető el a legfrissebb technológia és legnagyobb infrastruktúra. Adatvédelmi (jog)szabályok és praktikusság alapján általában megérheti nekünk inkább az ír központot használni. Mondjuk az picit drágább és nem minden fajta erőforrás érhető el ott. -
#11
Stauffenberg
nagyúr
#06658560
#8
Stauffenberg
nagyúr
Nem a NatGeo-ra alapoz, hanem megfigyelte abban a műsorban, hogy a légi közlekedési biztonságot a megtörtént balesetek helyszínelésénél kinyert adatokból javítják. A repülőgépeknek nincs töréstesztje, mint az autóknak, ezért ott csak a balesetekből levont tanulságok maradnak.
Egy Netflixnek sincs töréstesztje. A repülésben is sokszor megesett már, hogy egy biztonsági mechanizmus vagy szabályzat nem működött megfelelően.
Itt is valaki kiadhatott hülye utasítást, valaki végrehajthatott hülyeséget és a rendszer (nem csak a hardver-szoftver, hanem a vállalati szabályok) nem védte önmagát az emberi hibától.
Olyan ez, mint a Boeing és az Airbus felfogása egy repülőgépről. A Boeing igyekszik mindent a pilóta vállára tenni, de közben segít helyes döntést hozni a lehető legtöbb megjelenített információval. Az Airbus meg inkább átvállal feladatokat a pilótától és ha kell felülírja az emberi döntést ha az veszélyezteti a gép és az utasok épségét. Egyik rendszer sem jobb a másiknál, mindkettő vezetett már balesethez.
-
#12
bambano
titán
Stauffenberg
#11
bambano
titán
válasz
Stauffenberg
#11
üzenetére
természetesen van a repülőknek töréstesztje, még ha nem is mindegyik típusnak külön-külön.
"Egy Netflixnek sincs töréstesztje": ez a mondatod szó szerinti értelmezésben akár igaz is lehet, de valahol mégis azt érzem, hogy azt sugallja: nem is lehetne neki töréstesztje, ha nem idióták a managgák. pedig lehetne, miért ne lehetne.
az amazonnal meg az a gond, hogy az embert nem tudja áttervezni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
04ahgy
nagyúr
"Nem lehet elkerülni az analógiát: a csernobili atomerőmű végzetes balesetét is emberi mulasztás okozta, és az Amazon most hasonló típusú hibázást tárt fel."
Hát ezt eléggé el lehet kerülni. Az előbbi egy technikailag alulképzett / más reaktorra kiképzett személyzet, szabályzórúd tervezési hiba, továbbá egy kevéssé dokumentált, de létező tervezési sajátosság, a pozitív üregtényező, és rengeteg szignifikáns, vagy kevéssé szignifikáns tényező együtt okozta az említetteken felül. Továbbá ott nem magától állt le a dolog (az 1-2-3 blokk simán üzemelt volna tovább a 4-es reaktor tüze miatt, azokat biztonsági óvintézkedésképp állították le), míg a felhőnél a rendszer omlott össze.
A felhő hibája kellemetlen, ennyi. Senki nem halt bele, pár nap és elfelejtjük az egészet. A hivatkozott atomkatasztrófa pedig átírta az emberiség történelmét.Én nem említeném egy lapon a kettőt, mert ez már a nagyon bulvárnál is több!
HGyu
7855.94MHz CPU-Z valid \ Pulchra tibi facies, oculorum acies, capillorum series; o quam clara species! Rosa rubicundior, lilio candidior, omnibus formosior; semper in te glorior!
-
#15
#06658560
törölt tag
Stauffenberg
#11
#06658560
törölt tag
válasz
Stauffenberg
#11
üzenetére
"Nem a NatGeo-ra alapoz, hanem megfigyelte abban a műsorban, hogy a légi közlekedési biztonságot a megtörtént balesetek helyszínelésénél kinyert adatokból javítják. A repülőgépeknek nincs töréstesztje, mint az autóknak, ezért ott csak a balesetekből levont tanulságok maradnak"
Aki nem ért hozzá, az inkább ne beszéljen róla. Ez teljes mértékben hamis információ. Mondhatom úgy is, hazugság.
"Egy Netflixnek sincs töréstesztje." muszáj legyen neki, különben minden csip-csup puffertúlcsordulásra borulnia kéne, nem lenne hibatürö egyetlen algoritmusa sem.
"Itt is valaki kiadhatott hülye utasítást, valaki végrehajthatott hülyeséget és a rendszer (nem csak a hardver-szoftver, hanem a vállalati szabályok) nem védte önmagát az emberi hibától." Ergo a crashtest a rendszerre nem lett rendesen megcsinálva, nem lett hibatürö rendszer tervezve.
[ Szerkesztve ]
-
dajkopali
addikt
sztem félreértesz
itt nem arról van szó, hogy egy adott rendszernél egy hiba milyen hatásokkal jár, hanem arról, hogy milyen mértékben befolyásolhatja a működést az emberi hiba, vagyis mennyire védett a rendszer az emberi hibával szemben
ilyen szempontból az analógia - már amennyire egy analógia képes - megállja a helyét, bőven"fácánjava calvadosban/teljesítünk, egyre jobban " - Konok Péter
-
-
FlekkeN
aktív tag
válasz
#06658560
#15
üzenetére
"Nem a NatGeo-ra alapoz, hanem megfigyelte abban a műsorban, hogy a légi közlekedési biztonságot a megtörtént balesetek helyszínelésénél kinyert adatokból javítják.
Pontosan erre gondoltam és így szokott lenni. Amikor lehuzan egy gép és tipushiba az oka kivonják az összes olyan gépet és átvizsgálják majd kijavítják.
-
-
#21
fordfairlane
veterán
fordfairlane
veterán
"Szerintem kenjünk mindent a takarítóra!"
x gon' give it to ya
-
04ahgy
nagyúr
válasz
dajkopali
#16
üzenetére
A csernobili atomerőmű ilyen téren a cloudnál több tízezerszer, megkockáztatom, akár milliószor hibatűrőbb volt, szóval megállja a helyét, de nem jó, hanem rossz analógiaként.
Továbbá igen könnyen el lehet kerülni az analógiát, ha nem akarjuk szándékosan a cikkbe írni.
"... a csernobili atomerőmű végzetes balesetét..." - Csak egy reaktorra nézve volt végzetes, nem az atomerőműre. Tizenöt évig üzemelt a balesetet követően. Azt hiszem, analógiától függetlenül, ha valami végzetes, az nem tud üzemelni.
"az Amazon most hasonló típusú hibázást tárt fel" - Tehát a tervezők a cloudba több, ismert instabilitást is megengedő módon beépítettek, erről szándékosan nem, vagy csekélyen tájékoztatták a kezelőszemélyzetet, ráadásul az ominózus kezelőszemélyzet nem is ehhez, hanem egy másik architektúrás cloudhoz volt kiképezve. A cloudba épített instabilitások szerencsétlen egybeesés esetén az emberéletre, a bioszférára potenciálisan fatális jelleggel bírnak. Sőt, megpróbálták a cloud hibáját eltussolni, amiről a netforgalom csökkenéséből következtetve pl. észak-koreai tudósok tájékoztatták a közvéleményt.
Ha már analógia, sokkal kevésbé kirívó lett volna a piros sorompót figyelembe nem vevő embert a kocsijában halálra gázoló tehervonat esetét venni. Egy ember mulasztott, a rendszer összességében a tervezésének megfelelően működött, az ok-okozati összefüggések pedig egyeneságiak. Ott: hibázik a frissítést végző, a hibából (és az adott környezetet determinisztikusnak tekintve) következik a kialakult instabilitás. A sorompónál pedig a tilost figyelembe nem vevő ember mulasztásából következik a gázolás ténye. A résztvevők (sorompó, autó, tehervonat a fentihez) hasonlóan determinisztikusak.
Csernobilban semmi nem történt volna, ha csak egyetlen egy feltétel nem, van nem akkor áll fenn, amikor a többi. Itt a rendszerben egyidejűleg fennálló legalább 7-8 eltérő tényezőről beszélünk, melyek ráadásul különböző időpontokban kerültek a rendszerbe!
HGyu
[ Szerkesztve ]
7855.94MHz CPU-Z valid \ Pulchra tibi facies, oculorum acies, capillorum series; o quam clara species! Rosa rubicundior, lilio candidior, omnibus formosior; semper in te glorior!
-
van http://prohardver.hu/hir/igy_keszithetunk_360_os_panoramat_iphone_5-tel.html
panorámavideót 1db objektívvel, semmi kiegészítővel, megoldás: csak forgasd körbe 1x és kész a panorámavideó
A bortól bolondokat gondol az ember, DE A PÁLINKÁTÓL MEG IS CSINÁLJA!!!
-
bambano
titán
engem az is érdekelne, hogy ilyen adatokat miért nem épít újra automatikusan a rendszer?
legyalulom a terhelésmegosztás adatait, akkor mi van, kezdjen terhelést megosztani optimálisnál alacsonyabb szinten, majd észhez tér, ha már van elég statisztikai adat.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
azbest
félisten
Hát, ha letörlöm a listát arról, hogy milyen instancek vannak bekötve a load balancer mögé, akkor szvsz azt magától nem fogja tudni kitalálni. Egy account alatt futhat többféle rendszer is, több különböző instance-kkel és több load balancer-rel, meg lehetnek olyan példányok is amik egyik lb alá sem tartoznak. Mondjuk a különböző egységek rendszereit célszerű külön account alá tenni, amiket össze lehet kötni akár egy számlázási account alá is. Így lehet komolyabban elszeparálni különböző szervezeti egységek jogosultság rendszereit is.
Valószínűleg az okozott komplikációt, hogy közben az ügyfelek próbálták átkonfigurálni a rendszer beállításait és ezért nem volt használható a visszaállított információ - közben cserélődhettek az instancek amik részt vettek benne. Szóval valószínűleg már nem volt valid és talán a tranzakciókat végigpörgetve szedték össze a hiányzó és valid, aktuális infókat.
Annó az áramszünetnél olvastam hogy a ebs lemezek a tranzakciókezelésének hála az arról futó instancek ugyanabból az állapotból tudták folytatni a működést, ahol az áramszünet pillanatában voltak.
[ Szerkesztve ]
-
bambano
titán
gondolom az ec2 nem két noname pc-ből áll. feltételezem, hogy a különböző dolgok adatbázisban vannak, mert annyi lomot fejben tartani lehetetlen. akkor miért nem pakolták vissza rögtön a konfigokat adatbázis alapján? akár maga a rendszer automatikusan?
a másik: a tapasztalatom azt mutatja, hogy a forgalom statisztikai módszerekkel jól becsülhető. akkor miért nem szólt a rendszer, hogy valami fejreállt?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
azbest
félisten
a részletes leírásban szerepel, hogy az adatok törtlése egy olyan mellékhatás volt, amire nem számítottak. Amikor hibák jelentkeztek az lb api működése kapcsán, annak vizsgálatakor derült, ki hogy ez a valódi oka a problémáknak. Ezzel értékes órák mentek el. Azt ez a hír is írja, hogy megerősítették a rendszert, hogy ne fordulhasson ilyen elő.
Valószínűleg összetettebb a kérdés. Az ügyfelek szabadon konfigurálhatnak lb-ket, szóval központilag úgy általánosságban ez nem feltétlen jelez hibát. Az ügyfelek saját rendszerükben ha figyelnek erre, akkor ők érzékelhetik, hogy nem normális a működés. A supportot pedig értesíthetik, mondjuk azt nem tudom, hogy mennyire gyorsan jut el egy kis felhasználó ilyen hibajelentése a megfelelő emberhez, de a nagyok valsz előfizetnek komolyabb supportra is, ahol közvetlen kontaktjuk is van [link]
[ Szerkesztve ]
-
szepi79
őstag
Egy adatközpontban folyamatos üzem így folyamayos karbantartás is van.
nemnem. az év utolsó 1-2 hetében khm... illik network freeze-t elrendelni. egyrészt mert a sok mérnök/karbantartó/technikus otthon mereszti a hátsóját a kanapén a TVt bámulva, és ha gebasz van, eltart egy darabig, mire a megfelelő személyzetet mozgósitani lehet; másrészt ilyenkor nemcsak az adott cég emberei vannak szabadságon, hanem kb. mindenki más is, aki nem közszolga vagy vendéglátós (tescós is ideértve), ergo nagy forgalom várható. szóval, amig rendesen megy, addig ne piszkáljad.
''Ne menj sebesülten vadászni, mer' lehet, hogy lelegelnek az őzek'' by elmoraan(r) a ''Nők, nőügyek'' topikban
-
joysefke
veterán
kihámoztam a lényeget:
közzétett tájékoztató szerint egy szakszerűtlenül elvégzett karbantartási művelet okozta a hibát december 24-én, és mindezért egyetlen szórakozottan dolgozó munkatársat tettek felelőssé.
A központban dolgozó csapat még egy végzetes üzemzavar bekövetkezte előtt észlelte a gondot, ám teljes mértékben nem tudták leállítani a problémát okozó folyamatot. Ugyanakkor erőfeszítéseiknek köszönhető, hogy – ha lassan és igen kemény munkával is, de – vissza tudták állítani az elveszett adatokat, és a szolgáltatás kisvártatva újra működött.
ha cinikus akarnék lenni (anélkül, hogy az egészről bármit is tudnék)
az egész csapat (akik könnyen lehet ugyanannyira felelősek) talált egy balekot akire rányomták a teljes felelősséget, magukat pedig még megmentőnek is állítják be..J.
[ Szerkesztve ]
-
#06658560
törölt tag
A folyamatos üzem és folyamatos karbantartás sem azt jelenti, hogy béla beslattyog papucsban, amikor épp rájön a szükség és belebuherál a rendszerbe. minden módosítást meg kell tervezni, mikor legyen letesztelve nem éles rendszeren, mikor legyen implementálva az éles rendszerre, stb. És alapvetés, mindent egy elszeparált, nem élesített rendszeren tesztelünk, mielött a világra uszítjuk.
-
bijesz
aktív tag
válasz
#06658560
#35
üzenetére
@Kopi31415
Amiről te beszélsz az a változtatás (change management), itt nem erről van szó hanem rutinkarbantartásról.@szepi79:
Nem tudsz egy nagy adatközpontban "freeze"-t elrendelni.
Ahol pl a node-ok óránként halnak ki mert annyi van, ott folyamatosan kell beavatkozást eszközölni, különben elkerülhetetlenül lehalnak a szolgáltatások. -
#06658560
törölt tag
Rutin karbantartást sem úgy csinálnak, hogy bélára rájön a karbantarthatnék. Sehol. minden karbantartást szintén meg kell nézni, milyen hatása lehet. Egyáltalán mit kell karbantartani. Ahol a non-stop üzem különösen kritikus követelmény a rendszerrel szemben, ott nem lehet ad hoc az éles rendszert bütykölni.
-
szepi79
őstag
az hibajavitás, nem karbantartás. szerintem. lehet az én fogalomtárammal van gond, de nálam a karbantartás olyan megelőző intézkedés, amivel nő az adott cucc stabilitása/hibamentességi ideje/élettartama. ráadásul még előre is lehet tervezni.
''Ne menj sebesülten vadászni, mer' lehet, hogy lelegelnek az őzek'' by elmoraan(r) a ''Nők, nőügyek'' topikban
-
szepi79
őstag
hát, azért anyagilag nem volt happy end, a szolgáltatáskiesés komoly pénzbe fájt, plusz ilyenkor általában a tőzsdén is megérzik a részvények az ilyesmit, a negativ reklámról nem is beszélve.
ilyenkor a cég szempontjából jobb egy emberre kenni a dolgot. persze nem etikus.
''Ne menj sebesülten vadászni, mer' lehet, hogy lelegelnek az őzek'' by elmoraan(r) a ''Nők, nőügyek'' topikban
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
it Nem lehet elkerülni az analógiát: a csernobili atomerőmű végzetes balesetét is emberi mulasztás okozta, és az Amazon most hasonló típusú hibázást tárt fel.
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest