Suporte com SLA · plantão 24x7
Time de DBAs sêniores disponível para responder quando o banco de dados falha, degrada ou trava a operação. Suporte contínuo com SLA contratual ou acionamento emergencial pontual — em MySQL, MariaDB, PostgreSQL, SQL Server, Oracle e MongoDB.
Atendimento emergencial com acionamento imediato, mesmo sem contrato prévio.
Modelos
Os dois modelos existem porque as necessidades são diferentes. Um evita o incidente; o outro resolve o incidente que já está acontecendo.
Boa parte dos clientes chega pelo emergencial e permanece no contínuo. A razão é simples: depois da primeira madrugada resolvendo indisponibilidade sem histórico do ambiente, fica evidente que monitoramento e conhecimento acumulado custam menos que o downtime.
| Suporte contínuo | Atendimento emergencial | |
|---|---|---|
| Contrato | Mensal, com horas e SLA definidos | Pontual, sem contrato prévio |
| Acionamento | Portal, e-mail, telefone e WhatsApp | WhatsApp ou telefone |
| Monitoramento | Incluído, com alertas proativos | Não incluído |
| Escopo | Incidentes, mudanças, tuning e prevenção | Restabelecer o serviço afetado |
| Melhor para | Ambientes críticos e times enxutos | Crise pontual ou primeira experiência com a HTI |
Escopo
Resposta a incidentes
Indisponibilidade, corrupção, replicação quebrada, deadlock em massa, disco cheio e falha de failover.
Monitoramento e alertas
Métricas de disponibilidade, latência, replicação, espaço e saturação, com alerta antes do impacto ao usuário.
Análise de causa raiz
Todo incidente relevante gera relatório com causa, correção aplicada e ação preventiva.
Gestão de mudanças
Aplicação de patches, ajustes de parâmetros, criação de índices e mudanças de schema com janela e rollback.
Backup e restore
Verificação das rotinas, testes periódicos de restauração e execução de recovery quando necessário.
Suporte ao time de desenvolvimento
Revisão de queries e de modelagem antes do deploy, evitando que o problema chegue à produção.
SLA
O SLA é acordado por severidade, não em um número único de marketing. Severidade 1 é serviço indisponível ou perda de dados em andamento; severidade 2 é degradação com impacto ao usuário; severidade 3 é solicitação planejada. Cada nível tem prazo de primeira resposta e cadência de atualização definidos em contrato.
Ambientes com exigência de disponibilidade acima do padrão são desenhados junto com o cliente: redundância, failover testado e janela de manutenção combinada. Disponibilidade alta é resultado de arquitetura, e não apenas de tempo de resposta do suporte.
Severidade 1
Serviço indisponível. Acionamento imediato do plantão, trabalho contínuo até restabelecer.
Severidade 2
Degradação relevante. Diagnóstico iniciado no mesmo dia útil com plano de correção.
Severidade 3
Mudança ou dúvida planejada. Agendamento conforme a fila combinada.
Relatórios
Consolidado mensal de incidentes, tempo de resposta, mudanças e recomendações.
Cobertura
MySQL e MariaDB
Replicação, InnoDB Cluster, ProxySQL e ambientes em RDS e Aurora.
PostgreSQL
Streaming replication, Patroni, pgBouncer, RDS e Cloud SQL.
SQL Server
Always On, log shipping, tempdb, Agent e Azure SQL.
Oracle
Data Guard, RAC, RMAN e tuning de instância.
MongoDB
Replica set, sharding e Atlas.
Ambientes híbridos
On-premises, nuvem pública e coexistência entre os dois.
Perguntas frequentes
Sim. O plantão cobre 24 horas por dia, sete dias por semana, incluindo feriados, para clientes com contrato de suporte contínuo. Para acionamentos emergenciais sem contrato, o atendimento também é possível fora do horário comercial, conforme disponibilidade do plantão no momento.
Continue por aqui
Se o ambiente já está instável, aciona agora. Se ainda não está, é o melhor momento para desenhar SLA e monitoramento antes do primeiro incidente.
↗ Acionar um DBA agora