Como este tema funciona na sua empresa
Crescimento é previsível (20-30% ao ano). Planejamento simples: monitorar 2-3 métricas (CPU, RAM, armazenamento), revisar anualmente, budget anual para upgrade.
Crescimento menos linear (novos clientes, campanhas sazonais). Capacity planning trimestral + contingência para picos. Previsão simples (média histórica + margem).
Múltiplos times, dados complexos. Capacity planning mensal por aplicação. Previsão automatizada (machine learning) pode valer a pena. Integração com CapEx planning.
Capacity planning é processo de coletar dados de uso histórico, identificar tendências, prever crescimento futuro, e dimensionar infraestrutura para suportar demanda sem ficar oversize. O objetivo é equilíbrio: ter headroom suficiente (30-50% de margem), mas não ficar ociosa[1].
Coleta de dados: qual métrica monitorar
Monitorar CPU/RAM/disco é óbvio. Menos óbvio é IOPS (operações de disco) e bandwidth. Para aplicação de banco de dados, IOPS é o gargalo real, não CPU. Para CDN ou streaming, bandwidth é limitante, não armazenamento.
Ferramentas de monitoramento (Prometheus, Datadog, New Relic) coletam métricas contínuas. Objetivo: capturar padrões (picos em horários comerciais, sazonalidade mensal/anual, outliers).
Correlação com negócio é essencial: 95% de CPU quando? horário de maior uso? após marketing campaign? nova feature? Sem contexto, metrica pura é inútil.
Monitorar CPU, RAM, disco anualmente em planilha. Alertas simples (CPU > 80%). Revisão em planning anual.
Prometheus/Grafana para coleta contínua. Análise trimestral de trends. Alertas automáticos (CPU > 70%). Previsão simples (extrapolação linear).
Datadog/New Relic para observabilidade avançada. Análise mensal por aplicação. ML para previsão (Turbonomic, Fashwell). Integração com CapEx planning automatizado.
Previsão: de manual a machine learning
Método simples: média histórica + margem. Exemplo: CPU média foi 40% nos últimos 12 meses, crescimento esperado 20%, previsão é 48%, provisiono para 60% (margem de 12%).
Método mais sofisticado: regressão linear (encontra trend line), séries temporais (ARIMA — captura sazonalidade). Ferramentas online (Google Sheets, Excel) oferecem extrapolação. Ferramentas avançadas usam ML para capturar padrões complexos.
Armadilha comum: pico único (Black Friday, campanha) é confundido com trend. Diferençar: pico transiente vs. crescimento sustentado.
Headroom: quanto deixar de margem
Recomendação padrão: 30-50% de capacidade livre. Exemplo: servidor com 8 vCPU, manter CPU < 60% (headroom 40%). Isto parece caro, mas é economicamente saudável: evita degradação de performance, permite testes, reduz risco de downtime.
Trade-off: cloud permite burst — escalar em 5 minutos se pico inesperado. On-premise exige capacidade pré-provisionada. On-premise com 20% headroom vs cloud com burst — cloud ganha em flexibilidade.
SLA vs. capacity: dimensionar para latência, não apenas disponibilidade
Muitos confundem: "sistema não caiu" com "sistema atendeu em tempo aceitável". Capacity planning deve dimensionar para SLA de latência (tempo de resposta), não apenas uptime.
Exemplo: SLA é "responder em < 1 segundo em 99% das requisições". Com infraestrutura atual, percentil 99 é 500ms. Crescimento de 50% de volume dobraria latência (1000ms). Dimensionamento exigido para manter SLA.
Sinais de que capacity planning é urgente
- Infraestrutura está consistentemente acima de 80% de capacidade
- Picos causam lentidão ou timeout — não há headroom
- Processo de expansão leva 4+ semanas (compra, entrega, instalação)
- Métrica de crescimento não é monitorada — improvisação total
- SLA é violado regularmente sem motivo claro (não é outage, é performance)
- Scaling automático não existe (on-premise sem alternativa)
- Orçamento para infraestrutura é surpresa anual (não há planejamento)
Caminhos para implementar capacity planning
Viável se infraestrutura é não-complexa.
- Perfil necessário: Engineer com experiência em monitoramento, análise básica de dados
- Tempo estimado: 1-2 meses para setup + análise primária
- Faz sentido quando: Infraestrutura é simples, dados são centralizados, expertise existe
- Risco principal: Métrica errada, previsão otimista/pessimista, falta de ação baseada em dados
Indicado para infraestrutura complexa ou necessidade de ML.
- Tipo de fornecedor: Consultoria de infraestrutura, fornecedor de ferramentas (Turbonomic, Fashwell), MSP
- Vantagem: Análise robusta, setup de ferramenta, treinamento, ação recomendada
- Faz sentido quando: Múltiplos aplicações, crescimento exponencial, CapEx planning é crítico
- Resultado típico: Em 2-3 meses, ferramenta ativa, dados analisados, previsão confiável, recomendações implementadas
Precisa estruturar capacity planning?
O oHub conecta você gratuitamente a consultores de infraestrutura especializados em previsão e planejamento de capacidade. Em menos de 3 minutos, descreva sua necessidade e receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Como prever crescimento de infraestrutura?
Colete dados históricos (CPU, RAM, disco), identifique padrão (linear, exponencial, sazonal), extrapolue. Simples: última métrica + (taxa de crescimento × meses futuros). Avançado: ML que captura sazonalidade e outliers. Sempre valide com contexto de negócio (é crescimento real ou pico?).
Qual é a métrica certa para monitorar: CPU, RAM ou disco?
Depende da aplicação. Aplicação web: CPU e RAM. Banco de dados: IOPS (operações disco). Arquivo servidor: disco e bandwidth. Monitorar todas, mas focar no gargalo real. Muitas vezes gargalo não é o óbvio — teste de carga valida.
Como evitar picos repentinos (Black Friday)?
Previsão deveria mapear sazonalidade. Se Black Friday causa pico 5x, provisionar headroom para isto (ou usar cloud com scaling automático). Teste de carga prévia simula pico — valida que infraestrutura aguenta. Alternativa: modo degradado aceito (site fica lento mas não cai).
Qual é a margem de crescimento saudável para servidores?
Headroom de 30-50% é recomendado. 30% se crescimento é previsível; 50% se há incerteza. < 20% é risco (pouco tempo para escalar antes de problema). > 60% é desperdício (infraestrutura ociosa). Trade-off entre segurança e custo.
Como fazer capacity planning em cloud vs. on-premise?
Cloud permite burst — escala em minutos, paga-se pelo uso. Planejamento é mais flexível (não precisa provisionar 6 meses antes). On-premise exige planejamento rígido (compra, entrega, instalação em 4-8 semanas). Cloud é preferível se crescimento é incerto; on-premise se crescimento é previsível e volume é alto.
Quanto tempo leva para escalar infraestrutura?
Cloud: 5-30 minutos (automático via API). On-premise: 4-8 semanas (compra, entrega, instalação). Lead time é diferença crítica. Para infraestrutura que cresce rápido (startup, seasonal), cloud é obrigatório. Para estável, on-premise é viável com planejamento bom.
Fontes e referências
- Google Cloud. Capacity Planning Best Practices — Arquitetura e escalabilidade. Google Cloud Documentation.
- AWS. Well-Architected Framework — Reliability Pillar com capacity management. AWS Documentation.
- ISO/IEC. ISO/IEC 20000-1:2018 — Capacity management como parte de service delivery. International Organization for Standardization.