A filosofia, como disciplina, perdeu espaço no currículo escolar e, como tópico, quase sumiu da consciência coletiva, mas isso não significa que deixamos de filosofar. Talvez façamos com menos estrutura e retórica que os mestres gregos, mas o exercício filosófico tem sido frequente. É rotineiro o testemunho (e participação) em longas racionalizações sobre o papel do estado, os conflitos geracionais, as consequências da automação do trabalho – não faltam exemplos. Nessa longa lista de discussões desejo ignorar os pontos mais controversos (click bait!) e provocar uma reflexão inusitada sobre os pontos mais cotidianos numa série de textos, com a seguinte proposição: nosso conforto e entendimento sobre tecnologia têm influência determinante na nossa opinião.

No dia 19 de julho de 2024 (sexta-feira) tivemos uma falha em sistemas de TI que afetou ao menos 8,5 milhões de máquinas que utilizam sistema operacional Windows [link], o que ocasionou a paralisação de diversas empresas ocidentais – cias. aéreas, linhas emergenciais, bancos e hospitais foram os segmentos mais afetados. O número total de máquinas é pouco representativo na base total (possivelmente menos que 1% que todas as máquinas Windows ativas), mas nessa amostra temos servidores executando tarefas críticas, de maneira que empresas como United Airlines estão buscando ressarcimento de prejuízos da ordem US$ 500mn.

O problema foi causado por uma empresa de cibersegurança chamada Crowdstrike (NASDAQ: CRWD) ao atualizar um arquivo de configuração na sua plataforma de monitoramento de invasões, chamada Falcon. A empresa foi duramente criticada por não ter feito mais testes, e por não ter feito uma atualização escalonada invés de atualizar todos os clientes simultaneamente. Do dia fatídico até hoje, a empresa perdeu US$38bn em valor de mercado (uma queda de ~40%), e a Microsoft também foi elencada nos litígios que se procederam, dado que apenas máquinas rodando Windows foram afetadas.

A discussão após o incidente focou na superfície dos fatos, orbitando a culpabilidade e grau de responsabilidade dos envolvidos. Como a atribuição de culpa cabe aos tribunais e o efeito sobre a percepção de qualidade nós só veremos com o tempo, podemos ir mais fundo com alguns questionamentos. Porque a atualização só afetou 1% das máquinas, e o que isso significa dado o tamanho do problema? Porque a correção do problema levou dias, se o problema foi identificado na madrugada da sexta-feira? E por que um provedor de serviços tem acesso suficiente ao sistema operacional para causar tanto estrago?

Sobre o número de máquinas afetadas, se tamanho estrago foi feito com 1%, qual a efetividade de uma atualização escalonada nesse caso? E se estamos falando da atualização de um sistema de proteção, feita para proteger a máquina de uma nova vulnerabilidade, quão escalonada a atualização pode ser antes que um atacante cause estragos? Como comparar quais sistemas são mais críticos entre indústrias diferentes, ou entre concorrentes? A Crowdstrike reporta atualizações sobre o incidente neste link, onde já se comprometeu em fazer alterações nos seus processos de teste e de atualização dos clientes. A solução proposta parece alinhada com a crítica consensual na comunidade de TI, então discutir esse tópico é chover no molhado. A discussão que acho interessante é que sistemas críticos contam com diversos provedores, geralmente vetados por um processo intenso de compliance técnico, então argumento que não temos um problema com a Crowdstrike mas um problema geral de continuidade e resiliência de sistemas em indústrias importantes. E antes que o pobre compliance seja criticado, proponho que o problema não está na falta de processos mas na dependência excessiva deles.

Segundo a Crowdstrike, a atualização que causou o problema foi disponibilizada por volta de 4am UTC (1am em São Paulo) e interrompida às 5h27 UTC após a realização do problema. A correção do problema foi identificada e era aparentemente simples: deletar um único arquivo chamado Channel File 291 nas máquinas afetadas (1% do total) nessa janela de ~80min. Esse contexto não reflete o que se passou nos dias seguintes, com funcionários sem acesso à seus computadores, presos na tela azul da morte no windows (link). O serviço de publicação de notícias e registros regulatórios da London Exchange saiu do ar pela manhã e retornou no horário do almoço, enquanto companhias aéreas passaram mais de quatro dias com sistemas impactados. Porque deletar um arquivo não resolveu o problema, e por que a diferença de tempo tão grande para uma tarefa aparentemente simples? Talvez uma das explicações seja que essa tarefa exige privilégios administrativos concedidos à poucos, além de certo conhecimento sobre em quais máquinas rodam os sistemas afetados. Muitas empresas têm esse privilégio e/ou conhecimento dividido com consultores e implementadores de software (terceirizados), que em momentos de crise precisam dividir atenção entre múltiplos clientes. Com os canais de atendimento dos prestadores de serviço inundados, gestores de infra foram ao Reddit buscar soluções. Outro fator complicador importante é que o Windows possui uma característica peculiar – algumas atualizações exigem reboot manual da máquina, uma dificuldade grande quando falamos de milhares de estações de trabalho e servidores espalhados em grandes data centers.

Entendendo a dificuldade de um reboot manual em escala, poder voltar o sistema para um estado anterior não deveria ser um recurso importante? Essa peculiaridade do Windows é conhecida há muito, e sistemas deveriam ser atualizados frequentemente, então por que dessa vez foi diferente e porque esse recurso nunca foi implementado em novas versões? O Linux não sofre do mesmo problema, e é potencialmente gratuito, então por que sistemas críticos rodam Windows? O engenheiro de infra não tem o mesmo argumento de usabilidade que o usuário de Excel, quais motivos justificam essa escolha? Sistemas open source, com a contribuição de toda comunidade, são mais robustos que sistemas proprietários? A provocação que quero propor é que da escolha dos sistemas até a arquitetura e manutenção, grandes empresas terceirizaram muitas tarefas, e hoje sofrem certo esvaziamento de conhecimento técnico sobre a própria operação. Muito provavelmente toda infinidade de processos em caso de falhas foi seguida por essas empresas, mas faltou capacidade de resolver o inesperado, apesar de simples, porque o processo considerou que o contrato com o vendedor de software transferiria essa responsabilidade para fora da empresa. Para quem interessar, sugiro a análise de duas autoras brilhantes sobre o tema de terceirização e dependência excessiva de consultorias, no livro disponível neste link.

Não leia para refutar ou contradizer, para aceitar ou aquiescer, para arengar ou discursar, mas para ponderar e considerar.

— Francis Bacon, Os Ensaios

Em conclusão, defenderia que não sofremos de um problema da Crowdstrike, mas um problema de resiliência da indústria de TI. O grau de concentração da indústria e sobre-dependência de prestadores de serviço chave é menos causa e mais sintoma da forma como o TI de grandes empresas é gerido. Conforto e entendimento sobre tecnologia têm influência determinante na nossa opinião sobre temas empresariais importantes, e gostaria de provocar [1] [2] uma conexão entre grandes crises de TI e o fenômeno da terceirização.

Leia também

Convergência – grandes temas e efeitos secundários