Diário da TI: apertem os cintos, os dados sumiram!

Essa é uma história fictícia, qualquer semelhança com a realidade é pura coincidência.

José era Diretor de TI em um grande grupo de empresas de sua cidade e tinha comprado um projeto para seu data center de um dos grandes fabricantes nacionais, nada muito grande, mas tudo do bom e do melhor: três servidores para virtualização lotados de memória e processadores com muitos núcleos, switches e storage com algumas dezenas de discos.

Dirceu, o proprietário do grupo, costumava mostrar, todo orgulhoso, para os visitantes da sua empresa o data center que tinha montado, com piso elevado, extintores de incêndio de CO2 do lado de fora da sala e cabeamento estruturado. Ele não tinha ideia porque as luzes dos equipamentos piscavam tanto, mas achava aquilo bonito, tanto é que mandou quebrar a parede em frente aos racks, o equivalente a uma janela, e colocou um vidro temperado ali, para poder ver e exibir sem abrir a porta, afinal, aprendeu com José que era importante manter a temperatura dentro do data center, e abrir a porta para levar as visitas para dentro alterava drasticamente a temperatura.

Imagem via Shutterstock

Imagem via Shutterstock

Por dois anos tudo correu muito bem, o máximo de problemas que José teve foram 2 discos do storage que apresentaram defeito, mas o equipamento estava configurado para alertar o fabricante, e antes mesmo que José percebesse o problema, tinha um técnico do fabricante na porta com um HD novo para trocar.

Numa terça-feira ensolarada José chegou para trabalhar logo cedo, como de costume pegou seu café e foi para sua mesa ler os e-mails. Mal imaginava o que lhe aguardava naquela manhã.

Às 9:41 a primeira ligação aconteceu, um usuário reclamava de lentidão. Isso era algo bem incomum, e a última vez que ouviu isso faziam mais de dois anos, com a infraestrutura antiga. José estranhou quando ouviu o técnico do suporte atendendo a ligação e resolveu ir até a mesa dele para acompanhar de perto.

O técnico fez alguns testes iniciais e acessou o computador do usuário. Um relatório que estava demorando quase 2 minutos para processar, o usuário dizia que normalmente era tirado em cerca de 30 segundos. José deu uma relaxada, o técnico abriu um ticket de suporte para a equipe de desenvolvimento investigar, possivelmente era alguma querie mal escrita.

Alguns minutos depois veio a segunda ligação, lentidão novamente, mas dessa vez era na tela de cadastro de notas fiscais. Isso era bem incomum, e logo, vieram outras ligações e a fila de chamados começou a crescer rapidamente, com lentidão no cadastro de clientes, nas ordens de serviço e em pedidos de compras.

Resolveram acionar o responsável pelo banco de dados. Eles costumavam chamar um DBA autônomo, o Luiz, muito prestativo, estava disponível e acessou imediatamente o servidor de banco de dados da empresa. Ele examinou o consumo de memória, cpu, procurou por Locks, nada anormal. Sem ideias, sugeriu um reboot. Já era por volta das 11 horas, horário de almoço da maioria da fábrica, José conversou com Dirceu (que a essa altura já tinha vindo umas duas vezes até a sala da TI) e autorizaram o reboot às 11:05h.

Feito o reboot, os serviços subiram normalmente, José fez alguns testes e aparentemente tudo tinha normalizado. Ele ficou ao mesmo tempo contente e desconfiado, não sabia o que tinha acontecido. Mesmo assim foi para o almoço, já era 11:40h e estava com bastante fome.

12:20h o celular de José começa a tocar. Era um membro da sua equipe, dizendo que as reclamações voltaram. Alguns funcionários tinham voltado do almoço e estavam enfrentando dificuldades para realizar suas tarefas. José, que já estava comendo a sobremesa, ligou imediatamente para Luiz, o DBA, e o celular dele estava fora de área e caiu em caixa postal.

Enquanto voltava do refeitório para sua sala, José insistiu na ligação para o celular de Luiz, sem sucesso. Chegando lá buscou pelo número fixo de Luiz, ligou e ele atendeu. José informou a Luiz que ainda estava com problemas; Luiz acessou novamente e começou a investigar.

Nesse ponto José estava se sentindo muito mal, tinha comido às pressas, e o nervosismo transparecia em sua face, não sabia o que estava acontecendo, ao mesmo tempo em que prejudicava o trabalho da empresa. Ele sabia que tinha que resolver aquilo rápido.

Às 13:02h toca o telefone, é da portaria, tinha um representante do fabricante do hardware ali na porta. José perguntou pra equipe se alguém tinha chamado ou esperava por alguém, ninguém soube dizer. José não queria ninguém para vender nada agora, pediu para perguntar o assunto, ficou sabendo então que era um técnico e pediu para entrar imediatamente.

Ao chegar na sala, o técnico informou que tinha um alerta do storage, que uma das controladoras tinha apresentado problemas e se desligou e que ele tinha ali uma controladora nova para substituir.

José sabia que era um procedimento delicado, contou da situação de lentidão e perguntou ao técnico se poderia ser aquilo, o técnico disse que sim. Na dúvida José ligou para Luiz e fez a mesma pergunta. Luiz disse que já tinha visto casos assim, que alguns storages, quando uma controladora desliga, a secundária assume todas as conexões, mas o cache cai pela metade junto com a controladora problemática. Ele apoiou a troca e disse que já tinha visto esse procedimento ser feito, que era bem tranquilo e não teria interrupção.

José e o técnico foram para dentro do data center com a nova controladora e ferramentas em mãos, de fato, tinha um led vermelho aceso no storage, e José começou a ficar aliviado pensando que tudo se resolveria.

O técnico soltou os grampos de fixação da controladora problemática e puxou a mesma, os leds vermelhos se apagaram, ele removeu com cuidado para não desconectar nenhum cabo dos demais componentes. Ao colocar a controladora velha de lado, pegou imediatamente a nova e foi em direção ao storage. Começou a introduzir a mesma no equipamento, chegou no ponto de contato, apertou firme e prendeu os grampos de fixação.

Alguns segundos depois, os leds já tinham feito um show pirotécnico indicando o diagnóstico, e, ao invés de estarem todos verdes, estavam um misto de verde e laranja. Confuso, José perguntou para o técnico se já tinha visto isso, ele disse que sim, e precisava ligar para apoio da central.

Depois de alguns minutos de espera, o técnico que estava na empresa conseguiu ser atendido por um técnico da central. Ao descrever a situação dos leds, o técnico da central disse que teriam que acessar a interface de administração do equipamento. Eles foram para fora do data center, e José indicou para o técnico um computador que estava em um canto específico, disse que aquele computador poderia administrar todos os servidores, e tinha todos os softwares necessários para isso.

Eles foram juntos, José prontamente levou as senhas necessárias para os acessos. Ainda com o técnico da central na linha, eles acessaram e visualizaram a mensagem: “Error 408: version mismatch”. O técnico da central já sabia o que era isso: a versão da controladora velha e da nova não batiam, eles fizeram mais alguns procedimentos e confirmaram: a controladora velha era versão 3.51, e a nova 4.10.

A saída era simples, atualizar a controladora velha para a nova versão, mas como só ela estava operacional, ela precisaria rebootar no final, isso causaria indisponibilidade do ambiente, e era necessário ter certeza que o backup estava em ordem.

Já era 16h, Dirceu apareceu na sala, José estava otimista porque tinham encontrado o problema da lentidão, embora ainda não resolvido, a solução parecia simples agora. José aproveitou e comunicou a Dirceu que eles planejavam uma parada geral nos sistemas às 17:10h, hora que a fábrica fechava e a maioria dos funcionários iam embora. Ele e sua equipe ficariam ali para assegurar que tudo estivesse ok, e no dia seguinte, as coisas estivessem funcionando perfeitamente, Dirceu aprovou.

José já tinha tomado todas as medidas necessárias, pediu para Luiz um backup extra em disco, só por garantia. Validou se as rotinas do backup da noite tinham corrido tudo ok, passou um e-mail comunicando a parada para toda a equipe, pedindo para desligarem seus computadores às 17:05h no máximo.

Chegada a hora programada, José ligou para Luiz para confirmar se tinha acabado o backup, esse informou que não, que o processo ainda estava rodando, pelo tamanho que o arquivo estava, ainda demoraria uns 20 minutos pra terminar. Algumas ligações depois e longos minutos de espera, Luiz informa que o backup terminou, que poderiam prosseguir, já era 18:20h, Luiz não tinha previsto que a lentidão do storage afetaria tanto assim a rotina do backup.

Nesse horário começaram a desligar todos os sistemas, shutdown no banco de dados, desligaram as máquinas virtuais, e finalmente os hosts e servidor de banco de dados. O técnico do fabricante que ainda estava ali, ligou para a central para pedir apoio no procedimento. A central acessou remotamente a máquina de administração e juntos foram seguindo o passo a passo: o download do firmware tinha sido feito previamente, acessaram a interface do storage, em System, Firmware Upgrade, clicaram no botão, localizaram o arquivo e clicaram em Send.

Após aceitarem o aviso de Warning, indicando que a controladora ficaria indisponível, foram os minutos mais tensos da carreira de José, aquele contador de porcentagem que foi rápido até os 95%, parecia que não sabia nenhum número acima disso… embora tivesse nobreak, e o técnico tivesse indicado que o procedimento era bem seguro, José sabia da importância dos dados que ali estavam para a empresa.

Finalmente chegou a hora da verdade, e a controladora rebootou para assumir a nova versão de firmware, após o show pirotécnico dos leds, os mesmos se estabilizaram e ficaram todos verdes. Na interface de gerência, ainda tinha um aviso de Warning, que informava que a versão do firmware dos HDs tinha que ser atualizada. Com apoio do técnico da central, José e Henrique (o técnico que estava in loco) realizaram o procedimento, mais alguns minutos de tensão…

Após mais alguns longos minutos, tudo estava atualizado, as mensagens de Warning tinham desaparecido, os DiskGroups estavam online, enfim, tudo na mais perfeita ordem.

O técnico Henrique já pensava na 1h de estrada que pegaria e logo estaria com a família, José também já estava mais aliviado, mal sabia ele o que ainda aguardava.

José ligou para Luiz, informou que tinham terminado o procedimento e que ele deveria verificar se o banco de dados tinha subido normalmente. Sua equipe começava a ligar os hosts para depois ligar as máquinas virtuais.

Alguns minutos depois, as máquinas virtuais já estavam todas no ar, José liga novamente para Luiz para ver se o banco de dados estava ok, quando recebe a má notícia: “o banco não subiu, pois não consigo enxergar os volumes do storage”. José sente um frio na espinha.

Após alguns minutos de diagnósticos entre Luiz, Henrique e Paulo (o técnico remoto do fabricante), eles entendem que o storage está tudo certo, os dados estão lá, mas o servidor de banco de dados não consegue enxergar o volume.

Eles começam o diagnóstico básico, validam se o volume está apresentado, se os cabos do storage estão conectados aos hosts, se o mapeamento está correto, executam um scan no servidor para encontrar os volumes, e nada.

Joaquim, um dos membros da equipe de José tem uma ideia: porque não apresentam o volume para uma máquina virtual, afinal o ambiente virtual estava em ordem, e aparentemente o problema era só no servidor de banco de dados. Esse era inclusive o plano de contingência deles em caso de problemas no servidor físico.

Enquanto Henrique, Paulo e Luiz seguem o diagnóstico, José informa a ideia de Joaquim, e esse último começa a iniciar a máquina virtual. Como ninguém tem nenhuma objeção à ideia, eles refazem o mapeamento do storage para apresentar os volumes para o servidor virtual de contingência.

Luiz acessa o servidor de contingência, eles executam um scan, e os volumes do storage aparecem. Luiz confirma que os dados estão todos ali, mas ele não pode subir o banco naquele momento, pois não tem o último patch que ele aplicou no servidor de produção aplicado ali.

José sabe que isso levantará a base de dados, mas também sabe que o servidor de contingência foi dimensionado para ser apenas contingência, e haverá falta de recursos e possível lentidão no dia seguinte, essa não é uma opção segura.

Já são 19:40h, a equipe começa a apresentar sinais de cansaço, todos estão com fome e José resolve encomendar uma pizza para levantar a moral.

Quando a pizza chega às 20:16h, Luiz está terminando o download dos patches para aplicar no servidor, mas infelizmente não está ali para desfrutar da guloseima. Enquanto ele aplica os patches e sobe o banco, o restante da equipe se delicia.

Com o servidor de contingência em pleno funcionamento, José está um pouco menos tenso, mas sabe que é uma situação insustentável para o dia seguinte. Enquanto boa parte da equipe testa se está funcionando tudo corretamente, José e os técnicos do fabricante ainda se debatem para entender o que aconteceu de errado com o servidor de banco de dados principal e começam a encontrar algumas pistas.

Depois de rodar um software de diagnóstico do fabricante, o mesmo gerou alguns alertas referente a versão do firmware instalado nos servidores. Paulo sugeriu a atualização dos mesmos, mas Henrique teve o cuidado de validar no manual atualizado online sobre a compatibilidade, e observou na matriz de compatibilidade que aquela versão do firmware da placa HBA não seria compatível com a versão do sistema operacional, obrigando a instalação de um patch maior no mesmo.

Com o plano de upgrade improvisado na mão, os técnicos do fabricante começaram a baixar as versões novas de firmware e patch do sistema operacional, alguns gigabytes depois e com tudo em mãos, começaram os procedimentos, enquanto José cruzava os dedos e Luiz aproveitou o intervalo para comer um lanche rápido.

Cerca de 30 minutos depois os updates de firmware e sistema operacional estavam aplicados, chegou a hora de testar a conexão com o storage. O restante da equipe tinha terminado de fazer os testes no servidor de contingência, desanimados porque teriam que fazer todo o trabalho novamente.

José autorizou o failback para o servidor de produção, a equipe parou a base de dados no servidor de contingência, remapeou o volume do storage para o servidor de produção principal, e, ao rodar o scan, todos os volumes foram encontrados.

Luiz começou imediatamente o processo para ativar a base de dados, por sorte nenhuma informação foi perdida, os patches do banco de dados estavam aplicados, foi necessário apenas recompilar os drivers de conexão o que lhe tomou mais 30 minutos de trabalho extra.

Por volta das 23:15h a base estava de volta no ar, a equipe de sistemas ainda precisava testar para ter certeza que estava tudo em ordem. Por sorte tinham um processo documentado que demorava pouco mais de 1h, mas a chance de erros a essa hora da noite, com a equipe toda cansada era enorme, foi quando José apareceu com café, chocolate e barras de cereais para todos.

Às 00:43h a equipe estava saindo da empresa, indo para casa, exaustos, mas com a satisfação de dever cumprido.

José dirigia pra casa, pensando em lições aprendidas, no que poderia ter feito preventivamente, mas ele ainda estava preocupado, pois sabia que isso não terminaria ali, tudo seria resolvido no dia seguinte logo pela manhã em uma reunião com Dirceu.


Já passou por uma situação parecida? O que pode ter faltado para que José, Dirceu, Luiz e companhia dormissem com mais tranquilidade? Compartilhe sua história e opinião!

Artigo publicado originalmente no Blog da Blue Solutions.

Fernando Ulisses dos Santos

Mais artigos deste autor »

Empreendedor em Empresas de Tecnologia da Informação.

Pós-Graduado em Segurança da Informação, certificado VMware VCAP-DTD.

Atualmente trabalha no seu mais novo projeto, o Sky Monitor.

Idealizou e criou o PowerBiz, ferramenta para Convertion Rate Optimization em Marketing Digital.

Criou o Business Monitor, um mini sistema de BI para geração de Dashboards em tempo real.

Fundador da Blue Solutions, onde trabalhou em dezenas de projetos de virtualização, reestruturação, implantação e migração de Datacenter em empresas de todos os portes.


13 Comentários

Evandro Nascimento
1

Excelente artigo! Meus parabéns!
Infelizmente esse filme de terror é baseado em fatos reais que aconteceram e continuam acontecendo na minha vida e na de muitos outros profissionais.
A questão é, até que ponto a equipe de T.I está focada somente em T.I para conseguir agir de maneira preventiva?
Abraços e bom final de semana.

Leonardo
2

No meu ponto de vista, creio que faltou gestão de configuração, gestão de mudanças, gestão de continuidade e principalmente revisão de backups rsrs.

Paulo
5

Vcs são loucos?? quase morri lendo…tensão total! achei q o José ia pra rua! kkkkkkkkkkkkk

Marcos
7

Pelo que entendi, estava tudo ok com os últimos backups. Foi solicitado um backup extra, esse sim impactou no processo, por conta da lentidão devido ao problema com o storage. Infelizmente, muitas vezes o que falta é uma boa negociação entre as áreas de TI e negócio, para fechar as datas e horários de paradas para manutenções. E um melhor entendimento, por parte do negócio, da necessidade de se ter essas janelas para manutenção/atualização de patchs de segurança, drivers, etc. Trabalhei em empresa em que mesmo depois de toda a negociação feita, data/hora fechados, equipes informadas, mudanças aprovadas no comitê, todo o processo era abortado por que “um usuário” teria que usar o sistema naquele dia/hora. Aí, fica postergando a data, o tempo passa, nada é feito e na hora que se vai fazer apararecem essas surpresas.

Tiago de Aviz
8

Passei por muitas situações iguais ou piores a estas.
Arrisco dizer que aí o problema estava em o fabricante trazer uma controladora com um firmware mais atual que o que estava em produção. As vezes eu fico brabo com a IBM quando eles fazem isso comigo, mas a grande verdade é que isso é a melhor coisa a ser feita, pois dificilmente um cliente está rodando uma firmware mais velha do que a que está dentro da controladora.
Aí quando desencadeia o processo de atualizar firmwares, isso gera outro problema: você tem que rodar toda a matriz de compatibilidade de HBA’s, switches SAN, controladoras de storage e firmware de disco, além dos drivers de multipath e de HBA.
No desespero acaba se atualizando a versão da controladora e gera todo este problema aí em cima.
O Leonardo ali em cima tá coberto de razão.

Edton Martins
9

O grande problema que percebo é exatamente o que Marcos disse. É comum enfrentarmos muita dificuldade para conseguir estabelecer uma janela de manutenção. Na história citada, o tempo de restauração do ambiente seria reduzido se todos os patches se encontrassem na última versão disponibilizada pelo fabricante.

Felipe
10

Definitivamente é por isso que uso AWS, as chances disso acontecer são quase zero.
Eu fiquei agoniado só em ler a história

joe reis
11

Caras, muito bom esse texto. Li esperando que o final houvesse sangue e lagrimas, porém, deu tudo certo.

Marcelo Jeronimo
12

A única coisa que não condiz com a realidade é a rapidez com que a pizza chegou, o resto, sempre é de mal a pior… kkkk

Paulo
13

Cara… Carrie , A Estranha e conversa de criança perto dessa história…
O importante é que entre mortos e feridos e todos os dados se salvaram…

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!