NewsGeneration: um serviço oferecido pela RNP desde 1997


ISSN 1518-5974
Boletim bimestral sobre tecnologia de redes
produzido e publicado pela  RNP – Rede Nacional de Ensino e Pesquisa
17 de janeiro de 2000 | volume 4, número 1

volta à página inicial de NewsGeneration

Nesta edição:

NewsGeneration:



Bug do Ano 2000: O que Realmente Aconteceu

Ana Carolina T. Murgel <>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
O projeto
O dia D
Considerações finais

O presente artigo apresenta um resumo do Projeto Ano 2000 na RNP e avalia a extensão do chamado "bug do ano 2000" na sociedade.

^

Introdução

Nos últimos meses, o "bug do ano 2000" foi assunto constante na imprensa. Muito se especulou sobre o problema e quais seriam as suas conseqüêcias para a sociedade como um todo. Falou-se até na falta de controle de mísseis que contém ogivas nucleares, em desabastecimento de supermercados, farmácias, etc. O fato é que a humanidade sobreviveu a passagem do ano sem sentir-se ameaçada.

O fato é que o perigo real existiu. No entanto, num esforço mundial, técnicos saíram em busca de atualizações de softwares e hardwares de forma a resolver o problema em sua instituição.

Na RNP, o Serviço de Suporte a Operações ( SSO ) recebeu, em meados de 1998, a missão de tocar o Projeto Ano 2000. O trabalho consistia em fazer o levantamento de todos os equipamentos e software que pudessem apresentar problemas relacionados ao chamado "bug do ano 2000" na Base de Patrimônios da RNP; gerar uma listagem com as correções e orientar os núcleos da RNP e seus Pontos de Presença ( PoPs ) sobre como efetuar as devidas correções de forma a contornar o problema.

^

O projeto

Foi criada uma lista de discussão, a ano2000@rnp.br, com técnicos de toda a RNP, além de um representante técnico e um administrativo de cada um dos 30 Pontos de Presença que formam o backbone da RNP. O intuito era o de divulgar resultados e discutir conjuntamente o problema

A base de patrimônios continha aproximadamente 4.000 itens que precisaram ser checados (em alguns casos, itens obsoletos que continuavam em produção).

Após a checagem de software, hardware e quaisquer outros equipamentos que continham microprocessadores embutidos, foram divulgados na lista os laudos e correções para os técnicos. Em seguida, foi divulgado um Guia de Ações (REF0188), com o intuito de se fazer o levantamento diretamente no backbone sobre o que estava em produção e o que precisaria de substituição emergencial.

Considerando que os Pontos de Presença são unidades autônomas, o retorno foi satisfatório - direta ou indiretamente, todos se envolveram no projeto. Com base nos checklists enviados, foram substituídos aproximadamente 90 roteadores obsoletos ou que poderiam apresentar problemas.

Foram gerados 40 documentos diretos pelo SSO e 42 de retorno da RNP e PoPs. Diversos testes isolados e um teste do backbone, envolvendo todos os PoPs foram feitos. Foi um trabalho intensivo para que no final ocorresse o resultado esperado: nada!

^

O dia D

Com a virada do ano, foi feita uma checagem imediata da situação do backbone - todos os roteadores responderam, com exceção do PoP do Pará (PoP-PA), que ficou sem luz na instituição que o abriga, a Universidade Federal do Pará, o mesmo ocorrendo com o NC-RJ, em relação ao IMPA. Em nenhum dos casos, a falta de energia foi ocasionada pelo bug, conforme foi relatado posteriormente.

No dia 1 de janeiro, todos os técnicos de suporte compareceram para verificar o funcionamento de seus núcleos - com exceção de algumas pequenas falhas localizadas, tudo estava ok.

É claro que o backbone estar funcionando não significa que não ocorreu nenhum problema - houve falhas em alguns software e scripts, como, por exemplo, no caso do sistema do HelpDesk da RNP, que estava acusando o recebimento de mensagens no ano 100, o que fez ainda que o número dos protocolos fossem alterados, como mostra o exemplo abaixo:

------------------------------- | | Numero de Protocolo: 1000111-23 | Solicitante........: USR: Usuario de redes | E-mail.............: bia@acme.rnp.br | Data de Solicitacao: 11/01/100, 09:42:44 | Tipo de Solicitacao: ICNN: Informacoes sobre Connect | Status.............: Encaminhada | Classificacao......: Informacoes sobre IP e sobre IPV6 | Escopo.............: Sim: Esta dentro do escopo de atendimento do CI | Prioridade.........: Normal | Encaminhada Para...: | +--------------------- ERNA: ETIQUETA RECICLAVEL - NAO APAGUE

Essas pequenas falhas foram apontadas, no mundo inteiro, em software de usinas atômicas, satélites da NASA, bancos nacionais e estrangeiros, sistemas de saúde, etc. O bug não deixou de mostrar sua presença, mas todos os esforços unidos impediram que as falhas se transformassem em catástrofes.

Com relação à Internet mundial, é difícil avaliar, com precisão, o que foi afetado pelo bug. Há um consenso que os danos foram mínimos. Um relatório, veiculado através da lista de discussão NANOG ISP Y2K, apresenta alguns números que mostram um pequeno declínio do número de de redes (de 70.911 no dia 30 para 67.795 durante a virada do ano na costa leste americana). Este número tornou a crescer e, após as 5h, já se encontrava em 70.455.

Já era esperado que algumas instituições optassem por deixarem desligados os servidores de sua rede. Este declínio, portanto, não foi de se estranhar. O maior número de reclamações feitas por provedores de acesso, no entanto, disseram respeito a congestionamentos nos circuitos de voz, o que nestas circunstâncias, é algo perfeitamente normal.

Havia também o temor que muitos hackers lançassem um ataque "em massa" às máquinas da Internet, uma vez que muitos deles fizeram tal tipo de ameaça em listas de discussão no mundo inteiro. No entanto, os relatos de ataques foram muitos poucos. No Japão, foi feita denúncia de apenas uma tentativa.

Houve uma certa pressão por parte da imprensa e da mídia em geral em torno do assunto - nos últimos dias do ano o noticiário da maior emissora brasileira tratava o assunto como uma grande piada. No entanto, é certo que a caça ao bug também ocorreu lá dentro.

A grande pergunta que se ouvia nos primeiros dias do ano era: "gastou-se tanto e não aconteceu nada?" A impressão tida foi que se esperava alguma coisa, catástrofes ou shows pirotécnicos, como se o bug fosse também uma comemoração para a chegada do ano novo. Justamente depois de tantos gastos e de tanto trabalho para que ele passasse desapercebido.

E é por esse prisma que o bug do ano 2000 deve ser observado - a ausência de catástrofes significa que o projeto foi um sucesso no mundo inteiro, e que cada centavo gasto nele atingiu seu objetivo - que o ano 2000 se iniciasse sem que as pessoas tivessem suas vidas alteradas

^

Considerações finais

O Projeto Ano 2000 continua até o dia 03 de março - ainda há a questão de 2000 ser um ano bissexto - é claro que o sucesso na data crítica 01/01/2000 fez com que a prioridade sobre o projeto se tornasse mais baixa, e as pequenas falhas que vão sendo encontradas também estão sendo corrigidas.

Ninguém precisará virar a meia noite do dia 28 em seu escritório, mas todos estarão verificando o funcionamento de seus sistemas no dia 29, checando datas e funcionamento, desta vez sem a tensão que marcou a vida de milhares de pessoas na virada do ano - e poder-se-á, finalmente, em 31/12/2000, brindar junto com as pessoas amadas e sem pensar em trabalho a chegada do novo milênio, que começa em 2001 (mesmo com a insistência da mídia em dizer que já começou... Seria um bug na imprensa?...)

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004