# Como é um deploy de IoT de verdade, do piloto à produção

> Como é um deploy de IoT de verdade, da prova de conceito à operação em regime, as fases, os prazos e onde os projetos travam.

![Como é um deploy de IoT de verdade, do piloto à produção](https://tago.io/og/pt-br/blog/real-iot-deployment-from-pilot-to-production.png)

A maioria dos deploys de IoT não falha em campo. Eles falham na distância entre uma demo que funcionou e um sistema que alguém consegue operar por anos. A parte técnica, fazer um dispositivo enviar dados para um dashboard, é a parte que quase todo mundo consegue resolver. O problema está no que vem depois, e raramente é o que o plano original previu.

Um deploy de verdade passa por fases. Cada uma responde a uma pergunta diferente, e pular qualquer uma costuma reaparecer mais tarde como um problema que ninguém consegue explicar. Veja como o caminho realmente é, o que muda ao longo dele e onde os deploys empacam.

## As fases, e para que serve cada uma

**Prova de conceito.** Um dispositivo, ou poucos, na mesa ou na bancada. O objetivo é provar que o caminho dos dados funciona: o dispositivo reporta, o payload é interpretado, um dashboard mostra algo real. Isso é rápido, muitas vezes algumas semanas, e deve ser. Se uma prova de conceito se arrasta, o problema costuma ser meta mal definida, e não engenharia difícil.

**Piloto com dispositivos reais em campo.** Agora os dispositivos saem da bancada. Vão para o ativo real, no local real, com a conectividade real. É aqui que você descobre o que a prova de conceito não tinha como mostrar: que o sinal cai atrás de uma porta de metal, que a bateria descarrega mais rápido no frio, que o formato do payload muda quando o firmware é atualizado. Um piloto roda em semanas, não em dias, porque você precisa de tempo em campo suficiente para ver as falhas que só acontecem de vez em quando.

**Produção limitada.** Um subconjunto da frota completa, rodando do jeito que a produção vai rodar, mas pequeno o bastante para corrigir sem virar crise. Os alertas estão ativos. Alguém está acompanhando. Essa fase existe para testar a operação, não a tecnologia. Se algo quebra com cinquenta dispositivos, você quer saber antes de quebrar com cinco mil.

**Rollout completo.** O resto da frota entra em operação, normalmente site por site ou região por região, e não tudo de uma vez. Isso leva meses em qualquer deploy de porte real, porque provisionamento, instalação e verificação acontecem na velocidade humana, em muitos locais.

**Operação em regime.** O deploy deixa de ser um projeto. Vira um sistema que roda. Dispositivos falham e são trocados. Atualizações de firmware são publicadas. Alertas disparam e as pessoas respondem. Essa fase não tem data de término, e é a fase que o orçamento original quase sempre subestima.

## O que muda de verdade entre o piloto e a produção

O piloto provou a ideia. Produção é outro trabalho, e a diferença não é só ter mais dispositivos.

**A escala muda a conta.** Um processo que funciona quando você provisiona dez dispositivos na mão desmorona com mil. Você precisa de um jeito de registrar, configurar e agrupar dispositivos que não envolva uma planilha e uma pessoa digitando.

**A gestão de dispositivos vira uma disciplina própria.** No piloto você conhece cada dispositivo pelo nome. Em produção você tem dispositivos que nunca viu fisicamente, em locais que nunca vai visitar, e precisa saber quais estão saudáveis, quais ficaram em silêncio e quais estão prestes a falhar.

**O sistema de alertas precisa conquistar confiança.** Um alerta de piloto que dispara errado é um aborrecimento pequeno. Um alerta de produção que grita lobo acaba sendo ignorado, e um sistema de alertas ignorado é pior que nenhum, porque as pessoas param de olhar. Acertar os limites, suprimir ruído e rotear o alerta para quem pode agir exige ajuste de verdade, e isso acontece depois do piloto, não durante.

**Suporte e plantão aparecem.** Quando um dispositivo cai às 2 da manhã e isso importa, alguém precisa atender. Produção significa um caminho de suporte e uma escala de plantão, mesmo que enxuta. É um custo e uma responsabilidade que pilotos nunca têm.

**O rollout multi-site introduz variação.** Sites diferentes têm conectividades diferentes, layouts diferentes, pessoas diferentes instalando o hardware. O que funcionou no site do piloto não funciona automaticamente nos próximos dez.

**Atualizações de firmware viram rotina e risco.** Uma frota de dispositivos em campo precisa de atualizações de segurança e de novas funcionalidades. Enviar firmware para milhares de dispositivos sem inutilizar nenhum é um processo que você tem que construir e em que precisa confiar, e não é algo que um piloto chega a exercitar.

## Onde os deploys travam

As fases não são a parte difícil. As transições são. Alguns padrões de falha aparecem de novo e de novo.

**Purgatório do piloto.** O piloto funciona. Todo mundo concorda que funciona. E então nada acontece por meses. Em geral é porque o piloto provou a tecnologia mas ninguém montou o business case para escalar, ou ninguém ficou responsável por tocar o rollout, ou o orçamento de produção nunca foi real. O piloto vira uma demo permanente que prova um ponto sobre o qual ninguém age.

**Dados sobre os quais ninguém age.** Os dashboards estão no ar, os dados fluem, e a operação roda exatamente como rodava antes. O deploy gera informação que não muda nenhuma decisão. Essa é a falha mais silenciosa, porque tudo parece estar funcionando. O valor da IoT está na ação que o dado dispara, e se nenhuma ação foi conectada, o dado é só telemetria cara.

**Sem dono da operação.** A equipe de projeto constrói o deploy e segue em frente. Ninguém herda aquilo. Dispositivos começam a falhar, alertas ficam sem resposta, o firmware fica desatualizado, e o sistema se degrada até ficar não confiável, ponto em que as pessoas concluem que IoT não funciona. O problema de verdade foi que o deploy teve quem construísse, mas não teve dono.

## A passagem para a operação

O momento que decide se um deploy sobrevive é a passagem da equipe que construiu para a equipe que opera. Essa passagem falha quando é tratada como detalhe de última hora.

Uma passagem que funciona inclui o que a operação de fato precisa: significado dos alertas e passos de resposta documentados, um jeito de ver a saúde dos dispositivos de relance, um processo para trocar hardware morto e um dono claro, cobrado por garantir que o sistema rode. A equipe de operação não precisa entender como cada parser funciona. Ela precisa saber o que cada alerta significa, o que fazer a respeito e para quem ligar quando algo fugir do runbook.

Os deploys que chegam ao regime de operação são aqueles em que a operação foi envolvida antes da passagem, e não recebeu um sistema que nunca tinha visto com a ordem de manter de pé.

## Como uma camada de aplicação gerenciada encurta o caminho

Boa parte da distância entre piloto e produção é trabalho que não tem nada a ver com o seu caso de uso específico. Provisionar dispositivos em escala, armazenar e servir dados, construir dashboards, ajustar alertas, gerenciar firmware, monitorar a saúde dos dispositivos. Todo deploy precisa disso, e construir do zero é onde os meses vão embora.

É esse o trabalho que uma camada de aplicação gerenciada absorve. A TagoIO fica em cima da sua conectividade e cuida das partes que são iguais entre deploys: ingerir dados de dispositivos, armazenar, rodar a lógica, servir dashboards e disparar alertas. Provisionar e agrupar dispositivos é configuração, e não código sob medida, e é isso que faz o salto de dez para dez mil dispositivos ser um ajuste em vez de uma reconstrução. Como a plataforma é multi-tenant, um rollout em vários sites ou clientes não significa subir infraestrutura nova para cada um.

Para deploys em que outra pessoa vai operar o front-end, o TagoRUN dá aos integradores de sistema uma camada white-label para revender com a marca própria, de modo que a passagem para a operação possa ir para um parceiro em vez de uma equipe interna. Na borda, o TagoCore é um runtime open-source para o lado do dispositivo da mesma stack. E para trabalhos regulados, a TagoIO é certificada ISO 27001 e alinhada ao GDPR, o que importa quando um deploy passa a guardar dados reais de produção.

Nada disso elimina o trabalho de operar um deploy. As pessoas continuam respondendo a alertas, trocando dispositivos e sendo donas do sistema. O que isso elimina são os meses gastos reconstruindo as partes que todo deploy compartilha, para que o tempo que você gasta vá para a parte que é de fato sua.

## Recursos

- [Veja deploys e os problemas que eles resolvem](https://tago.io/use-cases)
- [Gestão e provisionamento de dispositivos em escala](https://docs.tago.io/docs/tagoio/devices/data-management/device-data-management)
- [Revenda com a sua própria marca usando o TagoRUN](https://tago.io/run)
- [Comece a construir e teste o seu próprio deploy](https://admin.tago.io)

[llms.txt](https://tago.io/llms.txt)