Inglês técnico para TI (tecnologia da informação): como explicar um incidente em produção

Por Alex Barros, intérprete simultâneo há 25 anos · atualizado em 05/11/2026

Escrevo "TI (tecnologia da informação)" por extenso na primeira menção porque "ti", em minúsculas, também se lê como "você". Daqui em diante uso só a sigla.

Interpreto há 25 anos, a maior parte do tempo em reuniões de finanças. Nelas, de vez em quando, entra um incidente: um sistema de pagamentos que parou, uma plataforma de negociação com lentidão, um portal de clientes fora do ar. Quando isso acontece, a reunião muda de natureza. Quem fala deixa de apresentar e passa a explicar um problema, ao vivo, para pessoas que precisam decidir rápido. A diferença entre uma explicação boa e uma ruim, nesse contexto, raramente é técnica. É de organização e de tom.

O profissional de TI brasileiro costuma ler inglês técnico sem dificuldade: logs, documentação, tickets, mensagens de erro. O que trava é falar, sob pressão, para uma plateia que não tem paciência com rodeios. A pessoa sabe o que aconteceu, mas não tem a frase pronta, e a frase que sai é uma tradução literal do português que soa estranha ou, pior, imprecisa.

Este guia é um roteiro para esse momento. Não substitui o runbook da sua empresa nem o processo formal de resposta a incidentes. Dá a linguagem: as frases de cada fase, as armadilhas e a estrutura do documento que vem depois. Para o vocabulário geral da área, veja o guia de termos de TI em inglês.

Vocabulário mínimo de um incidente

Antes das fases, os termos. Muitos têm tradução óbvia em português, mas o uso em inglês tem nuances que importam quando se fala com precisão.

Dois pares pedem atenção. O primeiro é incident e outage. Um incidente pode ser uma ameaça sem parada nenhuma, como uma falha que ainda não afetou usuários. Uma outage é a indisponibilidade em si. Nem todo incidente é uma outage, e dizer "outage" quando só havia lentidão exagera o problema.

O segundo é mitigation e resolution. Mitigar é reduzir o impacto: voltar a versão, desligar uma funcionalidade, trocar para o sistema reserva. Resolver é eliminar a causa. Muitas vezes o incidente é mitigado em vinte minutos e a causa só é resolvida dias depois. Quem usa "fixed" ou "resolved" quando só mitigou cria uma expectativa que o próximo alerta desmente.

A linha do tempo em cinco fases

Todo incidente, por mais complexo, pode ser contado na mesma ordem. Isso vale para a explicação oral numa chamada, para a atualização escrita na página de status e para o post-mortem. Se você tem a ordem na cabeça, as frases vêm mais fácil.

Durante o incidente, a causa raiz muitas vezes ainda é desconhecida, e a explicação para em mitigação. Isso é normal e deve ser dito. Uma atualização honesta no meio do incidente diz: "We have mitigated the impact. We are still investigating the root cause." Isso é melhor do que um palpite apresentado como fato.

Fase 1: detecção

Aqui você conta como o problema apareceu. Duas coisas importam: o horário e a fonte. Sempre diga o fuso horário, mesmo quando todos estão no mesmo. Em times distribuídos, "at two o'clock" sem fuso é um convite a erro. Em contexto técnico, é comum usar UTC e hora de 24 horas, e ler "14:05" como "fourteen oh five".

O verbo "to fire" para alertas é padrão: "the alert fired". Também se ouve "the alert went off" e "the alert triggered", mas "fired" é o mais usado em times de plataforma.

Sobre tempos verbais: o que já aconteceu vai no passado simples, com horário. "The alert fired at 14:05." Quando a investigação está em curso, use o presente contínuo: "We are investigating." O resultado de uma ação que ainda vale agora usa o presente perfeito: "We have identified the cause." Misturar esses três tempos é o erro mais comum de brasileiros em atualizações de incidente. Dizer "We identify the cause" ou "We did identified" soa errado, e numa atualização em que cada frase importa isso desvia a atenção.

Fase 2: impacto

O impacto é a parte que o executivo mais quer ouvir, e a que o engenheiro mais tende a pular. Fale em termos de quem foi afetado e do que não conseguiu fazer, antes de falar de componentes.

Duas cautelas. A primeira é a quantificação. Se você tem um número verificado, use. Se não tem, diga "approximately" ou "we are still measuring". Nunca invente uma porcentagem para parecer preciso. A segunda é a frase sobre dados. "No data was lost" é uma afirmação forte. Só a faça depois de verificar. Antes disso, "We have found no evidence of data loss so far" diz a mesma coisa com a ressalva honesta.

Fase 3: mitigação

É a fase em que há mais verbos, porque você descreve ações. Prefira verbos concretos a verbos vagos. "We did a change" não diz nada. "We rolled back the release" diz tudo.

"Roll back" é o phrasal verb (duas palavras, verbo). O substantivo é "rollback", uma palavra só. "We rolled back the release" e "We performed a rollback" são corretas. "We made a rollback" funciona na fala, mas "performed" ou "did" soam mais naturais para muitos ouvintes.

Existe uma distinção útil entre dizer que o serviço foi restaurado e dizer que o problema foi corrigido. "Service was restored at 14:50" é uma afirmação sobre o estado observável. "The issue is fixed" é uma afirmação sobre a causa. Se só a primeira é verdadeira, só ela deve ser dita.

Fase 4: causa raiz

Esta é a fase em que se pesa cada palavra. A causa raiz exige análise, e análise leva tempo. Durante o incidente, o mais honesto é dizer o que se tem: sinais, hipóteses, achados preliminares.

Observe a separação entre trigger e root cause. O gatilho é o que aconteceu naquela hora: uma mudança de configuração, um pico de tráfego, um certificado que venceu. A causa raiz é a razão pela qual o gatilho pôde derrubar o serviço: a mudança não foi validada, o sistema não tinha limite de carga, ninguém monitorava a data do certificado. Muitos incidentes têm mais de uma causa, e é por isso que existe a expressão "contributing factors". Dizer "the root cause was John's change" confunde o gatilho com a causa e, de quebra, aponta um culpado.

Para expressar graus de certeza, use uma escala: "we know", "we believe", "we suspect", "we don't know yet". Cada nível é uma promessa diferente. "We know" quer dizer que há evidência. "We suspect" quer dizer que há um indício. Usar "we know" por segurança, quando só há suspeita, é o tipo de coisa que volta contra você no post-mortem.

Fase 5: ações de acompanhamento

Termina com o que será feito. Ações têm verbo, objeto, responsável e prazo. Se faltar um desses, não é uma ação, é uma intenção.

A última cautela da fase é essa: nunca prometa que "this will never happen again". Ninguém pode garantir isso. "Reduce the chance of this happening again" é a frase honesta, e engenheiros experientes a reconhecem como tal.

Atualizações durante o incidente

Durante o incidente, a comunicação segue um ritmo. Muitos times usam, na página de status, rótulos padronizados de estágio: investigating, identified, monitoring e resolved. Eles dizem ao leitor em que ponto o problema está sem exigir que leia o texto inteiro.

Duas práticas valem para qualquer atualização. A primeira é sempre dizer quando será a próxima: "Next update in thirty minutes" ou "Next update at 15:00 UTC". Isso reduz as perguntas, porque quem espera sabe quando voltar a olhar. A segunda é usar a mesma estrutura toda vez: o que sabemos, o que não sabemos, o que estamos fazendo, quando falamos de novo.

Quando você é chamado de surpresa numa chamada de incidente e não tem tempo de preparar, esta fórmula de três partes funciona: "Here is what I know. Here is what I don't know yet. Here is the next step." Por exemplo: "Here is what I know: the payments API started returning errors at 14:05, and we rolled back the last release at 14:25. Here is what I don't know yet: why the release caused the errors. Next step: we are reading the database logs, and I'll update you at 15:00."

Falar com engenheiros e falar com executivos

O mesmo fato se diz de dois jeitos, conforme quem ouve. O engenheiro quer o mecanismo. O executivo quer o efeito e o que está sendo feito. Se você responder ao executivo com o mecanismo, ele perde o fio. Se responder ao engenheiro só com o efeito, ele vai achar que você está escondendo algo.

Para o executivo, três perguntas dominam: quem foi afetado, quanto dura, o que fazemos. Se você responder essas três antes de ser perguntado, a conversa fica curta. Para o engenheiro, as perguntas são diferentes: o que mudou, o que os logs mostram, o que descartamos. Saber quem está na chamada é metade da preparação.

Tom: seco, factual, sem culpa

O tom de uma comunicação de incidente tem três regras. Não dramatize. Não minimize. Não aponte culpados.

Dramatizar é dizer "this is a disaster" ou "we are in a critical situation" sem dados que o sustentem. Minimizar é dizer "it's just a small issue" quando clientes não conseguem pagar. As duas coisas corroem a credibilidade, uma por exagerar e a outra por esconder. A saída é descrever o fato: quem foi afetado, por quanto tempo, o que foi feito.

Apontar culpados é o erro que mais danifica a cultura de um time. O formato aceito em boa parte da indústria é o post-mortem sem culpados, em inglês "blameless post-mortem". A premissa é que as pessoas agem dentro de um sistema, e que, se uma pessoa pôde causar um incidente com uma ação razoável, o problema está no sistema que permitiu isso. A linguagem acompanha: o sujeito da frase é o processo, a mudança ou o componente, e não a pessoa.

Uma palavra pequena que merece atenção é "just". "It was just a configuration change" tira o peso de algo que derrubou o serviço. Corte a palavra. E "hopefully", que em português parece uma cortesia, em comunicação de incidente soa como insegurança. Se você não sabe, diga que não sabe. Se sabe, afirme.

Sobre o pedido de desculpas, aos clientes. Uma desculpa factual e curta é suficiente: "We apologize for the disruption." Ou: "We're sorry for the impact this had on you." Evite excesso. Uma desculpa longa, cheia de adjetivos, vira ruído. Peça desculpas, descreva o que aconteceu, diga o que mudará.

Pedir ajuda e escalar

Durante o incidente, saber pedir ajuda com clareza economiza minutos. A frase vaga "we need help" faz o interlocutor perguntar de quê. A frase específica já traz a resposta.

"Take it offline" quer dizer discutir fora da reunião. É uma frase útil quando a chamada se perde em debate sobre a causa enquanto o serviço continua fora do ar. A prioridade, numa chamada de incidente, é recuperar. A análise vem depois.

Estrutura de um post-mortem

O post-mortem, também escrito "postmortem" e, em alguns times, chamado de "incident review", é o documento que registra o que aconteceu e o que foi aprendido. Cada empresa tem seu modelo, mas as seções se repetem. Esta é uma estrutura comum, que serve de ponto de partida.

A seção "Where we got lucky" é a menos óbvia e uma das mais úteis. Ela registra o que poderia ter piorado o incidente e não piorou por acaso: o engenheiro certo estava de plantão, o problema ocorreu fora do horário de pico, o backup tinha sido testado na semana anterior. Se a sorte foi o que impediu um problema maior, a sorte não é um controle.

A cronologia é escrita em frases curtas, com horário no começo e verbo no passado.

• 14:00 UTC: A configuration change is deployed to production.
• 14:05 UTC: An alert fires for elevated error rates on the payments API.
• 14:07 UTC: The on-call engineer acknowledges the alert and opens an incident.
• 14:25 UTC: The release is rolled back.
• 14:50 UTC: Error rates return to normal.

O estilo é seco de propósito. Nada de adjetivos, nada de interpretação na cronologia. A interpretação fica nas seções de causa e de ações.

Um parágrafo de resumo, no mesmo estilo: "On the fourteenth, customers were unable to complete payments for approximately forty-five minutes. A configuration change deployed at 14:00 UTC caused the payments service to exhaust its database connections. We detected the issue through an automated alert at 14:05 UTC and restored service by rolling back the change at 14:25 UTC. We have found no evidence of data loss. The action items below address validation of configuration changes and alerting on connection usage."

Os números e horários desse exemplo são fictícios. Use os seus, e só os verificados.

Erros comuns de brasileiros em comunicações de incidente

Alguns erros se repetem. Nenhum é grave isoladamente, mas, juntos, deixam a comunicação menos clara.

Vale explicar alguns. "Out of the air" é tradução literal de "fora do ar" e não existe em inglês técnico. "Normalized" não é a forma usual de dizer que o serviço voltou ao normal; prefira "restored" ou "recovered". "Since yesterday" pede o presente perfeito, "have had", e não o presente simples. E "solve" funciona bem com problemas em geral, mas para defeitos de código a escolha natural é "fix".

Pronúncia de palavras que travam em chamada

Muitos termos de TI são usados em português com pronúncia adaptada, e isso funciona entre brasileiros. Numa chamada com estrangeiros, o som precisa ser outro. Uso aproximações em português, com a sílaba forte em maiúsculas.

Mesmo estas aproximações são só um ponto de partida. Antes de usar um termo novo numa chamada importante, ouça o áudio em um dicionário. A pronúncia de siglas também varia: "SQL" pode ser lido como "ess-cue-ell" ou "sequel", e as duas formas circulam. Siga a que o seu time usa.

Para onde ir daqui

Se o seu trabalho é de TI e você precisa falar inglês em chamadas de incidente, dailies, revisões e reuniões com a matriz, o Inglespetacular Executive de TI traz o vocabulário e as situações da área. Cada Executive Journey tem 10 unidades, 70 lições e cerca de 480 termos, e o Speak tem 750 linhas de fala para você praticar em voz alta. O curso exige B1 completo, tem o preço informado na página do curso, e a Introdução e a Unidade 1 são grátis. Veja o curso em Executive de TI.

Dois guias irmãos completam este. O de termos de TI em inglês reúne o vocabulário por área. O de como participar de uma daily em inglês trata da rotina do time, onde também se fala de bloqueios e de pedir ajuda. Para termos avulsos, consulte o glossário de TI.

Eu escrevo e reviso. Se encontrar algo errado, avise.