Confiabilidade¶
Compromissos operacionais factuais da TELECOM TOWER POWER. Métricas baseadas no que está implementado e medido em produção, não em aspiração.
Última revisão: 2026-06-24. Status em tempo real: monitoring.telecomtowerpower.com.br.
SLA por tier¶
| Tier | Disponibilidade mensal | Crédito por violação |
|---|---|---|
| Free | Best-effort | — |
| Starter | 99.5% | — |
| Pro | 99.5% | 10% do mês |
| Business | 99.9% | 25% do mês |
| Enterprise | 99.9% | 50% do mês |
| Ultra | 99.95% | 100% do mês |
A janela de cálculo é o mês civil em UTC. Manutenção programada anunciada com ≥72 h de antecedência não conta como indisponibilidade.
RTO e RPO¶
O Railway é a região primária única; a estratégia de recuperação é restore a partir de backup, não failover quente entre regiões.
| Cenário | RTO | RPO |
|---|---|---|
| Falha de container/instância (Railway) | < 5 min (restart automático) | 0 (stateless) |
| Incidente de região/provedor (Railway) | horas (depende da recuperação do Railway) | ≤ 24 h hoje (backup noturno → S3); ≤ 1 h quando o backup horário estiver habilitado |
| Corrupção lógica de banco | ~ 2–4 h (restore do último dump em S3) | ≤ 24 h hoje (backup noturno); ≤ 1 h com o backup horário |
| Perda total do projeto Railway | ~ 1 dia (restore do dump em S3, conta independente) | ≤ 24 h hoje; ≤ 1 h com o backup horário |
Drill semanal automatizado verifica restore de Postgres + assertions de integridade.
Recuperação de desastres¶
Não há failover quente ativo entre regiões — o Railway hospeda a região primária única. A continuidade é garantida por restore a partir de backup:
- Backup automatizado do Postgres → S3 (
backup-railway-postgres.yml, noturno) como linha de base. - Serviço de backup horário (
pg-backup, cron nativo do Railway → S3) provisionado para estreitar o RPO a ≤ 1 h. - Drill de restore semanal (
backup-restore-drill.yml) restaura o último dump em Postgres efêmero e valida integridade. - Os artefatos vivem em S3 (
sa-east-1), separados do provedor de compute (Railway), cobrindo a perda total do projeto Railway.
Multi-region ativo / failover quente está fora do roadmap atual por custo e pela natureza majoritariamente reconstruível do dado (as torres derivam de fontes públicas ANATEL/OpenCellID).
Detalhes em Operações/Runbook.
Observabilidade¶
- Métricas: Prometheus + Grafana, 14 dias de retenção
- Logs: Loki, 30 dias
- Traces: Tempo (OpenTelemetry), 7 dias
- Alertas: 12 regras Prometheus → Alertmanager → Slack (critical-only,
send_resolved=true); rota PagerDuty/Opsgenie disponível para tenants Tier-1 com NOC contratado, inerte por padrão - Synthetic monitoring: GitHub Actions cron probes nos endpoints públicos (api, app, www, monitoring, prometheus) a cada 5 min
- Dashboard público: monitoring.telecomtowerpower.com.br
Continuidade do negócio (Bus factor)¶
A empresa é pequena. Tratamos a continuidade como controle de primeira ordem:
| Mitigação | Aplicável a |
|---|---|
| Source code escrow (cláusula contratual) | Enterprise, Ultra |
| Runbook público versionado em git | Todos |
| Backups automatizados + restore drill semanal | Todos |
| Documentação de arquitetura completa | Todos |
| CI/CD reproduzível (44 workflows GitHub Actions) | Todos |
| Infraestrutura como código (railway.json por serviço, Docker Compose on-prem) commitada | Todos |
| Knowledge base de incidentes em git | Todos |
O escrow permite que clientes Enterprise/Ultra recebam o código-fonte completo (modulo dependências third-party com licenças incompatíveis) caso a empresa cesse operações por mais de 60 dias.
Histórico de incidentes¶
Página pública de status: Status.
Postmortems publicados em até 7 dias úteis após incidentes Sev-1 ou Sev-2.
Manutenção programada¶
- Janela preferencial: domingos 04:00–06:00 UTC
- Anúncio: email para todos os contatos de billing + banner em
app.*≥72 h antes - Tipicamente zero downtime (rolling deploy no Railway); janelas anunciadas só se rolling não for possível
Endurecimento recente (2026-Q2)¶
- Fila prioritária Enterprise/Ultra: RQ/Redis (fila
ttp_priority), SLA 99.95% no Ultra - Modelo ML em produção: ridge-v1 (RMSE 12.94 dB, n=20 000) para
/coverage/predict, com retrain noturno - Snap ANATEL por prestadora: melhora precisão de localização para todas as 12 SMP/SME indexadas
- Restore drill semanal: assertions de integridade em
towers,api_keys,alembic_versiontoda segunda 07:15 UTC
Limitações conhecidas¶
- Região única: o Railway hospeda a região primária única; não há failover quente entre regiões. A recuperação de desastres é por restore a partir de backup (S3). Multi-region ativo está fora do roadmap atual por custo.
- Sem auditoria SOC 2 / ISO 27001 externa hoje. Práticas documentadas e auditáveis em Compliance/SOC 2.
- Equipe pequena: on-call 24/7 só para Business+; planos inferiores recebem suporte em horário comercial UTC-3.