Apresentação: O Claude consegue resolver o problema sozinho? Utilização de LLMs na resposta a incidentes
Transcrição
Alex Palcuie: Sou o Alex. Faço parte da equipa de fiabilidade de IA da Anthropic, o que significa que o meu trabalho é manter o Claude a funcionar. Tenho utilizado modelos de linguagem de grande escala (LLMs) no âmbito da resposta a incidentes reais e gostaria de partilhar uma discussão sincera e bem-humorada sobre o que funciona e o que não funciona. Sou uma das duas pessoas que se juntaram à equipa de fiabilidade em Londres. Fiquei de plantão para a pilha de serviços do Claude, o Solo, durante os meus primeiros três meses, o que é uma forma muito eficaz e rápida — mas realmente stressante — de aprender sobre o sistema. Depois, integrei todos os outros para poder deixar de estar de plantão para sempre. Antes disso, trabalhei na Google, como SRE no produto de computação do Google Cloud, o GCE. Fazia parte da equipa de SRE para a equipa de SRE, que é a camada de escalamento para quando uma falha é grave o suficiente para que até os SREs normais queiram recuar. Já estou a fazer plantões há algum tempo. Tenho as minhas opiniões sobre o que torna um processo de resposta a incidentes bom e o que o torna mau. Embora, naturalmente, fosse cético no início, desde janeiro deste ano que comecei a fazer algo que me parece um pouco transgressivo admitir: recorro ao Claude antes de consultar os meus painéis de monitorização.
O Claude consegue resolver os vossos incidentes?
Então, estão a fazer-se a pergunta que me fazem constantemente em jantares, quando alguém me encontra no corredor desta conferência, ou pelos meus amigos da minha antiga empresa, onde os vice-presidentes lhes dizem para fazerem algo com IA: o Claude resolve mesmo os vossos incidentes? A rotação de plantão é agora só o Claude? Basicamente, automatizaste o teu próprio trabalho, tal como o livro original sobre SRE escreveu há mais de 10 anos? Compreendo por que razão as pessoas perguntam isto. Se há alguém que tem isto a funcionar, é a empresa que cria o modelo. Temos tokens ilimitados. Os investigadores estão sentados numa secretária ao meu lado. Eu próprio participo na formação dos modelos. Certamente, se há alguém capaz disso, somos nós. Deixem-me esclarecer logo a resposta. A resposta é «não». Quero refletir sobre esse «não» por um segundo. Seria genuinamente hipócrita da minha parte estar aqui a dizer-vos que o Claude resolve tudo.
A minha equipa vai completar, em breve, o seu primeiro aniversário. Se um LLM pudesse andar com um pager, talvez não precisássemos de contratar tanta gente. O facto de a minha equipa existir, o facto de estarmos a recrutar para muitos cargos, em Londres, em Dublin e nos EUA, e de termos cargos efetivos, isto deve mostrar-vos que, não, não funciona. No entanto, há um asterisco aqui. O asterisco está relacionado com os prazos. Penso que muitos de nós não ficariam surpreendidos se, num futuro qualquer, fôssemos capazes de fazer tal coisa. Hoje, também destaco as formas úteis como o Claude me ajuda durante o meu plantão. Voltando ao assunto, o Claude fica fora de serviço com mais frequência do que qualquer um de nós gostaria. Há pouco, estive envolvido num incidente, mesmo estando numa conferência. Talvez tenham reparado nisso, e alguns de vocês até tenham publicado tweets sobre o assunto; partilho exatamente do mesmo sentimento quando o Claude fica fora de serviço. Cheios de opiniões, as pessoas estão a marcar-me. Por favor, continuem a fazê-lo. Estes são os tweets positivos. Também recebi alguns maldosos, mas assim são as redes sociais hoje em dia.
SRE com IA
Há ainda mais. Conheço, neste momento, pelo menos 10 empresas cujo argumento de venda gira inteiramente em torno de alguma versão de AI SRE. Como também sou bastante aberto em relação ao investimento anjo, as pessoas, por alguma razão, pensam que eu seria menos cético em relação a elas, mas na verdade sou ainda mais cético. Existem agora benchmarks. Existem conjuntos de dados selecionados. Existem incidentes históricos. Há o desafio de saber que percentagem destes incidentes a tua aplicação consegue resolver. Há artigos científicos. Há, praticamente, toda uma indústria de plantões. A visão cínica que poderíamos ter numa sala cheia de engenheiros seniores que já viram ciclos de hype antes é, claro, que desta vez vai ser mesmo. Há dinheiro de capital de risco a circular. Era inevitável que alguém aplicasse a IA às operações, dissesse que o mercado total acessível (TAM) é de milhares de milhões, que vai engolir o setor da observabilidade e a nossa remuneração acima da média. Eles avançam, angariam uma Série A junto de investidores. Esses investidores estão a construir um portfólio diversificado.
Há a IA no direito, há a IA na saúde e há o AIOps. Sim, é muita coisa. Esta não é uma lista exaustiva. Enquanto escrevia os slides, surgiram pelo menos mais duas empresas. O cinismo é justificado. Alguns dos critérios de avaliação são do tipo: será que o modelo consegue resolver estes problemas pré-definidos com um prompt claro? Não é isto que se analisa às 3 da manhã, quando se recebe um aviso. Os incidentes reais não são problemas bem formatados. Não sou cínico em relação ao objetivo. Sinceramente, sem ironia, estou a torcer por estas pessoas. Quero que elas pratiquem. Não é pelas razões que as pessoas normalmente supõem. A razão é que o plantão é um imposto que cobramos aos seres humanos porque os nossos sistemas não são suficientemente bons para se cuidarem sozinhos. Quantas pessoas aqui já estiveram de plantão? Sabem como é na prática. O telemóvel vibra, há meio segundo em que se passa do sono para, provavelmente, o modo de comandante de incidentes.
Não é que cada chamada individual seja má. Eu até gosto de um bom incidente. O problema é o peso acumulado desta situação ao longo dos dias. Nunca é propriamente relaxante. Pelos padrões do plantão, sou um dos sortudos. Tenho seguido a rotação solar. Londres passa o testemunho à Costa Oeste às 18h, por isso posso ir ao pub. O pior cenário para mim é acordar às 6 da manhã. Tal como alguns de vocês, que acordam às 3 da manhã ou à 1 da manhã. Estão numa rotação de plantão 24 horas por dia, 7 dias por semana. Provavelmente são quatro pessoas. Recebem uma chamada às 3 da manhã. Vão dormir, recebem outra chamada às 4h30 porque a outra base de dados está em falha. Depois, às 9 da manhã, aparecem no trabalho e têm de estar na reunião diária, com um ar profissional e apresentável. Já passei por isso na minha carreira. Além disso, quero deixar claro que isto não deve ser um motivo de orgulho. A nossa indústria, por vezes, trata-o assim, como se fossem «histórias de guerra». Nas salas de pânico, usamos metáforas de combate. É um custo em termos de sono, de atenção e das nossas relações com as pessoas. Quando alguém me diz que estamos a desenvolver SRE com IA, a minha primeira reação pode ser: «Isso nunca vai funcionar.» E penso: «Espero que consigam fazer isto bem.»
Há uma segunda razão, que é mais fria e calculista. Um dos melhores conselhos que recebi no início da carreira, de alguém mais experiente do que eu, foi que não se é promovido por resolver incidentes. Lembro-me de ter pensado que isso estava errado da primeira vez que o ouvi, porque parece que deveria ser assim. És o herói. Foste chamado. Descobriste o que se passava. Resolveste o problema. O serviço voltou a funcionar e as pessoas agradeceram no canal do Slack. No início, quando és júnior, isso conta mesmo. Tipo: «Será que consigo resolver um problema grave num sistema de produção?» É um sinal claro de que estás no caminho certo para te tornares um bom engenheiro. Mas isso deixa de contar muito rapidamente. Quando já és sénior, é claro que consegues resolver isto. Isso é o mínimo exigido. Faz parte da tua descrição de funções. O que realmente faz a diferença no jargão das grandes empresas de tecnologia, o que te leva a ser promovido, o que te torna o líder técnico, é quando as pessoas dizem: «Ele está a operar a um nível diferente.»
É criar a solução que faz com que todo esse tipo de incidentes simplesmente não aconteça. Não é resolver aquele problema pontual, mas sim criar uma estrutura que garanta que esses problemas nunca mais voltem a acontecer. É aqui que o sonho da IA de plantão se concretiza para mim, se — e isto é um grande «se» — um LLM conseguir lidar com as medidas de mitigação genéricas, as reversões óbvias, as perguntas do tipo «já tentaste?», as medidas de correção padrão. Nesse caso, nós, os humanos, podemos dedicar-nos à parte da prevenção, à parte da plataforma, às coisas que são escaláveis. Isso é um sonho, e quero que resulte.
O Ciclo OODA (Observar, Orientar, Decidir, Agir)
Eis o quadro que utilizo para explicar a gestão de incidentes. Vou utilizá-lo ao longo de grande parte da apresentação. É de um coronel da Força Aérea dos EUA que costumava treinar pilotos de caça. Ele tentava explicar por que razão alguns pilotos vencem consistentemente outros pilotos, mesmo voando em aeronaves menos avançadas. A resposta era: não era a aeronave. O vencedor era aquele que completasse mais vezes este ciclo de «observar»: o que está a acontecer? «Orientar»: o que é que isto significa? Qual é o meu modelo mental? «Decidir»: o que vou fazer a respeito? «Agir»: tomar a decisão. Depois, mais uma vez, receber o feedback, porque o mundo mudou, e repetir este ciclo. Sinto que isto se aplica, não na perfeição, mas muito bem, à resposta a incidentes. Recebes uma chamada. Analisas os teus gráficos. Analisas os teus registos. Construíste um modelo mental do que poderá ter falhado.
Decides uma medida de mitigação. Depois, vais a um terminal, escreves o comando e executas-o. A razão pela qual gosto deste modelo é que os LLMs e a resposta a incidentes não são uniformemente bons nem uniformemente maus. São simplesmente extremamente desiguais — usamos o termo «irregular» na indústria — ao longo das etapas deste ciclo. Geralmente, é sobre-humano numa delas. É bastante perigoso noutra parte. É realmente obscuro em duas das partes.
Ciclo de Observação — Sobrenatural
Deixem-me explicar-vos o ciclo de observação, onde considero que os LLMs são sobre-humanos: ao recolherem sinais de um sistema, lerem os painéis de controlo, consultarem as métricas, extraírem os registos e encontrarem a agulha no palheiro. Isto é algo que, embora nos treinemos e nos tornemos bons nisso, não surge naturalmente. Além disso, a nossa atenção limitada não é paralelizável nem escalável. O Claude — vou dizer isto sem rodeios, e podem substituir o Claude por qualquer LLM que utilizem — é simplesmente melhor. Não é necessariamente mais inteligente, mas é muito rápido e consegue clonar-se a si próprio. Consegue aceder a todos os endpoints de métricas que tiveres em paralelo com o PromQL e escrever a sintaxe quase sem erros. Não se cansa de alterar as variáveis. Lê os registos à velocidade da E/S, assim que estes chegam. Já não se aborrece com 2 000 ou 4 000 linhas. Isto, em grande escala, é algo que nenhum ser humano consegue igualar.
O que menos gostamos, então, são as histórias. É 31 de dezembro, véspera de Ano Novo, equipa reduzida ao mínimo. Não me lembro se estava de plantão. Acho que não estava de plantão, mas o Claude Opus 4.5 estava a registar 500 erros HTTP internos. Abro o meu Claude Code e peço-lhe para dar uma vista de olhos com esse prompt específico. Não se trata apenas desse prompt; escrevi o meu próprio ficheiro SKILL.md que ensina ao modelo o ciclo de vida de um pedido, como um pedido chega aos servidores de borda e, em seguida, aos front-ends da API, onde fazemos o controlo de admissão, a verificação de quotas e toda a lógica de negócio enfadonha. Depois, segue para os backends de inferência, onde temos aceleradores como GPUs, TPUs e Trainiums em várias nuvens, e a multiplicação de matrizes ocorre, e os tokens são enviados ao utilizador. Depois de ter pensado nisso, há outro ficheiro comum a toda a empresa, que ensina ao Claude onde fica o nosso armazém de dados, quais são as tabelas mais importantes, quais são os campos e, mais importante ainda, como fazer introspecção e servir-se sozinho caso precise de mais informações. A parte seguinte da conversa foi resumida e retirei informações confidenciais. Publiquei internamente uma grande parte dela na Anthropic.
O Claude vai buscar os erros do servidor da última hora. Limita-se a escrever uma consulta SQL e, em segundos, tem a resposta: uma exceção não tratada no percurso de processamento de imagens. Estranho. 31 de dezembro. Em seguida, acede à base de código — uma vez que está no monorepo —, identifica o tipo de erro onde este foi gerado e descobre uma possível explicação para o que aconteceu. Na verdade, publicou o traço de pilha completo, mas não vos vou aborrecer com Python. No entanto, não fica por aí. Este caminho de código está ativo há semanas. É registado. Verifica se alguém o alterou recentemente e ninguém o encontrou até esta noite. Recolhe três pedidos com falha, lê o JSON bruto da carga útil e um deles tem uma matriz de imagens com exatamente 22 imagens, tendo um PDF anexado. Na segunda e na terceira, o sistema recolhe ainda mais, e o bug acaba por ser desencadeado na 22.ª.
Porque é que isso aconteceria? Pergunta-se: quem é que está a enviar isto? Executa-se outra consulta, na qual se analisam os registos de pedidos, e verificam-se cerca de 200 contas, todas a enviar exatamente 22 imagens, a partir desta noite, aproximadamente à mesma hora. Ora, isto, como diz a geração mais jovem hoje em dia, é bastante suspeito. O sistema executa outra consulta. Não pára, é implacável, para descobrir quantas contas foram criadas nesse período. Cerca de 4 000. A mesma janela. O mesmo modelo de e-mail. O mesmo fornecedor. Para citar o famoso cantor e compositor: «Eu sabia que eras problema assim que entraste»; as outras 3 800 contas não enviaram uma única solicitação. Estão inativas, ali paradas desde 28 de dezembro, à espera. O sistema executa outra consulta e, em seguida, analisa a frequência com que estas contas foram criadas, tendo constatado que estavam a registar-se a um ritmo de 9 por minuto. Isso parece, grosso modo, o que eu esperaria de alguém envolvido em abuso de contas, talvez a definir um limite.
Depois, diz: «Pára de olhar para os erros 500, isto é fraude.» Não é «pode ser suspeito» nem «não vale a pena sinalizar». Deixei literalmente o «Claude» à sua sorte, naquele momento em que ele fica realmente entusiasmado, quando encontra algo, porque fiquei chocado. Eu teria olhado apenas para os erros 500, os erros internos. Teria marcado isto como um bug para a minha equipa de API. Não teria contactado a equipa de abuso de contas a 31 de dezembro para se juntarem a mim e começarem a analisar a situação do lado deles, porque não tenho acesso a dados pessoais (PII) para saber o que se passava ali. Seria de esperar que este fosse o meu teclado a partir de agora. Fui tirar uma licenciatura em ciências da computação e recebi três teclas. Na IA, há aquela famosa jogada 37, em que o AlphaGo, o algoritmo da DeepMind, estava a jogar contra Lee Sedol, há mais de 10 anos. Todos os jogadores de Go ficaram chocados, a pensar: «Porque é que a IA estava a fazer aquilo?» Muitas pessoas têm os seus momentos pessoais «jogada 37». Este foi o meu momento «jogada 37». Naquele dia, soube que este ano seria especial.
História número dois. Esta também é positiva. Tivemos erros de pânico do Rust em produção. Enquanto eu analisava os registos manualmente — porque isto é algo que ainda faço, não sei porquê —, um dos meus colegas de equipa mais recentes, que nem sequer tinha formação para estar de plantão e estava na equipa há dois ou três meses, limitou-se a apontar o Claude Code para os registos. O programa encontrou instantaneamente a causa principal, como um «panic» do Rust no ficheiro checkpoint.rs, relacionado com a validação de um ID de segmento, indicando o ficheiro, o número da linha e a mensagem de asserção, mesmo antes de eu terminar de ler as minhas duas páginas de registos. Depois, ele pediu novamente para obter a análise completa do volume, como um zilhão de «panics» em cinco minutos, seguidos de uma queda e, em seguida, de um novo pico. O Claude é muito útil, mesmo em duas plataformas de hardware independentes, pelo que não preciso de contactar os meus CSPs para lhes perguntar. Ainda não está a raciocinar sobre a causa. Está apenas a recolher sinais muito mais rapidamente do que até mesmo os especialistas na matéria conseguem fazer.
Os erros de pânico estão todos nos servidores de pré-preenchimento. Trata-se de um ID de segmento duplicado. Deixa-me verificar quando é que o binário foi implementado, se houve ou não uma alteração na implementação imediatamente antes de os erros de pânico terem começado. O sistema simplesmente descobre isso antes de mim. O novo membro da equipa é muito mais eficaz do que as pessoas com experiência, porque não está sobrecarregado pelo facto de ter de ir manualmente verificar estas coisas.
Ciclo de Orientação
Agora vamos falar da parte do Orient. É aqui que o ciclo OODA se torna interessante para os LLMs. Esta é, finalmente, uma história de falha. A primeira coisa que preciso de vos explicar é algo que acontece com a inferência dos LLMs, para que compreendam realmente a lógica de negócio e o que correu mal. Quando se dá um prompt ao Claude, ou a qualquer transformador, a forma mais simples de gerar tokens é pegar na sequência inteira — que nunca vai acabar, é a primeira —, passá-la na íntegra pelo transformador e, assim, obter o primeiro token gerado. Depois, pega-se nessa sequência inteira novamente, passa-se-a mais uma vez pelo transformador e obtém-se o token seguinte, o que nunca acontece. Estás a anexar tudo, mas isto é extremamente ineficiente e ninguém faz isso da forma ingênua. Isto é usado apenas no meio académico para explicar. Porque, quando chegares ao token 1 000, já terás reprocessado o token 1 mil vezes para as mesmas multiplicações matriciais.
O truque chama-se cache KV, durante o que chamamos de etapa de atenção, em que cada token produz uma chave e um vetor de valor e, o que é crucial, estes não se alteram. Podemos guardá-los algures. Esse é o diagrama na parte inferior. Agora, a inferência tem duas fases. Há o pré-preenchimento, em que se processa todo o prompt numa grande passagem paralela. Guarda-se todos os pares chave-valor neste cache, e é a isto que chamamos de «compute bound», porque se estão a realizar muitas multiplicações matriciais. Depois, na fase de descodificação, ou de geração, utiliza-se este cache KV e, em seguida, introduz-se um token de cada vez na máquina. Em vez de reprocessar todo o prefixo, basta uma única passagem. É por isso que, caso alguma vez se tenha questionado, os tokens aparecem como um fluxo no Claude, no ChatGPT e no Gemini, porque são realmente gerados um a um. Se o seu fornecedor de inferência estiver a utilizar um tamanho de lote grande, poderá notar que o processo fica mesmo muito lento.
Se uma máquina avariar, acontece o mesmo. Normalmente, mantemos tudo otimizado para que tenhas uma boa experiência de utilizador. Este cache KV pode ter vários gigabytes de tamanho e é muito fácil de avariar. É muito delicado. É frágil. Quando o cache KV falha, de repente tem de voltar a preencher antecipadamente muitos prompts. Isso representa uma grande quantidade de computação para a qual não estava preparado. Esta é uma classe de incidentes que ocorre com bastante frequência no Claude. Quando isto acontece, é assim que os meus gráficos ficam. A linha cinzenta representa os pedidos de filtragem. A linha vermelha representa o número de erros. A laranja representa a janela do incidente. Reparem na forma. Os pedidos praticamente duplicam exatamente no momento em que os erros surgem. Depois, ambos descem em simultâneo. Sempre que isto acontece, pergunto ao Claude: «O que se passou aqui com este gráfico?» O Claude responde: «O volume de pedidos aumentou. Trata-se de um problema de capacidade. Basta adicionares mais servidores.»
Já corrigi isto seis ou sete vezes. Adiciona-se isso ao CLAUDE.md e ele compreende esta situação. Nas outras 99 situações, vai confundir correlação com causalidade. Não ajuda em nada. Se tiveres um novo colaborador na tua equipa, ele será imediatamente levado a pensar dessa forma. Pensará imediatamente: «É um problema de capacidade», quando, na verdade, o que aconteceu foi que perdeste o teu cache. Que tal ires corrigir o teu cache e perceberes o que se passou? Talvez consiga salvar a situação. É por isso que acho que não podemos confiar nos LLMs para a resposta a incidentes. Se ele pudesse dar um passo atrás e tentar distinguir entre causalidade e correlação... Sei que, para nós, humanos, também é difícil. Lutamos todos os dias com isto. Vemos duas linhas e pensamos: «Foi uma implementação, obviamente.» Ou «Foi outra coisa qualquer.» Temos essas cicatrizes. Temos experiência. Já vi esta falha demasiadas vezes no último ano. Não posso ignorar esta possibilidade. Posso explorar outras possibilidades.
Automação
Vamos falar sobre automação numa perspetiva de nível superior. Nós, na engenharia de software, não somos os primeiros a ter de lidar com sistemas automatizados. A Sociedade de Engenheiros Automotivos, as pessoas que fabricam automóveis, publicou um quadro de referência em 2014, há mais de 10 anos, sobre automóveis autónomos. Porque foi nessa altura que começámos a falar de automóveis autónomos. Ainda não em Londres. Tentaram mapear como seriam os carros autónomos para poderem ter modelos mentais. Escreveram sobre várias partes com várias fases. Uma coisa que os carros autónomos precisam de fazer é a execução, como a direção e a aceleração. A outra é monitorizar o ambiente de condução. A outra parte é o desempenho de contingência, que é o nome de código para situações em que algo inesperado acontece, como um cruzamento bloqueado ou a necessidade de ultrapassar um carro estacionado. Por fim, o seu maior desafio, a que chamam «âmbito e capacidade do sistema», o que, na minha opinião, se traduz em: será que este carro só conduz de forma autónoma quando está sol na Califórnia?
Ou será que consegue realmente conduzir sozinho quando está a chover em Londres? Porque não se pode simplesmente aplicar o que funciona num cenário ao outro. À medida que se sobe de nível, cada vez mais dessas colunas são preenchidas por sistemas em vez de por seres humanos. Por vezes, num determinado nível, há uma combinação de ambos. A maioria dos carros modernos que se podem comprar atualmente está, na verdade, no nível 2. Temos a travagem automática porque confiamos nessa tecnologia. Temos o seguimento de faixa e o controlo de velocidade de cruzeiro. O nível 3 é onde as coisas ficam interessantes. Penso que a Tesla já dispõe de condução totalmente autónoma nos EUA e, na Europa, temos a Mercedes e a BMW, mas apenas na Alemanha. Isso era o nível 3. O nível 4 é o mais emocionante. É a Waymo. Não há condutor, é apenas um táxi. Entramos no carro e vemos o volante a mover-se sozinho. Observamos na rua como carros sem ninguém a bordo se deslocam de A para B.
Os Waymos também já circulam nas ruas de Londres, em fase de testes. Reclamei com um amigo meu que trabalha lá: por que é que estão a demorar tanto? Na minha cabeça, basta pegar nos pesos do modelo de São Francisco, inverter a sinalização e o carro já consegue circular do outro lado da estrada. Ele diz-me que não é assim que se faz investigação.
Queria aplicar isto ao meu trabalho, à engenharia de produção. Alguns de vocês já viram isto antes, talvez numa apresentação anterior. Na minha opinião, as colunas representam a deteção, ou seja, quem identifica que algo está errado. Seja a detecção de anomalias ou a correlação de sinais — que são as partes mais sofisticadas —, ou, na verdade, se tenho bons alertas quando ocorrem erros internos. Depois, há a resposta inicial, que executa as medidas de mitigação, como restaurar os servidores, executar os comandos `kubectl scale`, o failover, os rollbacks, reduzir a quota do utilizador em causa, ou seja, conter o dano, como costumamos fazer. Depois, há a prevenção, em que alguém faz uma análise mais aprofundada para melhorar o sistema, como examinar os fatores que contribuíram para o problema e quais são as alterações na arquitetura. Ou seja, o trabalho que garante que isto não volte a acontecer. Depois, tal como acontece com os especialistas em carros autónomos, temos o domínio operacional. Será que este sistema lida apenas com o serviço principal cuidadosamente instrumentado que tenho, ou posso simplesmente «lançar» este agente de IA numa equipa diferente?
Ele vai aprender sozinho e perceber o que se passa. Eu eliminei o nível 0. Tivemos sorte. Conseguimos a automatização, porque os computadores são bastante bons. O nível 1 é apenas alguma assistência na deteção. O nível 2 é onde a maioria dos sistemas maduros chega. A observabilidade é totalmente automatizada. Temos alertas a disparar de forma fiável. Mesmo que não seja IA, continua a ser automatização. Correlacionámos alguns sinais e é aí que chegamos. Os humanos continuam a executar as medidas de mitigação e continuam a escrever todas as correções. Será que podemos passar do nível 3, onde nos encontramos agora, com humanos e IA na resposta, para o nível 4? É disso que tenho vindo a falar. Tipo, retirar os humanos da resposta a incidentes. O nível 5, na minha opinião, é simplesmente a IA Geral (AGI). Se for possível colocar um agente em qualquer lugar e tê-lo como colega de equipa, isso seria realmente fantástico.
Receitas do que fazer
Este foi o panorama geral. Foi o aspecto genérico. Foi o enquadramento da situação. Tenho agora cinco coisas que vi a funcionar na minha equipa, na minha empresa e para mim próprio. Surgiram ao longo de cerca de um ano de tentativa e erro por parte de todos. Padrão 1: foste chamado e há um alerta. És uma pessoa sensata, por isso o teu alerta está algures integrado na tua infraestrutura como código e tem um PromQL ou qualquer outra linguagem de consulta por trás. Não abras um chat em branco. Não te limites a copiar e colar coisas. Basta dares essa expressão ao teu agente de IA e passares ao Claude algumas instruções que, grosso modo, dizem: «sê curioso». Analisa isto por mim. Eis como o meu sistema está configurado: encontra coisas que eu normalmente não iria verificar. O teu Claude funciona em paralelo, ou pelo menos o meu funciona. Ele vai analisar os teus endpoints. Vai verificar se se trata de algo específico por região ou por nuvem.
Vai agir com base no código de estado. Vai analisar a semana passada e comparar o tráfego. Vai emitir essas consultas, creio eu, mais rapidamente do que tu conseguirias fazer ao analisar detalhadamente os teus painéis. Ou, se o puseres a funcionar quando fores chamado e, 5 a 10 minutos depois, chegares ao teu computador, já terás um panorama preparado para ti. Achámos isto extremamente útil. Tal como no meu exemplo anterior com a fraude, o Claude consegue detetar muito mais coisas, e isso é muito útil. Não se trata de uma grande mudança, basta apresentar o alerta de forma assíncrona a um agente.
Segundo, obtenha um exemplo, rastreie-o pelo seu sistema, mas, na verdade, basta pedir ao Claude para o fazer por si. Eu gerencio sistemas díspares com padrões de registo diferentes e com fontes de registo distintas em diferentes nuvens. A única coisa que os une é um ID de rastreio. Sempre que preciso de verificar o que aconteceu na entrada, na API ou ao nível da inferência, antes eu limitava-me a abrir cada uma dessas janelas. Tinha os marcadores, ou tinha um marcador de marcadores. Se pedires ao Claude para o fazer ele próprio, isso é realmente muito útil, porque cria uma linha do tempo no seu contexto e podes começar a interagir com essa linha do tempo. Pode ver que essa solicitação passou por três servidores, voltou para a API, onde o tempo limite de 10 segundos expirou, e foi por isso que retornei o erro. Isso mostra-lhe que, sim, o tempo limite não ocorreu na API; na verdade, foi no backend.
Ele faz isto e é capaz de, de forma coerente, acompanhar o ciclo de vida de uma solicitação. Também é capaz de indicar que foi este servidor. Pode começar a questionar: e quanto a esse servidor? Estava com a CPU sobrecarregada ou o problema estava na memória? Isto abre muitas possibilidades, mesmo que, por vezes, seja necessário voltar a verificar a informação obtida a partir do modelo.
O padrão número três é: o que mudou nesta janela? Abri uma discussão na «unconference» sobre esta vertente. Entrei para uma empresa onde não havia muitas implementações, nem muitas atualizações de configuração, e, embora a implementação de monólitos seja ótima, também não é escalável. Agora vivo num mundo de microsserviços, onde os serviços são lançados constantemente, através de atualizações de configuração, de feature flags e de tarefas cron. É-me muito difícil estabelecer uma correlação entre o que mudou e o momento em que o meu incidente começou. Criámos este sistema de acompanhamento artesanal de todas as grandes alterações que ocorrem na empresa. É selecionado, no sentido em que não vamos sobrecarregá-lo com 100 QPS de eventos. Se indicares ao Claude o intervalo de tempo em que o teu incidente ocorreu, ele informará-te muito rapidamente sobre as implementações. Além disso, irá verificar se existe algum commit que afete o pré-processamento da imagem.
O que é muito útil para encontrar vias de depuração e investigação. É um pouco como o que eu fazia manualmente anteriormente. Agora, obviamente, não se pode ficar muito entusiasmado só por ter encontrado a causa raiz. É do tipo: «Não. Encontraste três possíveis problemas que poderiam ter ocorrido e precisamos mesmo de analisar a fundo.» Se ele sugerir: «Talvez devas reverter isto», e se, por sorte, as tuas reversões forem fáceis, então, sim, basta reverter. Verifica se os erros já desapareceram. É muito mais rápido e poupa imenso esforço.
Número quatro: análises pós-incidente ou retrospetivas. O Claude é bom nas partes tediosas. Tipo, eu costumava detestar isto. Peço imensa desculpa a alguns dos engenheiros com quem trabalhei, mas às vezes sentia que era uma forma de «ensinar pelo fogo» para integrar os engenheiros mais juniores ou de nível médio que se juntavam à equipa. Eu dizia algo do tipo: «Sim, fizeste parte deste incidente. Não estiveste na linha da frente, mas, como recompensa por teres feito parte disso, vais agora escrever o post-mortem de duas a três páginas, para compreenderes como tudo funciona e para aprenderes o que pode correr mal.» Era sempre uma tarefa árdua. Tipo, ninguém quer compilar cronologias ou threads do Slack. Agora, pego no canal inteiro do Slack, pego na minha transcrição do Google Meet e coloco tudo em formato de texto. Dou ao Claude uma instrução com o modelo de análise pós-incidente que é cerca de 80% igual ao do livro sobre SRE, e ele produz mesmo algo.
Há, no entanto, dois problemas. Primeiro, ele falha completamente nas causas de raiz. É muito inconsistente. É do tipo: «Ok, foi isto», quando todos sabemos que não se trata de uma única causa. Todos sabemos que não há uma única causa principal. Há muitos fatores que contribuem. Há muitos problemas. São como o modelo do queijo suíço que temos de analisar. Nunca foi a implementação. Nunca foi a alteração no código. Foram todos os processos da empresa que permitiram que o incidente ocorresse. O Claude não conhece o histórico do vosso sistema, especialmente se o sistema já existe há 10 anos. Não sabe a razão pela qual não testaram o vosso banco de dados secundário de reserva. Não possui o conhecimento tácito que vocês têm. Embora obtenha um relatório de 80% que seja legível e convincente, peço-lhe veementemente que não o partilhe até o ter revisto. Se documentos como estes se proliferarem pela empresa e não forem verificados por seres humanos, há uma perda da verdade que ocorre, e eu já vi isso acontecer.
Um truque que estamos agora a utilizar nas análises pós-incidente é dizer ao Claude: «Se não tiveres a certeza sobre algo, insere uma tarefa para um ser humano.» Ele tem capacidade de autorreflexão. Não é perfeita, mas existe. Sabemos que uma análise pós-incidente não está pronta para divulgação oficial até que todas as tarefas pendentes tenham sido resolvidas, até termos corrigido todas as questões em que não temos a certeza quanto ao texto. Porque, se voltarmos a introduzir estas análises pós-incidente num ciclo, «lixo entra, lixo sai», mas também podemos ter uma boa fonte de verdade sobre quais foram os vossos incidentes. Quando o Claude resume essa coleção de documentos revistos, fica muito mais fácil elaborar os vossos planos de ação.
Número cinco: transferências de turno. Tal como nas análises pós-incidente, pode pedir ao Claude para redigir a sua transferência de turno. Tenho de salientar que é preciso trabalhar de forma pública. Todas as vossas ações de plantão estão num canal onde quem está de plantão pensa em voz alta, escrevendo a sequência de depuração de tudo o que fez durante a passagem de serviço. É bom. Também podem pedir ao Claude para se limitar apenas à parte do resumo. A pessoa que entra de plantão não precisa necessariamente de ler as 200 ou 400 mensagens que foram trocadas durante o dia em Londres. Basta ler o parágrafo com links para aceder aos tópicos. Esta é provavelmente a melhoria mais simples que pode implementar.
O Problema da Aprendizagem
Quero falar sobre algo em relação ao qual, de um modo geral, ainda não tenho uma posição definida. É o problema da aprendizagem. Se o Claude encontrou o rastreio da pilha e sugeriu o rollback, e tu aprovaste-o, e funcionou, o que aprendeste? Os responsáveis seniores pela resposta a incidentes não são mais inteligentes. Não conhecem o sistema de antemão. Já passaram por situações difíceis antes. Já viram outras pessoas a depurar os sistemas. Têm as cicatrizes. Se a IA começar a fazer isto, será que as nossas competências ficarão atrofiadas? Uma vez que já não há um ciclo de feedback sobre as ações que é preciso tomar para saber o que acontece ao sistema. Tal como no livro sobre SRE, a razão pela qual tínhamos uma pequena equipa de humanos de plantão para um sistema crítico e não tínhamos uma escala de 50 ou 100 engenheiros seniores que o fizessem uma vez por ano, era porque, se colocássemos esses engenheiros de plantão, e fosse essa a sua função, quando não estivessem de plantão, tratariam a resolução dos problemas por trás das páginas como a sua prioridade.
Porque não querem ser chamados novamente. Esta é toda a vossa missão. É isto que fazem em toda a vossa equipa. Se a IA começar a resolver isto, deixam de ter esse incómodo. Os teus incentivos podem não estar alinhados. Isso aplica-se ao nível sénior. No nível júnior e intermédio, não serás treinado em incidentes mais simples. Não terás de ser colocado na berlinda para digitar o comando de reversão sem pensar, ou sem consultar o histórico no teu manual de procedimentos. Quando acontecer algo grave que o modelo não consiga resolver, poderás não estar preparado para saber como responder a tal incidente. Estou genuinamente preocupado com isto. Um investigador da OpenAI, cujo nome é Roon, publicou um tweet em 2023 — isto é, antes do Claude Code e antes mesmo de as pessoas saberem da existência da Anthropic —, afirmando que o paradoxo de Jevons permitirá que a complexidade do software aumente drasticamente até se tornar muito difícil fazer engenharia de software.
O paradoxo de Jevons é o paradoxo preferido na indústria da IA. Ocorre quando as melhorias tecnológicas aumentam a eficiência da utilização de um recurso, mas o custo mais baixo resultante acaba por fazer com que o consumo aumente, em vez de diminuir. No nosso caso específico, é mais fácil escrever software, por isso escrevemos muito mais, pelo que a complexidade aumenta em vez de diminuir, o que significa que as coisas avariam de formas mais interessantes, o que significa mais incidentes, o que significa mais plantões. A resposta que se segue é que todas as melhorias nas ferramentas de desenvolvimento que possamos implementar serão anuladas por esta complexidade cada vez maior. No entanto, e como se acionássemos uma varinha mágica, poderíamos ter agentes para quebrar este ciclo. Poderíamos despender quantidades arbitrárias de recursos computacionais para simplificar e gerir os sistemas complexos. Aqui, criámos receitas. Sabemos como fazer crescer equipas. Sabemos como fazer crescer as organizações. Temos microsserviços. Talvez os agentes de IA consigam fazer o que aprendemos coletivamente no nosso setor. Isso é um grande «se». Como era de esperar, o roon é um utilizador prolífico, e esta discussão envelheceu muito bem, e mantém-me acordado à noite.
Trajetória dos modelos de IA ao longo do tempo
Deixo-vos com o gráfico favorito no mundo da IA. A METR é uma organização que avalia as capacidades da IA, e um dos seus estudos incide sobre quanto tempo um modelo consegue funcionar de forma autónoma. No eixo x, podem ver a data de lançamento dos modelos. No eixo y, podem ver a duração agregada das tarefas. Cada modelo é avaliado num conjunto de tarefas que anteriormente tinham sido atribuídas a seres humanos, tendo sido medido o seu sucesso e cronometrado o tempo gasto. Se um modelo conseguir completar pelo menos 50% das tarefas, marcamos a duração no gráfico. É possível observar a trajetória exponencial de como os modelos estão a melhorar, e não se trata apenas de uma melhoria linear, como seria de esperar. Parece que estamos a acelerar. Muitos tweets têm sido dedicados a debater este tema. Muitas pessoas têm vindo a traçar curvas sigmoides, sugerindo que o crescimento irá parar, tal como o crescimento parou para algumas destas linhas. As pessoas têm vindo a afirmar, desde 2022, que, sim, isso irá acontecer. Temos as leis de escalabilidade da IA. Sabemos que os modelos irão melhorar assim que tivermos mais dados e mais capacidade de computação. Irão tornar-se mais inteligentes. Os modelos estão hoje no seu pior momento de sempre e irão melhorar a partir de amanhã, à medida que continuamos a trabalhar nisto.
Veja mais apresentações com transcrições