Sto cercando storie divertenti sugli incidenti dell'amministratore di sistema che hai avuto. Eliminazione dell'email del CEO, formattazione del disco rigido errato, ecc.
Aggiungerò la mia storia come risposta.
Sto cercando storie divertenti sugli incidenti dell'amministratore di sistema che hai avuto. Eliminazione dell'email del CEO, formattazione del disco rigido errato, ecc.
Aggiungerò la mia storia come risposta.
Risposte:
Mi sono divertito a scoprire la differenza tra il comando "killall" di Linux (uccide tutti i processi corrispondenti al nome specificato, utile per fermare gli zombi) e il comando "killall" di solaris (uccide tutti i processi e arresta il sistema, utile per arrestare il server di produzione in nel bel mezzo delle ore di punta e far ridere tutti i tuoi colleghi per una settimana).
hostname -f
su Linux stampa il nome di dominio completo su Linux. Su Solaris, imposta il nome host su -f
.
Mi occupavo del nostro proxy web aziendale che all'epoca era il prodotto di Netscape. Mentre giocavo nei moduli di amministrazione (era un'interfaccia basata sul web) c'era un grande pulsante (e giuro che era rosso) che diceva Elimina database utenti . Nessun problema, ho pensato. Vediamo quali sono le opzioni che mi dà quando lo colpisco. Sicuramente ci sarà una richiesta di conferma se non ci sono opzioni.
Sì, nessuna conferma. Nessuna opzione Non più utenti.
Quindi, è andato dal Sig. Solaris Sysadmin e ha detto che avevo un disperato bisogno di un ripristino dal nastro a cui ha risposto: "Non backup quella scatola".
"Uh, vieni di nuovo", ribattei.
"Non eseguo il backup di quella casella. È nella mia lista di cose da aggiungere alla rotazione del backup ma non ci sono ancora riuscito."
"Questo server è in produzione da quasi 8 mesi!" Ho urlato.
scrollata di spalle , rispose. "Scusate."
Molti anni fa la società per cui lavoravo aveva un client che eseguiva un backup notturno del proprio server NT 4.0 su un'unità Jaz (come un disco zip ad alta capacità).
Abbiamo impostato un file batch, che è stato eseguito come lavoro pianificato durante la notte. Ogni mattina raccoglievano il disco delle ultime notti dall'unità e prima di partire la sera inserivano il disco successivo nella sequenza.
Ad ogni modo, il file batch era simile al seguente (l'unità Jaz era l'unità F:) ...
@echo off
F:
deltree /y *.*
xcopy <important files> F:
Ad ogni modo, una notte si sono dimenticati di inserire il disco. La modifica all'unità F: non riuscita (nessun disco nell'unità) e il file batch ha continuato a essere eseguito. La directory di lavoro predefinita per il file batch? C :. La prima volta che ho visto una routine di backup distruggere il server di cui stava eseguendo il backup.
Quel giorno ho imparato qualcosa sul sysadminning (e sulla gestione delle eccezioni).
Jim.
PS: la correzione? "deltree / y F: \ *. *".
root @ dbhost # find / -name core -exec rm -f {} \;
Io: "Non riesci a entrare? OK. Qual è il nome del DB?"
Cu: "Core".
Io: "Oh".
Adoro il modo in cui tutti qualificano la loro storia con "quando ero giovane / verde" come se non l'avrebbero mai più rifatta. Gli incidenti possono capitare anche ai professionisti più esperti.
Il mio peggior momento è così brutto che ho ancora palpitazioni a pensarci ...
Avevamo una SAN con dati di produzione su di essa. Critico per l'azienda. Il mio "mentore" ha deciso di estendere una partizione per liberare spazio su disco. Riesci a vedere dove sta andando? Ha detto che il software SAN potrebbe farlo dal vivo, nelle ore di produzione e nessuno se ne accorgerebbe. I campanelli d'allarme avrebbero dovuto iniziare a suonare, ma erano visibilmente silenziosi. Ha detto di averlo fatto "un sacco di volte prima" senza problemi. Ma ecco il punto: mi ha fatto fare clic sul pulsante che diceva "sei sicuro?"! Dato che ero nuovo della compagnia, pensavo che questo ragazzo sapesse di cosa stava parlando. Grosso errore. La buona notizia è che il LUN si è esteso. La cattiva notizia era ... beh, sapevo che c'erano brutte notizie quando ho iniziato a vedere gli errori di scrittura del disco sulla finestra di Windows.
Sono contento di indossare pantaloni marroni.
Abbiamo dovuto spiegare perché 1 TB di dati era scomparso all'ora di pranzo. È stata una giornata davvero brutta.
In realtà è un buon principio: prima di fare qualcosa di cui hai dei dubbi, immagina di dover spiegare al management se qualcosa va storto. Se non riesci a pensare a una buona risposta per spiegare le tue azioni, allora non farlo.
Nagios ci ha telefonato una mattina quando l'orario di lavoro ha iniziato a dire che non poteva connettersi a un server non critico. Ok, fai un'escursione nella sala server. È un vecchio server, un Dell 1650 acquistato nel '02, e sapevamo che i 1650 avevano problemi hardware. Il PFY accoltella il pulsante di accensione. Niente. Colpiscilo di nuovo e tienilo premuto per cinque secondi per "forzare l'accensione" ... il che sovrascrive la protezione degli errori del BMC, poiché senza un DRAC non c'è modo di esaminare i registri BMC senza avere l'alimentazione allo chassis.
La macchina avvia POST, quindi muore di nuovo. Sto sopra di esso e dico "Sento odore di fumo". Tiriamo fuori il server dai suoi binari e uno degli alimentatori sembra caldo, quindi il PFY lo estrae e sta per chiudere la scatola. Dico "No, non è fumo dell'alimentatore, è fumo della scheda madre".
Apriamo di nuovo il caso e cerchiamo la fonte dell'odore bruciante. Viene fuori una bobina di induttore e un condensatore qualcosa ha fatto esplodere il regolatore di tensione sulla scheda madre e ha spruzzato rame fuso e condensatore goop su tutto, mettendo in corto circuito un sacco di cose e fondamentalmente facendo un gran casino.
La parte peggiore per me era riconoscere che avevo fumato abbastanza hardware per riconoscere la differenza tra l'odore di una scheda madre bruciata e un alimentatore bruciato.
Tre giorni fa (seriamente) sono stato effettuato l'accesso remoto a un server scolastico, installando Service Pack 2 su un file server Windows Server 2008.
Ho deciso di pianificare il riavvio necessario per la sera tardi, quando gli insegnanti non avrebbero effettuato l'accesso per finire le pagelle di fine anno. Ho scritto qualcosa del tipo:
alle 23:59 "shutdown -r -t 0"
... che potrebbe aver funzionato bene.
Ma poi ho indovinato me stesso. La sintassi del mio "arresto" era corretta? Ho provato a visualizzare la guida all'uso digitando
spegnimento / h
... e ho perso immediatamente la mia connessione RDP. Nel panico, ho colpito Google per la sintassi. Una rapida ricerca ha rivelato che la versione Server 2008 di shutdown include un parametro / h, che (come avrete intuito) va in letargo sulla macchina.
Gli insegnanti hanno iniziato a chiamarmi in pochi minuti per segnalare che non potevano più aprire o salvare le pagelle su cui stavano lavorando. Dato che ero fuori sede e la sala server era chiusa a chiave, ho dovuto chiamare direttamente il preside della scuola e guidarla attraverso il processo di riaccensione della macchina.
Oggi ho portato biscotti fatti in casa a tutti come una forma di scuse.
/?
primo!
man shutdown
. So che non causerò problemi con man
!
In un precedente lavoro, disponevamo di un ottimo sistema locale che registrava e archiviava ogni singolo pezzo di posta che entrava, usciva o rimaneva all'interno dell'azienda.
Hai spazzato via tutta la tua casella di posta? Nessun problema! Alla ricerca di un pezzo di posta che qualcuno ti ha inviato una settimana / mese / anno fa ma non ricordi chi lo ha inviato o quale fosse l'oggetto? Nessun problema! Restituiremo tutto da febbraio per te in una cartella speciale.
Ad un certo punto, è emersa la necessità che l'amministratore delegato dell'azienda monitorasse la posta tra un concorrente e un venditore interno sospettato. Quindi abbiamo impostato uno script che è stato eseguito ogni notte e consegnato la posta pertinente dal giorno precedente al CEO. Nessun problema!
Circa un mese dopo la notizia di un doppio e più urgente problema arrivò dall'alto. Sembra che mentre il CEO stava leggendo l'elenco delle mail inviate a $ OTHERCOMPANY, si fosse imbattuto in questo:
To: somebody@$OTHERCOMPANY
From: CEO
Subject: CEO has read your message (subject line here)
Naturalmente, essendo il CEO una persona importante e tutto il resto, era troppo impegnato per fare clic su tutte quelle finestre di dialogo "Invia ricevuta di lettura" in Outlook e aveva configurato il suo client per inviarle tutte. Uno dei messaggi catturati dal filtro di monitoraggio aveva una richiesta di conferma di lettura impostata. Indovina cosa ha fatto Outlook? Certamente risolto il monitoraggio "clandestino".
Il nostro prossimo compito: aggiungere regole al filtro di posta per bloccare le conferme di lettura in uscita dal CEO a quella società. Sì, è stato il modo più semplice. :)
Ah, il mio era circa 10 anni fa, quando mi stavo ancora bagnando i piedi. Ho avuto la gioia di installare i backup della batteria su tutti i computer dei programmatori. Volevano anche che il software fosse caricato per avvertire di mancanza di corrente e spegnersi correttamente.
Quindi l'ho installato sul mio computer per testare tutto prima ovviamente e assicurarsi che tutto funzionasse. Quindi scollego il cavo di alimentazione e il messaggio appare sullo schermo. msgstr "alimentazione esterna persa, avvio arresto del sistema".
Quindi ho pensato, Hey, ha funzionato. Ma per qualche strano motivo, non ricordo nemmeno, ha inviato quel messaggio come un messaggio di rete, quindi tutti i 200+ computer dell'azienda hanno ricevuto quel messaggio, dove 100+ utenti erano programmatori.
Sì, parla di fuori di testa !!
Ho tenuto la testa bassa in quel posto per un po '!
Userei spesso il comando "sys-unconfig" sulle macchine Solaris per ripristinare il servizio Nome macchina, l'indirizzo IP e la password di root. Ero su un sistema di utenti e ho effettuato l'accesso al server di installazione dell'edificio e ho cercato qualcosa (come root), dimenticando di aver effettuato l'accesso a un'altra macchina (prompt "#" non descrittivo) Ho eseguito il comando "sys-unconfig".
# sys-unconfig
WARNING
This program will unconfigure your system. It will cause it
to revert to a "blank" system - it will not have a name or know
about other systems or networks.
This program will also halt the system.
Do you want to continue (y/n) ? y
Connection closed
#
Quel messaggio "connessione chiusa" si trasformò lentamente in panico ... a quale macchina ero connesso quando ho eseguito quel comando.
La parte peggiore di questo non è stato il momento difficile che i miei colleghi mi hanno dato, è stato che ho fatto la stessa cosa un mese dopo.
Ne ho una abbastanza buona. Certo, era prima del mio tempo come amministratore di sistema, ma era ancora legato alla tecnologia, quindi ho pensato di aggiungerlo.
All'epoca lavoravo come tecnologia satcom / a banda larga per l'USAF. Dopo essermi laureato in una scuola tecnica, mi sono trovato di stanza in Corea del Sud. Poco dopo l'arrivo in stazione, si presentò l'opportunità di viaggiare a sud con i "grandi" che erano stati lì per un po 'di tempo e di lavorare effettivamente su alcune attrezzature del mondo reale (cioè "produzione").
Sono andato giù con l'equipaggio e come un giovane tecnico impaziente, si stava rilassando un po ', abbastanza eccitato dalla prospettiva di mettere le mani su un vero pezzo di equipaggiamento che stava passando il traffico di voce e dati militari LIVE.
Per iniziare lentamente, mi hanno consegnato un manuale, si sono rivolti alla sezione di manutenzione preventiva e mi hanno indicato nella direzione di quattro rack pieni di molti grandi multiplexer digitali. L'attrezzatura era abbastanza facile, avevamo coperto la stessa attrezzatura nella scuola di tecnologia.
Prima pagina del manuale letto; "Alimentare il multiplexer ditigale. Ruotare entrambi gli interruttori posteriori in posizione ON e attendere l'accensione dell'apparecchiatura, quindi iniziare i test." Alzai lo sguardo e c'era già il potere APPLICATO!
Ero sicuramente in un dilemma. Non sapendo come procedere, ho fatto del mio meglio, "Ummmm .. Kinda perso qui", guarda il senior.
Mi guardò e rise: "No, no, va bene. Puoi ignorare quella parte della lista di controllo." Poi, quando notò lo sguardo sul mio viso, (dato che a scuola ci hanno insegnato MAI, MAI ignorato qualsiasi parte di una lista di controllo, ed era certo morte e distruzione se si dovesse farlo) ha dato uno sguardo serio al suo faccia e disse: "Ignora SOLO quella parte! Segui il resto, fino alla lettera!"
Devo dire che ho seguito le istruzioni in più passaggi del PM, felice come una vongola e orgoglioso di aver permesso a una tecnologia di così basso livello (anche se intelligente) di svolgere questo importante lavoro.
Tra la quinta e la sesta lista di controllo per la manutenzione preventiva su questi enormi multiplexer ho iniziato a notare un aumento del livello di attività attorno a me. I telefoni squillavano, le persone si muovevano rapidamente. Si stavano scambiando sguardi interrogativi.
Alla fine, un gruppo di persone mi è corso incontro, guidato da uno dei tecnici senior che mi aveva abbattuto.
"Ehi! Stiamo vedendo enormi interruzioni nel traffico dati e abbiamo isolato / tracciato il percorso di ritorno ai rack su cui stai lavorando! Stai vedendo qualcosa di strano .."
(A quel punto fu interrotto da un altro degli addetti alla risoluzione dei problemi che si erano fatti strada verso il primo gruppo di multiplexer su cui avevo eseguito i PM.)
"NOCI SANTE! SONO SPENTI! STATI SPEGNENDO !!!!"
In breve tempo, ho guardato mentre correvano frettolosamente attraverso il primo passo del manuale, "Girare entrambi gli interruttori posteriori in posizione ON ..." Quando la tecnologia senior fu finita, si avvicinò a me e mi chiese incredulo cosa stavo pensando di, spegnendo le apparecchiature critiche.
Spaventato dal mio ingegno, gli consegnai la lista di controllo che stavo seguendo, giurando che non avevo deviato affatto. Che l'avevo seguito, "alla lettera" come aveva ordinato.
Dopo un po 'rise e indicò dove si trovava il problema.
Nel manuale, la fase FINALE nell'elenco di controllo della manutenzione preventiva era:
"Registrare la lettura finale della sonda, pulire il pannello anteriore, rimuovendo tutta la polvere e il particolato, quindi portare entrambi gli interruttori di alimentazione posteriori in posizione OFF."
:)
È una specie di incidente di amministratore di sistema ... nella misura in cui gli amministratori di sistema devono occasionalmente trasportare fisicamente un gran numero di macchine dal punto A al punto B (dove A e B sembrano essere sempre separati da diverse rampe di scale in un edificio senza ascensore). Durante l'ennesima gita della giornata, mi sono fermato per un attimo di tre voli su dal piano di carico del seminterrato per chattare con qualcuno che stava scendendo, ho appoggiato la torre a grandezza naturale con la stazione che stavo schizzando sul corrimano interno del vano scala aperto e ... beh, hai indovinato ... leggermente perso la presa su di esso. Si immerse infallibilmente dritto nel pozzo e quando raggiunse il fondo, ehm ... non tanto con la funzionalità di quello! Parti totalmente recuperabili: due stick di RAM, un floppy drive e una scheda ISDN (Dio benedica la gente dell'ingegneria di Hermstedt!). Tutto il resto o si è rotto,
Per grazia di Dio, nessuno camminava sotto, il che, per fortuna per me, è stato il primo del mio capo, quindi ho dovuto mantenere il mio lavoro. Però mi sono sentito molto male per circa un'ora.
Morale: la gravità vince sempre!
Stavo ricaricando un sistema per qualcuno e durante il processo di backup manuale gli ho posto la domanda "Hai altri programmi che usi?" e "C'è qualcos'altro di importante che fai sul computer?"
Ha detto "no" SEVERAL volte.
Ero convinto e formattato l'unità.
Circa 30 minuti dopo ha detto "oh mio dio" e gli ha messo entrambe le mani in testa.
Si scopre che ha lavorato alla sceneggiatura di un libro per oltre 10 ANNI in un programma specializzato. Questo era quando i programmi usavano per salvare i dati dell'utente nella sua directory dei file di programma e mi mancava.
Whhhhooooops.
Non era arrabbiato con me, ma era una sensazione rassicurante.
Il mio preferito personale non è in realtà il mio, e ne sono MOLTO felice. Dai un'occhiata qui.
Questo non è successo a me, ma ...
Lavoravo in un'azienda che produceva software che funzionava su macchine Linux fornite dal client. Sostanzialmente 'prenderemmo il controllo' delle macchine, le configureremmo completamente secondo le nostre specifiche e faremmo tutta la gestione e il monitoraggio. In sostanza, eravamo un team di 10-15 amministratori di sistema, in grado di gestire migliaia di server per centinaia di clienti. Gli errori dovevano succedere.
Uno del nostro team ha riscontrato alcuni problemi su un server (un backup, credo) e ha deciso che avrebbe dovuto eseguire fsck su di esso. Ha interrotto tutti i servizi rilevanti, si è assicurato che il sistema fosse stato sottoposto a backup di recente, quindi ha eseguito fsck, ma si è lamentato del fatto che il filesystem fosse montato. Dato che eravamo remoti e non avevamo accesso remoto (DRAC, ILO, ecc.), Non poteva fare l'sck, ma era abbastanza sicuro che sarebbe stato sicuro farlo con il filesystem montato, se stavi attento.
Ha deciso di provarlo da solo eseguendo fsck sulla sua partizione di root, con risultati prevedibili: ha corrotto la sua partizione di root e non è più riuscito ad avviarsi.
Confuso, si avvicinò e parlò con il capo della nostra squadra. Il lead ha detto che era abbastanza sicuro che non potevi farlo, e il membro del team ha detto 'Certo che puoi!', Ha preso la tastiera del lead e gli ha mostrato che puoi - eseguendo fsck sulla partizione root del lead. Che ha completamente danneggiato la sua partizione root HIS.
Risultato finale? Nessun dato perso dai clienti, grazie ai test dei membri del team. Sono stati persi due giorni di produttività dei dipendenti, ma ciò valeva molto, molto meno dei dati sulla macchina del cliente. E per la cronaca? È possibile eseguire fsck su un'unità montata, ma solo per verificare i dati. Non ripararlo. Questo è stato l'errore del membro del team.
-
Per aggiungere la mia storia, lavoravo nella stessa azienda e cercavo di reimpostare una password utente. Il nostro sistema ha rifiutato di consentirmi di impostarlo sulla password di cui aveva bisogno, perché ha tracciato gli hash delle password precedenti e si è rifiutato di consentirti di duplicare la password. Il meccanismo era semplice: ha convalidato la tua password rispetto all'hash più recente nel database.
(E per la cronaca, doveva essere la vecchia password perché era un account condiviso e assicurarsi che tutti sapessero che la nuova password non era pratica)
Ho deciso di andare nel database degli utenti ed eliminare i nuovi record in modo che usasse quello più vecchio. È tutto solo SQL (che esegue una versione antica di Sybase), quindi è facile. Innanzitutto, ho dovuto trovare i record:
SELECT * FROM users_passwords WHERE username='someuser';
Ho trovato il vecchio disco che voleva conservare; ce n'erano altri due davanti. Ho deciso di essere intelligente e di eliminare qualsiasi cosa più recente del vecchio disco. Guardando il set di risultati, ho visto che la vecchia password era l'ID # 28 nel database e le nuove erano l'ID #superimila (sistema molto occupato). È semplice, tutte le vecchie righe erano> 28, quindi:
DELETE FROM users_passwords WHERE id > 28;
Non c'è niente di peggio che fare una semplice potatura delle file e vedere "212.500 righe interessate". Fortunatamente, avevamo due server di database master (con ID utente), ma Sybase (almeno, la nostra versione) non supportava la replica automatica, quindi non cancellava automaticamente i vecchi record. È stato banale ottenere un dump della tabella users_passwords e reimportarlo. Comunque, un 'oh f ** k!' Piuttosto grande momento.
Un altro dei miei preferiti:
Quando ho installato un computer e una stampante laser locale su un sistema, ho avuto la brillante idea di collegarli entrambi all'UPS del computer. Hai mai provato a stampare su una stampante laser locale quando è collegato a un UPS desktop? Bene, se non lo sai, tende a tirare tutti gli amplificatori ... Il che riavvia il computer ... E il lavoro di stampa non finisce mai ...!
Ricevi sempre la chiamata: ' Ogni volta che stampo, riavvia il mio computer e non stampa !!! '?
Ops!
JFV
Dichiarazione DELETE senza una clausola WHERE, nel database degli utenti attivi dei clienti.
Digitato kill 1
come root. init
e tutti i suoi figli sono morti. E tutti i loro figli. ecc. ecc.
Quello che intendevo scrivere era kill %1
Dopo aver realizzato quello che ho fatto, sono corso al pannello di controllo di una GRANDE selezionatrice di balle di lana e ho premuto il pulsante di arresto di emergenza. Ciò ha impedito alla macchina di strapparsi in pezzi, poiché avevo appena ucciso il software che lo controllava.
Eravamo nel mezzo di un'interruzione di corrente e abbiamo visto che l'UPS funzionava al 112% del carico configurato. Questo non era un grosso problema dato che stavamo correndo sul generatore in quel momento.
Quindi andammo in giro tirando i cavi di alimentazione di backup per ridurre il consumo di energia su quell'UPS (ne avevamo due, uno molto più grande dell'altro). Siamo arrivati allo switch di rete che gestiva la sala server (questa era la sala server con tutti i server interni dell'azienda, con i clienti che affrontavano i server in un'altra sala server). Lo switch era un grande switch di classe enterprise con tre alimentatori. Le forniture erano N + 1, quindi ne avevamo bisogno solo due per far funzionare l'interruttore.
Abbiamo preso un cavo e lo abbiamo estratto. Sfortunatamente per noi gli altri due sono stati collegati a una singola ciabatta, che è esplosa prontamente quando il carico è salito sui due alimentatori che sono stati collegati. Quindi l'amministratore di sistema è entrato nel panico e ha inserito il terzo cavo. L'interruttore ha tentato di accendersi, mettendo l'intero carico dell'interruttore sul singolo alimentatore. Invece di interrompere l'alimentazione elettrica, esplose in una pioggia di scintille a non più di 12 pollici dalla mia faccia, facendomi tornare indietro nel rack di server.
Per istinto ho provato a saltare di lato, ma purtroppo alla mia sinistra c'era un muro, e due alla mia destra era un ragazzo di 6'4 "molto grande. Sono riuscito in qualche modo a saltargli addosso, o forse a farlo rimbalzare via dei rack Compaq (quelli con i frontali a maglie sottili) senza mettere un intero nel rack e senza toccare il ragazzo delle strutture.
Ad un certo punto della mia carriera, un'indagine legale presso la società per la quale lavoravo ci imponeva che tutte le e-mail fossero conservate da "questo giorno" in avanti, fino a quando diversamente indicato. Dopo circa un anno di archiviazione dei backup completi giornalieri del nostro ambiente di scambio (1 TB ogni notte) abbiamo iniziato a rimanere senza spazio.
Gli amministratori dello scambio hanno suggerito di conservare solo ogni ottava copia dell'email. Per fare ciò, abbiamo dovuto ripristinare i database di scambio per un periodo di giorni, estrarre l'e-mail di cui avevano bisogno (persone specifiche contrassegnate per le indagini) e archiviarlo nuovamente. Lo hanno fatto per ogni 8 ° giorno di posta elettronica per tutti i nostri backup. L'ottavo giorno è stato scelto perché Exchange aveva un set di parametri in cui "elementi eliminati" sono conservati nel database per 8 giorni.
Dopo aver terminato ogni archivio, tornavo indietro ed eliminavo tutti i backup più vecchi di quelli che avevano archiviato.
TSM non ha un modo semplice per farlo, quindi è necessario eliminare manualmente gli oggetti dal database di backup.
Ho scritto uno script che eliminerebbe tutti i backup più vecchi di una data, mediante un calcolo della data usando la differenza tra oggi e la data in questione. Un giorno ho dovuto cancellare circa un mese di backup, tranne quando ho fatto il calcolo della data, ho fatto un refuso e ho inserito la data come 7/10/2007 anziché 6/10/2007, ed eseguito lo script. Ho cancellato un intero mese di dati in più, accidentalmente che faceva parte di una causa molto importante.
Successivamente, ho aggiunto alcuni passaggi allo script per confermare che si desidera eliminare i dati e mostrarti cosa stava per eliminare ...
Fortunatamente, non hanno nemmeno mai usato nessuno dei dati che abbiamo lavorato così duramente per preservare, e ho ancora il mio lavoro.
Dopo una lunga giornata o un tracciamento delle prestazioni e l'ottimizzazione di un enorme mainframe (sai che le bestie che impiegano un paio d'ore prima che tutti i siti di backup in standby abbiano concordato che è effettivamente riavviato e completamente sincronizzato) Ho allungato le dita, digitato spegnimento soddisfatto -p ora nel prompt del mio laptop, chiuso il coperchio, strappato il cavo seriale dal mainframe, con l'anticipazione di un bel bicchiere freddo di birra chiara.
Improvvisamente sento il suono assordante di far girare il mainframe mentre il mio laptop mostrava ancora felicemente X.
Mentre aspettavo che la macchina tornasse completamente online, ho deciso di avere il tempo di far funzionare il mio ACPI sul mio laptop in modo da non essere mai tentato di spegnere il mio laptop.
Questo incidente non si è verificato ... ma vale la pena ricordare:
Sono stato inviato a un data center molto utilizzato per condurre test di larghezza di banda su un nuovo circuito. Sono arrivato alla sala demarc / IDF, ho trovato un posto su uno degli scaffali per il mio router di prova, ho effettuato i miei collegamenti e ho iniziato i test. Sfortunatamente, non sono riuscito a notare che il router di frontiera in produzione non si trovava esattamente sul rack successivo (quasi allo stesso livello), ma che aveva anche la stessa marca e modello del mio router di test.
Quando il test è stato completato, ho iniziato a premere l'interruttore di accensione in posizione off (... immaginalo al rallentatore ...) e, lo giuro, mentre stavo applicando la pressione mi sono reso conto che il router che stavo per spegnere era quello in produzione. Il mio cuore si è fermato e quasi ... beh, uso la tua immaginazione.
Ho lasciato il MDF del data center spaventato e pallido, ma allo stesso tempo felice di avere ancora un lavoro!
Ho cancellato l'account di qualcuno per errore, ho confuso i nomi con quello che volevo eliminare. Opps
Il bello è che non hanno mai saputo cosa è successo. Ho ricevuto la chiamata a cui non potevano accedere, il centesimo è caduto sull'account che ho eliminato.
Mentre ero al telefono con loro, ho ricreato rapidamente il loro account, ho ricollegato la loro vecchia cassetta postale (per fortuna Exchange non cancella subito le cassette postali) e l'ho ricondotto ai loro vecchi file utente.
Poi li ho accusati di aver dimenticato la loro password che avevo appena ripristinato per loro :)
Ho accidentalmente installato un file tar.gz sulla mia scatola Gentoo Linux nel posto sbagliato e ha lasciato i file ovunque. Questo deve essere stato intorno al 1999, all'epoca 19 (grazie per i commenti qui sotto)
Essendo il geek che sono, ho deciso di provare a copiarmi dal lavoro di sfogliare manualmente ogni file.
Quindi ho provato:
tar --list evilevilpackage.tar.gz | xargs rm -rf
Non mi ci è voluto molto tempo per notare che tar elencava anche tutte le directory utilizzate dal programma, quelle incluse erano '' / usr, / var, / etc '' e alcune altre che non volevo davvero andare.
CTRL-C! CTRL-C! CTRL-C! Troppo tardi! Tutto finito, reinstalla il tempo. Fortunatamente la scatola non conteneva nulla di importante.
Come parte piccola della mia vita precedente ho amministrato il file server dell'azienda, una scatola 4:11 di netware. Non ha quasi mai avuto bisogno di alcun input, ma se lo ha fatto, hai aperto una finestra della console remota.
Abituato a usare il DOS continuamente, quando avevo finito, naturalmente scrivevo "Esci". Per Netware, "exit" è il comando per arrestare il sistema operativo. Fortunatamente, non ti farà chiudere a meno che tu non abbia prima "Down" il server (rendilo non disponibile per la rete / i client) Quindi quando digiti "Esci" nella console, ti viene utile dire "Devi prima digitare" Giù "prima di poter uscire"
Chiedimi quante volte ho 1: ho digitato "exit" nella sessione della console e 2: Obbedientemente ho digitato "Down" e poi "Exit" in modo da poter "finire quello che stavo cercando di fare"
E poi il telefono inizia a squillare .....
LOL
Un'altra storia che non è accaduta (phew):
Ogni giorno eseguivamo backup incrementali su un'unità nastro.
Ci è capitato di scrivere un nastro contenente i dati da spedire a qualcun altro. Dissero "non possiamo leggere il tuo nastro". In realtà, nemmeno noi. O qualsiasi nastro in effetti.
Abbiamo acquistato un'altra unità nastro e abbiamo trattenuto il respiro fino a quando non l'abbiamo installata.
Morale della storia. Assicurati sempre di testare i tuoi backup.
L'ultimo posto in cui ho lavorato, il mio collega aveva i suoi figli con sé nella sala server (perché? Non ho IDEA!).
Si è assicurato che fossero lontani dai server e ha spiegato al suo bambino di 5 anni che non avrebbe dovuto toccare QUALUNQUE server e Sicuramente nessuno degli interruttori di alimentazione.
In effetti, li aveva proprio vicino alla porta ... (riesci a vedere dove sta andando ...?)
Il ragazzo non ha toccato nessuno dei pulsanti di accensione del server ... No, sarebbe del tutto troppo facile da spiegare. Invece ha colpito il GRANDE PULSANTE ROSSO che era vicino alla porta ... Il pulsante che interrompe l'alimentazione all'INTERA SALA SERVER !!!
Le linee telefoniche iniziarono immediatamente a illuminarsi chiedendosi perché Exchange, File Server, ecc. Non fossero disponibili ... Immagina di provare a spiegarlo al CEO!
-JFV
Una volta ho litigato con il software di monitoraggio UPS APC. Essendo una piccola azienda, avevamo un paio di piccoli UPS e vari server erano configurati per monitorarli. La maggior parte dei server erano Linux, ma alcuni eseguivano Windows e quindi erano quelli utilizzati perché il software APC è solo Windows.
Tuttavia, il software APC all'epoca era codificato per dare per scontato che l'UPS con cui stava parlando alimentasse anche il suo PC! Questo non era il caso di questo server, ma l'ho scoperto troppo tardi per dirlo di fermarsi. Inoltre, sfortunatamente, il programmatore principale stava dimostrando il prodotto dell'azienda a un partner: era un'app basata sul Web, in esecuzione sullo stesso server in cui non volevo che il software APC si spegnesse ...
Stavo dando a un nuovo amministratore di sistema un tour di un'app Service Manager. Ho detto "se mai avessi bisogno di interrompere questo servizio, faresti clic su questo pulsante, ma non dovresti mai farlo durante il giorno". Non crederesti mai quanto fosse sensibile il suo pulsante del mouse!
Due minuti dopo il servizio era ripartito e nessuno sembrava accorgersene.
Inciampando su un server tower che era incastrato dietro un rack e colpendo la mia testa sul retro del router principale Cisco mentre scendevo. Rivelando così quanto vagamente i cavi di alimentazione fossero effettivamente alloggiati negli alimentatori sulla parte anteriore del Catalyst 6500 .
Si. Adesso abbiamo un elmetto protettivo agganciato nella sala server. Con il mio nome sopra.