Zeptám se i tady. Nevíte někdo, jak se má správně řešit tohle?
> Jeden z přepojovaných prvků způsobil zkrat, který vyhodil hlavní jistič (na trase byl i podružný jistič, který však nevybavil).
Mně se to totiž děje, jističe nejsou selektivní (by design, nad cca. 4násobek jmenovitého proudu vybaví elektromagnetem okamžitě, nezávisle na tom, jak jsou zapojeny za sebou), a nevím jak tomu pomoct. Napadlo mě, že by to mohlo řešit zařízení s indukčností a rychlým odpínačem, ale nic jsem nenašel. (pozn. nemám serverovnu, stačilo by mi chránit 1-2 zásuvky)
Časy se pro vysoké proudy (tvrdý zkrat) překrývají (bonusová úloha: v některých případech nemůžu nadřazený jistič ovlivnit, protože ho poskytuje někdo jiný a nejde mu do toho kecat, takže ho nemůžu třeba vyměnit za pomalejší). Elektrikářů jsem se ptal různých, firem vyrábějících věci taky (ABB, Eaton), všichni mi řekli, že to nejde. Tady je o tom třeba taky od nich přednáška.
Přitom si ale myslím, že se to nějak dělat musí, jinak by se situace z článku stávala každý den.
Konkretne tento pripad? Minimalizace rizika.
K ochranam elektriky necht se vyjadri elektrikar co dela DC. Je to veda. Bezjisticove ochrany, elektronicky monitoring prubehu proudu a monitoring pred odpojenim jak v elektrarne.
Riziko se da taky zmensit technologii na DC misto AC a rozdeleni na sekce po napajecich zdrojich.
Mit extra treti napajeci vetev na jine technologii jinak postavenou a řešit prepojovani do ni.
Nedelat prepojovani mezi vetvemi a nechat zakose/technologie s jednim zdrojem byt - je to chyba zakaznika. Nepustit do DC veci s jednim napajenim a pokud ano mit je za extra online ups a nizkym SLA.
Delat testy s rizikem odpojeni jedne vetve - nektera US datacentra to delaji a chodi mi pravidelne statusove zpravy - test bypassu, test ats, test generatoru na dane vetvi. A jo obcas to taky spadne:-) Ale technologie to vetsinou da.
Ono i kdyz mate PDU s ATS jako workaround pro sockoidni zarizeni,tak i tech 10ms nektera zarizeni zblazni.
Kazda prepojovaci manipulace je rizikova.
Je chyba zakaznika/DC ze nema dvoji napajeni na technologii.
To vsak samozrejme neresi pripady kdy zdroj/napajeci cast u serveru nejakeho zarizeni odejde pod vysokou zatezi jednoho zdroje - pak. Viz navrh na treti vetev.
DC namisto AC je reseni pro telco... ale ne pro bezne dostupny (serverovy) HW - bavime se samozrejme o tom, co vyrobce podporuje a supportuje (ne o domacich bastlech). A i u telco zarizeni ne kazdy vyrobce podporuje mixovani AC a DC zdroju.
S vice zdroji, treti vetvi/extra technologie/dalsi UPS take stoupaji i naklady na udrzbu. A na konci mame porad zakaznika, co pak bude frlat ze to je drahy... :-) Ostatne ona ta cenovka DC v USA je taky jinde... kdyz uz chceme srovnavat.
Nemusíte být nutně v druhém DC. Když budete mít recovery plan, který bude počítat dočasně s AWS nebo DigitalOcean nebo jinou službou, tak to je pořád lepší než nemít nic a čekat před branami datacentra až nahodí proud a začne fungovat bzučák na dveřích. Důležité je vědět co dělat a transparentně to komunikovat s uživateli.
Zaujímalo by ma, ako sa v týchto prípadoch postupuje pri odškodnení zákazníkov. Nejde mi o rýpanie, ale skutočne ma zaujíma, aký faktor ako zohráva rolu. Pokiaľ viem, pri výpadku napájania mimo sa zákazník neodškodňuje, lebo datacentrum za to nemôže. V ich prípade ale zlyhanie nastalo u nich, lebo systémy nenabehli tak, ako sa očakávalo. To už by na odškodnenie bolo myslím. A čo potom ten výpadok vetvy B? To asi už duplovane. A o čo mi konkrétne ide? Krízové scenáre sú vždy len na papieri a takmer nikto s nimi nepočíta, že nastanú, nie, že by ešte nastali problémy s ich nasadením. Je fajn, že spoločnosť presne vysvetlila, čo sa stalo. To chválim. Na druhej strane, po ich vyjadrení nastáva otázka: Koľkokrát urobili pokusne krízový scenár, počas riadnej prevádzky, aby overili, že skutočne funguje? Pár rokov dozadu sa písalo na roote (?), že sa niekde v datacentre skúšal fingovaný požiar, aby zistili, že ako na tom sú. A nakoniec prekvapí obyčajný výpadok elektriny. Ale ako som písal, chválim, že na rovinu povedali, čo sa stalo, hoci tým priznali, že to dovrzali oni sami. Iné veľké spoločnosti v takýchto prípadoch radšej mlčia a zahmlievajú ako jeden webhosting pred pár rokmi, len nie som si istý, ktorý to bol. Teda myslím si, ale neviem na isto.
"Zde bych rád uvedl, že všechny tyto technologie splňovaly kvalitativní standard datacentra včetně pravidelných revizí a testování, rovněž i postup personálu se po vyšetřování ukázal být v souladu s krizovým plánem. "
To je alibi jak za totáče. K čemu to je, že to splňovaly, když to i přesto lehlo? Tak asi se stala někde chyba v návrhu testů, kdy se to jen tak jakože povypínalo, ale neřešily se uvedené extrémy.
Technika selhat muze i pri sebelepsim testovani (problem vetve A). Zkrat nastat muze... ono spousta veci "umre" v momente, az kdyz ztrati napajeni a posleze se obnovi (zjevne ten pokus o prepojeni zateze z problematicke vetve A na fungujici vetev B).
Uvedomte si, ze koncova zarizeni typicky datacentrum pod kontrolou nema. Proste neovlivnite to, ze si zakaznik prinese patnact let stary vrak, co v extremni situaci sam o sobe muze byt zdrojem problemu z pohledu napajeni. Jistice coby prvky proste nejsou dokonale, nevybavi tak rychle... a zkrat obcas proleti dal, nez ocekavate... pokud mate pocit, ze projektanti datacenter to delaji spatne a vy to umite lepe, muzete se predvest... :-)
Naivně bych ovšem tedy očekával, že konkrétně server housing proto bude jištěn zvlášť důkladně tak, aby selhání koncového zařízení nezlikvidovalo celé datacentrum. Neberte to jako kritiku, projektování datacenter nerozumím, dívám se na problém pouze jako zákazník a uživatel jak těch datacenter, tak prosté neformální logiky.
Ak vsetko bolo v sulade s planom, tak bol zjavne zly krizovy plan.
Minimalne v tej casti, kde sa maju prepinat zariadenia medzi vetvami.
Ako uz bolo spomenute vyssie:
A.) presuvanie zariadeni medzi vetvami bolo zbytocne riziko, a v tomto pripade dokazane sposobilo viac problemov, ako vyriesilo
B.) riziku sa dalo predist uplne jednoducho - komunikovat ho zakaznikom, ktori nemaju zdvojene napajanie
Ostava jedine drzat palce a dufat, ze Lessons Learned sa nezahodia do kosa...
Žádný krizový plán není nastaven na 100% dostupnost – nejde to. Takže mohla nastat ta situace, kdy i podle krizového plánu dojde k výpadku.
U přesouvání zařízení mezi větvemi bůhvíproč předpokládáte, že šlo o zákaznická zařízení. Ve vyjádření je napsáno:
přesouvání vybraných zařízení větve A na sekundární větev B. Jeden z přepojovaných prvků způsobil zkrat
Jednalo se tedy o extrémní případ souběžného selhání několika záložních a jisticích prvků v soustavě. Zde bych rád uvedl, že všechny tyto technologie splňovaly kvalitativní standard datacentra včetně pravidelných revizí a testování, rovněž i postup personálu se po vyšetřování ukázal být v souladu s krizovým plánem.
To mnohem pravděpodobněji vede na to, že přesouvání se týkalo zařízení MasterDC.
Mnozí kolegové v diskuzi mají pravdu nebotˇ:
Výpadek, el. energue je běžný provozní stav.
Výpadek jedné větve (či UPS) je počítaným rizikem s řešením v redundanci.
Přenášení zátěže v dané situaci, poukazuje na neřešení dostupnosti těchto zařízení od počátku a je jedno čí jsou. Pokud Master DC o to hůře.
Selhání zdroje je v DC běžná porucha, která by neměla mít vliv na redundanci. Mnoho selhání zdrojů vede ke zkratu.
Problém však je v tom, že běžné UPS mají el. ochranu , kdy vypnout při 10x In do 5 ms.
Proto se musí sladit i UPS s jističi (Třída Z?) jinak, vždy první zareaguje ochrana UPS, což v datovém centru není žádoucí.
No a pro všech minimálních předpokladů pro zajištění se dostaneme k tomu, že UPS musí mít minimální velikost ..... Jinak tento problém nelze vyřešit.
Presun zarizeni byl podle vseho nutnost - uz jen proto, ze ne vsichni zakaznici chteji/maji privedene obe vetve - viz specifikace variant napajeni. Jak byste to tedy vyresil Vy? Nechal ty zakazniky na vetvi A proste odpojene - realne vzato asi jeste i k dnesnimu dni - protoze problem s UPS na vetvi A jeste vyreseny neni (aktualne cas zprovozneni za cca dva dny)?
Vase teorie je pekna, ale v praxi holt nesmyslna... i zakaznici s jednou privedenou vetvi zcela urcite maji nejake smluvni SLA (trebaze horsi) - a nemuzete za nimi dost dobre prijit s tim, ze "hele sorry, ted ti to par dni nepojede, protoze nam tu umrela UPSka na tve napajeci vetvi"...
1. Horší služba nesmí ohrozit lepší službu.
2. Poukazoval jsem na to, že zkrat nesmí ohrozit ostatní větve, není jednoduché zejména u malých datových center, kde začne rychleji odbavovat UPS ka než jistič. Pro příklad u standartních ochran třídy B by jištění větve k zařízení mělo být max 1/7 In UPS.
3. Pokud zařízení nemá možnost dvou napájecích větví, můžu dát automatický powerswitch.
Chápu snahu přivést online zákazníky, kteří mají jen single vstup, ale SLA je dané tím co si platí, tady spíš ukazujete na to, že slibují vyšší SLA než je reálně možné a nemají provedenou FTA analýzu. Případně se ukázalo, že zapoměnili či mají neověřený MTTR.
Tak to v realnem svete ale nefunguje. Viditelne zijete v nejakem svete virtualnim :-)
A ono reseni pro pripojovani jednozdrojovych zarizeni s automatickym prepojovanim vetvi ma take sve nevyhody a rizika - zrovna treba v situaci, kdy vadny napajeci zdroj vyzkratuje jednu vetev... logicky vypadne jistic, ten prepinac korektne prepne na druhou vetev, ale zkrat ve zdroji jeste je... no a mate razem vyhozene obe vetve - driv nez se rozkoukate... :-)
2N redundance neco stoji - ona ostatne neni ani v pozadavcich na Tier3 (na to staci staci N+1), az u Tier4 mate 2N - tedy skutecne oddelene vetve mimo jine vc. oddelenych UPS... A ostatne i v tom zaslibenem Nemecku najdete datacentra, co maji jen N+1 (a nikoliv 2N). Asi byste mel jit tem Nemcum jit vysvetlit, jak to tam hosi delaji blbe :D
Připojení pomocí ATS není samo o sobě problém je to řešení pro jednozdrojové zařízení, které potřebuji mít zajištěno vůči selhání napájení. Prostě někdy zařízení se dvouma zdroji neexistují. Použití vychází ze statistiky, kdy selhání zdroje je řádově méně pravděpodobné než selhání dodávky el. energie.
To očem vy píšete, že by umřela další větev protože vadný zdroj by vyhodil první větev a byl připojen na záložní a tu by vyhodil také, je problematika jištění a správného návrhu. Stejně tak při dostatečném počtu zařízení roste pravděpodobnost, že mohou selhat dva různé zdroje a každý na jiné větvy.
Zároveň bych upozornil, že článek hovoří o UPS N+1 na větvy B a poruše UPS N+1 na větvy A. (vice versa) Tedy napájení DC je z celkového pohledu v režimu 2(N+1)
Pokud investuji do 2(N+1)režimu, měl bych si být jist, že mi to nevyhodí kravina.
Kolegové správně poznamenali, že dokud neidentifikuji závadu nemám do toho šahat. Spálená pojistka se sice laicky řeší její výměnou, ale správně má být nejdříve ověřeno, že není jiný problém a až následně ji vyměnit, případně jistič "natáhnout". To jsou základní pravidla u elektrikářů s pravidelným přezkoušením.
Zarizeni se dvemi zdroji existuji - bavime se o tom, co se bezne nosi do DC za UPSkou zalohovane vetve - servery, switche, routery, firewally, zdroje presneho casu atd... pripadne u nekterych jednozdrojovych zarizeni je predpoklad, ze provozujete dve v HA (a logicky si kazde pripojite na jinou vetev) - napr. ty zminene firewally.
Dobre spocitane jisteni pred ATS nezabrani tomu, ze vam pri zkratu ve zdroji vypadne napajeni pro cely stojan (pripadne jeho cast). Ja nikde nepsal, ze to nutne musi vyhodit cele datacentrum... ale dostupnost vasi sluzby to proste ovlivni :-) ATS je v tomto spise spise low-cost redundance (a spise odchazeji ty zdroje, nez ze by vypadavaly zalohovane vetve v DC)...
Clanek nehovori o poruse UPS na vetvi B - clanek rika, ze pri havarijnim prepojovani casti zateze z vetve A doslo k vypadku jistice (v 10:43)... no, tyhle veci se obcas stavaji i jinde. Kdyby doslo k poruse druhe UPS, asi by to nenahodili zpet tak rychle (v 11:16), ze ;-) Jistotu, ze vam jistic nevyhodi nejaka kravina nemate nikdy. Ono kdyz vypadne jistic, co ma jmenovity proud ve stovkach amper, tak to nikdy neni kravina. V neposledni rade i ten jistic se muze porouchat (nebo byt treba jen chybne nastaveny, viz link vyse).
A samozrejme, po bitve bude kazdy general. Ono se na internetu se od kafe vzdy lepe teoretizuje a rozmysli, ale zkuste se vzit do role techniku na miste v case vypadku, kde do nej zvenci busi zakaznici s tim, kdy uz jim to teda konecne pojede... a zpravidla ti, co plati nejmene (provozuji low-cost reseni) jsou ti, kteri pak busi nejvice ;-)
Doplním, že jsem byl účasten velké události o povodních 2002 na Karlíně, kdy jsme udržovali v provozu infrastrukturu v době, kdy tam oficiálně nebylo živé duše a Karlín byl "obklíčen" vojskem a policií. Znovu jen zopakuji, že ve většině případů jde o dodržování základních pravidel. Ano nevyloučí, že se tak nestane, ale MTTR i podle jejich záznamů bylo neodpovídající.
Vsak o tom Karline tu je clanek (a diskuze pod nim)... aneb slunickovy to tehda vsude taky nebylo.
Ano sluníčkové to nebylo, padali jsme na hubu. Omezení počet lidí mělo povolen vstup do zóny, např. o DC se pak staral jeden člověk, který tam byl 24 hodin denně nonstop. Plus k tomu pak pomáhali hasičům a dělali jim zázemí, neboť jako jediný jsme měli elektřinu. Kolem padali baráky a přesto se tam lidi snažili zajistit vše , aby v mnoho služeb fungovalo i přes vyšší událost typu katastrofy. V diskuzi pod tím např. není vše pravdivé. Ten údajný manažer co řídil přepojování generátoru jsem byl já osobně. I když jsem vůbec manažer nebyl, pouhý specialista strategie a rozvoje sítě internet online. Jen jsem byl jako jediný ze všech kolegů IOL s elektro vzděláním. A aby to přepojení bylo úspěšné, tak jsem vypracoval plán práce a s montéry prošel každý krok a ověřil, že mají každý potřebný nástroj pro danou činnost bez nutnosti jej hledat, tak aby jsme se mohli v každém okamžiku vrátit ke starému generátoru. K tomu se pojila i hrůza , kdy po přepojení UPS odmítli akceptovat napájecí napětí z nového generátoru a odmítly se nabíjet. Naštěstí pomohlo manuálně snížit a zvýšit frekvenci a ono se to chytlo. A mimo to protože, v karlíně hrozili propady vozovky se jezdilo s cisternou nafty společně s vojenskou tatrou s rozkazem dotáhnout i na smyka bez podvozku. Samozřejmě původní rozvody nešly použít, tak tam se táhl pěkně dlouhý kabel, který opravdu topil jaký proud ním tekl.
Vše růžové nebylo, než šplouchla voda, jsme chtěli jako technici od ředitele schválení pro přenos všeho co jde na Olšanskou, jen místo rozhodnutí bylo ticho, asi nechtěl řešit kdyby to byl planý poplach.
Kluci z master DC udělali co neměli, jak jsem psal. Volili na pohled nejrychlejší a nejjednodušší cestu a doplatili na to s pravděpodobnou design chybou.
Tak ci onak ta diskuze zjevne odrazi zpetnou vazbu tehdejsich zakazniku - a ta asi bude objektivnejsi nez samochvala. A kdyz uz mluvime o design chybach - tak jednou z nich bylo treba uz i to mit datacentrum kousek od reky (zvlaste kdyz se podivame, kde bylo jeji historicke koryto - ostatne Pobrezni nema sve jmeno nahodou...) :-)
Ano, umístnění bylo špatné. Taktéž to odnesl RedBus ten sotva co postavil svoje DC ve stejném areálu tak skončil kompletně vytopen. Také bylo vše jak to šlo okamžitě odvezeno a nikdo se nepokoušel o návrat do dané lokality.
Jen bych konstatoval jednu věc, vše bylo postaveno a naplánováno, tak aby to normální povodeň ustálo, to co přišlo nikdo nečekal. Stejně tak bylo ohroženo a odstaveno DC na Moravě klasifikace TIER III v případě tornáda, tam to také nikdo nečekal. A přitom víme, že větrná smršť je ČR běžná a běžně lítají střechy.
V tomto případě srovnáváte nesrovnatelné. Závada napájecího zdroje je běžný provozní incident. (MTBF daného zdroje a jejich počet) Zatímco Povodeň , Tornádo je vyjímečná událost. Tady si stačí uvědomit, že ani protipovodňová zábrana při výstavbě metra nezabránila jeho zaplavení. Okolnosti, že bylo metro zaplaveno ve větším rozsahu, než muselo být, je jinou otázkou.
Karlin zaplavovala voda odjakziva. Aneb baraky v Karline v dusledku povodni padaly treba i v roce 1845. Ale kdo by se zajimal o historii, vymluvit se na "necekane" je jednodussi :-)
Zrovna tu řeku bych jim nevyčítal, s tím nepočítal nikdo. Desítky let všichni slýchali, že pro ochranu před povodní přece máme přehrady, na Vltavě celou kaskádu. A taky desítky let žádná povodeň v Praze nebyla – naposledy 1940 (před tou z roku 1954 Prahu opravdu ochránily Slapy, akorát že díky tomu, že byly před napuštěním).
Navíc později bylo vypočteno, že povodeň v roce 2002 byla cca pětisetletá – a nemyslím si, že běžné datacentrum má být stavěné tak, aby bez výpadku ustálo událost, ke které dochází v průměru jednou za pět set let.
Ostatně i ta zpětná vazba tehdejších zákazníků ukazuje, že povodeň bylo něco, s čím vůbec nepočítali – a teprve po hodině telefonování uvěřili tomu, že je Praha opravdu pod vodou.
Ne, bezne datacentrum by nemelo byt stavene u vody. Zadne. Predvidat prirodni jevy dost dobre nedokaze nikdo a ze voda v roce 2002 byla "petisetleta" neimplikuje, ze dalsich pet set let se nic podobneho prihodit nemuze... muze, klidne treba uz letos.
Navic do Prahy nepriteka jen Vltava... ona treba i Berounka umi pekne zatopit... a tam zadne "Slapy" nemate, ze :-)
Ano, riziko se vseobecne podcenovalo. A pokud jde o to, "jaka voda" - v minulosti byly mj. vypracovane i plany zohlednujici protrzeni vltavske kaskady. Tzn. stacilo vychazet z techto planu... coz se proste nestalo.
Jak pravděpodobné je protržení vltavské kaskády? Opravdu by někoho při protržení vltavské kaskády zajímalo, jestli běží jedno tuctové pražské datacentrum? To datacentrum není chráněné ani proti pádu dopravního letadla, zemětřesení, cunami, pádu meteoritu. Akorát že lidé chtějí levné datacentrum a nepotřebují být jištění proti takhle nepravděpodobným věcem. A pokud někdo potřebuje mít pokryté i takhle nepravděpodobné události, nebude mít zařízení v jednom superbezpečném datacentru, ale v několika datacentrech, která jsou dostatečně daleko od sebe.
Vzdyt to, jak se lidi muzou zblaznit (po**at), kdyz chvili nebezi jedno tucove prazske datacentrum krasne odrazi tato diskuze :-) Uz vidim, jak tihle borci najednou smirlive a s pochopenim prijimaji skutecnost, ze datacentrum splachla velka voda nebo na nej spadlo to ledadlo, kdyz nedokazou prekousnout ani to, ze i pri sebelepsim navrhu muze elektrika obcas vypadnout...
Datacentra se ovšem nestaví pro to, aby se vyhovělo pár křiklounům v diskusi. Výpadek rozvodny VVN by tuctové datacentrum mělo ustát. Předpokládám, že MasterDC v tuto chvíli šetří, co přesně se stalo – zda mají chybu v návrhu a výpadek chodovské rozvodny by je sestřelil stejně i před půlrokem nebo znovu za půl roku. Nebo zda selhalo ještě něco jiného, co se nedá s rozumnými náklady zajistit (a svou pravděpodobností tedy ta událost byla podobná třeba té pětisetleté vodě nebo pádu meteoritu.)
Tady jde o něco jiného. Za prvé Internet v roce 2002 a v současné době je velký rozdíl a to v závislosti ekonomiky.
Každá událost slouží i ostatním k poučení, kde se stala chyba a co udělali špatně a tedy kde mohu mít chybu i já.
I díky vám se ukázalo, že většinou jde o selhání lidského faktoru viz váš příklad TTC, které to však přiznalo.
U master dc nedošlo k přiznání chyby, ale jen popisu co se dělo. V rámci diskuze byli předloženy různé pohledy, včetně informací o chování UPS v případě zkratu na výstupu UPS. Což mě a myslím, že další lidi vede k předběžnému závěru, že došlo taktéž k selhání lidského faktoru, resp. obsluha neměla dostatečné znalosti o chování UPS a podstoupila rizikovou operaci. Pokud ji měla tak to holt nevyšlo.
Nikdo nezpochybňuje to, že nemůže dojít k závadě. Podle Murphyho k ní dojde obvykle v nejméně vhodnou dobu. Což se naplnilo.
Proto ta konstruktivní kritika se zdůvodněním práce kluků z master. V tomto případě ten výpadek se zdá být zbytečným a ne způsoben souhrou okolností bez možnosti ovlivnění obsluhou.
Domnívám se, že spousta lidí si až teď uvědomila, že jistič za UPSkou, neřeší vše co si mysleli.
Hodnoceni z roku 2002 clanek take obsahuje. Z 319 respondentu ~69% hodnotilo reseni jako spatne :) Z diskuze je patrna i (ne)dulezitost - ale chapu, vy sam se musite vychvalit a kriticke hlasy z te doby proste budete bagatelizovat...
Co tu porat mumlate o neznalosti chovani UPS? Jedine, co se v ramci havarijniho prepojovani casti zateze z vetve A na vetev B doopravdy stalo je v 10:43 vypadly jistic pred UPS. A v textu clanku, ktery komentujete to mate popsane. Z textu je rovnez patrne, ze take nevybavil podruzny jistic po ceste. Vite proc? Nevite, jen tu varite z vody. Ano, mohla to byt lidska chyba - ale klidne mohlo jit jen o technicke selhani toho podruzneho jisticiho prvku (ano, i jistice odchazi).
A vypadek UPS na vetvi A byl instantni, ta vetev vypadla uz v 8:49. Tam o zadnou lidskou chybu neslo. Selhala technika. No a datacentrum na te vetvi ma zakazniky, co druhou vetev privedenou nemaji (vc. takovych, jako je treba Cesky Rozhlas ci Ceska Televize) - ale i tihle zakaznici urcite ve smlouve maji nejake SLA. Takze ta vase idea na nic nesahat a nechat tyhle zakazniky proste odpojene je formalne vzato holy nesmysl. Postupovali podle havarijniho planu, ktery pro takovou situaci maji vypracovany (a viditelne je na takovy scenar pripravena samotna energeticka infrastruktura) - ne jako ty vase improvizace s poddimenzovanym kabelem hozenym z okna ;-)
Domnívám se, že jsem vcelku srozumitelně popsal proč a kde udělali chybu. Když si přečtěte ten technický dokument o funkci UPS, tak pochopíte proč jejich postup bez nahození vypadlé větve aspoň bez UPS byl risk. Skoro to vypadá jako by jste tam pracoval a nechcete si to přiznat. Pokusme se opravdu na to podívat i z pohledu jak tomu předejít. Může to být poučné i pro spoustu malých DC v továrně, ale i v nemocnicích.
Nebyl jste tam, neznate mistni podminky.... ale bezpecne vite, v cem udelali chybu. Tak jisteze. Podle popisu proste jen vybavil jistic u vyvodu z UPS (chranici samotnou UPS pred ucinky zkratu). Takze cele to vase pojednani o reakci UPS na zkrat je sice pekne, ale v kontextu celeho incidentu naprosto o nicem.
Kdyby tu vetev nahodili nejdriv bez UPS, tak to nevyresi nic - k havarijni manipulaci s prepojenim single-feed zakazniku by vysoce pravdepodobne muselo dojit, nechat X dalsich dni zakazniky mimo UPS by asi bylo o poruseni SLA - i zakaznik s jednou vetvi si plati za to, ze vetev bude zalohovana (a ne pripojena natvrdo). A i pri tom prepojovani "po testu" se muze neco pokazit - to jsou veci, ktere proste nepredpovite (a zjevne ani nepripoustite). A jeste jako bonus by to meli ti zakaznici s dalsim nerizenym vypnutim svych serveru "natvrdo" v dusledku toho jako "blikani" treba jeste vic rozbitymi filesystemy... tady se presne ukazuje, ze premyslite "uzkoprofilove" jen jako elektrikar, co ma nulovy vhled do technologie na konci dratu - a je mu to vlastne jedno, co se deje dal...
Pokud by jste četl, ten dokument tak se dozvíte, že většinou UPS není schopna odbavit zkrat a proto si pomůže bypasem. Tedy zajistí dostatečně tvrdý zdroj pro odbavení zkratového proudu a ano máte pravdu, tady nastupuje jistič před UPS, který to má ustát. V jiném případě je pak defakto UPS k ničemu.
Samozřejmě nic jistého nevím, dedukuji. Také jsem poznamenal, že vyjádření master dc je neúplné z tohoto hlediska. Vámi zmiňované TTC uznalo lidskou chybu se špatně nastaveným jištěním.
Co se týče mého vzdělání, tak elektroprůmka a mikroelektronika na VŠ, tedy můj pohled není úzkoprofilový, ale právě velmi široký s uvědoměním si, že vše na sebe navazuje a jedno bez druhého v krizi selže.
Tady ještě doplním, že opravdu kluci z master DC neměli na to šahat, pokud neznají co se může stát.
Stačí si přečíst dokument výrobce UPS, jak se UPS chovají v případě zkratu.
Tedy prvně měli zprovoznit nefunkční větev aspoň bez UPS nejlépe s napájením ze sítě příp. dostatečně silným generátorem, aby spolehlivě mohla vybavit při správné selektivitě příslušná ochrana a až pak se pokoušet- přepojovat zařízení, neboť i jak zmiňuje dokument v odkazu, riskovali odpojení UPS a přepnutí na bypass což u single přívodu, nemusí technika ustát. A někdy to vezme režimem, kdy to zařízením nevadí a někdy v režimu, kdy je zaznamenán krátkodobý výpadek. Pokud UPS nedokáže dodat proud na vybavení ochrany, tak to vezme přes bypass, který by měl již odbavaní ochrany zvládnout. Hlavně by měli v momentě práce, vždy další funkční větev i když už ne zálohovanou. Takto neměli nic.
Tak si znovu prectete report z TTC. Proste nic vam nezaruci, ze v ramci toho prepojovani neco neshori a nasledne nevyhodi vse okolo. Druha vec je, ze to nouzove prepojeni ze site/generatoru vetve A na zalohovane vyvody vetve B by bezvypadkove rozhodne nebylo - takze to mate s dalsim vypnutim serveru natvrdo... no jejich spravci by Vam jiste pekne podekovali.
Dle dostupnych informaci v MasterDC postupovali podle havarijnich planu. To jsou dokumenty, ktere mozna rizika analyzuji a zohlednuji. Tvrdit, ze nevedeli, co delaji je hodne odvazne. Zrovnatak muzu tvrdit, ze vy v Karline jste mel jenom zprdele kliku, ze to tam neshorelo cele (viz ty zminky o topicim kabelu, to znamena ze byl asi poddimenzovany, ze? ).
Princip je jednoduchý, postup práce musí být takový aby neohrozil fungující věci s výjimkou záchrany vyšších škod. Topící kabel byl nouzově natažený a ano hlídal se. Vyhoření nehrozilo byl natažen z okna venkem ke generátoru.
Zapojení vypadnuté větve, nebylo myšleno způsobem odpojení funkční větve.
v Reportu TTC je chyba výpadku zřejmě označena v bodě 2 - sumarizace chyb
lidská chyba na straně dodavatele zařízení pro projekt Náhrada zastaralých UPS, kdy nedošlo k ověření správnosti nastavení jistící ochrany v nově dodávaném prvku výstupního jištění UPS = první výpadek
Proto jsem popisoval v jiném příspěvku, že jsem kontroloval činnost montérů při přepojování generátoru. Aby nedošlo k průšvihu. Připravenost, přesné pojmenování a návaznost kroků, které budou dělat vždy s identifikací jestli se můžeme vrátit okamžitě nebo dostatečně rychle zpět. (předělání způsobu připojení).
V těchto situacích je potřeba se zastavit a říct si co se stane, když a podle toho postupovat. A hlavně kontrolovat. Checklisty.....
Je to to co jsem uvadel v diskusi. Kultura vícenásobné zpetne kontroly. Poradek a navaznost praci. To nam v nasi kulture dost chybi. Cest takovym výjimkam dokazi organizovat a maji predstavu o navaznosti kroku.
Jsem rad ze je tu nekdo z praxe kdo to na realnem prikladu popsal.
A nemyslete si ze treba na elektrarnach je proti DC je situace lepsi. Vzhledem ke komplexite a konzervativnosti tohoto průmyslu horsi. Lidsky bordel a zbytecna/zastaraly zpusob vedeni procesu.
Btw: V Karlíně se nam oddelalo pole, ale DR plan vetsinou fungoval. Kde myslite ale ze byla cast ulozen havarijniho planu ? Nekde na tom poli... Tridente vyzer si to... nebo si dej kokes z firemni lednicky az to skonci.
Jasne, byl natazen z okna a proto ten kabel nemohl zahoret... :-) A stala u nej nepretrzite hlidka s kyblikem vody, ktere bylo vsude okolo dostatek, ze? :-D Mluvit o pripravenosti, kdyz jste vse napajel poddimenznovanym kabelem (system, co se kde zrovna narychlo vyhrabalo) je fakt vtipny. Kdyby to fakt zahorelo, tak vam zadny checklist nepomuze. Proste jste mel jen kliku, ze se nahodou nic nestalo...