Todo contrato de TI tem SLA. Poucos SLAs sao escritos para funcionar - a maioria protege o fornecedor enquanto parece proteger o cliente.
O problema comeca na definicao de disponibilidade
99,9% de uptime significa 8,7 horas de indisponibilidade por ano. Se esse downtime acontecer nas 3 horas criticas de fechamento contabil, o SLA foi cumprido - e sua operacao parou.
A armadilha: fornecedores medem uptime em janela 24x7. Seu sistema critico precisa de 99,9% das 8h as 20h em dias uteis - isso e diferente.
Os 5 elementos que todo SLA precisa ter
1. Definicao de disponibilidade com janela correta
Janela de medicao: dias uteis, das 7h as 21h (horario de Brasilia).
Exclusoes: manutencoes programadas com 72h de aviso previo.
2. Categorias de incidente com RTO definido
| Severidade | Definicao | Resposta | RTO |
|---|---|---|---|
| P1 Critico | Sistema indisponivel | 15 min | 4h |
| P2 Alto | Funcionalidade principal degradada | 1h | 8h |
| P3 Medio | Funcionalidade secundaria afetada | 4h | 2 dias uteis |
3. Como medir - nao apenas o que medir
"Disponibilidade medida pelo fornecedor" e conflito de interesse. Exija ferramenta externa (UptimeRobot, Pingdom, Datadog) com acesso de leitura para o cliente.
4. Penalidades com dentes
- Credito de servico proporcional ao impacto (nao ao custo mensal)
- Direito de rescisao sem multa se SLA descumprido por 3 meses consecutivos
5. A clausula mais negligenciada: RPO
Para sistemas financeiros, RPO > 1h e risco regulatorio (SOX, BACEN). Exija RPO explicito no contrato.
Anderson Chipak - Auditor de Sistemas Criticos | ALC Consultoria | alc.srv.br
