Sustentação
& Plantão.
Engenheiro com nome no plantão. Não número de chamado. Sev1 com toque em 5 min, postmortem blameless em 5 dias úteis, runbook na wiki do cliente. Contrato anual com saída em 30 dias — recontrata se for melhor que a alternativa.
Engenheiro sênior desde o primeiro alerta. Acordado, com contexto, com autonomia.
Plantão tradicional usa catraca: nível 1 abre chamado, nível 2 lê chamado, nível 3 — onde mora a expertise — vira ponte só quando o cliente já está irritado. Não compra tempo, compra fricção. Aqui o sênior é o primeiro toque, com runbook na mão e autonomia para corrigir — não só escalar.
- P·01
On-call rotation com nome
Calendário compartilhado: você sabe quem está no plantão da semana, com qual experiência, em qual fuso. Se prefere alguém específico para uma janela crítica (Black Friday, virada fiscal), a gente combina e fixa em contrato.
- P·02
Follow-the-sun real
São Paulo, Lisboa, México. Plantão noturno não é alguém acordado às 3h tomando decisão sonolento — é o engenheiro do outro fuso, com café, lendo o mesmo runbook.
- P·03
Pager fadiga monitorada
Engenheiro acordado 3 vezes na mesma semana é sintoma de alerta ruim — e backlog imediato. A meta é <1,5 página por turno. Burnout não escala.
- P·04
Autoridade para corrigir
Plantonista tem credencial, runbook e janela de mudança emergencial pré-aprovada. Não escala para acordar arquiteto a fim de aplicar fix de 4 linhas. Ação registrada no audit trail, revisada na manhã seguinte.
- P·05
Comunicação durante incidente
Status page interna atualizada a cada 15 min, sem jargão. Cliente recebe versão executiva (1 parágrafo, próximo update em X) por canal acordado — não é reféns de perguntar.
Linha do tempo do incidente. Sev1 ao postmortem.
Incidente bem gerido tem rito. Quem comanda (incident commander), quem comunica (comms lead), quem investiga (subject matter expert) — papéis acordados antes do alerta tocar. Fluxo abaixo é o padrão Redgator, ajustado por cliente quando ferramental ou regulação pede.
Alerta dispara contra SLO. Pager toca. Incident channel criado automaticamente (Slack/Teams).
Plantonista assume IC, classifica severidade, abre war room. Bot puxa dashboard, último deploy, alertas correlatos.
Rollback, feature flag, scale up, circuit breaker. Causa pode esperar — usuário não. Comms lead informa cliente.
Sintoma resolvido. SME investiga causa raiz com calma. Status page atualizada a cada 15 min até resolução.
Causa raiz mitigada (não só sintoma). Fix permanente em PR ou backlog priorizado. War room fechada.
Documento publicado. Ações de engenharia com owner e prazo. Apresentado em reunião quinzenal com cliente.
- G·01
Incident commander designado
Plantonista assume IC. Não é o sênior mais sênior — é o que está no plantão. Sêniores entram como SME quando convocados, sem disputar comando. Hierarquia de incidente não é hierarquia de cargo.
- G·02
Comms lead separado do IC
IC investiga e decide. Comms escreve update e fala com stakeholder. Em Sev1 com cliente afetado, esse desacoplamento é a diferença entre IC focado e IC sobrecarregado.
- G·03
Tooling integrado
PagerDuty, Opsgenie, FireHydrant, Rootly, incident.io. Bot que abre canal, puxa dashboard, registra timeline, gera draft de postmortem. Operamos sem fanatismo — o que o cliente já tem.
- G·04
Mitigação primeiro, causa depois
Restaurar serviço é prioridade absoluta. Causa raiz vira investigação após estabilização. Rollback é honesto — não fracasso. Reverteu? Documenta e segue.
- G·05
Severidade reavaliada em tempo real
Sev2 que vira Sev1 sobe na hora. Sev1 que se mostra Sev2 desce, com critério. Severidade não é orgulho — é decisão operacional.
- G·06
Status page externa quando faz sentido
Cliente B2B: comunicação direta basta. Cliente B2C com base larga: status page pública (Statuspage, Instatus, Better Stack) atualizada na mesma cadência da interna.
Blameless. Em 5 dias úteis. Vira backlog, não PDF.
Postmortem que acusa pessoa não previne incidente — gera ocultação. Postmortem em PDF que ninguém lê é cerimônia. Postmortem útil tem três partes: linha do tempo factual, análise de causas (sistema, não humano), ações com owner e prazo. E é lido — porque vira backlog priorizado na sprint seguinte.
- 01Resumo executivoUma página. Quem foi afetado, por quanto tempo, qual a causa em uma frase.
- 02Timeline factualUTC e horário local. Sem juízo de valor. Apenas o que aconteceu, quando, por quem.
- 03Análise de causas5 Whys ou causal tree. Foco em sistema, não em "operador errou". Toda causa humana esconde uma falha de processo.
- 04O que funcionou bemDetecção rápida, runbook útil, comunicação clara. Reforça o que vale repetir.
- 05O que faltouHonesto. Sem cobertura. Identifica gaps de telemetria, runbook, alerta, processo.
- 06Ações com owner e prazo3 a 8 ações concretas. Cada uma com responsável e data. Vira issue na sprint, não item em ata.
Princípios não negociáveis.
- ▸Blameless. Pessoa que apertou o botão errado teve contexto incompleto, ferramenta hostil ou processo frágil. Atacar a pessoa preserva o sistema quebrado.
- ▸5 dias úteis. Mais que isso, memória já se foi. Sev1 e Sev2 obrigatório. Sev3 se padrão se repete.
- ▸Escrito por quem viveu. Não por gestor que ouviu falar. Plantonista que comandou o incidente é o autor.
- ▸Ação rastreada. Cada item vira issue com label de postmortem. Burndown trimestral mostra o que foi entregue.
- ▸Compartilhado com o cliente. Em reunião quinzenal, com ações próprias e do cliente claramente separadas. Sem ofuscação.
- ▸Buscável depois. Wiki indexada, com tags por sistema, por causa, por cliente. Próximo incidente parecido começa lendo o postmortem do parecido anterior.
Manutenção que não vira dívida. Hardening que não vira hype.
Sustentação de aplicação não é só apagar incêndio — é evitar o próximo. Banco de horas para evolução, ciclos de hardening, atualização de dependência, refatoração cirúrgica do que dá problema todo mês. Tudo registrado, tudo priorizado com o cliente — sem surpresa em fatura, sem dívida técnica acumulando em silêncio.
- A·01
Banco de horas com transparência
Pacote mensal acordado em contrato (16h, 40h, 80h, 160h). Burndown semanal compartilhado: o que foi consumido, em qual demanda, por quem. Saldo positivo acumula até o fim do trimestre. Não usou? Devolve.
- A·02
Backlog técnico priorizado junto
Reunião quinzenal: ações de postmortem, dependências críticas vencendo, refatoração que reduz MTTR. Cliente decide ordem com critério de impacto e custo — não em isolamento.
- A·03
Patch & upgrade programado
Janela mensal acordada para SO, runtime, dependência crítica. CVE alto sai do ciclo e vira hotfix. Janela vazia? Devolve a janela.
- A·04
Refatoração cirúrgica
O componente que aparece em 4 postmortem em 6 meses entra em ciclo de refatoração. Não rewrite — reescrita parcial com testes, atrás de feature flag, com rollback ensaiado.
- A·05
Dependency hygiene
Renovate ou Dependabot configurado, com política: patch automático, minor com revisão, major em ciclo de hardening. Versão 4 anos atrás não envelhece bem em produção.
- A·06
Documentação viva
Diagrama C4 atualizado a cada mudança arquitetural. ADR para decisão não-trivial. Onboarding de novo membro do nosso time vira teste real da documentação — se não dá pra entrar lendo, a docs precisa de melhoria.
- A·07
Capacity & performance review
Trimestral. Onde está apertando: CPU, banco, fila, dependência externa. Recomendação técnica e de custo. Antecipar saturação custa menos que resolver no plantão.
Wiki do cliente. Não a nossa.
Conhecimento que mora só com o fornecedor é refém. Aqui o runbook nasce no Confluence, Notion, GitHub Wiki — o que o cliente já usa. Atualizado a cada incidente, lido por quem entra no plantão pela primeira vez, e — quando o contrato termina — fica. Sem dependência, sem chantagem disfarçada.
Runbook por alerta
Cada alerta no Grafana/Datadog/PagerDuty linka para a página do runbook correspondente. Diagnóstico em árvore, comandos copiáveis, critério de quando escalar.
Runbook por sistema
Visão geral, dependências, fluxo de deploy, contatos. Onboarding-ready: plantonista novo lê e consegue assumir.
Playbook de incidente
Cenários conhecidos: queda de RDS, fila estourando, latência inter-AZ. Cada um com sintoma, hipótese, ação imediata, verificação.
ADR & decisão arquitetural
Architecture Decision Record para cada escolha não-trivial. Contexto, opções consideradas, decisão, consequências. Daqui a 3 anos alguém precisa entender por que está assim.
Diagrama C4 & mapa de dependências
Contexto, container, componente. Atualizado quando o sistema muda — não no fim do projeto. Mermaid em markdown, versionado em git.
Postmortem indexado
Tag por sistema, por causa, por cliente. Próximo incidente parecido começa lendo o anterior. Conhecimento composto.
- R·01
Mora onde o cliente já está
Confluence, Notion, GitHub Wiki, GitBook, Outline. Não criamos um portal Redgator paralelo — usamos o que o time do cliente já abre.
- R·02
Atualiza a cada incidente
Postmortem com ação "atualizar runbook X" é prática-padrão. Página com data de última revisão visível — se passa de 90 dias sem update, aparece em alerta de hygiene.
- R·03
Lido na rotina, não só na crise
Onboarding de plantonista novo é sessão guiada lendo runbook e simulando incidente passado. Se a docs não funciona em sala calma, não vai funcionar às 3h.
- R·04
Saída sem dependência
Fim de contrato: handover formal, runbook revisado, sessão de Q&A com time do cliente. 30 dias previstos em contrato. Recontrata se for melhor que alternativa.
Próximo incidente é mais barato que o último.
Hardening não é projeto separado — é hábito. A cada postmortem, a cada game day, a cada review trimestral, sai uma lista de gaps. Esses gaps entram no banco de horas com critério: o que reduz MTTR primeiro, o que aumenta SLO segundo, o que economiza FinOps em paralelo. Em 6 meses o sistema está mais resiliente sem ninguém ter feito "projeto de hardening".
- H·01
Game day trimestral
Failover ensaiado em ambiente de staging. AZ derrubada, RDS promovido, dependência externa simulada como indisponível. Hipótese antes do experimento, resultado vira backlog. DR que ninguém testou não existe.
- H·02
Chaos engineering quando faz sentido
LitmusChaos, AWS FIS, Gremlin. Pod kill aleatório em horário comercial só quando o sistema já tolera. Não é vandalismo — é experimento controlado, com hipótese e métrica.
- H·03
Load test contra SLO
k6, Gatling, Locust. Carga simulada antes da Black Friday, da virada de safra, do lançamento. Saber onde quebra antes é mais barato que descobrir no prazo.
- H·04
Revisão de alerta
Trimestral: alerta que dispara muito sem ação é ruído. Alerta que nunca dispara é dead letter. Refinamento contínuo — o pager toca menos, e quando toca, importa.
- H·05
Tabletop exercise
Cenário em sala: "RDS primário cai às 14h de uma terça". Time do cliente + Redgator percorrem a árvore de decisão. Identifica gap antes do incidente real.
- H·06
Threat modeling iterativo
Para sistemas com dado sensível ou regulação. STRIDE light, com atualização semestral. Saída: backlog de hardening de segurança que não compete com feature.
Multa contratual quando a gente erra. Saída em 30 dias.
Contrato de sustentação tradicional protege fornecedor: SLA frouxo, multa simbólica, lock-in de 36 meses. Aqui é diferente. SLA tem dente, multa é apurada no mês, saída tem rito de 30 dias. Se a gente está aqui, é porque está sendo melhor que a alternativa — não porque o contrato segura.
- C·01
SLA por severidade, com multa
Sev1 e Sev2 com penalidade financeira por descumprimento. Apurada por mês, descontada na fatura seguinte. Não é decoração — entra no contrato com cláusula clara.
- C·02
Saída em 30 dias
Aviso de 30 dias, handover formal, runbook revisado, sessão de Q&A. Sem multa de rescisão. Quem fica, fica porque vale.
- C·03
Banco de horas com burndown público
O que foi consumido, em qual demanda, por quem. Saldo visível semanalmente. Não usou? Devolve. Acumula no trimestre, não vira receita não-entregue.
- C·04
Reajuste previsível
IPCA + 3% no aniversário. Sem reajuste fora da época. Sem "ajuste de escopo" disfarçado. Você sabe o orçamento de plantão para os próximos 12 meses, à risca.
- C·05
NPS interno trimestral
Time do cliente avalia o time da Redgator. Notas baixas viram conversa franca, não retaliada. Se a gente está enchendo o saco, queremos saber antes da renovação, não depois.
- C·06
Recontratação opcional, não automática
No mês 11 conversa-se: vale renovar? Que ajuste no escopo, que mudança no banco de horas? Inércia não é estratégia — pra nenhum dos dois.
Plantão não é catraca de tickets.
- NÃO
Help desk de aplicação
Atender usuário final com dúvida funcional não é nosso mandato. Suporte de produto fica com o time do cliente — a gente entra quando o problema é técnico, não comportamental.
- NÃO
NOC com upsell de severidade
Aquele modelo onde o nível 1 sempre acha que é Sev2, o nível 2 transforma em Sev1, e a fatura cresce conforme a fila. Aqui severidade é técnica — não comercial.
- NÃO
Hot fix sem postmortem
Apagar incêndio sem entender a causa garante que o próximo incêndio vem na mesma esquina. Sev1 sem postmortem em 5 dias é falha de processo nosso — apurada em retrospectiva.
- NÃO
Lock-in via conhecimento oculto
Runbook em sistema só nosso, postmortem em formato proprietário, dependência de pessoa específica. Saída em 30 dias é cláusula de contrato — e funciona porque o conhecimento mora no cliente desde o dia 1.
Plantão sem nome, postmortem sem dono, dívida acumulando? Conta o problema.
45 min com um líder de SRE. Sem pitch.