Resposta rápida
“Sustentar” é garantir que o sistema permaneça disponível, seguro e evoluindo depois do lançamento — com métricas, processo e responsabilidades claras.
O que é sustentação (de verdade)
Sustentação não é “ficar à disposição”. É um acordo operacional. A IBM define SLA como um contrato que define o serviço, o nível de performance esperado, como medir e o que acontece se não cumprir.
“Um SLA… define o serviço e o nível de performance esperado.”
SLA vs SLO: o que entra no combinado
A prática que funciona é: SLA no contrato + SLO no painel (para acompanhar a saúde do serviço). A IBM explica que SLOs fazem parte de SLAs e definem baselines como taxa de erro, latência e uptime.
Métricas mínimas (comece simples)
- Disponibilidade (ex.: 99,9%)
- Latência (tempo de resposta)
- Taxa de erro (ex.: 5xx)
- MTTR (tempo para restaurar)
- Tempo de primeira resposta (suporte)
Exemplo de prioridades (pra não virar discussão)
- P0: sistema fora / impacto total (ação imediata)
- P1: impacto alto / workaround parcial
- P2: impacto moderado / sem urgência
Rotina de suporte: incidente → problema → mudança
No ITSM, esses três processos formam um ciclo: incidente restaura rápido, problema acha causa-raiz, mudança aplica correção com controle.
Rotina semanal (o mínimo que sustenta)
- Triagem e classificação (P0–P2)
- Correções rápidas (hotfix) com validação
- Backlog de melhorias priorizado por impacto
- Janela de mudança (release) com rollback planejado
O que todo incidente precisa registrar
- sintoma, impacto, duração
- ações executadas
- causa-raiz (RCA) e prevenção
- decisão: vira problema? vira mudança?
Evolução contínua sem virar caos
Um jeito maduro de equilibrar “melhorar” e “não quebrar” é usar SLO + error budget: no material de SRE do Google, error budget é 1 – SLO e serve para balancear confiabilidade e ritmo de mudanças.
Tradução prática: se a estabilidade piora, pausa feature e paga dívida (performance, testes, observabilidade).
Checklist de sustentação para os próximos 30 dias
- Definir 3 SLOs e publicar painel
- Fechar SLA (horários, prazos, prioridades, canais)
- Criar rotina de releases (quinzenal ou mensal)
- Padronizar RCA para incidentes relevantes
- Planejar evolução (roadmap) com capacidade reservada
Na growtech™, a sustentação entra como método: suporte + performance + segurança + evolução, com critérios e cadência.
Notas e trade-offs (riscos, alternativas, dependências)
- Risco: “SLA genérico” (sem métrica, sem prioridade, sem penalidade) vira atrito. A definição de SLA exige medição e consequência.
- Trade-off: mais rigor (SLO/painel/postmortem) aumenta custo inicial, mas reduz custo de crise e retrabalho no médio prazo.
- Dependência: para cumprir SLO, você precisa de monitoramento/alertas e rotina de mudança; sem isso, o ciclo “incidente→problema→mudança” não fecha.
- SEO/AIO: o Google afirma que não existe “otimização especial” para AI Overviews/AI Mode — o jogo continua sendo conteúdo útil, estruturado e rastreável.
