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

[Pavouk106]

Když jsem v roce cca 2007 začínal s Linuxem na desktopu (do té doby jsem byl víceméně nepolíben), tak mi docela vadilo, že jsem musel pořád používat editor Kate v root režimu, když jsem chtěl editovat něco v /etc. Tak jsem na /etc pustil rekurzivně chmod 777 a od té doby už jsem neřešil problém s editací... Skončilo to přeinstalováním systému.

To je asi ta největší blbost, co se mi kdy povedla (resp. měla největší dopad). Takové ty blbosti jako smazání něčeho, co jsem nechtěl, vypnutí stroje na dálku apod., to nemá cenu zmiňovat. Nestarám se o žádné servery, takže škody jsou vždy minimální.

Jinak souhlasím s tím, že nejhorší je ta chvíle, kdy si člověk uvědomí, že ten letící prst na "Enter" už nezastaví a přitom mu ještě před dopadem dochází důsledek.

[Reklama]

[aabb]

mne sa viac krat stalo, aj stava sa, ze v ramci ladenia, a hladania priciny nejakej chyby, zakomentujem cast kodu na produkcnom serveri (potrebujem mat zive data, na teste niesu), alebo vypnem nejaky cron... Chybu najdem, opravim, no kod / cron zabudnem dat do povodneho stavu a tym padom nieco aj par dni nefunguje, nieco sa par dni neloguje...
Tip ako ladit veci kde je potrebny zivy dataflow? Ako predchadzat podobnemu "zabudaniu" ?

[tuz]

Jako root heslo na serverech zakaznika jsem pouzival znacku monitoru co tam byl pripnutej. Po roce vymenili monitory. Po dvou letech bylo treba to heslo a nikdo uz nepamatoval co za monitor to byl. Tak se slo brute force metodou vsech moznych a nemoznych znacek az to byl tusim Philips 

[Bubbler]

V hostingu nám jednou shořelo diskové pole (doslovně, plamenem). Tak se tam v rámci 24/7 servicu hned dokolembali maníci z IBM, nahodili nový HW a my spustili rozbalení záloh. Po pár hodinách byli disky zelený a šlo se nahazovat mašiny.

A ouha. Během let vývoje distribuovaného řešení se nové servery a servicy přidávali postupně a nějak závisely už na běžících službách jiných. Pro ilustraci - šlo snad o 20+ blejdů a mnoho z nich mělo i do 5 virtuálů.

• Zapnout všechny naráz nevedlo k ničemu.
• Zkoušet to nějak zapínat podle logiky taky moc úspěchů nepřineslo.
• Nakonec to trvalo snad 2 dny než sme našli tu zlatou cestu v jakém pořadí servery zapínat a s jakými časovými prodlevami.
• To se slavnostně zdokumentovalo a dnes takový rutinní reboot dáme pod 2 hodiny :-D

[annn]

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...)

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í....

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......

[Reklama]

[Danny]

Vytvářel jsem textový editor pod Windows: DanielSoft Editor. Byl jsem bombardován dotazy lidí, kteří chtěli asociovat příponu TXT s editorem a neuměli to (ptali se, "jak zařídit, aby se místo Poznámkového bloku pouštěl DanielSoft Editor?") - tak jsem si řekl, že naprogramuju asociování rovnou do editoru, aby se pořád neptali: vygooglil jsem potřebné WinAPI funkce a dal to dohromady.

Za nějakou dobu si lidé začali stěžovat, že když vytváří v editoru nový soubor, tak je "divný", nebo že v něm "straší" - já jsem nic takového nepozoroval.

Za nějakou dobu jsem na to přišel: při tom přidávání těch asociací bylo tehdy nutno vytvořit "typ souboru" pro Windows, aby se jim řeklo, které přípony zahrnuje. Tak jsem tehdy vytvořil typ "Textový soubor pro DanielSoft Editor". Ovšem tím se stalo to, že když uživatel kliknul v Průzkumníku pravým a dal "nový" - šlo vybrat Nový -- Textový soubor pro DanielSoft editor", což vytvořilo prázdný soubor.

Když se editor pustil s prázdným souborem -teď přijde ta chyba- počítal, kolik sekvencí CRLF obsahuje. Což byla nula, proto usoudil, že soubor je UNIXový. Tento způsob vytváření nových souborů jsem nepoužíval, takže ta chyba tam nějakou dobu strašila, takže lidem na Windows se vytvářely soubory s UNIXovými konci řádků a oni s nimi pak neuměli pracovat a stěžovali si, že v nich "straší".

[Pavouk106]

Ještě jsem si vzpomněl na jednu perličku. Jedu už dlouho na Gentoo a před nějakou dobou (cca 2010?) jsem pořídil Intel Atom N270 desku pro sběr informací (24/7, levný provoz). Chtěl jsem na něj Gentoo, ale říkal jsem si, že bych mohl systém předkompilovat, abych nečekal třeba i několik hodin, než to zmákne ten Atom.

Všechno jsem si připravil, zkompiloval, nakonec došlo na jádro - pečlivě jsem si přečetl, co je na desce za šváby, našel jsem si je, zaškrtal, vybral nějakou podstatnou věc, abych viděl disk (tuším, že muselo být v té době v jádře zaškrtnuto "Podpora SCSI disků" i když byly PATA nebo SATA), zkompilované jádro dal do /boot, napsal vše do GRUBu a došlo na připojení disku a první start. Protože jsem si byl v té době naprosto jistý svými zkušenostmi s Gentoo a tím, že jsem udělal fakt všechno, tak jsem očekával boot na první dobrou! Jak odvážné!

A ejhle... zkompiloval jsem jádro pro 64bitový CPU, což Atom N270 samozřejmě není Po překompilování jádra s 64bit vypnuto to už najelo napoprvé se vším všudy tak, jak jsem si to původně představoval.

[Trupik]

mne sa viac krat stalo, aj stava sa, ze v ramci ladenia, a hladania priciny nejakej chyby, zakomentujem cast kodu na produkcnom serveri (potrebujem mat zive data, na teste niesu), alebo vypnem nejaky cron... Chybu najdem, opravim, no kod / cron zabudnem dat do povodneho stavu a tym padom nieco aj par dni nefunguje, nieco sa par dni neloguje...
Tip ako ladit veci kde je potrebny zivy dataflow? Ako predchadzat podobnemu "zabudaniu" ?

Ja to mám v Git-e a keď dokončím opravu, tak to chcem commitnuť, aby mi to ďalší ľudia neprepísali. Pred commitom zásadne dávam git diff, aby som videl, pod čo sa vlastne idem podpísať, a takéto zakomentované riadky svietia neprehliadnuteľne. Horšie je to s debugovými hláškami... čo mi pripomína:

Kolega zúfalo ladil nejakú korporátnu strašnosť v PHP pre jednu českú automotive spoločnosť a keď mu došli nápady, dával do kódu echo "aaa", echo "tu som", a podobne, aby videl, ktorými časťami kódu skript ide, keď sa spustí. Postupne minul rozumné názvy (ako "aaa" a "tu som") a aj jeho frustrácia narastala, takže takto v kóde vzniklo aj echo "k***t" (pohlavný úd), ktoré samozrejme zabudol na konci odstrániť. Čo čert nechcel, bolo to v kóde, ktorý po submite formulára vyvolal refresh stránky, takže po odoslaní formulára tam na zlomok sekundy bola celkom biela stránka s jedným slovom "k***t" vľavo hore, kým sa načítala stránka ďalšia. Na lokálnej sieti sa ďalšia stránka načítala hneď a nikto si to nevšimol. Na pobočke, ktorá sa pripájala z druhého konca republiky, to ale trvalo dosť dlho na to, aby si to všimli tí, ktorí s tou aplikáciou mali pracovať. Bol z toho celkom prieser, že prečo im IT oddelenie tak vulgárne nadáva po každom odoslaní výkazu.

[Wal-De-Mar]

Objednal som, vtedy ešte pre Eurotel, 20 pokladničných zásuviek. Prišli v piatok, všetky s nesprávnym pripojením / koncovkou. Moja chyba. Tak som na vlastné náklady hneď zavolal výrobcovi, na sobotu ráno objednal nákladný taxík, odviezol sa s nimi k výrobcovi a celý deň čakal kým ich prerobia. A naspäť do BA. Z Oravy... Situácia zachránená, ale stálo ma to prakticky celý plat.

[Fuki]

Jedneho dna zakaznik vola, ze mu vypisalo nezvycajnu hlasku, ze ci ju ma citovat. Citujte.

Dačo sa fest dojebalo, všetko v piči!

Bola to hlaska, pre fatal error ku ktoremu teoreticky nikdy nesmelo dojst. Ale prax je prax

[Honza1Ubuntu]

Spatne nastaveni zalohovaciho skriptu prez Rsync.

Skript smaze vsechna data, ktere jsou  v cilove slozce, ne vsak ve zdroji. Jenze ja zadal spatnou cestu ke zdroji, tudiz se smazali vsechny data, v backup, ktera tam mela byt.

A pak odkracel do haje disk se zdrojovymy daty .....

Prikaz ktery smaze vsechna data, co nejsou ve zdroji, ale jen v cili, kontroluje, zda je stejna verze souboru zdroj-cil pomoci kontrolnich souctu ne datum a cas, ukazuje prubeh zalohovani, omezena rychlost transferu:

Kód: [Vybrat]

rsync -ahvc -e ssh --delete --progress --bwlimit=5000k Zdroj_S_Cestou/ Cil_S_Cestou/


[t2000]

Výborné téma, taky přidám něco do placu, i když ne přímo související s IT:

Stalo se to před mnoha lety, v době, kdy jsme ve firmě postupně přeinstalovávali PC z Win98 na Win2000 současně s vyčistěním od prachu, takže jsme každý PC museli odpojit a odnést pryč. Toho dne přišla na řadu účtárna. Byl jsem tehdy ještě mladé ucho po VŠ a s kolegou jsme často dělali různé srandičky.
Vlítli jsme tedy do kanclu účetních po pracovní době, kdy tam již nikdo nebyl. Nejbližší PC byl položený na starém trezoru, jeho výška totiž byla na úrovni pracovního stolu. Kolega začal odpojovat kabely, ale mě nějak zaujal ten trezor. Koukám na to kolečko a říkám mu: "Já to zkusím heknout, viděl jsem to ve filmu, stačí přiložit ucho ke skříni a otáčet kolečkem, dokud to necvakne." Tak jsem i provedl, ale ať točím jak točím, žádné cvakání se neozývá. Zkoušel jsem tedy točit různými směry a mačkat, ale po nějaké době jsem to nakonec neúspěšně vzdal a šel raději pracovat.
Na druhý den ráno zvoní telefon z účtárny od vedoucího oddělení: "Nedělali jste náhodou včera něco s trezorem ? Nemůžeme se tam dostat a potřebujeme z něj hotovost pro platbu dobírek!" Já okamžitě automatická odpoveď: "Myyyy ? Vůůůůbééc." Nakonec se mi to nějak podařilo zamluvit, že jsem možná zavadil o to kolečko nohou, jak jsme sundávali ten PC. Ti troubové totiž používali k otevírání pouze klíč bez toho kódu, který nikdo neznal! A tak se s tím nesmělo hýbat, ale to jsem samozřejmně nevědel. No, skončilo to nakonec tak, že musel přijít zámečník, který to celé odvrtával. Platilo to pak technické oddělení, pod které spadalo i IT.

[M.]

No, vynechám průsery na území Česka (paní Drábová by žasla a laici zbytečně divili).
To tak přišel člověk ráno v Rusku do stojící atomové elektrárny a všichni na něj škaredě koukali...
Že jsme ji svoji chybou v noci odstavili (že jsme sejmuli komunikační systém s daty do krizového řizení, tak došlo k nucené odstávce, než se na to přišlo). V přislušnou dobu ale člověk ležel v baru pod stolem u X-té láhve koňaku s prvozním ředitelem té elektrárny je nepodstatný detail.
A pak nám příslušní lidé s milým úsměvem sdělili, že si to samozřejmě podělali sami, ale museli to hodit na nás, protože jako zahraniční experti dostaneme maximálně malý červený puntík do spisu u FSB, kdežto je by přímo zastřelili...

[Yokotashi]

Kdysi jsem dostal genialni napad, ze si ve $HOME na kazdem stroji udelam adresare $hostname kazdeho stroje v siti a navzajem je namountuju pres NFS. Tim uvidim vzdy vsechna data a budu si moci pohodlne vybrat, kam je ulozim.

Moc zasto nerebootuji a kdyz, tak maximalne jeden stroj, takze vsechno fungovalo perfektne. NFS bylo default v /etc/fstab, takze reboot jednoho stroje byl uplne v pohode.

Pak jednou vypadl proud.

Nastesti to nebyl produkcni system. Mel jsem to stesti nadelat dostatek pruseru na domaci siti, kde mi za to nemohl vynadat nikdo jiny, nez ja sam.

[pruserar]

Synology. Ve firme s 50 zamestnanci bylo sdilene uloziste s ACL, ktere lide pouzivali na sdileni dokumentu vcetne planovanych vyplat a dalsich zajimavych dokumentu. Nekoho napadlo updatovat Synology. To probehlo, vsechno na prvni pohled fungovalo. Az za mesic se kvuli jinemu bugu zjistilo, ze Synology prestalo kontrolovat prava i kdyz v GUI bylo vsechno v poradku. Kontrolu prav se nepovedlo obnovit i kdyz jsme zkouseli vsechny navody. Nakonec bylo treba preformatovat disky a zacit od zacatku.

Trezor. Vsechny dulezita hesla se napsala na papir jako zaloha, kdyby se neco stalo nebo by je bylo treba pouzit. To vcetne kodu k trezoru. Za delsi dobu nastal vypadek a bylo treba pouzit heslo z trezoru. Bohuzel kod vsichni zapomeli, tak bylo treba zavolat zamecnika.

Obnova dat. Castecna obnova nekolik zaznamu ze zalohy se pravidelne testovala. Prislo se na systematicke poskozeni dat, tak byla treba vetsi obnova. Bezna obnova uplne vytizila databazi na 100% tak ze ji nemohl pouzivat nikdo jiny a bezet nekolik dni bez DB proste neslo. Tak obnova trvala 3 mesice.

A-B test. V eshopu se casto delali A-B testy se zakazniky, tak se na to udelal framework a bezelo treba 20 experimentu najednou. Jeden experiment bylo par dni ponoukat x% zakaznikum zbozi za nakupni cenu. Experiment byl rozdelen na 2 casti a byla odstranena jenom ta zrejma cast. Zakaznik tak v nasem rozhrani videl plnou cenu, ale platba byla na mensi sumu. Toto bezelo dost dlouho, skoda byla v milionech.

Integracni testy. Chybou konfigurace se spustili integracni testy na produkcnich datech. Po skonceni testu si testy za sebou uklizeli smazanim testovacich dat. Jenomze to nebyli testovaci data.

Chmod. Kolega omylem udelal chmod -R 777 /. Tak jsem se ho zeptal, co to dela. A on to hned "fixnul" tim, ze zavolal chmod -R 700 /.