Modelos de Runbook de Incidentes

Modelos adaptáveis para runbooks de resposta a incidentes cobrindo detecção, triagem, mitigação, resolução e comunicação.

Não use esta habilidade quando

• A tarefa não estiver relacionada a modelos de runbook de incidentes
• Você precisar de um domínio ou ferramenta diferente fora deste escopo

Instruções

• Clarifique metas, restrições e entradas necessárias.
• Aplique melhores práticas relevantes e valide resultados.
• Forneça passos acionáveis e verificação.

Use esta habilidade quando

• Criando procedimentos de resposta a incidentes
• Construindo runbooks específicos de serviço
• Estabelecendo caminhos de escalonamento
• Documentando procedimentos de recuperação
• Respondendo a incidentes ativos
• Integrando engenheiros de plantão

Conceitos Principais

1. Níveis de Severidade de Incidentes

2. Estrutura do Runbook

1. Overview & Impact
2. Detection & Alerts
3. Initial Triage
4. Mitigation Steps
5. Root Cause Investigation
6. Resolution Procedures
7. Verification & Rollback
8. Communication Templates
9. Escalation Matrix

Pré-requisitos do Runbook

Vincule o serviço, namespace, contexto do cluster, banco de dados, proprietários, autoridade de incidente aprovada, fontes de evidência e revisão de rollback antes de adaptar esses modelos. Limiares, valores financeiros, porcentagens de impacto e mensagens de resolução são ilustrativos, nunca fatos de incidentes observados. A triagem somente leitura vem primeiro; mutações requerem uma resposta específica de serviço aprovada. Verifique os scripts de smoke/rollback reais no projeto de destino antes de usá-los. Nenhum script é incluído ou implícito por este modelo.

Modelos de Runbook

Modelo 1: Runbook de Interrupção de Serviço

# [Service Name] Outage Runbook

## Overview
**Service**: Payment Processing Service
**Owner**: Platform Team
**Slack**: #payments-incidents
**PagerDuty**: payments-oncall

## Impact Assessment
- [ ] Which customers are affected?
- [ ] What percentage of traffic is impacted?
- [ ] Are there financial implications?
- [ ] What's the blast radius?

## Detection
### Alerts
- `payment_error_rate > 5%` (PagerDuty)
- `payment_latency_p99 > 2s` (Slack)
- `payment_success_rate < 95%` (PagerDuty)

### Dashboards
- [Payment Service Dashboard](https://grafana/d/payments)
- [Error Tracking](https://sentry.io/payments)
- [Dependency Status](https://status.stripe.com)

## Initial Triage (First 5 Minutes)

### 1. Assess Scope
```bash
# Verificar saúde do serviço
kubectl get pods -n payments -l app=payment-service

# Verificar implantações recentes
kubectl rollout history deployment/payment-service -n payments

# Verificar taxas de erro
curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))"
```

### 2. Quick Health Checks
- [ ] Can you reach the service? `curl -I https://api.company.com/payments/health`
- [ ] Database connectivity? Check connection pool metrics
- [ ] External dependencies? Check Stripe, bank API status
- [ ] Recent changes? Check deploy history

### 3. Initial Classification
| Symptom | Likely Cause | Go To Section |
|---------|--------------|---------------|
| All requests failing | Service down | Section 4.1 |
| High latency | Database/dependency | Section 4.2 |
| Partial failures | Code bug | Section 4.3 |
| Spike in errors | Traffic surge | Section 4.4 |

## Mitigation Procedures

### 4.1 Service Completely Down
```bash
# Passo 1: Verificar status dos pods
kubectl get pods -n payments

# Passo 2: Se os pods estiverem em loop de crash, verificar logs
kubectl logs -n payments -l app=payment-service --tail=100

# Passo 3: Verificar implantações recentes
kubectl rollout history deployment/payment-service -n payments

# Passo 4: ROLLBACK se a implantação recente for suspeita
kubectl rollout undo deployment/payment-service -n payments

# Passo 5: Escalar se houver restrição de recursos
kubectl scale deployment/payment-service -n payments --replicas=10

# Passo 6: Verificar recuperação
kubectl rollout status deployment/payment-service -n payments
```

### 4.2 High Latency
```bash
# Passo 1: Verificar conexões com o banco de dados
kubectl exec -n payments deploy/payment-service -- \
  curl localhost:8080/metrics | grep db_pool

# Passo 2: Verificar consultas lentas (se for problema de DB)
psql -h $DB_HOST -U $DB_USER -c "

…