Bilhões de dólares foram gastos com o bug do Y2K. Os sistemas governamentais, militares e corporativos estavam todos em risco, mas nós sobrevivemos, mais ou menos, ilesos. Então, a ameaça era real?
Índice
Nas décadas de 1950 e 60, representar anos com dois dígitos tornou-se a norma. Um dos motivos para isso foi economizar espaço. Os primeiros computadores tinham pequenas capacidades de armazenamento e apenas uma fração da RAM das máquinas modernas. Os programas deveriam ser tão compactos e eficientes quanto possível. Os programas foram lidos em cartões perfurados, que tinham uma largura finita óbvia (normalmente, 80 colunas). Você não pode digitar além do fim da linha em um cartão perfurado.
Onde quer que o espaço pudesse ser salvo, estava. Um truque fácil – e, portanto, comum – era armazenar os valores do ano como dois dígitos. Por exemplo, alguém marcaria 66 em vez de 1966. Como o software tratava todas as datas como ocorrendo no século 20, ficou claro que 66 significava 1966.
Eventualmente, os recursos de hardware melhoraram. Havia processadores mais rápidos, mais RAM e terminais de computador substituíram cartões perfurados e fitas . Mídias magnéticas, como fitas e discos rígidos, foram usadas para armazenar dados e programas. No entanto, a essa altura, havia um grande corpo de dados existentes.
A tecnologia da computação estava avançando, mas as funções dos departamentos que usavam esses sistemas permaneciam as mesmas. Mesmo quando o software foi renovado ou substituído, o formato dos dados permaneceu inalterado. O software continuou a usar e espera anos de dois dígitos. Conforme mais dados se acumulavam, o problema se agravava. O corpo de dados era enorme em alguns casos.
Transformar o formato de dados em uma vaca sagrada foi outro motivo. Todo o novo software teve que ceder aos dados, que nunca foram convertidos para anos de quatro dígitos.
Limitações de armazenamento e memória surgem em sistemas contemporâneos também. Por exemplo, sistemas embarcados , como firmware em roteadores e firewalls, são obviamente limitados por limitações de espaço.
L programáveis OGIC c ontrollers (PLCs), maquinaria automatizada, linhas de produção robóticos, e sistemas de controlo industriais foram todos programado para utilizar uma representação de dados que foi o mais compacto possível.
Reduzir quatro dígitos para dois economiza bastante espaço – é uma maneira rápida de reduzir a necessidade de armazenamento pela metade. Além disso, quanto mais encontros você tiver que lidar, maior será o benefício.
Se você usar apenas dois dígitos para valores de ano, não será possível diferenciar as datas em séculos diferentes. O software foi escrito para tratar todas as datas como se estivessem no século XX. Isso dá resultados falsos quando você chega ao século seguinte. O ano 2000 seria armazenado como 00. Portanto, o programa o interpretaria como 1900, 2015 seria tratado como 1915 e assim por diante.
Ao bater da meia-noite de 31 de dezembro de 1999, todo computador – e todo dispositivo com um microprocessador e software integrado – que armazenasse e processasse datas como dois dígitos enfrentaria esse problema. Talvez o software aceite a data errada e continue, produzindo uma saída de lixo. Ou talvez gerasse um erro e continuasse – ou engasgasse completamente e caísse.
Isso não se aplica apenas a mainframes, minicomputadores, redes e desktops. Os microprocessadores funcionavam em aeronaves, fábricas, centrais elétricas, sistemas de controle de mísseis e satélites de comunicação. Praticamente tudo o que era automatizado, eletrônico ou configurável continha algum código. A escala da questão era monumental.
O que aconteceria se todos esses sistemas mudassem de 1999 em um segundo para 1900 no próximo?
Normalmente, alguns trimestres previam o fim dos dias e a queda da sociedade. Em cenas que irão repercutir em muitos na atual pandemia, alguns começaram a estocar suprimentos essenciais . Outros chamaram a coisa toda de farsa, mas, inegavelmente, era uma grande notícia. Ele ficou conhecido como bug do “milênio”, “Ano 2000” e “Y2K”.
Havia outras preocupações secundárias. O ano 2000 foi um ano bissexto e muitos computadores – mesmo sistemas experientes para anos bissextos – não levaram isso em consideração. Se um ano for divisível por quatro, é um ano bissexto; se for divisível por 100, não é.
De acordo com outra regra (não muito conhecida), se um ano é divisível por 400, é um ano bissexto . Muito do software que foi escrito não aplicou a última regra. Portanto, ele não reconheceria o ano 2000 como um ano bissexto. Como resultado, seu desempenho em 29 de fevereiro de 2000 era imprevisível.
No Estado da União de 1999 do presidente Bill Clinton, ele disse:
“Precisamos de todos os governos estaduais e locais, todas as empresas, grandes e pequenas, para trabalhar conosco para garantir que [o] bug de computador Y2K seja lembrado como a última dor de cabeça do século 20, não a primeira crise do século 21 . ”
Em outubro anterior, Clinton assinou a lei de divulgação de informações e prontidão do ano 2000 .
Muito antes de 1999, governos e empresas em todo o mundo vinham trabalhando duro para encontrar soluções e implementar soluções para o Y2K.
No início, parecia que a correção mais simples era expandir o campo de data ou ano para conter mais dois dígitos, adicionar 1900 a cada valor de ano e ta-da! Você então tinha anos de quatro dígitos. Seus dados antigos seriam preservados corretamente e os novos dados se encaixariam perfeitamente.
Infelizmente, em muitos casos, essa solução não foi possível devido ao custo, ao risco de dados percebido e ao tamanho da tarefa. Sempre que possível, era a melhor coisa a fazer. Seus sistemas seriam seguros para datas até 9999.
Claro, isso apenas corrigiu os dados. O software também teve que ser convertido para manipular, calcular, armazenar e exibir anos de quatro dígitos. Surgiram algumas soluções criativas que eliminaram a necessidade de aumentar o armazenamento por anos. Os valores do mês não podem ser maiores que 12, mas dois dígitos podem conter valores até 99. Portanto, você pode usar o valor do mês como um sinalizador.
Você pode adotar um esquema como o seguinte:
Você teve que modificar os programas para codificar e decodificar as datas ligeiramente ofuscadas, é claro. A lógica nas rotinas de verificação de dados teve que ser ajustada, também, para aceitar valores malucos (como 44 por um mês). Outros esquemas usaram variações desta abordagem. Codificar as datas como números binários de 14 bits e armazenar as representações inteiras nos campos de data foi uma abordagem semelhante no nível de bits.
Outro sistema que reaproveitou os seis dígitos usados para armazenar datas dispensou totalmente os meses. Em vez de armazenar MMDDYY, eles mudaram para um DDDCYY formato:
Soluções alternativas também abundaram. Um método era escolher um ano como ano pivô. Se todos os seus dados existentes fossem mais recentes do que 1921, você poderia usar 1920 como ano pivô. Qualquer data entre 00 e 20 significava de 2000 a 2020. Qualquer data de 21 a 99 significava de 1921 a 1999.
Essas soluções eram de curto prazo, é claro. Você comprou algumas décadas para implementar uma correção real ou migrar para um sistema mais novo.
Revisitar sistemas em funcionamento para atualizar correções antigas que ainda estão em execução? Okay, certo! Infelizmente, a sociedade não faz muito – basta olhar para todos os aplicativos COBOL que ainda são amplamente usados.
RELACIONADOS: O que é COBOL e por que tantas instituições confiam nele?
Consertar sistemas internos era uma coisa. Consertar o código e, em seguida, distribuir patches para todos os dispositivos do cliente em campo era outra, totalmente diferente. E as ferramentas de desenvolvimento de software, como bibliotecas de software? Eles prejudicaram seu produto? Você usou parceiros de desenvolvimento ou fornecedores para parte do código do seu produto? O código deles era seguro e compatível com o ano 2000? Quem era o responsável se um cliente ou cliente tivesse um problema?
As empresas se viram no meio de uma tempestade de papelada. As empresas estavam se atropelando, solicitando declarações legalmente vinculantes de conformidade de fornecedores de software e parceiros de desenvolvimento. Eles queriam ver seu Plano de preparação para o Y2K abrangente e seus relatórios de revisão e correção de código para o Y2K específicos do sistema.
Eles também queriam uma declaração confirmando que seu código estava seguro para o ano 2000 e que, caso algo ruim acontecesse em ou depois de 1º de janeiro de 2000, você aceitaria a responsabilidade e eles seriam absolvidos.
Em 1999, eu trabalhava como gerente de desenvolvimento de uma software house com sede no Reino Unido. Fizemos produtos que fazem interface com sistemas telefônicos comerciais. Nossos produtos desde os call centers profissionais de tratamento automático de chamadas confiam diariamente. Nossos clientes eram jogadores importantes neste campo, incluindo BT , Nortel e Avaya . Eles estavam revendendo nossos produtos rebatizados para um número incontável de clientes em todo o mundo.
Nas costas desses gigantes, nosso software estava sendo executado em 97 países diferentes. Devido aos diferentes fusos horários, o software também passava pela meia-noite na véspera de Ano Novo de 1999, mais de 30 vezes !
Desnecessário dizer que esses líderes de mercado estavam se sentindo um tanto expostos. Eles queriam evidências concretas de que nosso código era compatível. Eles também queriam saber se a metodologia de nossas revisões de código e suítes de teste eram sólidas e se os resultados do teste eram repetíveis. Nós passamos pelo mutilado, mas saímos com um atestado de saúde limpo. É claro que lidar com tudo isso exige tempo e dinheiro. Mesmo que nosso código fosse compatível, tivemos que suportar o golpe financeiro de prová-lo.
Ainda assim, saímos mais leves do que a maioria. O custo global total de preparação para o Y2K foi estimado entre US $ 300 e US $ 600 bilhões pelo Gartner e US $ 825 bilhões pela Capgemini . Só os EUA gastaram mais de US $ 100 bilhões. Também foi calculado que milhares de anos-homem foram dedicados a resolver o bug do Y2K.
Não há nada como colocar seu dinheiro onde está sua boca. Na véspera de Ano Novo de 1999, John Koskinen, presidente do Conselho do Presidente para a Conversão do Ano 2000, embarcou em um vôo que ainda estaria no ar à meia-noite. Koskinen queria demonstrar ao público sua fé na remediação extremamente cara e plurianual necessária para preparar os EUA para o milênio. Ele pousou com segurança.
É fácil para os não-técnicos olhar para trás e pensar que o bug do milênio foi exagerado, exagerado e apenas uma maneira de as pessoas ganharem dinheiro. Não aconteceu nada, certo? Então, qual era o motivo do alarido?
Imagine que há uma represa nas montanhas, segurando um lago. Abaixo está uma aldeia. Um pastor anuncia para a aldeia que viu rachaduras na barragem e não vai durar mais de um ano. Um plano é traçado e as obras de estabilização da barragem começam. Finalmente, o trabalho de construção é concluído e a data de falha prevista passa sem incidentes.
Alguns aldeões podem começar a resmungar que sabiam que não havia nada com que se preocupar e, olhe, nada aconteceu. É como se eles tivessem um ponto cego para o momento em que a ameaça foi identificada, tratada e eliminada.
O equivalente Y2K do pastor era Peter de Jager, o homem creditado por trazer o problema à consciência pública em um artigo de 1993 da revista Computerworld . Ele continuou a campanha até ser levado a sério.
Com o amanhecer do novo milênio, de Jager também estava embarcando em um vôo de Chicago para Londres . E também, assim como o de Koskinen, o vôo de De Jager chegou com segurança e sem incidentes.
Apesar dos esforços hercúleos para evitar que o Y2K afetasse os sistemas de computador, houve casos que escaparam da rede. A situação em que o mundo se encontraria sem rede seria impensável.
Os aviões não caíram do céu e os mísseis nucleares não se auto-lançaram, apesar das previsões dos destruidores. Embora o pessoal em uma estação de rastreamento dos EUA tenha tido um leve frisson quando observaram o lançamento de três mísseis da Rússia .
Este, no entanto, foi um lançamento ordenado por humanos de três mísseis SCUD enquanto a disputa entre a Rússia e a Tchetchênia continuava a escalar. No entanto, aumentou as sobrancelhas e os batimentos cardíacos.
Aqui estão alguns outros incidentes que ocorreram:
Você se lembra daqueles anos importantes que mencionamos? Eles foram a solução que comprou pessoas e empresas por algumas décadas para colocar em uma solução real para o Y2K. Existem alguns sistemas que ainda contam com essa correção temporária e ainda estão em serviço. Já vimos algumas falhas em serviço.
No início deste ano, os parquímetros em Nova York pararam de aceitar pagamentos com cartão de crédito . Isso foi atribuído ao fato de que eles atingiram os limites superiores do ano pivô. Todos os 14.000 parquímetros tiveram que ser visitados e atualizados individualmente.
Em outras palavras, a grande bomba-relógio gerou várias pequenas bombas-relógio.
Muitos aplicativos de limpeza estão disponíveis para Windows ao longo dos anos, mas hoje em…
Seu PlayStation 4 está congelado? Seus jogos favoritos continuam travando? Reiniciar seu PS4 pode resolver…
A popularidade das mensagens de texto significou aprender uma forma totalmente nova de comunicação. Você…
A foto dos "Pilares da Criação" tirada pelo Telescópio Espacial Hubble é uma das fotos…
O Proton Drive saiu de seu estágio beta há algumas semanas, mas o aplicativo real…
Para ver suas fotos mais de perto ou para uma edição precisa , você pode…