IA cuidando de incidentes afasta engenheiros dos próprios sistemas

A tese: automação de incidentes erode a prática humana

Sylvain Kalache, ex-SRE do LinkedIn e hoje à frente do AI Labs na Rootly, escreve que ferramentas de resposta a incidentes assistida por IA - os chamados "AI SREs", termo de que ele não gosta - já inspecionam alertas, formam hipóteses, consultam telemetria, correlacionam implantações recentes e até implementam correções sozinhas. Ele conta que, em 2012, quando era SRE no LinkedIn, projetou um protótipo de sistema auto-curável que aprendia com incidentes anteriores; as capacidades de IA da época não permitiam levá-lo adiante, e isso hoje virou realidade.

Apesar de reconhecer o valor - sobretudo quando a ferramenta resolve um incidente de rotina à noite, sem acordar ninguém para um problema de capacidade -, sua preocupação central é que estamos perdendo contato com nossos sistemas. Quanto melhores as ferramentas ficam em resolver incidentes rotineiros, menos prática os respondentes humanos terão. E quando chegar um incidente ambíguo de alta severidade que a automação não consiga resolver, os engenheiros estarão em desvantagem.

O paradoxo da automação

O argumento se apoia em Lisanne Bainbridge, pesquisadora de fatores humanos, que descreveu o paradoxo no artigo de 1983 "The Ironies of Automation": a automação reduz as oportunidades de praticar o trabalho rotineiro, mas mantém os operadores responsáveis por situações novas e anormais. Ela conclui que operadores precisam ser mais qualificados e receber ainda mais treinamento do que antes da automação.

Kalache faz uma previsão: o MTTR médio da maioria dos incidentes deve cair graças à resposta assistida por IA, mas o tempo de resolução de incidentes complexos deve disparar, porque os respondentes perderam contato com o sistema e terão dificuldade de investigar.

A lição da aviação

A indústria da aviação serve de inspiração. A automação das aeronaves cuida de boa parte do voo, mas os pilotos permanecem responsáveis por situações que a automação não administra: falhas de motor, instrumentos não confiáveis, arremetidas de decolagem rejeitadas, estol e outras condições anormais.

Esses eventos são raros: motores turbofan modernos têm menos de uma desligada em voo por 100.000 horas de voo - um piloto comercial pode passar a carreira inteira sem vivenciar uma fora do simulador. Mas, quando ocorrem, a reação precisa ser rápida e correta. Kalache cita o voo 235 da TransAsia Airways: o autofeather da hélice do motor direito acionou logo após a decolagem e, embora a aeronave fosse projetada para voar com o motor esquerdo, a tripulação identificou errado o problema; o avião entrou em estol e caiu 117 segundos após o primeiro alerta.

Sob regras da FAA nos EUA, capitães devem cumprir treinamento recorrente ou verificação de proficiência a cada seis meses, incluindo cenários como falha de motor na decolagem. Kalache argumenta que, embora a maioria dos incidentes de software não ameace vidas, isso não é razão para não aperfeiçoar o ofício - e a própria tecnologia que criou o problema pode ajudar a fechá-lo.

Simuladores de incidentes e IA como treinadora

Na Rootly, empresa de gestão de incidentes onde trabalha, a equipe fez parceria com a Uptime Labs para aplicar a ideia por meio de simulações realistas: o engenheiro assume o assento de incident commander durante uma interrupção simulada de e-commerce, usando ferramentas de observabilidade enquanto coordena stakeholders movidos por LLM no Slack. O resultado, segundo ele, parece real - é preciso investigar enquanto mantém a resposta organizada e lida com o CEO e o suporte ao cliente, praticando habilidades como interpretar informação incompleta, comunicar-se com clareza e coordenar pessoas.

Ele também considera o uso da IA como treinadora: responderes podem pedir a um agente que explique os passos que tomou, os sinais que examinou e as evidências do diagnóstico. Mas explicar e observar não substituem a prática - assim como assistir Serena Williams não ensina tênis; só se aprende entrando em quadra. Kalache passou mais de meio século... [corrigindo] mais de meio decênio de carreira construindo uma escola de engenharia de software baseada em aprendizado progressivo, sem professores e com projetos; quando o Dropbox disse que graduados contratados ainda tinham pouca experiência em troubleshooting, ele criou projetos que entregavam infraestrutura quebrada para diagnosticar e reparar. Para habilidades manuais, ele acredita que educação prática vence a instrução passiva com folga.

Dívida de compreensão e prontidão de on-call

À medida que LLMs fazem mais do trabalho, equipes de engenharia arriscam acumular "comprehension debt": uma distância crescente entre como seus sistemas funcionam e quão bem os respondentes os entendem. Engenheiros deveriam interagir regularmente com o sistema que vigiam, lidar com falhas desconhecidas, praticar sob pressão e ensaiar a coordenação e comunicação exigidas em um SEV0. Exercícios de tabletop e chaos engineering não são novidade, mas a prática ficou ainda mais importante na era dos LLMs.

Kalache fecha retomando Bainbridge, que recomendava controle prático regular pelos operadores e uso de simulação para evitar a decaimento das habilidades. Essa é a ironia da automação: quanto mais bem-sucedida, menos preparados os humanos podem estar para o momento em que ela falhar.