Pior acidente do SysAdmin [fechado]

De acordo com a pergunta sobre o melhor acidente com o administrador de sistemas , qual o pior acidente em que você esteve envolvido? Ao contrário da pergunta anterior, quero dizer "pior" no sentido de maior dano ao sistema ou dano real às pessoas.

Vou começar com o meu:

Temos dois armários de fiação remotos que estão no final de um corredor de 30 metros que possui uma grade de metal para o piso. Depois que instalamos o cabo Cat6, os empreiteiros limparam todos os detritos que caíam da grade para o concreto 3 pés abaixo. Um colega de trabalho e eu entramos no corredor para verificar o progresso um dia, mas estávamos distraídos e não percebemos que um pedaço de grade havia sido deixado de lado. Meu amigo entrou no ar e seu peito bateu na barra de aço. Ele estava com fôlego e dolorido o suficiente para tirar alguns dias de folga, mas felizmente a viga de aço tinha bordas arredondadas e o tamanho da abertura era tal que ele não bateu com a cabeça nela ou no chão abaixo.

Obviamente, aprendemos que as áreas onde o piso é parcialmente removido precisam ser sinalizadas.

Imagine se você vai morar no sul da Flórida durante o furacão Andrew (um pouco antes da mania 24X7). Todos os seus servidores estão trancados com segurança em um prédio que exige seu crachá e uma área mais segura que exige uma verificação adicional do seu crachá. Imagine um idiota que não explicava a necessidade de maçanetas reais nas portas. Imagine um contrato de quatro milhões de dólares exigindo uma entrega, sendo a eletricidade mais próxima 230 milhas norte, o gás sendo escasso, estradas perigosas e um gerador que foi projetado para fornecer 48 horas de eletricidade. Ria se você observar uma coleção de servidores na traseira de um caminhão, presos na estrada do Mickey Mouse, parados por falta de combustível. Ria se você tiver a total falta de desculpa de como tudo foi ruim do ponto de vista logístico, sysadmin e operacional.

Quando eu trabalhava na Cisco, costumava obter clientes que compravam placas sem fio de US $ 30 e que cuspiam chips quando o driver não instalava, ou pessoas com o roteador mais básico e mais barato da Cisco, que reclamavam e elogiavam problemas de suporte.

Tudo isso foi contextualizado um dia, quando recebi uma ligação de um dos maiores fornecedores de cartões do mundo (pense em Amex, Mastercard, Visa, Diners ... na verdade, era uma dessas marcas, não sei se elas gostaria que eu mencionasse). Eu era o suporte da linha de frente, meu único trabalho era avaliar o cenário, classificá-lo e colocá-lo na divisão de suporte apropriada. Este foi o único caso de Prioridade Um que eu já participei.

Um homem da empresa de cartões telefonou e afirmou que o vínculo entre os mainframes da costa leste e oeste dos Estados Unidos havia diminuído. Se uma conta foi criada em um mainframe, a transação sempre foi processada nesse mainframe. O que seria bom se o link mais próximo estivesse sempre próximo desse mainframe. Porém, nesse dia específico, se você tivesse uma conta no servidor da costa leste, mas estivesse na costa oeste, a transação seria negada porque o link estava inoperante.

A pergunta padrão ao avaliar os danos era "Quanto isso está custando aos seus negócios?" A resposta, calma e coletada, foi "Cerca de um milhão de dólares a cada 30 segundos".

Realmente coloca isso em contexto na próxima vez que você se sentir tentado a reclamar e elogiar o suporte ao cliente por sua placa wireless de US $ 30.

(observe que a Cisco teve seu link em funcionamento dentro de 5 minutos após a transferência)

É muito comum usar comandos alternativos como rm ou mv para adicionar a opção '-i' para evitar erros. Mas isso aconteceu na minha empresa há um tempo atrás. Alguém colocou essa linha no .bashrc do root em um dos servidores.

alias rm='rm -i'

Então copiou a linha e substituiu rm por mv ... ou assim ele pensou:

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

O resto é história :)

Bem, o problema é que, ao mover a pergunta 'você tem certeza', disse 'remover' em vez de 'mover', mas ainda assim ...

Estávamos instalando um sistema massivo de ponto de venda em um grande varejista (mais de 1000 agências). O servidor central de pesquisa era todo o código HP-Unix personalizado, e o teste para a migração de produção foi realizado por um único indivíduo - o filho do diretor de TI.

Esse cara passava 7,95 horas do dia lendo romances de fantasia e os outros minutos executando seu trabalho em lotes para migrar as construções noturnas para a produção. O sistema demorou três dias para ser lançado em 150 das filiais (nossa primeira distribuição "real"). Tudo estava pronto, e minha equipe acabou de testar os trechos finais de código. Comprometemos nossas alterações e transferimos nossas imagens do desenvolvimento para o teste, a ser captado pelo filho do diretor de TI na manhã seguinte.

Eu chego lá às 8:00 e tudo está em caos. Acontece que o filho recebeu instruções de que, depois de copiar os arquivos para produção, ele deveria entrar na pasta ./changed e digitar "rm -rf *". Sim, alguém realmente disse isso a ele! Obviamente, ele fez isso acidentalmente na unidade raiz de produção, que também abrigava nosso banco de dados de pesquisas transacionais (que estava offline para backups na época, apenas nossa sorte).

Resultado: nossas 16 lojas piloto tiveram que atender clientes fora das caixas de charutos (em alguns casos, literalmente) por 2 dias. O filho do CIO foi despromovido para o Server Watcher (ele estava sentado na sala fria de servidores e deveria procurar sinais vermelhos ... mas ele não tinha permissão para tocar em nada ... eles nem sequer lhe deram um computador e revogou todos os seus logins / e-mail). Nossa equipe de desenvolvimento realizou uma reconstrução de dados perdidos durante toda a noite, a partir de backups e código de novo / reenvio.

Felizmente, fizemos o lançamento de 150 filiais, mas foi a pior experiência de lançamento de SEMPRE.

Aprendi a terminar todas as frases de comando antes de pressionar a tecla Enter.

Uma situação um pouco semelhante que enfrento é quando não tenho certeza sobre um comando, pressiono Home e digito alguns caracteres indesejados para que o comando não seja reconhecido.

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 então eu verifico as opções novamente, lentamente, se necessário. Alguém mais faz uma coisa dessas? Obviamente, você deve garantir que você digite caracteres indesejados suficientes (5 ou mais) , para evitar que ele se torne outro comando válido e cause danos mais imprevisíveis.

(Existe uma falha básica nisso que eu ainda não descobri ou em uma situação em que, com mais de 5 caracteres indesejados, geralmente nas teclas "asdfghjkl", isso faz algo imprevisível?)

Ao reinstalar o sistema operacional de um laptop para um gerente, alguém fez uma cópia de todos os seus dados pela rede para uma estação linux em / tmp. Houve alguns problemas e levou mais de um dia.

... a estação linux foi encerrada no final do dia ...

No dia seguinte, quando foram procurar os dados do gerente ...

Trabalho como SysAdmin há cerca de 7 meses, uma das minhas primeiras tarefas foi a execução de um servidor proxy Squid e, na verdade, funcionou, duas semanas depois de usar o BackTrack e mexer com muitas ferramentas " Playing the Hacker "Na verdade, eu hackeei o servidor, o que foi meio bom, mas depois que entrei por algum motivo estranho, fiz um rm -rf a partir de / e apaguei parte do sistema operacional (Debian linux).

Aprendi a terminar todas as frases de comando antes de pressionar a tecla Enter.

Felicidades.

Um de nossos clientes encontrou um bug do sistema de arquivos XFS bastante incomum em 24 de dezembro de 2005 ... Bem, na época, eu não sabia que era um bug do kernel do linux, é claro, pensei que eram apenas alguns dos suspeitos do costume (13TB RAID falha de unidade espúria livre de 8 KB na matriz, etc.).

Finalmente, como o sistema de arquivos era desmontável, pedi ao operador da linha para entrar xfs_repair -n /dev/whatever. Hmm, ele deseja limpar o log (obviamente, como o FS não é montável), mas não há mensagem muito ameaçadora. Então, vá para ele: xfs_repair /dev/whatever.

15 minutos depois, ela chama de volta:

por que não consigo ver a maioria dos arquivos?

Hu oh ... Acontece que, para adicionar insulto à lesão, os xfsprogs eram de alguma versão que causaria danos graves neste caso exato ... Ai. 8 TB de dados foram perdidos de verdade.

Minhas instalações de colo tiveram algum tempo de inatividade há algum tempo.

Eles retiraram o link de rede principal da Internet para realizar alguma manutenção de software no roteador, o suficiente.

No entanto, ao mesmo tempo, o provedor upstream do link secundário o desativou para realizar alguns testes (aparentemente eles foram avisados, mas haviam sido rotulados incorretamente no datacenter)

Até aí tudo bem ... no entanto, os clientes tiveram alguma dificuldade em acessar as instalações para chamar a atenção do provedor. O provedor só tinha telefones VoIP, que eram conectados através de ... bem, você pode adivinhar.

Eu imagino que você não acreditaria em mim, mas é verdade, e uma questão de registro na blogosfera :)

Não tenho certeza de que essa possa ser uma resposta interessante, mas também sou um codificador. Eu codifiquei meu último site completamente em uma avaliação de produção, sem backups no meu PC. Um dia ruim, após 16 horas de trabalho contínuo, tive que empthy uma partição, e a maneira mais rápida de fazê-lo era formatá-la. Corri fdisk -lpara verificar qual era o nome da partição que tinha que formatar e, infelizmente, li a linha errada e a formatei.

Perdi 6 meses de trabalho.

Felizmente, na segunda vez em que você faz a mesma coisa, é melhor e mais rápido, já que você já sabe como fazê-lo. Agora o site está ativo. E eu tenho backups: =)