Qual foi a grande falha que você participou?

Question

As interrupções são algumas das coisas que tentamos evitar, mas são inevitáveis: acontecem (muito raramente, esperamos) e temos que saber como lidar com elas (e aprender com elas).

Então, qual é a maior falha que você fez? Como você e sua equipe lidaram com o problema? O que você aprendeu para o futuro? Por favor, compartilhe seus pensamentos:)

    

Answer 1

Eu faço parte de interrupções quase todos os dias (monitore links WAN para 44 sites). Os 'pequenos' são os que têm menos de 5 minutos e na maioria das vezes passam despercebidos (o NOC monitora apenas as interrupções superiores a 5 minutos, por algum motivo). Eu tento me comunicar com o site para ver se era um problema interno e verificar os logs do roteador sempre que o problema for "desconhecido".

Eu acho que Comunicação é fundamental (e isso é um eufemismo!) ao lidar com interrupções. NÃO ESPERE SER CHAMADO enquanto estiver resolvendo problemas ou tentando descobrir o que exatamente aconteceu. Certifique-se de comunicar que você sabe que eles estão em baixo e você está trabalhando nisso. Dê a eles um período de tempo em que você retornará a eles para lhes dar atualizações sobre a situação (ETR). Não deixe que eles pensem que você se esqueceu deles, certifique-se de que eles saibam que alguém está olhando para o problema deles. Você os chama, então eles não precisam ligar para você.

Felizmente, o mais longo que um site esteve em baixo do meu relógio foi de 7 horas (isto é dentro de um dia de trabalho 10 am-5pm). Deveria ter sido mais curto em algumas horas, se não fosse pela falta de boa comunicação entre todas as partes envolvidas. Muito bem, o problema não foi escalado corretamente, e devido à suposição de que "alguém estava trabalhando nisso", o problema levou (relativamente ao site) para sempre a ser resolvido.

    

Answer 2

Tivemos um tubo de vapor de aquecimento que percorreu a ruptura do nosso data center. Muito quente, condensação e isolamento de amianto em todo o lugar. Corte de energia por semanas durante a limpeza.

OK, o material do grupo meu era emparelhado com BGP, com carga balanceada entre vários data centers. Tivemos uma fração de nossos usuários vendo um congelamento de 30 segundos antes da transação atual ser transferida. Muitos dos outros projetos tiveram interrupções de até vários dias, com todo mundo realizando muitas horas extras para ajudar todos os outros.

Lições aprendidas: faça seu planejamento de continuidade primeiro e, em seguida, crie seu sistema para apoiar suas conclusões:

• Se você não puder tolerar uma semana de inatividade, planeje e pratique sua transferência. Em vez de sites principais / de failover, eles são azuis / dourados e rotacionam a cada duas semanas para garantir que tudo esteja atualizado e disponível.
• Se você não puder tolerar meia hora a um dia, equilibre a carga entre os sites ativos. Você gastará menos tempo e esforço para configurá-lo do que gastará sob pressão tentando fazer a recuperação contra o relógio.
• Se você não pode tolerar minutos de inatividade, precisa fazer muito esforço para realizar a Alta Disponibilidade real. A melhor aposta é contratar um consultor especialista.
• Apenas para finalizar a hierarquia, se você não puder tolerar segundos de inatividade, precisará de hardware especializado e de design especializado. É melhor você ser o especialista

Answer 3

Eu estava participando de uma entrevista de emprego em uma empresa que, no momento, estava enfrentando uma interrupção de rede inteira em seus 50 escritórios de usuários. Eu resolvi isso em questão de minutos e consegui conhecer seu administrador de sistemas atual e sua empresa de suporte de TI que eles ligaram porque ele não conseguiu resolvê-lo - eles passaram a manhã toda tentando descobrir o que estava errado.

O cara anterior instalou dois roteadores sem fio no modo bridge e os conectou na rede com fio. Eles mal estavam ao alcance um do outro, então eles tinham um loop em sua rede que entrava e saía conforme a recepção variava.

É desnecessário dizer que consegui o emprego e implementei alguns registros de gerenciamento de alterações assim que comecei.

    

Answer 4

Eu experimentei uma interrupção de uma semana de toda a nossa rede de servidores. Nós lidamos com isso criando uma rede de redundância, para evitar o mesmo problema no futuro, mas enquanto a interrupção estava ocorrendo, usamos um servidor antigo que instalamos em um local remoto. Aprendemos a ter sempre um plano de backup.

    

Answer 5

Provavelmente, o maior deles foi uma indisponibilidade de rede de 4 dias, causada por uma grande atualização de rede.

A maior dica que eu tenho é ter um sólido processo de gerenciamento de incidentes estabelecido. Há uma apresentação brilhante da conferência Velocity 2008 que eu vi sobre a adaptação do Sistema Geral de Comando de Incidentes usado pelo pessoal de emergência ( link ) para Incidentes semelhantes ao tipo de TI: link

Crímos extensivamente disso ao desenvolver nosso próprio processo incidente "Sev1" interno. Ele enfatiza a comunicação, a unidade de comando, a transferência clara de responsabilidades e outras coisas importantes.

Também adicionarei um plug-in para o blog do Transparent Uptime: link - o serviço on-line está focado, mas suas regras gerais sobre como / o que se comunicar para uma interrupção também se aplica a coisas internas de TI. link especificamente - nós tivemos um berço de gerente a partir disso e começamos a enviar comunicações em esse formato e você não acreditaria na resposta positiva.

    

Answer 6

Quão bem cronometrado. Acabei de voltar de uma viagem de emergência para um dos sites que suportamos.

No que diz respeito ao impacto do usuário, não foi um grande impacto, mas teve o potencial de ser. Como parte de um projeto em andamento para migrar alguns sites do nosso suporte, criamos um novo domínio confiável. Após testes extensivos, preparamos o primeiro site para migrar para o novo domínio que ainda gerenciaríamos. Assim, a noite da migração chega e começamos migrando um dos dois DCs para o novo domínio. Isso vai bem. Nós migramos os grupos de segurança e as contas de usuário. Isso vai bem também e a associação ao grupo é atualizada corretamente. Nós migramos o servidor de arquivos e executamos a conversão de segurança para atualizar as ACLs. Mais uma vez tudo vai bem. Migre servidores de aplicativos e atualize o IAS para VPN sem problemas. Em seguida, migramos um PC de usuário de teste e o usuário mantém suas configurações de perfil e pode acessar todos os recursos de rede perfeitamente. Em seguida, migramos o outro DC. Em seguida, migramos os computadores restantes e falhamos. Descobrimos que o firewall local do XP está ativado. Eu imediatamente empurro um GPO para o site para desligá-lo, mas vou ter que esperar a atualização dos computadores. Isso não acontece com rapidez suficiente e os usuários começam a chegar. Eles não podem entrar no domínio original porque os dois DCs estão no novo.

Em vez de tentar adicionar novamente um controlador de domínio ao domínio original, atualizamos as regras de firewall para permitir acesso a outros DCs remotos do domínio original e levamos a unidade de três horas até o site.

Indo dormir pouco: o GPO para desativar o firewall local foi removido. Sem pensar eu pego todos os objetos do computador e empurro a migração. Esqueci que isso RESETs os objetos do computador. Então agora todos os PCs migrados com sucesso são cortados do domínio.

Para piorar a situação, a aprovação do administrador local que implementamos com nossa imagem não funciona devido a uma tecnologia antiga que a redefine.

Passei o fim de semana adicionando manualmente todos os PCs ao novo domínio depois de usar um disco de inicialização para limpar o passe de administrador local.

Lições aprendidas:

• Espere o inesperado e tente antecipar todos os possíveis problemas.
• Centralize o gerenciamento de itens como senhas de administradores locais e configurações de firewall
  • GPOs e preferências de política de grupo
• Reserve um minuto para verificar se você está fazendo as coisas corretamente antes de clicar.

Desculpem-me.