Peggior incidente di Amministratore di sistema [chiuso]


8

In linea con la domanda sul miglior incidente di amministratore di sistema , qual è il peggior incidente in cui sei stato coinvolto? A differenza della domanda precedente, intendo "peggio" nel senso della maggior parte dei danni al sistema o dei danni reali alle persone.

Inizierò con il mio:

Abbiamo due armadi elettrici remoti che si trovano alla fine di un corridoio di 100 piedi che ha una griglia metallica per il pavimento. Dopo aver installato il cavo Cat6, gli appaltatori hanno ripulito tutti i detriti che sono caduti attraverso la griglia sul cemento 3 piedi più in basso. Un collega ed io siamo entrati nel corridoio per verificare i progressi un giorno, ma eravamo distratti e non ci siamo accorti che un pezzo di grigliato era stato spostato da parte. Il mio amico entrò in aria e il suo petto sbatté contro la traversa d'acciaio. Era tortuoso e abbastanza doloroso da prendersi un paio di giorni liberi, ma per fortuna la trave d'acciaio aveva bordi arrotondati e le dimensioni dell'apertura erano tali da non schiacciarci la testa o il pavimento sottostante.

Ovviamente abbiamo appreso che le aree in cui il pavimento è parzialmente rimosso devono essere contrassegnate.


1
Questo dovrebbe essere impostato su wiki della comunità
Joe,

Risposte:


1

Immagina se vivrai nel sud della Florida durante l'uragano Andrew (leggermente prima della mania del 24X7). Tutti i server sono bloccati in modo sicuro in un edificio che richiede l'inserimento del badge al suo interno e un'area più sicura che richiede un'ulteriore scansione del badge. Immagina un idiota che non tiene conto della necessità di avere delle vere maniglie sulle porte. Immagina un contratto da quattro milioni di dollari che richiede una consegna, l'elettricità più vicina è 230 miglia a nord, il gas scarseggia, strade pericolose e un generatore progettato per fornire 48 ore di elettricità. Ridi se vuoi che una raccolta di server si trovi sul retro di un camion, bloccata sull'autostrada del Topolino, bloccata per mancanza di gas. Ridi se ti mancherà la totale mancanza di una scusa per quanto tutto sia andato male dal punto di vista logistico, di sistema e operativo.


17
Uuuh, per favore, non prenderla nel modo sbagliato, ma non ho idea di cosa sia realmente successo nella storia, a causa di tutti i "Laugh Ifs" ...
Mark Henderson,

1
È divertente, mi piace la parte del generatore di 48 ore. Un posto che ho controllato una volta aveva 48 ore di carburante sul posto e altri 14 giorni nel cortile di servizio e possedevano un camion di carburante per riempire il generatore, quindi non dovevano contare su nessun altro. Erano anche una compagnia idroelettrica.
SpaceManSpiff,

Pur non essendo una narrazione ... l'intera storia è sopra.
ojblass,

Il camion del carburante è un'idea intelligente. L'anno scorso ho visitato un datacenter di Seattle che aveva solo pochi giorni di gasolio in loco. Non sono rimasto impressionato: solo una volta in circa 40 anni il sistema di autobus di Seattle è mai stato chiuso per un giorno, e ciò è dovuto principalmente ai camion del carburante che non si sono presentati alle basi per fornire gasolio durante un grande evento di neve. Non riesco a immaginare che un grave terremoto, inondazione o altri disastri regionali renderebbero il carburante più disponibile di una tempesta di neve.
Skyhawk,

25

Quando lavoravo per Cisco, ero solito ottenere clienti che avevano acquistato carte wireless da $ 30 e che sputavano chip quando il loro driver non si installava, o persone con il router più economico di base che avevano Cisco che volevano rovinare i problemi di supporto.

Tutto questo è stato messo in contesto un giorno, quando ho ricevuto una chiamata da uno dei maggiori fornitori di carte del mondo (penso Amex, Mastercard, Visa, Diners ... in effetti era uno di quei marchi, non so se loro mi farebbe piacere menzionarlo). Ero un supporto in prima linea, il mio unico lavoro era valutare lo scenario, valutarlo e trasmetterlo alla divisione di supporto appropriata. Questo caso è stato l'unico caso prioritario che abbia mai affrontato.

Un uomo della compagnia di carte chiamò e dichiarò che il loro legame tra i loro mainframe della costa orientale e occidentale era inattivo. Se un account è stato creato su un mainframe, la transazione è stata sempre elaborata su quel mainframe. Il che andava bene se il tuo collegamento più vicino era sempre vicino a quel mainframe. Ma in questo particolare giorno, se avessi un account sul server della costa orientale, ma ti trovassi nella costa occidentale, la transazione verrebbe negata perché il collegamento era inattivo.

La domanda standard nella valutazione del danno era "Quanto costa questo alla tua azienda?" La risposta, calma e raccolta, fu "Circa un milione di dollari ogni 30 secondi".

Lo mette davvero nel contesto la prossima volta che ti viene la tentazione di invocare e rave al supporto clienti tramite la tua scheda wireless da $ 30.

(va notato che Cisco aveva il suo link attivo e funzionante entro 5 minuti dal trasferimento)


3
Questa è probabilmente l'unica risposta onesta a quella domanda che sentirai mai!
SpaceManSpiff,

6
Questo è il modo più bello che abbia mai sentito qualcuno dire "smetti di fare domande stupide e correggilo ADESSO ". Soprattutto al supporto tecnico.
Ernie

10

È molto comune ai comandi alias come rm o mv per aggiungere l'opzione '-i' per evitare errori. Ma questo è successo nella mia compagnia qualche tempo fa. Qualcuno ha inserito questa riga nel .bashrc di root in uno dei server.

alias rm='rm -i'

Quindi ha copiato la riga e ha sostituito rm con mv ... o almeno così ha pensato:

alias rm='rm -i'
alias mv='rm -i'

Il resto è storia :)

Bene, la cosa è che quando hai la domanda "sei sicuro", hai detto "rimuovi" invece di "sposta" ma ancora ...


Sono così dispiaciuto amico ... il comando di storia non ti aiuterebbe nemmeno a trovare il grosso veleno che ti sei procurato.
ojblass,

4

Stavamo installando un enorme sistema Point of Sale presso un grande rivenditore (oltre 1000 filiali). Il server di polling centrale era tutto codice HP-Unix personalizzato e il test per la migrazione della produzione era gestito da un solo ragazzo, il figlio del direttore IT.

Questo ragazzo ha trascorso 7,95 ore della sua giornata a leggere romanzi fantasy, e gli altri pochi minuti eseguendo il suo lavoro batch per migrare le costruzioni notturne alla produzione. Il sistema è stato messo in funzione a 3 giorni da 150 filiali (il nostro primo "vero" lancio). Tutto era pronto e il mio team aveva appena finito di testare gli ultimi pezzi di codice. Abbiamo commesso le modifiche e spostato le immagini dallo sviluppo al test per essere raccolte dal figlio del direttore IT la mattina successiva.

Arrivo alle 8:00 e tutto è nel caos. Si scopre che al figlio era stato detto che dopo aver copiato i file in produzione, avrebbe dovuto andare nella cartella ./changed e digitare "rm -rf *". Sì, qualcuno gli ha detto questo! Naturalmente, lo ha fatto accidentalmente sull'unità root di produzione, che ospitava anche il nostro database di polling transazionale (che al momento non era in linea per i backup, solo per fortuna).

Risultato: i nostri 16 negozi pilota hanno dovuto servire i clienti dalle scatole di sigari (in alcuni casi, letteralmente) per 2 giorni. Il figlio del CIO è stato retrocesso a Server Watcher (era seduto nella fredda sala server e avrebbe dovuto sorvegliare le luci rosse ... ma non gli era permesso di toccare nulla ... non gli hanno nemmeno dato un computer e revocato tutti i suoi accessi / e-mail). Il nostro team di sviluppo ha creato una notte di ricostruzione ricostruendo i dati persi dai backup e testando nuovamente il codice.

Per fortuna abbiamo fatto il lancio di 150 filiali, ma è stata la peggiore esperienza di lancio MAI.


1
Almeno lo hanno declassato
SpaceManSpiff il

9
Strano. Normalmente, qualcun altro coinvolto sarebbe immediatamente licenziato e il figlio del regista promosso.
Kubanczyk,

@kubanskamac - fantastico
Beep beep

Di solito è il tipo di demoniaca che dice "smettila, stupido bastardo, quindi non dobbiamo licenziarti". Il che mi fa chiedere se lo abbia mai fatto o no.
Ernie

1
Non ha mai smesso ... è ancora lì (oltre 10 anni dopo), ed è tornato alla sua vecchia posizione (fondamentalmente un coordinatore dell'implementazione e supporto di helpdesk). Tuttavia, è rimasto nella sala server per alcuni anni.
Beep beep

2

Ho imparato a completare ogni frase di comando prima di premere il tasto Invio.

Una situazione leggermente simile che affronta è quando non sono sicuro di un comando, premo Home e digito alcuni caratteri spazzatura in modo che il comando non sia riconosciuto.

me@mypc:~$ sdkjfhdsudo mv --too-many --switches-to-be --comfortable --working-with --while-running --an-important-command /here/this /there/that

bash: sdkjfhdsudo: command not found

E poi ricontrollo le opzioni, lentamente se necessario. Qualcun altro fa una cosa del genere. Ovviamente, devi assicurarti di digitare caratteri junk sufficienti (5+) , per evitare che diventi un altro comando valido e faccia un danno più imprevedibile.

(C'è un difetto di base in questo che non ho capito o una situazione in cui, dati 5+ caratteri spazzatura, in genere nelle chiavi "asdfghjkl", fa qualcosa di imprevedibile?)


9
I personaggi spazzatura vanno bene, ma forse altri due approcci più comuni (e deterministici!): Attaccare un # sulla parte anteriore del comando o aggiungere il prefisso all'intera 'eco'?
Murali Suriar,

Sono con @Murali, 'echo' o dry run aiutano soprattutto nel debug per prevenire la perdita di dati.
LiraNuna,

3
Su bash(e forse altre shell): Alt + Maiusc + 3 (Alt + #) commenterà il comando.
Belmin Fernandez,

2

Nel reinstallare il sistema operativo di un laptop per un gestore, qualcuno ha fatto una copia di tutti i suoi dati sulla rete su una stazione Linux in / tmp. Ci sono stati alcuni problemi e ci è voluto più di un giorno.

... la stazione Linux è stata chiusa alla fine della giornata ...

Il giorno seguente, quando andarono a cercare i dati del gestore ...


1

Ho lavorato come amministratore di sistema per circa 7 mesi, una delle mie prime attività è stata quella di far funzionare un server proxy Squid e in realtà l'ho fatto funzionare, come 2 settimane dopo che stavo usando BackTrack e scherzavo con molti strumenti " Playing the Hacker "In realtà ho hackerato il server che era abbastanza buono ma dopo essere entrato per qualche strana ragione ho fatto un rm -rf da / e ben cancellato parte del sistema operativo (Debian Linux).

Ho imparato a completare ogni frase di comando prima di premere il tasto Invio.

Saluti.


Whoa. Hai violato il tuo server, quindi hai cancellato accidentalmente il root? Tipo, le tue dita sono scivolate?
Matt Simmons,

4
Guardami mentre lancio questo n3wb, ho il suo IP. 127.0.0.1!
Chris Thorpe,

1

Uno dei nostri clienti ha riscontrato un bug piuttosto raro del filesystem XFS il 24 dicembre 2005 ... Beh, al momento non sapevo che fosse un bug del kernel Linux, ovviamente, pensavo che fosse solo uno dei soliti sospetti (RAID da 13 TB con 8 KB liberi, guasto spurio dell'unità nell'array, ecc.).

Alla fine, dato che il filesystem era smontabile, ho chiesto all'operatore sulla linea di entrare xfs_repair -n /dev/whatever. Vuole cancellare il registro (ovviamente, poiché l'FS non è montabile), ma nessun messaggio troppo inquietante. Quindi, andare per esso: xfs_repair /dev/whatever.

15 minuti dopo, richiama:

perché non riesco a vedere la maggior parte dei file?

Hu oh ... Si scopre che per aggiungere un insulto a un infortunio, gli xfsprogs erano di una versione che avrebbe causato gravi danni in questo caso esatto ... Ahi. 8 TB di dati erano spariti per davvero.


Sono molti i dati da perdere!
Mark Henderson,

1

Qualche tempo fa il mio impianto di colo aveva dei tempi morti.

Hanno rimosso il loro collegamento di rete principale a Internet per eseguire un po 'di manutenzione del software sul router, abbastanza equo.

Tuttavia, allo stesso tempo, il fornitore a monte del collegamento secondario lo ha disattivato per eseguire alcuni test (apparentemente gli era stato detto, ma era stato etichettato erroneamente nel datacenter)

Fin qui tutto male ... tuttavia, i clienti hanno avuto qualche difficoltà a raggiungere la struttura per portare i tempi di inattività all'attenzione del provider .. il provider aveva solo telefoni VoIP, che erano collegati attraverso ... beh, puoi indovinare.

Immagino che non mi crederesti, ma è vero, e una questione di record sulla blogosfera :)


1

Non sono sicuro che questa potrebbe essere una risposta interessante, ma sono anche un programmatore. Ho codificato il mio ultimo sito Web completamente su un piano di produzione, senza alcun backup sul mio PC. Una brutta giornata dopo 16 ore di lavoro continuo, ho dovuto svuotare una partizione e il modo più veloce per farlo era formattarla. Corsi fdisk -la controllare quale fosse il nome della partizione che dovevo formattare, e sfortunatamente ho letto la riga sbagliata e l'ho formattata.

Ho perso circa 6 mesi di lavoro.

Fortunatamente, la seconda volta che fai la stessa cosa lo fai meglio e più velocemente, dal momento che sai già come farlo. Ora il sito è online. E ho i backup: =)


+1 per 6 mesi di lavoro
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.