Deploy e publicação para decisão executiva: Vercel e Cloudflare
Revisado em
Um curso para quem aprova a fatura da plataforma, assina o contrato do fornecedor, responde pelo produto fora do ar e presta contas ao regulador. Começa do zero absoluto, sem exigir uma linha de código, e preserva a profundidade técnica em camadas opcionais para quem também opera a esteira. Inclui três laboratórios de marketing para validar a prévia, comparar a migração e ensaiar a reversão, revisados em 17 de outubro de 2026.
Antes do módulo 1
Aula zero: a fatura que ninguém sabe explicar
Segunda-feira, comitê de tecnologia da Nortis, software de gestão de frotas vendido por assinatura para transportadoras no Brasil e para três clientes na União Europeia, 240 funcionários. O financeiro projeta a fatura da plataforma de publicação: US$ 4.180 no ciclo que fechou, contra US$ 2.960 no anterior. Aumento de 41% em um mês em que nenhuma funcionalidade nova foi lançada e o número de clientes ficou igual. O time de engenharia responde que não mexeu em nada. O marketing lembra que houve uma campanha em junho. Ninguém abre a fatura na tela.
Marina, CEO, precisa decidir em quarenta minutos se aprova o novo patamar de custo, se manda cortar ou se troca de fornecedor. As três opções são defensáveis com o slide que está na tela, e é exatamente por isso que o slide não serve.
A conta chega somada
Um número único de US$ 4.180 não diz se cresceu computação, transferência de dados, requisições, build ou observabilidade. Cada uma dessas linhas é movida por um comportamento diferente, e cada comportamento tem um dono diferente dentro da empresa.
A decisão que encareceu foi tomada meses antes
A região de execução foi fixada em São Paulo em uma reunião técnica de 2025, para reduzir latência. Ninguém registrou que o mesmo trabalho de CPU custa US$ 0,221 por hora em São Paulo contra US$ 0,128 em Washington, um prêmio de 72,7% verificado na documentação do fornecedor em 24 de julho de 2026.
Ninguém sabe qual é o teto
A pergunta seguinte de Marina é quanto a empresa pode perder num fim de semana se algo der errado. A resposta honesta é que não existe teto rígido: a documentação de gestão de gasto do fornecedor, atualizada em 26 de junho de 2026, afirma que definir um valor não interrompe o consumo, que a verificação ocorre a cada poucos minutos e que a retomada dos projetos pausados é manual, um a um.
O risco não está na fatura, e chega pela fatura
Em 17 de junho de 2026, um cliente relatou no fórum oficial do fornecedor que um ataque entre 21 e 25 de maio gerou mais de 2 TB de saída e levou a conta de uma faixa de US$ 20 a US$ 60 para US$ 231,71, classificada pelo suporte como não reembolsável. Em plataforma medida por consumo, incidente de segurança chega primeiro como cobrança, não como queda.
Dois modos de percorrer
Modo decisão
Você lê, questiona, cobra e decide. Este é o trilho principal do curso e não exige nenhuma linha de código, nenhum terminal e nenhum acesso ao painel do fornecedor.
Modo execução
Blocos marcados como camada de execução mostram como o time faz na prática: comando, arquivo de configuração, workflow e tabela de limites. Pule sem culpa, porque a linha de raciocínio se mantém inteira sem eles. Node.js e Git são pré-requisito apenas desta camada.
Escada de confiança do dado
- Afirmação de reunião: alguém disse que sobe, que cai ou que é seguro. Serve para levantar hipótese, nunca para decidir.
- Número com fonte: a linha da fatura, o limite na documentação primária do fornecedor ou o registro público do incidente, com data de verificação ao lado.
- Número com dono: a mesma evidência com o nome de quem responde por aquele comportamento dentro da empresa e o prazo dessa pessoa.
- Decisão registrada: a escolha escrita com premissas explícitas, data de revalidação e o gatilho numérico que obriga reabrir o assunto.
As quatro perguntas que você passa a fazer
- Qual linha desta conta cresceu, e qual comportamento move essa linha?
- Se isso cair às três da manhã de um sábado, quem reverte, por qual caminho e em quanto tempo?
- Quem, hoje, consegue publicar em nome desta empresa sem passar por mais ninguém?
- Se precisássemos sair deste fornecedor em noventa dias, o que teríamos de reconstruir do zero?
Entregável da aula zero: Uma versão reescrita do slide da fatura, com as linhas separadas, o comportamento que move cada uma, o dono de cada comportamento e a pergunta que a próxima medição precisa responder.
A cadeia de 6 passos que atravessa o curso
A mesma sequência reaparece em todos os módulos. Ela existe para que a conversa sobre publicação deixe de começar pela ferramenta e passe a começar pela decisão que depende dela.
- Passo 1
Nomear
O que exatamente vai ao ar, por qual caminho e sob responsabilidade de quem? - Passo 2
Custear
Qual linha da fatura essa decisão move, em quanto e por qual comportamento? - Passo 3
Comparar
Com qual número escolhemos fornecedor, e a partir de que volume a resposta se inverte? - Passo 4
Proteger
Quem consegue publicar em nosso nome, e o que roda no mesmo processo que a credencial? - Passo 5
Reverter
Se cair agora, quem devolve a versão anterior sem depender do painel do fornecedor? - Passo 6
Prestar contas
O que provamos ao regulador, ao cliente auditor e ao conselho, e em quantas horas?
O vocabulário do curso, em duas listas separadas
As duas listas descrevem coisas de natureza diferente e por isso não se misturam. A primeira nomeia as peças do caminho até o cliente. A segunda nomeia os artefatos que você leva embora e continua usando depois que o curso acabar.
Peças do sistema
- Publicação
- O ato de colocar uma versão do produto diante do cliente. Tem hora, autor, aprovador e caminho de volta. Quando não tem, o problema já existe antes do incidente.
- Build
- A montagem do artefato que será servido. Consome máquina, tem teto de tempo e aparece na fatura, mesmo quando o time chama de etapa gratuita.
- Runtime
- Onde o seu código roda de fato depois de publicado. Define o teto de duração, o teto de memória e a linha da fatura que o consumo alimenta.
- Região
- O ponto do mundo onde a execução acontece. Decide latência, decide preço unitário e decide para qual jurisdição o dado pessoal viaja.
- Egresso
- O dado que sai da plataforma em direção ao cliente. É a linha da conta que o marketing move sem avisar e a única em que a diferença entre fornecedores é de ordem de grandeza.
- Reversão
- Devolver ao cliente a versão anterior. Só existe de verdade quando tem caminho alternativo testado, que não depende do painel do fornecedor estar no ar.
Artefatos que sobrevivem ao curso
- Fatura decomposta
- A conta do último ciclo aberta em linhas nomeadas, com o comportamento que move cada linha e o dono desse comportamento. Sem isso, aumento de conta vira discussão de opinião.
- Ponto de virada
- O volume mensal a partir do qual a comparação entre fornecedores deixa de ser percentual e vira ordem de grandeza. Calculado antes da escolha, revisado com data.
- Matriz de publicação
- Quem escreve, quem revisa, quem dispara, quem aprova e quais ramos podem publicar. Cada exceção nomeada, justificada e com data de encerramento.
- Runbook de reversão
- Uma página com caminho principal, caminho alternativo independente do painel do fornecedor, tempo alvo, responsável e data do último ensaio realizado.
- Calendário de obsolescência
- As datas definidas pelo fornecedor que param a publicação sem ninguém tocar em uma linha do sistema, cada uma com dono interno e prazo de aplicação.
- Política de publicação assinada
- O documento que reúne alçadas, matriz de risco, orçamento de plataforma, trilha de auditoria e data de revisão. Assinado e datado, para não depender da memória de uma pessoa.
Guias práticos: publicação aplicada a marketing digital
Oito guias passo a passo para o time que publica landing page de campanha, formulário de lead e teste A/B na Vercel ou na Cloudflare. Cada passo tem verificação, armadilha e critério de pronto, com as mudanças dos fornecedores entre julho e 1º de outubro de 2026 e capturas da documentação oficial. O guia fica dentro do módulo que explica por que ele importa.
- Guia de marketing 1 · Prévia por pull request
Publique a landing page da campanha com prévia aprovada antes do ar
No fim deste guia cada alteração da landing page gera um endereço de prévia próprio, protegido, que o time de marketing revisa e aprova antes de a versão ir para o domínio da campanha, e existe um caminho de volta em segundos se algo escapar.Abrir no módulo 1 - Guia de marketing 2 · Formulário de lead
Receba o lead do formulário numa função, com o segredo do CRM fora do código
No fim deste guia o formulário da landing envia o lead para uma função que valida o dado, grava no CRM com uma chave que ninguém consegue ler depois de salva e responde em menos de um segundo, na Vercel ou na Cloudflare.Abrir no módulo 3 - Guia de marketing 3 · Medição e SEO
Meça visita, origem e Core Web Vitals da landing sem pagar pelo que ninguém lê
No fim deste guia a landing reporta visitas, origem do tráfego e a experiência real de carregamento, com o custo de cada medição conhecido antes de ligar, e o time sabe qual número leva para a reunião de SEO.Abrir no módulo 4 - Guia de marketing 4 · Cache e custo
Faça a landing da campanha sair do cache, e não da função, no dia do pico
No fim deste guia a landing servida no pico da campanha sai do cache da rede de entrega, o time sabe ler o motivo de cada falha de cache e a linha de requisições da fatura tem preço conhecido antes do disparo.Abrir no módulo 7 - Guia de marketing 5 · Turnstile e limite de gasto
Feche o formulário para bots e ponha aviso de gasto antes do fim de semana
No fim deste guia o formulário só aceita envio com token Turnstile validado no servidor, o time recebe aviso quando o gasto do mês passa do combinado e existe uma ação automática definida para quando o valor for atingido.Abrir no módulo 8 - Guia de marketing 6 · Cloudflare Workers
Publique a mesma landing em Cloudflare Workers, com prévia por pull request
No fim deste guia a landing roda em um Worker com arquivos estáticos, cada pull request ganha uma prévia com endereço estável, e o time tem os números das duas plataformas para a comparação com o volume real.Abrir no módulo 9 - Guia de marketing 7 · Domínio e redirecionamento
Troque domínio ou endereço da campanha sem perder UTM nem posição de busca
No fim deste guia todo link antigo de anúncio, e-mail e QR code leva ao endereço novo com os parâmetros UTM intactos, com o código de status certo para busca, e existe teste que prova isso antes da troca.Abrir no módulo 12 - Guia de marketing 8 · Teste A/B e freio
Rode o teste A/B da landing com flag, e desligue a variante sem publicar
No fim deste guia a landing serve duas variantes divididas por percentual, a divisão real é conferida no painel, a conversão de cada variante é medida, e qualquer pessoa autorizada desliga a variante perdedora sem nova publicação.Abrir no módulo 16
Parte 1A mesa com o CTO
Entender o caminho do código até o cliente antes de discutir dinheiro, risco ou fornecedor. Você termina com o mapa do caminho atual do código até produção, doze termos que sustentam qualquer reunião de publicação, a ficha de execução dos sistemas críticos e a linha de base das quatro métricas de entrega, com a ressalva de que velocidade ganha por assistência de IA vem acompanhada de perda de estabilidade.
Desenhar o caminho real do código até o cliente, nomear os seis pontos de quebra e colocar um responsável ao lado de cada um.
- 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.
Em linguagem simples
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.
- 01O 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.
- 02O 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.
- 03A 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.
- 04Executar é 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.
Glossário rápido
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.
O que muda no mundo quando alguém diz que subiu
O módulo em vídeo: o diagrama de três caixas da Nortis, a cadeia escondida na palavra subiu, o incidente do registro do .de em 5 de maio de 2026, os seis pontos de quebra com os números da Vercel e da Cloudflare, por que dois contratos não são dois pontos de falha independentes e o mapa de uma página com dono e suplente em cada elo.
Transcrição
0:00Bom, vamos direto ao ponto. Quando a equipe técnica avisa que uma correção no software finalmente subiu, a sensação é de missão cumprida, certo? Mas será que é isso mesmo? Hoje, a nossa análise mergulha no primeiro capítulo do curso sobre deploy e publicação. O foco aqui é para quem toma a decisão executiva, CEO, diretoria financeira, gestão de produto, ou seja, quem não opera a infraestrutura, mas precisa entender o que realmente acontece nos bastidores.
0:26A gente vai quebrar aquela ilusão de que o processo é super simples. Vamos descobrir juntos quais são os sistemas reais, e muitas vezes invisíveis, que ficam ali, espremidos entre a correção de uma linha de código e a tela do cliente.
0:39Afinal, antes mesmo de sentar para discutir custo ou fornecedor, a gente precisa saber onde exatamente a corda pode arrebentar. E para organizar nossa conversa, a agenda de hoje tem seis partes. O caso fictício Nortis, a cadeia escondida de publicação, os seis pontos de quebra, contratos contra falhas independentes, a construção do mapa e, por fim, o mapa de uma página.
1:01Vamos nessa? Começando pelo item 1, o caso Nortis e a ilusão do diagrama curto. Para facilitar a didática aqui do nosso estudo, vamos usar um caso totalmente fictício, o da empresa Nortis.
1:13A Marina, que é a CEO, senta com o CTO e faz um pedido que parece super simples. Ela quer um desenho do caminho exato que uma correção de código percorre até chegar no celular do cliente.
1:24E aí o CTO, cheio de boas intenções, volta com um diagrama clássico de três caixinhas. Escreve, publica e cliente. Bom, parece inofensivo, né? Mas quando a gente dá um zoom no que acontece ali no meio, a história muda de figura.
1:38Esse desenho padrão é curto demais e incrivelmente perigoso para quem precisa gerenciar riscos. Ele esconde, na verdade, seis pontos diferentes de quebra. E olha o detalhe alarmante. Desses seis elos que podem derrubar o produto de uma vez só, Três pertencem a fornecedores que nunca passaram por um contrato assinado pela empresa.
1:55O registro do domínio e o resolvedor de nomes, por exemplo, simplesmente não tem um dono nomeado. É literalmente metade da infraestrutura crítica operando às cegas. Isso nos leva à nossa segunda parte, a cadeia escondida de publicação.
2:09Despachar não é entregar. E o conceito principal aqui é que executar um código não é a mesma coisa que servir esse código para o cliente. Pensa bem, essa palavra subiu esconde um universo inteiro em reuniões.
2:22Alguém escreve a correção, uma máquina monta o pacote, o pacote viaja para algum canto do mundo, um serviço ensina o navegador a achar esse lugar e uma rede finalmente entrega os arquivos. É exatamente como mandar uma encomenda física, sabe?
2:35A peça sai da fábrica, passa pela transportadora, por um centro de distribuição terceirizado, pelo cadastro da prefeitura, pelo porteiro do prédio, até chegar no elevador. A fábrica só assinou contrato com a transportadora.
2:47Mas se o cliente não recebe, não adianta a fábrica dizer que despachou. O produto só existe quando o cliente consegue usar. A responsabilidade real abrange a cadeia inteira, incluindo aquelas partes que ninguém contratou formalmente.
3:00E ignorar isso custa muito caro. Vamos olhar um caso real e documentado. A DENIC, operadora alemã de registros de domínios. Em 5 de maio de 2026, exatamente às 19h30 UTC, a DENIC começou a publicar assinaturas DNSSEC inválidas durante uma troca de chaves que já estava programada.
3:18O que aconteceu? Resolvedores que validam nomes, como o famoso 1.1.1.1, fizeram exatamente o que deveriam fazer. Rejeitaram a resposta e retornaram um erro chamado SERVFAIL.
3:29Milhões de domínios caíram e ficaram inalcançáveis até a Cloudflare conseguir mitigar o problema lá pelas 22h17 UTC. Foram quase três horas de apagão absoluto. E o mais chocante? Nenhuma hospedagem falhou.
3:41Foi o comportamento tecnicamente perfeito de um sistema invisível que derrubou tudo. Então vamos ao tópico 3, os seis pontos de quebra detalhando o caminho real. E aqui vai a regra de ouro, a âncora da nossa análise.
3:54Um elo sem responsável interno nomeado é um elo sem plano. Vamos jogar fora aquele diagrama curto de duas setas e olhar para os seis sistemas reais. O primeiro elo é o registro do domínio. É quem detém a autoridade sobre o nome.
4:06Se der problema aqui, o produto simplesmente é apagado da internet global na mesma hora, sem nem triscar na infraestrutura da própria empresa. Foi exatamente o que aconteceu no caso da DENIC. O segundo ponto é a resolução de nomes.
4:20É o grande tradutor de endereços. Geralmente é o elo mais barato de se contratar, mas sem dúvida é o mais caro de se perder. Ah, e um detalhe vital, usar o DNSSEC traz muita integridade para a zona, com certeza, mas também transfere um risco enorme para um terceiro que a gente não pode nem escolher.
4:36O terceiro elo é a rede de entrega de conteúdo, a famosa CDN. São as cópias globais do produto. É ela que dita a linha de transferência de dados na fatura e é o único elo que o time de marketing consegue estressar e derrubar sozinho durante uma campanha pesada.
4:51Para dar contexto, em 6 de maio de 2026, a Cloudflare já declarava presença em 337 cidades de mais de 100 países. O Build é a máquina que transforma o texto em um pacote real. Muita gente no mercado ainda acha que esse passo é de graça.
5:06Não é. Ele tem tetos rígidos e fila de concorrência. Na Vercel, por exemplo, segundo a documentação de 24 de julho de 2026, o build é cobrado por CPU-minuto, a partir de US$ 0,0035, com um teto absoluto de 45 minutos por publicação. O quinto elo é a execução.
5:24É onde o código roda sob demanda, para pedidos personalizados. A Vercel impõe um teto de 300 segundos em todos os planos, de acordo com as regras de 1º de julho de 2026. Ah, e se alguém da equipe técnica falar num limite antigo de 10 segundos, pode corrigir.
5:39Isso só vale para projetos criados antes de 23 de abril de 2025. E, finalmente, o sexto elo, banco e armazenamento. É onde os dados dos clientes moram. Atenção total aqui. Esse é o único ponto de quebra onde simplesmente republicar uma versão antiga do código não conserta falha.
5:57A Vercel, na documentação de 8 de julho de 2026, informa que faz backups a cada duas horas retidos por 30 dias, mas que eles ficam indisponíveis para os clientes. Ou seja, ter uma cópia restaurável é uma responsabilidade inteiramente interna.
6:12Agora entramos na seção 4, contratos contra falhas independentes, o mito do Plano B. Porque a dura verdade no mundo digital é que a quantidade de contratos assinados definitivamente não é igual à quantidade de pontos de falha independentes.
6:26Olha só essa tabela aqui. Quando a gente investiga quem realmente opera de fato cada um dos seis elos e se esse operador é independente do fornecedor principal, a ilusão desmorona. A própria documentação de conformidade da Vercel, de 8 de julho de 2026, declara que a plataforma usa primariamente a AWS, espalhada em 20 regiões.
6:47O que isso quer dizer na prática? Que se a empresa tiver um segundo contrato, achando que tem um super plano B, mas esse contrato também roda em cima da AWS, não existe plano B. Existe um ponto único de falha pelo qual a empresa está pagando em dobro.
7:01Isso nos leva à seção 5, a construção do mapa numa reunião de 40 minutos. Como transformar todo esse risco abstrato de infraestrutura num checklist executivo que a diretoria consegue acompanhar? Simples.
7:13Uma única reunião de 40 minutos com a liderança técnica. Ninguém vai olhar para a linha de código. São apenas seis linhas no papel listando o fornecedor real, quem é o responsável, quem é o suplente e quais passos dependem de um clique manual.
7:27E para esse mapa não envelhecer e perder a validade na gaveta, são necessárias só cinco verificações, a cada trimestre. Validar se os responsáveis e suplentes ainda trabalham na empresa, rastrear fornecedores compartilhados para evitar falsas redundâncias, marcar a caneta os passos manuais, inserir as renovações de domínio no calendário financeiro com alertas de 60 dias e, claro, atualizar a data de revisão do próprio mapa.
7:50E por falar em domínio, a decisão de quem é o dono dele é fundamental. Se deixar a propriedade só com o setor administrativo, o boleto é pago, mas se houver uma invasão, a parte operacional fica travada.
8:01Se deixar só com a área técnica, a operação flui, mas corre o risco do domínio expirar no meio de um feriado. A saída recomendada é ter posse conjunta, nomear dono técnico e dono financeiro para o mesmo elo, sempre ativando a renovação automática, avisos de 60 dias e bloqueio de transferência.
8:18Perder um domínio acontece por duas razões completamente independentes que moram em departamentos totalmente diferentes. Chegamos à nossa última parte, a seção 6, o mapa de uma página, entregáveis e salvaguardas.
8:31Antes de olharmos o documento final em si, existe uma salvaguarda operacional obrigatória que impacta diretamente as campanhas de marketing, e é um mecanismo que quem toma a decisão precisa exigir.
8:42A ramificação principal tem que ser a de produção, as prévias precisam ser protegidas com senhas ou logins, e detalhe, a Vercel Authentication ficou de graça em todos os planos desde 9 de setembro de 2026.
8:55Terceiro, toda revisão deve ser feita exclusivamente nesse ambiente de prévia, nunca direto em produção. E quarto, a reversão instantânea, o Instant Rollback, precisa estar a postos.
9:05Só lembrando que ele só funciona se a política de retenção da plataforma ainda guardar as versões antigas da campanha. E finalmente o nosso grande entregável, o mapa de uma página. É ele que tira aquele jargão técnico pesado da mesa de decisões.
9:19São os seis elos listados, os fornecedores reais por trás dos panos identificados, dono e suplente com nome e sobrenome, etapas manuais destacadas em vermelho e a data cravada da próxima revisão. O indicador de sucesso não podia ser mais simples.
9:33Seis elos mapeados, com seis responsáveis internos nomeados. E uma revisão documentada com menos de 90 dias de idade. Para encerrar, deixo aqui uma reflexão provocativa para a próxima reunião de diretoria. Quando o time disser que a nova versão subiu e no meio da madrugada o resolvedor de nomes ou o registro do domínio simplesmente cair, Sabendo que esses são elos vitais sem um contrato formal assinado na gaveta do jurídico, quem é que acorda para salvar o produto?
10:00Não esqueça, um elo sem responsável interno nomeado é um elo sem plano. Fica aí o alerta para a gente garantir a resiliência dessa cadeia o quanto antes. Um grande abraço e até a nossa próxima análise.
O caminho do código até o cliente, em conversa
Dois apresentadores percorrem o módulo pelo caso Nortis: por que o resolvedor que fez a coisa certa derrubou milhões de domínios, o que cada um dos seis elos custa e quanto tempo aguenta, por que o plano B pode cair junto com o plano A, quem deve responder pelo registro do domínio e o que fazer na segunda-feira.
Transcrição
0:00Bom, começando a nossa análise aprofundada de hoje, a gente vai mergulhar no primeiro capítulo do curso Deploy e Publicação para Decisão Executiva, Vercel e Cloudflare Exato, o capítulo que se chama O que muda no mundo quando alguém diz que subiu? E o nosso foco hoje é muito específico Muito. É focado exclusivamente na pessoa que aprova o orçamento de tecnologia. Quem assina o cheque, escuta a palavra subiu em toda a santa reunião, mas, sabe, nunca viu o caminho real que uma correção percorre até chegar no cliente.
0:31É. A regra desse material é clara. Não basta pagar a fatura. É preciso entender a cadeia completa. Pois é. E, para ilustrar isso, o curso usa o caso Nortis. E, aqui, só deixando claro em voz alta, como manda a regra didática do material, a empresa Nortis e a CEO dela, Marina, são um caso inteiramente fictício.
0:51Sim. Criados só para a didática do curso mesmo. Justo. Então, no cenário, a Marina vira para o CTO e pede o desenho do caminho do código até o cliente. E o CTO, claro, volta com aquele diagrama ingênuo de três caixas, né? Tipo, escreve, publica e cliente.
1:08Nossa, clássico. E aí vem o choque de realidade. Quando a gente detalha essas três caixas, aparecem imediatamente seis pontos de quebra. Seis. E o pior, três deles pertencem a fornecedores que nunca passaram por um contrato assinado pela empresa. Caramba.
1:23E a Nortis jurava que tinha só dois fornecedores de infraestrutura. Beleza, vamos desempacotar isso. O que exatamente essas caixas tão simples estão escondendo? Bom, elas escondem o que a palavra subiu realmente significa.
1:38Dizer que o código subiu é tipo dizer que uma carta foi enviada. Ah, o remetente joga na caixa de correio e ignora todo o complexo sistema postal. Exatamente. Ele lava as mãos. E a fonte detalha quatro fatos ocultos por trás da palavra subiu.
1:52Primeiro, existe uma máquina alugada que consome tempo para montar o pacote Segundo, o nome do site não é o site em si Terceiro, a entrega física acontece bem longe do fornecedor principal contratado E quarto, o ato de executar o código é fundamentalmente diferente de servir uma página que já estava pronta Olha, esse segundo fato de que o nome do site não é o site Parece até inofensivo no dia a dia Parece, né?
2:19Mas isso só até o momento em que a internet inteira decide discordar. E isso puxa o gancho para o maior pesadelo documentado na fonte, que é o caso da DENIC, em 5 de maio de 2026. Um dia tenso. Muito.
2:31Às 19h30 UTC, a DENIC, que é a operadora do registro do TLD .de, lá na Alemanha, passou a publicar assinaturas DNSSEC inválidas. Isso durante uma rotação de chave programada, é bom lembrar. Exato. E o impacto foi imediato.
2:46Os resolvedores validadores, incluindo o famoso 1.1.1.1, passaram a retornar um erro chamado SERVFAIL. Milhões de domínios ficaram absolutamente inalcançáveis, até a mitigação feita pela Cloudflare só às 22h17 UTC. Ou seja, cerca de três horas de apagão.
3:04E aqui, lendo a fonte, eu tenho que admitir uma estranheza, porque se o resolvedor estava ali só validando a segurança da assinatura, ele tecnicamente fez a coisa certa. Sim, ele fez.
3:15Então, não faz o menor sentido que a atitude correta tenha derrubado milhões de sites que estavam perfeitos na hospedagem. O resolvedor foi lá e desligou a internet. De propósito. Bom, a especificação técnica obriga a gente a enxergar diferente.
3:29A regra é rígida. Ela obriga o resolvedor a rejeitar de imediato qualquer resposta com assinatura inválida. Tá, não tem margem para interpretar o erro. Nenhuma. O comportamento correto e esperado do sistema foi exatamente o que causou a indisponibilidade.
3:44E a fonte deixa claro, embora esse caso da DENIC seja europeu, o mecanismo de DNSSEC é global. Entendi. Qualquer registro de domínio no mundo pode errar uma rotação de chave. É, fica bem claro que o registro é apenas um elo frágil no processo.
4:01E isso força a gente a dissecá-los, a transição imediata para os seis pontos de quebra daquela cadeia completa. O que é fascinante aqui é a regra da falha isolada. Cada um desses elos derruba o produto sozinho.
4:14O primeiro, acabamos de ver, que é o registro do domínio. O elo que falhou, no caso, o .de, sem sequer tocar na infraestrutura. E o segundo elo, que é a resolução de nomes, o famoso DNS, é o que o material diz ser o elo mais barato de contratar.
4:29Mas, paradoxalmente, é o mais caro de perder. Exato. E por que o mais caro? Porque não existe substituto imediato na hora da falha. Se o DNS cair, não tem botão de pânico. O terceiro ponto é a rede de entrega, a CDN. Cópias do produto espalhadas pelo mundo.
4:46A escala disso impressiona muito. É massiva. Em 6 de maio de 2026, a Cloudflare já declarava presença em 337 cidades e mais de 100 países. Caramba! E aí passamos para o quarto elo, que é o Build, a máquina que transforma texto em pacote.
5:03E a fonte é bem específica. A Vercel cobra a partir de 0,0035 dólares por CPU-minuto e tem um teto de 45 minutos por publicação. Passou disso? Falha. E o quinto elo é a execução em si, o consumo sob demanda.
5:19O teto de duração é de 300 segundos em todos os planos da Vercel. Peraí, só um detalhe importante para quem aprova orçamento e costuma ter informação antiga. Aquele famoso limite de 10 segundos só vale para projetos anteriores a 23 de abril de 2025.
5:33Bem lembrado, o teto subiu. E o sexto e último elo é o banco de dados e armazenamento. A Vercel, em documentação de 8 de julho de 2026, declara fazer backup a cada duas horas com retenção de 30 dias.
5:48Mas os backups são totalmente indisponíveis para os clientes. O que é assustador, porque o banco de dados é o único elo dessa lista toda, onde republicar a versão anterior do código não resolve o problema. Não resolve mesmo.
6:01É, fica muito evidente que o produto viaja por muitas mãos que não controlamos. A fonte até usa uma metáfora de logística muito boa aqui. Ah, da fábrica, né? Isso. Uma peça sai da fábrica, aí ela passa por uma transportadora, vai para um centro de distribuição subcontratado, depois viaja por uma rua que a prefeitura precisa ter cadastrado no mapa.
6:21Sim, até chegar no prédio. Chega no prédio, passa pelo porteiro, sobe no elevador, mas a fábrica, no começo de tudo, só assinou um contrato nessa cadeia inteira. A lição central aí é dura. Despachar não é entregar.
6:34O cliente só considera que o produto está no ar quando ele efetivamente consegue usar. A responsabilidade percebida recai sobre a cadeia toda. Tá, mas se despachar não é entregar, a liderança geralmente pensa Ah, vou assinar contratos com dois fornecedores de nuvem diferentes.
6:50Isso garante a entrega final. Aqui é que a coisa fica realmente interessante. A famosa ilusão da redundância. Pois é. Ter dois fornecedores gigantes é o princípio básico da redundância corporativa.
7:03Se a Vercel cair, a alternativa do plano B segura a onda. Certo. Eu discordo completamente dessa visão. E, baseado na tabela da fonte, eu provo o porquê. Contratos assinados não significam pontos de falha independentes. Como assim?
7:19A Vercel declara, naquela mesma documentação de 8 de julho de 2026, que usa primariamente a AWS, espalhada em 20 regiões. Ou seja, dois contratos com marcas diferentes podem repousar sobre a mesmíssima infraestrutura subjacente.
7:35Quando isso acontece, o seu plano B, que custou uma fortuna, cai no exato mesmo instante que o plano A. É o famoso castelo de cartas. E, diante desse choque de realidade sobre infraestrutura compartilhada, como é que uma liderança mapeia o caos sem enlouquecer?
7:52Voltamos ao CTO da Nortis e a solução prática dele. Sim. Numa reunião de 40 minutos, ele desenha o mapa real. E a CEO, a Marina, tem que ler o documento em voz alta, elo por elo, na frente de todo o time. E a regra de ouro que ele aplica aí é vital.
8:10Elo, cujo dono precisa ser descoberto na hora da crise, vira uma pendência com prazo. Jamais, em hipótese alguma, ele é preenchido de improviso só para terminar a reunião. E a métrica de sucesso para quem aprova o orçamento fica bem clara.
8:24Seis de seis elos precisam de um responsável nomeado, e o mapa exige uma revisão com menos de 90 dias. Obrigatoriamente. Mas vem cá, por que a revisão precisa ser com menos de 90 dias? O que faz esse mapa apodrecer assim na gaveta?
8:40Se a gente conectar isso com a imagem maior, a resposta está na invisibilidade das mudanças. O que invalida o mapa é quando o fornecedor muda de arquitetura sem avisar, O registrador é comprado por outra empresa, a equipe interna troca de membros.
8:55Ah, e aquele passo manual que era da pessoa X migra para a pessoa Y e ninguém anota. Exatamente. É por isso que existem as cinco verificações trimestrais. Tudo isso cabe numa reunião de 15 minutos, focada puramente em verificar se as fundações do documento ainda são reais.
9:11E foi justamente fazendo essa checagem que o mapa da Nortis encontrou um elo esquecido no tempo. E isso traz à tona o problema enorme do registro do domínio deles. Um cenário de risco de dar frio na barriga.
9:24O domínio da Nortis foi contratado em 2019 por uma pessoa que já saiu da empresa. Nossa! E a renovação acontece em apenas quatro meses. O pior detalhe, a fatura é debitada direto num cartão da área administrativa. Que não tem noção técnica nenhuma do perigo.
9:41E a fonte analisa três opções para resolver isso. A primeira é deixar com o administrativo. Resolve o pagamento, mas a área vai ignorar os aspectos técnicos que podem fazer a empresa perder o domínio num ataque de engenharia social, por exemplo.
9:55A segunda opção seria transferir para a área de infraestrutura. Que também tem problemas. Resolve a técnica, mas o vencimento financeiro do cartão sai completamente do radar de quem controla o orçamento. Pode expirar por falta de saldo e ninguém vê. Exato.
10:09E é por isso que a fonte determina que o correto é a terceira via. nomear um dono técnico e um dono financeiro para o mesmíssimo elo. Perfeito. Isso exige que a renovação automática seja ativada no painel, exige um aviso de 60 dias cravado direto no calendário financeiro da empresa e o bloqueio de transferência ativado.
10:28Assim, você blinda a falha de pagamento e a falha de configuração. E convenhamos, resolver esse risco primário de infraestrutura é o que permite, no fim do dia, executar o trabalho prático, como, por exemplo, colocar uma campanha de marketing no ar sem vazamentos.
10:42Totalmente. Sem a base garantida, você nem chega no marketing. E o guia prático de marketing do material resolve isso em poucas frases. A landing page de uma campanha deve ser revisada sempre numa prévia gerada por pull request. Importante frisar isso.
10:56E essa prévia deve estar rigidamente protegida antes de ir ao ar, para garantir que o público não acesse preços ou datas de lançamento antes da hora. E no caso de uma reversão rápida de campanha, o famoso Instant Rollback, A liderança precisa saber que reverter em segundos depende inteiramente de a versão anterior ainda existir lá no armazenamento do fornecedor.
11:18Ou seja, exige total atenção às políticas de retenção. Então, o que tudo isso significa? Significa que o próximo módulo trata justamente das palavras daquele diagrama que quem aprova o orçamento ainda não consegue explicar em voz alta.
11:32E, para fechar nossa análise, temos a tarefa intransigente que a fonte passa. A missão para segunda-feira. Missão para segunda-feira. A liderança deve desenhar o mapa de publicação em uma única página. Esse mapa deve conter as seis linhas de quebra, identificar o fornecedor real em cada uma e colocar o dono interno e o suplente para cada elo.
11:53Além da marcação visual, né? Todo passo que ainda exige clique manual precisa estar destacado. Sim, marcação visual. A data rigorosa da próxima revisão deve estar no topo e, finalmente, o lançamento da renovação do domínio tem que estar direto no calendário financeiro da empresa. Um fechamento denso, sem enrolação.
12:13Obrigada por ouvir mais esse nosso mergulho técnico e estrutural. Até a próxima análise.
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. Exemplo: 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. Exemplo: 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. Exemplo: 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. Exemplo: 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. Exemplo: 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. Exemplo: 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.
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.
Contratos 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ém
Para quem decide
Camada 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.
Para quem executa
- 01Comece pelo registro: quem é o registrador, quais são os servidores de nome declarados e quando a renovação vence.
- 02Verifique se a zona está assinada. Zona assinada acrescenta integridade e acrescenta dependência do operador do registro, o que precisa estar escrito no mapa.
- 03Leia 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.
- 04Confira quem responde de fato pelos cabeçalhos da resposta, e não pelo que o contrato diz.
- 05Decomponha o tempo total: resolução de nome, aperto de mão TLS e resposta. O elo lento aparece sozinho.
Levantamento dos seis elos a partir de qualquer máquina, sem acesso ao painel. Comandos conferidos em 24 de julho de 2026.
# 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.
Recomendação: 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.
Guia prático · Guia de marketing 1 · Prévia por pull request
Publique a landing page da campanha com prévia aprovada antes do ar
Caso de uso: Campanha de mídia paga · landing page de lançamento
No fim deste guia cada alteração da landing page gera um endereço de prévia próprio, protegido, que o time de marketing revisa e aprova antes de a versão ir para o domínio da campanha, e existe um caminho de volta em segundos se algo escapar.
Onde fica: Vercel: projeto > Settings > Git para a integração; Security > Deployment Protection para a proteção; Deployments para promover e reverter.
Passo a passo
Passo 1: Conecte o repositório e deixe a ramificação principal como produção
Importe o repositório no painel e confirme que a ramificação principal publica em produção. Toda outra ramificação e todo pull request passam a gerar uma prévia com endereço próprio. Verificação: abra um pull request de teste e confira se o comentário com o link da prévia aparece nele em poucos minutos.
Passo 2: Proteja todas as prévias, e a produção enquanto a campanha não estreia
Em Deployment Protection, escolha Vercel Authentication com o escopo All Deployments. Desde 9 de setembro de 2026 isso não custa nada em nenhum plano. Se a página do lançamento ainda não pode vazar, mantenha o escopo até a data de estreia e só então volte para prévias apenas.
Passo 3: Decida como a agência ou o cliente vão ver a prévia
Se o revisor tem conta na Vercel, convide-o para o time. Se não tem, use uma exceção de proteção para um endereço de prévia específico, gratuita desde 9 de setembro de 2026, ou ligue Password Protection no projeto, que no plano Pro passou a custar US$ 20 por projeto por mês. Antes, a senha só existia num complemento de US$ 150 por mês para o time inteiro.
Passo 4: Revise conteúdo, links e marcação na prévia, nunca em produção
Abra a prévia, confira o texto final, os botões, o formulário e as UTMs dos links de saída. Use a barra de comentários da prévia para pedir ajustes no próprio ponto da página. Critério para seguir: todos os comentários resolvidos e o formulário enviado ao menos uma vez com dado de teste.
Passo 5: Publique por mesclagem e saiba reverter em segundos
Mescle o pull request aprovado: o código revisado segue para um novo build de produção, com as variáveis de Production. Repita o teste do formulário nesse ambiente antes de liberar mídia. Se houver erro, Instant Rollback reaponta o domínio para uma produção anterior elegível, sem novo build. Confira antes se essa publicação ainda está retida.
| Ajuste | Valor recomendado |
|---|---|
| Deployment Protection | Vercel Authentication em All Deployments até a estreia; depois, só prévias |
| Revisor externo | Exceção de proteção por endereço (grátis) ou Password Protection (US$ 20 por projeto por mês no Pro) |
| Retenção de publicações | Manter ao menos as últimas versões de produção durante toda a campanha |
No plano Hobby, desde 16 de setembro de 2026, cada projeto guarda só as três publicações de produção mais recentes e as três mais recentes de qualquer tipo. Campanha com muitas publicações por dia pode perder a versão para a qual você queria voltar.
Prévia sem proteção fica aberta a qualquer pessoa com o link e vaza preço, oferta e data de lançamento. Não compartilhe o endereço de prévia em grupo aberto.
Critério de pronto e como medir
- Critério de pronto: um pull request de teste gerou prévia protegida, foi revisado por alguém de marketing e virou produção por mesclagem, sem publicação manual.
- Ensaio de reversão feito antes da estreia, com o tempo cronometrado e anotado no runbook da campanha.
Imagem: Documentação da Vercel.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Laboratório de campanha: validar a prévia sem contaminar os leads
A Nortis prepara uma campanha fictícia de diagnóstico logístico. Marketing aprovou o título, mas o formulário de prévia ainda pode enviar contatos ao CRM real. O exercício transforma a revisão visual em uma ficha verificável: ambiente separado, envio fictício e política de indexação. Use um projeto didático e um coletor de teste que aceite dados sintéticos; nenhuma mensagem deve chegar a uma pessoa real.
Aplicação prática revisada em 17/10/2026. A documentação de variáveis da Vercel, atualizada em 11/09/2026, confirma que alterações valem para novos deployments. Salvar uma variável não corrige uma prévia já construída.
Executar a revisão em Preview
Passo 1: Preparar o destino do teste
No projeto didático, abra Settings > Environment Variables. Cadastre LEADS_MODE=teste e o endereço do coletor de teste em LEADS_ENDPOINT, restritos a Preview. O código do formulário deve ler essas variáveis no servidor; o nome da variável sozinho não muda o comportamento.
Deu certo quando: A configuração e o código apontam para o mesmo coletor isolado.
Erro comum: Selecionar Production por engano ou supor que LEADS_MODE funciona sem implementação.
Passo 2: Gerar uma prévia com a configuração nova
Abra um pull request da campanha e, em Deployments, confira o SHA e o ambiente Preview. Se mudou variáveis depois do build, crie outro deployment antes de testar.
Deu certo quando: A URL testada pertence ao SHA e ao ambiente anotados na ficha.
Erro comum: Reabrir uma URL antiga e concluir que a variável não funcionou.
Passo 3: Enviar o lead fictício e conferir o recebimento
Na landing, use nome Contato de teste e teste@example.com, aceitos pelo coletor fictício, com utm_source=ensaio e utm_campaign=nortis-diagnostico. Confira a resposta de sucesso e o registro correspondente no coletor. Teste também campo obrigatório vazio.
Deu certo quando: Há um registro sintético coerente com o envio e nenhum contato no funil real; campo vazio mostra erro útil.
Erro comum: Agradecimento aparece mesmo com falha de envio. Peça ao time que só mostre sucesso após confirmação do servidor.
Passo 4: Conferir o navegador e a indexação
Em Ferramentas do desenvolvedor > Network, revise a requisição do formulário: o navegador chama a rota da aplicação, sem token de CRM no payload. Inspecione meta robots ou X-Robots-Tag: a prévia deve ter noindex. Mantenha proteção de acesso quando houver oferta confidencial.
Deu certo quando: O revisor autorizado consegue testar; a prévia não é candidata à indexação; credenciais ficam no servidor.
Erro comum: Confundir noindex com sigilo ou colocar chave privada em variável NEXT_PUBLIC_ ou VITE_, que pode ir para o JavaScript público.
No fim você tem: Entregue a ficha ao responsável pela publicação. O envio fictício precisa ser repetido na produção com uma rotina de teste controlada antes de ligar a campanha.
Aprovar a prévia da campanha
Evidências de conclusão
0/4Copiar a ficha de aceite da prévia
Documento montado
Campanha: Nortis diagnóstico, exercício fictício Prévia: [URL DA PRÉVIA] SHA: [SHA REVISADO] Revisor: [RESPONSÁVEL PELA REVISÃO] [ ] Ambiente Preview e configuração nova [ ] Formulário recebido no coletor de teste [ ] Erro de validação conferido [ ] Noindex e ausência de segredo no navegador Pendências e decisão: preencher antes da publicação.
O que você digitar fica salvo neste navegador. Nada é enviado para servidor algum.
Para um protótipo pequeno feito só de arquivos estáticos, o anúncio da Vercel de 17/09/2026 descreve um caminho de publicação sem build para até dez arquivos HTML ou Markdown, somando até 5 MB, com CLI 59.16.0 ou posterior. Isso ajuda a compartilhar uma proposta de campanha. Não comprova funcionamento de formulário, não substitui proteção da prévia e não promete esse tempo para um projeto Next.js.
Imagem oficial: documentação da Vercel sobre variáveis de ambiente, atualizada em 11/09/2026.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
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.
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.
Passo a passo do exemplo
Passo 1: Perguntar 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.
Passo 2: Perguntar 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.
Passo 3: Perguntar 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.
Passo 4: Marcar 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.
Exercício: o mapa de uma página
Exercício · 30 min
Passo 1: Desenhe seis linhas, uma para cada ponto de quebra: registro de domínio, resolução de nomes, rede de entrega, build, execução e banco.
Passo 2: Preencha 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.
Passo 3: Preencha a coluna do responsável interno, com suplente. Elo sem dono fica em branco e vira pendência com prazo, jamais preenchido de improviso.
Passo 4: Marque os passos que ainda dependem de uma pessoa clicar, com o nome de quem clica hoje.
Passo 5: Escreva 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.
No fim você tem: Entregável: Uma página com seis elos, fornecedor real, dono e suplente, passos manuais destacados e data de revisão marcada.
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.
Parte 2A mesa com o CFO
Ler a fatura de plataforma linha por linha e descobrir qual comportamento move cada linha. Você termina com a fatura do último ciclo decomposta, um parecer de região que separa carga sensível a latência de carga que pode rodar barato, o orçamento das linhas invisíveis de build e medição e uma política de gasto assinada, sabendo que a plataforma não oferece teto rígido.
Parte 3A mesa com o fornecedor
Escolher com número, entender o que o contrato devolve e saber quanto custa sair. Você termina com a comparação das duas plataformas preenchida com o volume real da empresa e o ponto de virada calculado, a tradução do compromisso de disponibilidade em minutos e em dinheiro, o calendário de obsolescência com datas já publicadas e um plano de saída com data de teste de restauração.
Parte 4A mesa com o CISO
Tratar a esteira de publicação como porta de entrada, porque foi por ela que os ataques de 2026 entraram. Você termina com o inventário das credenciais que publicam em produção, a política de dependências com janela de quarentena e inventário de componentes por build, a fronteira escrita do que a proveniência prova e a matriz de quem pode disparar a publicação.
Parte 5A mesa do incidente e do board
Cair, reverter, notificar quem a lei manda notificar e transformar tudo isso em rito permanente. Você termina com o cartão de incidente com caminhos de reversão testados e datados, o plano de notificação com o gatilho que inicia a contagem, a ficha de transferência internacional por sistema e a política de publicação assinada com data de revisão marcada.