Vaše největší přehmaty?

[osoba]

Začal jsem číst diskuze pod sobotním komixem.
A už se v tom vezu několik let a neumím přestat.

[Reklama]

[Zzz]

...

Vítej do klubu. Stálo mě to mega a asi jsem se stejně nepoučil

[Sklicko]

Kedysi davno (1994) ako vojakovi zakladnej vojenskej sluzby v hodnosti podporucika sa mi "podarilo" zle zamierit RM-70. No a dve ostre rakety raze 122 mm nam odleteli do civilneho priestoru.... Nastastie som mal hodnost podporucika, tak som nedostal "niekolko" ostrych dni vazenia a nikomu sa nic nestalo... :-)
Vid RM-70: https://cs.wikipedia.org/wiki/RM-70
Robim v oblasti telekom a "podarilo" sa mi zle nastavit smerovanie pre 800x a 840x,84xx v CZ (zelene a modre cisla), niekolko tisic odmietnutych volani na , zakaznici boli uspesni pri kazdom druhom volani :-)
Chyba v jednom cisle konfiguracie a zablokovany voice interkonekt(IC) na jeden den. Cez spomenuty IC malo prechdzat 30 tisic minut volani za den :-)
A este ine... :-)

[Vim]

Volal admin zakaznika, ze na MsSQL DB servru dochazi misto na disku, jestli se na to podivam co lze smazat a uvolnit misto. Tak jsem se pripojil, kouknul nejvetsi zrouty a byl tam nejaky 40GB log file. Rikam si, maji to zalohovany. V zivote se tam na ty logy nikdy nikdo nekoukal a i kdyby nekomu ten log bylo potreba tak ho vylovi ze zalohy. Tak jsem previta smazal i kdyz se zurive branil, ze ho neco pouziva.

Byl to transakcni log MsSQL...

+1 , taky jsem mazal "zbytečný" log ještě na mssql 2000, ..přece zabíral dost na disku,  tehdy jsem o databázích lautr nic nevěděl....

[Vim]

......já mám zase "veselou" historku s  Dell podporou.
 Cca 10 let zpět, byl jsem totální admin ucho a  byl páteční večer a já se rozhodl po pracovní době vyřešit jeden problematický dell server, kde padal OS, asi ram nebo board říkal jsem si, zavolám na dell podporu (placená 4h reakce) a týpek ochotně kolem 22:00 dorazil  i s náhradním boardem a ram, (prý to expres objednával až z PL skladů, v CZ díly pro tento typ serveru neměli).   Pustili jsme se do práce a na serveru vyměnili kde co, protože diagnostika žadný problém neukazovala, cca po 2 hodinách jsem si uvědomil, že  děláme na jiném serveru :-) , no co už mi zbývalo, nechal jsem si to pro sebe a celou situaci hrál až do konce a kolem 2:00 po té, co týpek defakto poskládal z dílů nový server jsme se rozloučili, že  budu  hw sledoval zda se chyba znova neukáže... no neukázala.   Cca za týden jsem nahlásil, tentokrát už ten správný server, týpek znova dojel a opravil reálnou chybu. Nakonec jsme si navzájem postěžovali na těžký úděl adminů. Trochu jsem se vnitřně zastyděl :-)...

Příští měsíc jsme zavedli inventarizaci serverů :-)

[Reklama]

[MasoxCZ]

Kamarádovi se povedlo v roce 1997 při aktualizaci firmwaru do jednoho routeru poslat místo souboru s firmwarem soubor se zálohou konfigurace. Jelikož to bylo něco staršího, nedělalo to žádný kontroly, takže z něj udělal cihlu za tehdy asi 150 tisíc :-) Kupodivu na to asi někdo při vývoji myslel, protože šel modul vyndat, dát místo něj živej, nastartovat, a za chodu opět přehodit a flashnout správně, takže ho dokázal vzkřísit.

[kemik]

Kdysi v jedne velke telco firme jsem v abapu napsal nasledujici select ktery nacetl materialy ktere se nasledne aktualizovaly:

SELECT matnr mtart
    FROM mara
    INTO CORRESPONDING FIELDS OF TABLE it_mara
    FOR ALL ENTRIES IN it_matnr
    WHERE matnr = it_matnr-table_line.

SQL v ABAPu ma urcita rozsireni jako napr zde FOR ALL ENTRIES IN, it_matnr je v podstate pole prvku. V sapu se tento prikaz prelozi predtim nez se posle do databaze na WHERE ( matnr = 'MATN1' or matnr = 'MATN2 or ...atd'. Problem je ze jsem si predtim neotestoval ze pole it_matnr neni prazdne, takze ve vysledku jako kdyby tam zadna where podminka nebyla. Po spusteni aktualizacniho programu na produkci jsem zmenil nekolik tisic materialu ktere zmeneny byt nemely, diky bohu ze to uzivatel killnul po 10 min, ze pry to bezi nejak dlouho.

[Lojza]

bricknul jsem dva tp-link wifi routery pri snaze nahrat tam openwrt


odpalil jsem 2 stare hloupe nokie a jeden usb port na ntbk (pripojenim usb hubu s neoriginalnim zdrojem) vetsi napeti nez melo byt


holt jsem nepoucitelny

[CoffeeMan]

Já tohle vlákno vypravuji. Moc se nesmějeme, protože to platíme. Obecně to podporuje můj názor, že na rozdíl od jiných profesí ta zodpovědnost v IT není zrovna nejlepší. My jsme tomu ale všichni přizpůsobeni, nebojte.

[MasoxCZ]

Při cestě Velká Bíteš - Brno (ve 3 ráno) jsem dojel do Žďáru nad Sázavou... True story 

Jo, stalo se mi že jsem jel vyzvednout máti na Folmavu, a když jsem ji na celnici hledal a nemohl najít, ukázalo se že jsem na Rozvadově :-)
A jednou jsem si u zákazníka v Č.Bud. zapomněl flashku s PDFkama protokolů co jsme tiskli a podepisovali. Volal mi to, když jsem projížděl Miličínem. Na flashku bych hodil bobana, ale na kroužku byly jediný klíče od bytu.
Obdobně na jaře jsem nechal flashku v Plzni na Borských polích. Přijel jsem v létě, podávám novou, spolu s papíry dostávám tu jarní. Odjíždím, u Ejpovic zvoní telefon :-D

[R2D2]

Testování na produkčním stroji (AIX) v 6 ráno, jestli nejde jeden ovladač nastavit do nějakého stavu, aby to neshazovalo kernel. V 7:30 poslední test; před testem ovladače jsem nenapsal "sync". Bohužel instalace SW předtím modifikovala /etc/inittab, takže byl po rebootu prázdný.... Tak jsem zjišťoval, jak se AIX bootuje z CD.... naštěstí tam byl nějaký záložní, tak se to povedlo docela rychle nahodit (hodně dááávno...)
Joo to halt nesmis pouzivat halt ale shutdown
Kolega připojoval disky z většího diskového pole na server; použil wizard. Wizard si myslel, že disk je prázdný a přepsal hlavičku.... Noční recovery komplet celého prostředí zákazníka ze záloh, cca. za týden se mi povedlo i modifikovat nějaký SW pro čtení vmware disků, takže jsem z toho nakonec dostal i originální data...

Cluster v polorozpadlém režimu...říkám kolegovi - zkontroluj, jestli node č.2 běží a jestli ne, rebootni. OVĚŘ si, že je to node č.2. Rebootnul node č.1 (protože tam byla migrující IP adresa a on se připojoval na node 1.....) - obnova celého prostředí....
root se halt ma hlasit na persistentni adresu, ne na servisni :-)

rm -rf $VAR/  ($VAR byl z nějakého důvodu uprostřed skriptu prázdný) - naštěstí na testovacím stroji...

Klasika od zákazníků: test záložního zdroje, celé prostředí bez proudu (zdroj naběhl, ale při přepojování zpátky vylítly pojistky.... zdroj se pokusil naběhnout, ale nebyla v něm nafta.... zdroj naběhl, ale byly zarezlé žaluzie u výfuku...).

Test samočinného hašení - výdechy byly umístěné nad podhledama......

[armabeton]

Já tohle vlákno vypravuji. Moc se nesmějeme, protože to platíme. Obecně to podporuje můj názor, že na rozdíl od jiných profesí ta zodpovědnost v IT není zrovna nejlepší. My jsme tomu ale všichni přizpůsobeni, nebojte.

proč jen v IT? Četls tu část o zastavení elektrárny například, nebo s tou krochnou? To nemělo s IT nic společného. Stejně jako jistič bez označení "nešahat" (jj taky se mě to stalo, dobrá zkušenost). Výpadky má prostě každej, jen si to přiznat.

[to_je_jedno]

Vaše největší přehmaty?

svatba.

[R2D2]

V den odjezdu dovolene na Umag (Chorvatsko) mi přišel fax od SCO s pozváním na konferenci v Portoroži (Slovinsko) s překvapivým dodatkem , že platí i ubytování. Je to pár desítek kilometrů, říkám si, bude sranda , potkám staré kamarády a odjel jsem tam s pár markama v kapse a v plážových kraťasech. Na konferenci byly pozvány špičky polské policie a ministerstev a navíc jsem se při odjezdu dozvěděl, že info o placení byl omyl sekretářky. Hostitel to vyřešil jako gentleman

[R2D2]

V den odjezdu dovolene na Umag (Chorvatsko) mi přišel fax od SCO s pozváním na konferenci v Portoroži (Slovinsko) s překvapivým dodatkem , že platí i ubytování. Je to pár desítek kilometrů, říkám si, bude sranda , potkám staré kamarády a odjel jsem tam s pár markama v kapse a v plážových kraťasech. Na konferenci byly pozvány špičky polské policie a ministerstev a navíc jsem se při odjezdu dozvěděl, že info o placení byl omyl sekretářky. Hostitel to vyřešil jako gentleman

Byl to nejlepší hotel ve městě