Entre a correção de um desenvolvedor e o cliente ver essa correção, quantos sistemas de terceiros precisam funcionar, e quais deles eu contratei sem saber?
- Nomear os seis pontos de quebra que separam a correção do cliente.
- Separar número de contratos assinados de número de pontos de falha independentes.
- Marcar, no mapa, cada passo que ainda depende de alguém clicar.
Caso Nortis · Semana 1, depois do comitê
Marina pede ao CTO o desenho do caminho que uma correção percorre até chegar ao cliente. Ele volta com um diagrama de três caixas. Ao detalhar, aparecem seis pontos de quebra, e três deles pertencem a fornecedores que nunca passaram por contrato assinado.
A empresa acredita ter dois fornecedores de infraestrutura. O registro do domínio e o resolvedor de nomes, que derrubariam o produto inteiro, não têm dono nomeado.
Desenhar o caminho real do código até o cliente e nomear o responsável por cada ponto de quebra antes de discutir qualquer otimização.
Nunca aprovei uma publicação: comece por aqui
Publicar é colocar uma versão do produto diante do cliente. A frase que o time usa em reunião, subiu, esconde uma cadeia: alguém escreveu a correção, uma máquina montou o pacote, esse pacote foi colocado em algum lugar do mundo, um serviço de nomes ensinou o navegador a encontrar esse lugar, e uma rede entregou os arquivos. Se qualquer elo falhar, o cliente vê erro, e em vários desses elos a empresa não tem contrato nenhum.
Ninguém precisa saber operar esses elos para responder por eles. Precisa saber que existem, quem é o fornecedor de cada um, quem dentro da empresa acorda quando ele cai e o que acontece se ninguém acordar. Esse é o mapa que este módulo produz, e ele cabe em uma página.
- 1O código vira pacote antes de virar site. Uma máquina alugada monta o produto a partir do texto que o desenvolvedor escreveu. Essa etapa tem teto de tempo, custa dinheiro por minuto e falha por motivos que nada têm a ver com o cliente.
- 2O nome do site não é o site. O endereço que o cliente digita precisa ser traduzido em um lugar da rede. Quem faz essa tradução é o registro do domínio e o resolvedor de nomes, dois fornecedores que quase nunca aparecem em contrato revisado por jurídico.
- 3A entrega acontece longe do seu fornecedor. A rede de entrega guarda cópias do produto em centenas de pontos do mundo e responde ao cliente a partir do mais próximo. Ela é a razão de o site parecer rápido e a razão de a fatura ter uma linha chamada transferência de dados.
- 4Executar é diferente de servir. Página pronta e guardada é servida pela rede. Página que depende de dado do cliente exige que um código rode naquele instante, e é essa execução que consome CPU, memória e tempo, com teto declarado pelo fornecedor.
- Ponto de quebra
- Elo do caminho cuja falha isolada já derruba o produto para o cliente, independentemente de todo o resto estar perfeito.
- Fornecedor de caminho
- Empresa que participa da entrega sem necessariamente ter contrato com você: registro do domínio, resolvedor de nomes, provedor de nuvem por trás do seu fornecedor.
- Passo manual
- Etapa que só acontece porque uma pessoa específica clica ou digita. É onde a publicação para quando essa pessoa está de férias.
Confusão mais comum: Achar que contratar dois fornecedores cria duas chances independentes de o produto continuar no ar. A documentação de conformidade da Vercel, atualizada em 8 de julho de 2026, declara que a plataforma usa primariamente a AWS, em 20 regiões. Dois contratos podem repousar sobre a mesma infraestrutura, e nesse caso o plano B cai junto com o plano A.
Explique em voz alta: Diga em voz alta, para alguém de fora da tecnologia, quais são os seis elos entre a correção do seu time e o cliente, e qual deles a sua empresa não contratou.
Três caixas no quadro, seis pontos de quebra na realidade
Quando alguém diz em reunião que subiu, a frase descreve um evento que a maior parte da mesa nunca viu acontecer. O desenho que costuma acompanhá-la tem três caixas e duas setas: escreve, publica, cliente. É um desenho honesto e é curto demais para sustentar qualquer decisão de risco, porque as duas setas escondem seis sistemas diferentes, operados por pelo menos quatro empresas, e apenas duas delas costumam ter contrato revisado.
A prova de que o desenho curto é caro chegou em 5 de maio de 2026. Às 19h30 UTC, a DENIC, operadora do registro do domínio .de, passou a publicar assinaturas DNSSEC inválidas durante uma rotação de chave programada. Resolvedores que validam assinatura são obrigados pela especificação a rejeitar a resposta, e milhões de domínios ficaram inalcançáveis até a mitigação da Cloudflare, às 22h17 UTC. Nenhum desses sites tinha problema. Nenhuma hospedagem contratada falhou. O elo que quebrou foi o registro do domínio, que quase nunca aparece no diagrama de três caixas.
O trabalho deste módulo é substituir as duas setas por seis nomes, colocar um fornecedor e um responsável interno ao lado de cada nome e marcar quais passos ainda dependem de alguém clicar. Feito isso, a conversa sobre custo, contrato e incidente passa a ter onde se apoiar. Sem isso, toda decisão seguinte é tomada sobre um desenho que não corresponde ao que existe.
Modelo operacional
Os seis pontos de quebra, do registro até o banco
Cada item derruba o produto sozinho. A pergunta a fazer em cada linha é sempre a mesma: qual empresa opera isso, quem aqui dentro acorda quando cai e o que acontece nos primeiros trinta minutos.
Registro do domínio
Quem detém o direito sobre o nome e quem publica as informações de autoridade dele. Falha aqui apaga o produto da internet inteira, sem que nada na sua infraestrutura tenha acontecido.
O incidente do TLD .de, em 5 de maio de 2026, tornou milhões de domínios inalcançáveis por cerca de três horas por erro do registro, não das hospedagens.
Resolução de nomes
O serviço que traduz o endereço digitado no lugar da rede onde o produto vive. É o elo mais barato de contratar e o mais caro de perder, porque ele não tem substituto no momento da falha.
Zona assinada por DNSSEC transfere risco para o operador do registro. O ganho de integridade é real e o custo é uma dependência a mais de um terceiro que você não escolhe.
Rede de entrega
As cópias do produto espalhadas pelo mundo e a decisão de qual cópia responde a cada cliente. Move a linha de transferência de dados da fatura e é o elo que o marketing consegue estressar sozinho, com uma campanha.
Cloudflare declarava, em 6 de maio de 2026, presença em 337 cidades e mais de 100 países. Material antigo que fala em mais de 300 data centers está descrevendo outra coisa.
Build
A máquina alugada que transforma o texto do desenvolvedor no pacote servido ao cliente. Tem teto de tempo, fila de concorrência e linha própria de fatura, ainda que o time a trate como etapa gratuita.
Na Vercel, o build é cobrado por CPU-minuto a partir de US$ 0,0035 e tem teto de 45 minutos por publicação, verificado em 24 de julho de 2026 em documentação com atualização de 24 de junho de 2026.
Execução
Onde o código roda quando o cliente pede algo que não estava pronto. Define teto de duração, teto de memória e a linha da conta que o consumo alimenta.
O teto de duração de uma execução, o que a documentação chama de timeout, é de 300 segundos em todos os planos da Vercel, inclusive o gratuito, conforme documentação de 1º de julho de 2026. Os 10 segundos que muita gente repete valem apenas para projetos anteriores a 23 de abril de 2025, data em que o novo modelo de execução da plataforma passou a ser padrão.
Banco e armazenamento
Onde o dado do cliente mora entre uma visita e outra. É o único elo do caminho em que a falha não se resolve republicando a versão anterior.
A Vercel declara, em documentação de 8 de julho de 2026, que faz backup a cada duas horas com retenção de 30 dias e que esses backups não estão disponíveis para os clientes.
Elo sem responsável interno nomeado é elo sem plano. O objetivo do mapa não é o desenho: é a coluna com nome de gente ao lado de cada linha, e a data em que essa coluna foi conferida pela última vez.
Metáfora conhecida
A encomenda que passa por seis mãos
Uma peça sai da fábrica e chega à casa do cliente. No caminho, ela passa por uma transportadora contratada, por um centro de distribuição que a transportadora subcontrata, por um endereço que depende de a prefeitura ter cadastrado a rua, por um porteiro do prédio e pelo elevador. A fábrica assinou contrato com uma dessas seis partes. Quando a peça não chega, o cliente liga para a fábrica, e a fábrica diz que despachou.
Despachar não é entregar. O produto está no ar quando o cliente consegue usá-lo, e a responsabilidade percebida cobre a cadeia inteira, inclusive os elos que ninguém contratou.
Evidência pública
Caso documentado: o registro do domínio derruba milhões de sites que estavam perfeitos
DENIC, registro do TLD .de, com mitigação da Cloudflare
Em 5 de maio de 2026, por volta das 19h30 UTC, a DENIC passou a publicar assinaturas DNSSEC inválidas durante uma rotação de chave programada. Resolvedores validadores, incluindo o 1.1.1.1, passaram a retornar SERVFAIL, e domínios .de ficaram inalcançáveis até a mitigação, às 22h17 UTC.
- A causa foi erro do registro do domínio, não das hospedagens contratadas pelos sites afetados.
- A especificação obriga o resolvedor validador a rejeitar resposta com assinatura inválida, então o comportamento correto do resolvedor foi justamente o que tornou os sites inalcançáveis.
- A mitigação consistiu em marcar a zona como insegura, apoiada também no mecanismo de servir resposta expirada, e levou cerca de três horas para ser aplicada.
Existe uma classe de indisponibilidade que nenhuma decisão de arquitetura sua evita e nenhum teste de código detecta. Para ela, o que reduz o dano é saber quem opera o elo, ter comunicação pronta e reconhecer o sintoma em minutos em vez de horas.
O caso é europeu e o mecanismo é global: qualquer registro de domínio pode errar uma rotação de chave, inclusive o do seu domínio.
Cloudflare, análise da indisponibilidade do TLD .de por DNSSEC, maio de 2026Contratos assinados contra pontos de falha independentes
A coluna que importa é a última. Dois contratos com o mesmo provedor de nuvem por baixo produzem um ponto de falha, não dois. Dados verificados em 24 de julho de 2026.
| Elo do caminho | Quem opera de fato | Tem contrato revisado por jurídico? | Independente do fornecedor principal? |
|---|---|---|---|
| Registro do domínio | Registro do TLD e o registrador intermediário | Quase nunca, porque a assinatura costuma ser antiga e por cartão | Sim, e é justamente por isso que ele some do diagrama |
| Resolução de nomes | Provedor de DNS autoritativo, muitas vezes o mesmo da rede de entrega | Às vezes, embutido no contrato da rede de entrega (CDN) | Depende: se for o mesmo fornecedor, não é plano B de nada |
| Rede de entrega | Vercel sobre AWS, ou Cloudflare sobre rede própria | Sim | Não, quando a alternativa contratada roda sobre a mesma nuvem |
| Build | O próprio fornecedor de publicação ou o provedor de CI | Sim, mas raramente com teto de gasto declarado | Sim, se o CI for de outra empresa que a da publicação |
| Execução | Vercel, primariamente sobre AWS em 20 regiões, conforme documentação de 08/07/2026 | Sim | Não, em relação à nuvem subjacente |
| Banco e armazenamento | Serviço gerenciado do fornecedor ou banco próprio | Sim, e quase nunca com cláusula de devolução de backup | Só se a cópia restaurável estiver sob guarda da empresa |
Rotina real
O CTO desenha o mapa em quarenta minutos
CTO da Nortis, com a CEO na sala e o gerente de infraestrutura por chamada · Reunião de quarenta minutos marcada uma única vez, com o mapa revisado a cada trimestre e sempre que houver troca de fornecedor.
- Situação
- O comitê pediu o caminho do código até o cliente. O material interno existente descreve um fluxo linear de três etapas e não nomeia nenhum fornecedor fora do contrato principal.
- Entradas
- Lista de domínios da empresa, painel do fornecedor de publicação, contrato vigente, extrato do registrador e o organograma da área de tecnologia.
- Processo
- Cada um dos seis elos é escrito em uma linha. Ao lado, o fornecedor real, o responsável interno com suplente e a resposta a uma pergunta única: se isso cair agora, o que muda para o cliente nos primeiros trinta minutos. Passos que dependem de alguém clicar recebem marca visual.
- Saída
- Uma página com seis linhas preenchidas, três passos manuais destacados e duas linhas em vermelho, que são os elos sem responsável nomeado.
- Verificação humana
- Marina lê o mapa em voz alta na frente do time e pergunta, elo por elo, quem responde. Elo cujo dono precisa ser descoberto na hora entra na lista de pendências com prazo, não é preenchido de improviso na reunião.
- Como se mede
- Número de elos com responsável nomeado, sobre seis, e data da última revisão do mapa. A meta é seis de seis e revisão com menos de noventa dias.
Guardrail
O que invalida o mapa depois de pronto
Mapa de caminho envelhece por motivo alheio à empresa. O fornecedor muda de arquitetura, o registrador é comprado, a equipe troca e o passo manual migra de pessoa sem que ninguém atualize a página. Estas cinco verificações mantêm o documento vivo, e todas cabem em uma reunião trimestral de quinze minutos.
- Cada um dos seis elos tem nome de pessoa e de suplente, e nenhum dos dois está de saída da empresa.
- Está escrito qual elo pertence ao mesmo fornecedor de outro elo, para que ninguém chame de redundância aquilo que é o mesmo ponto de falha.
- Os passos manuais estão marcados, com o nome de quem clica e o que acontece quando essa pessoa está em férias.
- A data de renovação do registro do domínio está no mesmo calendário em que se anotam vencimentos financeiros, com aviso de sessenta dias.
- O mapa tem data de emissão e data da próxima revisão, porque fornecedor muda arquitetura sem consultar cliente e o mapa antigo continua parecendo correto.
Levantar o caminho real sem depender do slide de ninguémCamada de execução · Para quem opera. Quem decide pode pular sem perder nada: o resultado destes comandos é exatamente a coluna do meio do mapa, e ele pode ser pedido pronto. · opcional para quem só decide
O caminho declarado em apresentação e o caminho que responde ao cliente divergem com frequência, sobretudo depois de migração. Estes comandos leem o estado real e levam menos de cinco minutos. O último deles decompõe o tempo de resposta e mostra em qual elo o atraso mora.
- 1Comece pelo registro: quem é o registrador, quais são os servidores de nome declarados e quando a renovação vence.
- 2Verifique se a zona está assinada. Zona assinada acrescenta integridade e acrescenta dependência do operador do registro, o que precisa estar escrito no mapa.
- 3Leia o valor de apex no painel do fornecedor no momento da configuração. Endereços de apex mudam, e material de curso que fixa um endereço específico envelhece sem avisar.
- 4Confira quem responde de fato pelos cabeçalhos da resposta, e não pelo que o contrato diz.
- 5Decomponha o tempo total: resolução de nome, aperto de mão TLS e resposta. O elo lento aparece sozinho.
# 1. Registro do domínio: registrador, servidores de nome e vencimento
whois nortis.com.br | grep -i -E "registrar|nserver|expires|owner"
# 2. Resolução de nomes: quem é autoritativo e se a zona está assinada
dig nortis.com.br NS +short
dig nortis.com.br DNSKEY +short # saída vazia = zona sem DNSSEC
# 3. Para onde o apex aponta hoje.
# Leia o valor de destino no painel do fornecedor no momento de configurar.
# Endereço fixado em tutorial envelhece e derruba o site na migração seguinte.
dig nortis.com.br A +short
dig www.nortis.com.br CNAME +short
# 4. Quem entrega a resposta e a partir de qual borda
curl -sI https://nortis.com.br | grep -i -E "^server|^x-vercel|^cf-ray|^age"
# 5. Onde o tempo é gasto, elo por elo
curl -s -o /dev/null \
-w "dns=%{time_namelookup}s tls=%{time_appconnect}s total=%{time_total}s\n" \
https://nortis.com.brTratar a saída do comando como verdade permanente. Ela é uma fotografia. O valor útil é a diferença entre duas fotografias tiradas em datas diferentes, e é por isso que o mapa tem data e revisão trimestral.
Laboratório de decisão
Onde colocar o dono do registro do domínio
O mapa da Nortis mostrou dois elos sem responsável: o registro do domínio e o resolvedor de nomes. O registro foi contratado em 2019 por uma pessoa que já saiu, a renovação vence em quatro meses e a fatura cai num cartão que hoje pertence à área administrativa.
Quem passa a responder por esse elo, e com qual instrumento?
A. Deixar com a área administrativa, que já paga a fatura, e tratar como despesa recorrente.
Resolve o pagamento e não resolve a operação. Quem paga não sabe reconhecer expiração de assinatura, mudança de servidor de nome ou pedido de transferência do domínio, que são exatamente as três formas de perder o nome da empresa.
B. Transferir para a equipe de infraestrutura e encerrar o assunto na reunião.
Coloca o elo com quem sabe operá-lo e deixa o vencimento financeiro fora do radar de quem controla orçamento. É o arranjo que produz domínio expirado em feriado, com o time descobrindo pelo cliente.
C. Nomear dono técnico e dono financeiro para o mesmo elo, com trava de renovação automática, aviso de sessenta dias no calendário do financeiro e bloqueio de transferência ativado no registrador.
Custa uma linha a mais no mapa e duas configurações. Cobre as duas formas distintas de perder o domínio, a operacional e a contratual, e deixa registro de quem responde por cada uma.
Escolha antes de abrir
A terceira opção, com o bloqueio de transferência verificado no mesmo dia e a data de renovação lançada no calendário financeiro antes do fim da reunião.
Perder o domínio tem duas causas independentes e elas moram em áreas diferentes da empresa. A causa financeira é o não pagamento, que a equipe técnica não enxerga porque não recebe a fatura. A causa operacional é a mudança indevida de configuração ou um pedido de transferência aceito por engano, que o financeiro não reconhece porque a mensagem parece técnica. Escolher um único dono deixa metade do risco descoberta, e é a metade que ninguém está olhando. O custo de nomear dois donos é uma linha; o custo de errar esse elo é o produto inteiro fora do ar, com prazo de recuperação medido em dias e não em minutos.
Exemplo trabalhado
O diagrama de três caixas que virou seis pontos de quebra
CTO da Nortis, com Marina ao lado, na semana seguinte ao comitê
O desenho entregue tem três caixas: escreve, publica, cliente. É o mesmo desenho que o material técnico antigo da empresa usava, um fluxo linear de três etapas, sem nome de fornecedor fora do contrato principal.
- 1Perguntar o que precisa estar de pé para a caixa do meio funcionar. A caixa publica se abre em três: a máquina que monta o pacote, o lugar onde o pacote fica e o serviço que executa o código quando o cliente pede algo personalizado. Cada uma dessas três tem teto, fatura e modo próprio de falhar.
- 2Perguntar como o cliente encontra o endereço. Aparecem dois elos que não estavam no quadro: o registro do domínio, contratado em 2019 com um cartão corporativo que hoje pertence a outra área, e o resolvedor de nomes. Nenhum dos dois tem dono nomeado na Nortis, e os dois derrubam o produto inteiro sozinhos.
- 3Perguntar quem entrega os arquivos ao cliente. A rede de entrega é o sexto elo, e é a que menos cai e mais aparece na fatura. Fica registrado que ela pertence ao mesmo fornecedor da execução, o que significa que ela não é o plano B de ninguém.
- 4Marcar os passos manuais e datar o mapa. Três passos ainda dependem de uma pessoa: aprovar o pedido de mudança, promover a versão para produção e avisar o suporte. Os três recebem nome, suplente e data de revisão do mapa.
Resultado: O comitê deixa de discutir se o fornecedor é bom e passa a discutir seis elos com dono. Dois deles não tinham responsável e um deles, o registro do domínio, estava com renovação vencendo em quatro meses sem ninguém olhando.
Continua sob responsabilidade humana: O mapa mostra onde a falha entra e nunca prova que ela não vai entrar. Ele também não substitui o teste: elo com dono nomeado e sem ensaio de reversão continua sendo elo sem plano. A data no rodapé do mapa existe para lembrar que fornecedor muda de arquitetura sem avisar cliente.
Aplicação imediata
Exercício: o mapa de uma página
30 min- 1Desenhe seis linhas, uma para cada ponto de quebra: registro de domínio, resolução de nomes, rede de entrega, build, execução e banco.
- 2Preencha a coluna do fornecedor real, e não a do contrato. Onde dois elos tiverem o mesmo fornecedor por baixo, escreva isso na mesma linha.
- 3Preencha a coluna do responsável interno, com suplente. Elo sem dono fica em branco e vira pendência com prazo, jamais preenchido de improviso.
- 4Marque os passos que ainda dependem de uma pessoa clicar, com o nome de quem clica hoje.
- 5Escreva no rodapé a data de emissão e a data da próxima revisão, e leve o mapa para a próxima reunião de tecnologia como pauta de dez minutos.
Entregável: Uma página com seis elos, fornecedor real, dono e suplente, passos manuais destacados e data de revisão marcada.
Checkpoint
Entregável do módulo: Mapa de uma página do caminho do código até o cliente, com os seis pontos de quebra nomeados (registro de domínio, resolução de nomes, rede de entrega, build, execução e banco), o fornecedor responsável por cada um, o dono interno e os passos manuais destacados.
- Eu consigo nomear os seis pontos de quebra entre a correção do time e o cliente, sem consultar o slide.
- Eu sei dizer quais dos meus fornecedores repousam sobre a mesma infraestrutura e, portanto, não são plano B um do outro.
- Eu tenho o nome de quem responde por cada elo e sei quais passos ainda dependem de alguém clicar.
Com o caminho desenhado, aparece o obstáculo seguinte: metade das palavras do diagrama não é explicável em voz alta por quem aprova o orçamento.