Um SLA de broker MQTT é o compromisso escrito de um provedor sobre disponibilidade, e as letras miúdas importam tanto quanto o percentual da manchete. Este artigo traduz metas comuns de uptime em minutos reais de indisponibilidade, explica o que os SLAs normalmente cobrem e excluem e mostra como projetar seus dispositivos e aplicações para lidar bem com a indisponibilidade que qualquer SLA ainda permite.
O Que um SLA É, e o Que Ele Não É
Um acordo de nível de serviço é um documento contratual. Ele define uma meta mensurável, geralmente a disponibilidade mensal, como a disponibilidade é medida e o que o provedor deve a você se a meta não for cumprida. Três termos relacionados costumam ser confundidos:
- SLI (service level indicator): o valor medido, como o percentual de tentativas de conexão bem-sucedidas.
- SLO (service level objective): a meta interna que uma equipe persegue, muitas vezes mais rigorosa que o SLA.
- SLA (service level agreement): a promessa externa e contratual com consequências, geralmente créditos de serviço.
O ponto crucial: um SLA não impede indisponibilidades. Ele define quanta indisponibilidade é aceitável e como você é compensado quando há mais. O seu sistema ainda precisa lidar com a indisponibilidade que o SLA permite.
Percentuais de Uptime em Minutos de Indisponibilidade
As diferenças entre os "noves" são maiores do que parecem. A tabela usa um mês médio de cerca de 30,4 dias e um ano de 365 dias.
| Disponibilidade | Indisponibilidade por mês | Indisponibilidade por ano |
|---|---|---|
| 99% | cerca de 7 horas e 18 minutos | cerca de 3 dias e 15,6 horas |
| 99,5% | cerca de 3 horas e 39 minutos | cerca de 1 dia e 19,8 horas |
| 99,9% | cerca de 43,8 minutos | cerca de 8,8 horas |
| 99,95% | cerca de 21,9 minutos | cerca de 4,4 horas |
| 99,99% | cerca de 4,4 minutos | cerca de 52,6 minutos |
| 99,999% | cerca de 26 segundos | cerca de 5,3 minutos |
Passar de 99,9% para 99,99% reduz a indisponibilidade permitida em dez vezes. Alcançar isso exige redundância entre domínios de falha, failover automatizado e gestão cuidadosa de mudanças, e é por isso que os níveis mais altos costumam estar ligados a infraestrutura dedicada e contratos enterprise.
Você pode calcular esses valores por conta própria:
def allowed_downtime(availability_pct, period_minutes):
return period_minutes * (1 - availability_pct / 100)
MONTH = 30.44 * 24 * 60
YEAR = 365 * 24 * 60
for a in (99.0, 99.5, 99.9, 99.95, 99.99, 99.999):
print(f"{a}%: {allowed_downtime(a, MONTH):.1f} min/month, "
f"{allowed_downtime(a, YEAR) / 60:.2f} h/year")
O Que um SLA de Broker MQTT Normalmente Cobre
Definição de Indisponibilidade
Leia como "indisponível" é definido. Para um broker, pode significar que o endpoint não aceita novas conexões, que um percentual das tentativas de conexão falha ou que as mensagens não são entregues. Alguns contratos só contam indisponibilidades que duram mais que alguns minutos consecutivos, o que significa que falhas curtas simplesmente não contam.
Método de Medição
Quem mede, e de onde? O monitoramento do lado do provedor pode ver o broker saudável enquanto os seus dispositivos em uma determinada rede não conseguem alcançá-lo. Pergunte se você pode enviar os seus próprios dados de monitoramento ao solicitar créditos.
Escopo
Verifique quais componentes estão cobertos: endpoints de conexão, listeners TLS e WebSocket, o portal de gerenciamento, APIs usadas para provisionamento. Portais e APIs costumam ter cobertura diferente da do plano de dados, ou nenhuma.
Créditos de Serviço
Quando a meta não é cumprida, a compensação usual é um crédito: um percentual da mensalidade, muitas vezes escalonado conforme o quanto a disponibilidade caiu. Os créditos normalmente precisam ser solicitados dentro de um prazo e raramente são proporcionais ao impacto de uma indisponibilidade no negócio. Pense nos créditos como um incentivo para o provedor, não como um seguro para você.
Exclusões Comuns
Quase todo SLA exclui alguns eventos. Exclusões típicas incluem:
- Manutenção programada anunciada com antecedência.
- Problemas causados pelos próprios dispositivos, redes ou configurações incorretas do cliente.
- Ultrapassar os limites do plano, como cotas de conexões ou de mensagens.
- Eventos de força maior.
- Planos gratuitos, de avaliação ou beta.
- Problemas em redes de terceiros entre os seus dispositivos e o provedor.
Planos gratuitos, em especial, raramente vêm com um SLA contratual. Isso é razoável para desenvolvimento e pilotos, mas compromissos de produção com os seus próprios clientes devem se apoiar em um plano com termos explícitos.
Disponibilidade Composta: O Seu Sistema É uma Corrente
A sua disponibilidade de ponta a ponta não é a disponibilidade do broker. Uma mensagem de um sensor passa pelo dispositivo, pela rede local, pela operadora móvel ou de internet, pelo broker, pelo seu back-end e pelo seu banco de dados. Quando os componentes estão em série, as disponibilidades se multiplicam.
Por exemplo, se a rede de um dispositivo tem 99,5% de disponibilidade, o broker 99,9% e o seu back-end 99,9%, a corrente fica em aproximadamente 0,995 x 0,999 x 0,999, cerca de 99,3%. O elo mais fraco domina. Investir pesado em noves do broker enquanto o seu back-end roda em um único servidor traz pouco ganho. Para padrões de arquitetura, veja alta disponibilidade de broker MQTT.
Projetando para a Indisponibilidade que um SLA Permite
Mesmo com 99,99%, um broker ocasionalmente ficará inacessível. Construa clientes que tolerem isso:
- Reconecte com backoff exponencial e jitter, para que milhares de dispositivos não reconectem no mesmo instante.
- Faça buffer local em dispositivos e gateways e publique quando a conexão voltar.
- Use sessões persistentes com um session expiry adequado, para que mensagens QoS 1 e 2 destinadas a assinantes offline fiquem enfileiradas.
- Use retained messages para estado, para que os dashboards vejam o último valor conhecido logo após reconectar.
- Configure um Last Will para que o seu back-end saiba quando um dispositivo caiu inesperadamente.
- Monitore de fora com um cliente sintético que publica e recebe um heartbeat.
O guia de indisponibilidade de broker MQTT cobre o lado dos incidentes, e o checklist MQTT para produção transforma esses pontos em tarefas pré-lançamento.
Disponibilidade Não É o Mesmo que Durabilidade
Uma meta de disponibilidade diz se o broker aceita conexões e roteia mensagens. Ela não diz nada sobre se cada mensagem é preservada durante um incidente. Pergunte separadamente como sessões, mensagens enfileiradas e retained messages se comportam quando um nó do broker reinicia ou faz failover, e projete de acordo com a resposta. Se perder uma mensagem for caro, mantenha a fonte da verdade no dispositivo ou no seu back-end e faça do broker um transporte, não um repositório. Os tempos de resposta do suporte são um terceiro compromisso, separado, que vale ler com atenção.
Perguntas a Fazer Antes de Assinar
| Pergunta | Por que importa |
|---|---|
| Como a disponibilidade é medida, e por quem? | Determina o que conta como indisponibilidade |
| Qual é a duração mínima de indisponibilidade contabilizada? | Indisponibilidades curtas podem ser excluídas |
| A manutenção programada é excluída, e com quanta antecedência é avisada? | Paradas planejadas ainda afetam os dispositivos |
| Quais componentes estão cobertos? | Portal e APIs podem ser diferentes dos endpoints |
| Como os créditos são calculados e solicitados? | Há prazos e tetos |
| Existe uma página de status e um histórico de incidentes? | Mostra o histórico real |
| Quais tempos de resposta do suporte se aplicam? | Uptime e suporte são compromissos separados |
SLAs e o ConnectMQ
O ConnectMQ é um broker MQTT gerenciado e oferece vários planos, de um nível Serverless gratuito em cluster compartilhado a clusters isolados Dedicated, BYOC na sua própria conta de nuvem gerenciado pelo ConnectMQ e Self Managed Enterprise. Se o seu projeto precisa de termos contratuais de disponibilidade, discuta-os com a equipe do ConnectMQ para as opções Dedicated, BYOC ou enterprise e use as perguntas acima para revisar o que for oferecido. Quaisquer que sejam os termos, são as práticas do lado do cliente descritas neste artigo que mantêm a sua frota saudável quando qualquer broker tem um dia ruim, seja numa frota de medidores de uma distribuidora de energia ou nos sensores de uma planta de saneamento.
Comece com o ConnectMQ
Construa e teste a sua lógica de reconexão e buffer em um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, ou experimente antes no servidor MQTT público (gratuito), pensado para testes e protótipos, não para dados de produção. Para uma visão geral do que um broker MQTT gerenciado tira das suas mãos e de como os modelos de hospedagem se comparam, leia o guia de broker MQTT na nuvem.
Perguntas frequentes
Quanta indisponibilidade um SLA de 99,9% permite?
Cerca de 43,8 minutos por mês, ou aproximadamente 8,8 horas por ano.
Um SLA garante que meus dispositivos ficarão conectados?
Não. Ele define uma meta de disponibilidade e a compensação caso ela não seja cumprida. Seus dispositivos ainda precisam de lógica de reconexão, buffer e monitoramento.
Planos gratuitos de broker MQTT incluem SLA?
Planos gratuitos normalmente não incluem SLAs contratuais. Use-os para desenvolvimento e pilotos e escolha um plano com termos explícitos para compromissos de produção.
99,99% é sempre melhor que 99,9%?
Permite dez vezes menos indisponibilidade, mas a sua disponibilidade de ponta a ponta depende de cada componente da corrente. Melhore primeiro o elo mais fraco.
