Saúde do Plantão

Um plantão sustentável mantém os especialistas em Rust eficazes: rotações curtas o suficiente para recuperação, alertas que significam ação e runbooks que reduzem a improvisação às 3 da manhã. Engenheiros de plantão esgotados entregam mais incidentes, não menos.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# Checklist de saúde do plantão (trimestral)
 
## Rotação
- [ ] Turno primário <= 7 dias (ou siga o sol)
- [ ] Secundário definido para cada primário
- [ ] Documento de passagem de plantão modelo usado toda segunda-feira
 
## Higiene de alertas
- [ ] < 5 páginas/semana por serviço (mediana)
- [ ] Cada alerta de página tem link para runbook
- [ ] Alertas intermitentes corrigidos ou silenciados com ticket
 
## Bem-estar
- [ ] Páginas após incidente revisadas para redução de trabalho repetitivo
- [ ] Política de compensação aplicada quando > 2 páginas/noite
- [ ] Nenhuma cultura de "herói" para alertas preveníveis

Quando usar:

• Configurando o primeiro plantão de produção para um serviço Rust
• Volume de alertas dobrou após nova implantação
• Esgotamento ou rotatividade de engenheiros na equipe de plataforma
• Revisão de SRE da política de paginação

Exemplo de Trabalho

//! alert_context.rs - anexa URL do runbook a métricas exportadas para anotações do Grafana.
use prometheus::{IntCounterVec, Opts};
 
pub fn panic_counter() -> IntCounterVec {
    IntCounterVec::new(
        Opts::new("rust_panic_total", "Pânicos capturados pelo hook"),
        &["service", "runbook"],
    )
    .expect("descritor de métrica válido")
}
 
pub fn record_panic(service: &str) {
    let counter = panic_counter();
    counter
        .with_label_values(&[service, "https://wiki.example.com/runbooks/panic-storm"])
        .inc();
}

# Relatório semanal de plantão (páginas por serviço)
alertmanager silences --filter 'service=orders-api' --since 7d
# Alvo: investigar qualquer serviço com > 10 páginas/semana

Anote métricas com URLs de runbooks para que os dashboards lembrem os respondedores por onde começar, reduzindo o tempo de mitigação e o estresse.

Mergulho Profundo

Modelos de Rotação

Níveis de Alerta

• Página - SLO do cliente em risco; acorde alguém.
• Ticket - Corrigir em horário comercial; limite sustentado por 30+ min.
• Log - Tendência informativa; apenas dashboard.

Serviços Rust: prefira páginas em taxa de erro, taxa de pânico e falhas de prontidão em vez de CPU bruta, a menos que a CPU se correlacione com a perda do SLO.

Reduzindo Trabalho Repetitivo

• Automatize botões de rollback no runbook (kubectl scriptado).
• Corrija sintéticos instáveis que causam páginas falsas.
• Agrupe atualizações de dependência de baixa urgência para horário comercial.
• Pós-mortem de cada página que exigiu >30 min de trabalho manual sem etapa de runbook.

Armadilhas

• Alerta em cada reinicialização de pod - Ruído durante implantações. Correção: Exclua janelas de rollout ou use taxa de queima de SLO.
• Sem secundário - Férias = ponto cego. Correção: Sempre agende um secundário com política de escalonamento.
• Runbook desatualizado - Pior que nenhum (falsa confiança). Correção: Treinamento trimestral atualiza a data de last_verified.
• Mesma pessoa sempre de plantão - Fator de ônibus e esgotamento. Correção: Rotação inclui juniores com semanas de sombra.
• Ignorando alertas de worker - Plantão da API surpreso com backlog da fila. Correção: Paginação unificada do serviço inclui workers.

Alternativas

FAQs

Relacionados

• Playbooks de Resposta a Incidentes - processo de resposta
• Transformando Incidentes em Barreiras de Proteção - reduzir páginas repetidas
• Métricas DORA - rastreamento de MTTR
• Depuração de Produção - resolução mais rápida
• Delegação e Disseminação de Contexto - fator de ônibus

Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4 e Polars 0.46+.