9.7 Planejamento de capacidade e previsão de demanda

Visão geral e motivação

Todo sistema tem um teto. Os núcleos de computação se esgotam, os discos enchem, os pools de conexões se exaurem e uma fila que estava vazia no café da manhã transborda no almoço. O planejamento de capacidade é a disciplina de ajustar a oferta de computação, armazenamento e rede à demanda que vocês esperam, com folga suficiente para que um dia normal nunca chegue perto do teto e um dia ruim falhe com elegância e não de forma catastrófica. A previsão de demanda é a outra metade: prever quanta carga está chegando, quando e por quê, para que a oferta chegue antes da demanda e não depois da interrupção.

Este capítulo fica entre dois vizinhos e permanece complementar a ambos. O capítulo 3.5 cobre a escalabilidade como propriedade arquitetural: como um sistema é construído para poder crescer, por meio de ausência de estado, fragmentação (sharding) e escala horizontal. O capítulo 9.1 cobre a engenharia de confiabilidade de sites (SRE), que define as metas de confiabilidade que a capacidade precisa defender. Aqui vocês tomam a arquitetura como dada e as metas como fixas e depois respondem a uma pergunta quantitativa: quanto de tudo vocês precisam comprar, reservar e guardar em reserva para que o sistema cumpra seus objetivos de nível de serviço (SLOs, as metas de confiabilidade do capítulo 9.1) na demanda prevista e nos picos que vocês não previram. O autoescalonamento e a engenharia de desempenho (capítulo 2.16) são ferramentas que vocês usam aqui, mas não substituem o planejamento, e confundi-los com o planejamento é um erro comum e caro.

Para grandes equipes, a capacidade deixa de ser uma planilha que um engenheiro mantém e vira um modelo compartilhado de que muitos serviços dependem. Uma plataforma de centenas de serviços compartilha pools finitos: conexões de banco de dados, vazão do broker de mensagens, cotas de contas de nuvem, saída de rede. O crescimento de uma equipe pode esgotar o de outra se ninguém detém o quadro inteiro. Em contextos corporativos, os erros de capacidade aparecem ou como milhões desperdiçados em infraestrutura ociosa ou como interrupções constrangedoras nos exatos momentos que mais importam. No governo, as apostas se afiam ainda mais. Um prazo de impostos, uma janela de inscrição em benefícios ou uma campanha de registro de saúde pública concentram a demanda de um país em poucas horas, a carga é imposta por lei e não opcional, e o público se lembra de um site que cedeu sob um prazo que ele mesmo fixou. O planejamento de capacidade é como vocês cumprem essas promessas.

Princípios fundamentais

Planejem a capacidade para a demanda prevista mais folga deliberada. Não rodem perto da saturação.
Separem o planejamento de capacidade, o autoescalonamento e a engenharia de desempenho. Cada um resolve um problema diferente.
Prevejam a partir da tendência, da sazonalidade, dos eventos conhecidos e do crescimento do negócio, não só da semana passada.
Achem os limites reais por testes de carga e benchmarks, não por chute nem esperando que a produção os ache.
Tratem a latência perto da saturação como um precipício, não uma ladeira. As metas de utilização existem por causa da teoria das filas.
Conheçam os seus gargalos rígidos: pools de conexões, cotas e pontos únicos não autoescalam.
Equilibrem custo contra confiabilidade de propósito e revisem a capacidade numa cadência regular e não depois de um incidente.

Recomendações

Separe o planejamento de capacidade, o autoescalonamento e a engenharia de desempenho

Essas três disciplinas costumam ser confundidas, e confundi-las leva a comprar a correção errada. O planejamento de capacidade é a pergunta de médio a longo prazo de quanto recurso total vocês precisam provisionar, reservar e orçar ao longo de semanas, trimestres e anos. O autoescalonamento é o ajuste automático de curto prazo dos recursos para acompanhar a carga minuto a minuto: ele move vocês dentro do envelope que o planejamento provisionou, mas não consegue conjurar uma cota que vocês nunca reservaram, aquecer um banco de dados frio nem escalar um componente que só roda como instância única. A engenharia de desempenho (capítulo 2.16) muda a forma do problema ao tornar cada unidade de trabalho mais barata, de modo que o mesmo hardware atenda mais demanda.

A distinção é prática. Quando um sistema está lento sob carga, o autoescalonamento acrescenta instâncias, a engenharia de desempenho torna cada instância mais rápida e o planejamento de capacidade decide se vocês podem bancar as instâncias e se o banco de dados a jusante aceita as conexões que elas abrirão. Uma equipe que só recorre ao autoescalonamento baterá num limite rígido que nunca planejou; uma equipe que só recorre à engenharia de desempenho otimizará o código enquanto a cota da conta a limita de qualquer modo. Vocês precisam dos três e precisam saber qual deles um dado problema pede.

Preveja a demanda a partir da tendência, da sazonalidade, dos eventos e do crescimento do negócio

Uma previsão construída sobre a média da semana passada perderá todo momento interessante. Construam a sua a partir de quatro componentes distintos. A tendência é a direção de fundo: a demanda está crescendo, estável ou encolhendo, e com que velocidade? A sazonalidade é o padrão que se repete: o pico diário das 9 da manhã, a calmaria semanal nos fins de semana, a onda anual antes das festas. Os picos guiados por eventos são as concentrações pontuais: um lançamento de produto, uma campanha de marketing, uma menção na televisão, um prazo de declaração governamental. O crescimento guiado pelo negócio é a demanda que o seu próprio roteiro cria: um novo mercado, a integração de um grande cliente, uma funcionalidade que triplica as requisições por sessão.

Usem a técnica certa para cada um. Uma série temporal de carga histórica, decomposta em tendência e sazonalidade, dá uma linha de base defensável para a demanda estável. Os eventos não podem ser extrapolados do histórico porque não têm histórico; vêm de conversar com o negócio, ler o roteiro e perguntar ao marketing e ao produto o que estão para lançar. As falhas de capacidade mais danosas são quase sempre eventos de que a engenharia nunca ouviu falar. A cura é organizacional, não estatística: um canal permanente em que produto, marketing e operações declaram os picos futuros com antecedência suficiente para provisionar.

Defina metas de utilização e respeite o precipício da teoria das filas

O instinto de rodar a infraestrutura “quente”, a 90% de utilização, para economizar dinheiro é uma armadilha, e o motivo é a teoria das filas, coberta em profundidade no capítulo 11.3. À medida que um recurso se aproxima da utilização plena, o tempo de espera não sobe de modo suave e linear: explode. Um servidor a 50% de utilização tem folga confortável; o mesmo servidor a 90% pode ter uma latência várias vezes pior, e a 95% a fila pode fugir do controle por completo. A latência perto da saturação é um precipício, não uma ladeira, e os seus usuários sentem o precipício como tempos limite, novas tentativas e erros muito antes de o recurso estar tecnicamente “cheio”.

É por isso que os planejadores de capacidade definem metas de utilização bem abaixo de 100%, comumente na faixa de 50% a 70% para serviços sensíveis à latência, mais altas para trabalho em lote orientado a vazão que tolera filas. A meta não é desperdício; é o preço da latência previsível. Escolham a meta a partir do SLO: se o seu objetivo de latência é rigoroso, o seu teto de utilização é mais baixo, porque a latência de cauda que as filas produzem é exatamente o que estoura um SLO. Folga e margem de segurança são a mesma ideia vista de duas direções. A folga é a diferença entre a carga normal e a capacidade; a margem de segurança é essa diferença expressa como seguro contra uma previsão que sai alta, um failover que concentra a carga ou um pico que vocês não viram chegar.

Ache os limites reais por testes de carga e benchmarks

Vocês não conseguem planejar em torno de um limite que não mediram. O teste de carga conduz tráfego sintético ou reproduzido contra um sistema para observar como a latência, a vazão e a taxa de erro se comportam conforme a carga sobe e onde quebram. O benchmark mede um componente isolado para estabelecer seu teto: requisições por segundo por instância, escritas por segundo por nó de banco de dados, mensagens por segundo por partição do broker. Juntos, dizem os dois números de que o planejamento precisa: quanto uma unidade de capacidade entrega e onde o sistema inteiro cai.

Rodem vários testes distintos. Um teste de carga sobe até o pico esperado e confirma que o SLO se mantém com folga. Um teste de estresse empurra além do ponto de ruptura para ver como o sistema falha, porque um sistema que se degrada com elegância é muito diferente de um que colapsa. Um teste de resistência (soak) mantém uma carga moderada por horas ou dias para expor vazamentos de memória, esgotamento de conexões e problemas de disco cheio que só aparecem com o tempo. Um teste de pico (spike) despeja a carga de repente para checar se o autoescalonamento e os buffers a absorvem antes que os usuários notem. Testem contra dados e topologia semelhantes aos de produção, porque um limite medido num conjunto de dados de brinquedo mente. Rerrodem esses testes quando o sistema muda, para que os seus números descrevam o sistema que vocês têm e não o que tinham um ano atrás.

Escolha as estratégias de provisionamento deliberadamente

Os provedores de nuvem permitem comprar a mesma capacidade de formas que trocam preço por flexibilidade, e misturá-las bem é onde se economiza dinheiro de verdade. A capacidade sob demanda é flexível e cara: vocês pagam a tarifa cheia pela capacidade de iniciar e parar a qualquer momento, o que serve a cargas imprevisíveis e de curta duração. A capacidade reservada (compromissos de um ou três anos, ou planos de economia) é mais barata por unidade em troca de uma promessa de continuar usando, o que serve à sua linha de base estável. As instâncias spot vendem capacidade sobressalente com grande desconto, mas podem ser recuperadas com pouco aviso, o que serve ao trabalho tolerante a falhas e interrompível, como o processamento em lote e os workers sem estado.

O padrão que funciona é em camadas. Cubram a linha de base estável com capacidade reservada para o menor custo unitário, absorvam a variação diária e semanal com autoescalonamento sob demanda e empurrem o trabalho em lote interrompível para o spot a fim de colher o desconto. Mantenham um pool-tampão aquecido de capacidade pré-provisionada para serviços que não toleram o atraso de partida a frio de escalar a partir de zero, de modo que um pico repentino encontre capacidade pronta e não uma fila enquanto novas instâncias sobem. A mistura certa é uma decisão de portfólio e muda conforme o formato da demanda e os preços do provedor mudam, então revisitem-na.

Mapeie os gargalos rígidos que não autoescalam

O autoescalonamento cria uma confiança perigosa, porque muitos limites ficam a jusante do que escala e não se movem quando ele se move. Os pools de conexões de banco de dados são o exemplo clássico: escalem a camada sem estado de 10 para 100 instâncias e cada uma abre conexões com o mesmo banco de dados, que tem um teto rígido de conexões concorrentes e começará a recusar novas. As contas de nuvem carregam cotas sobre quase tudo: instâncias por região, endereços IP, chamadas de API por segundo, concorrência de funções. Qualquer ponto único da arquitetura, um banco de dados primário, um nó líder, um cache compartilhado, um appliance licenciado, é um teto que a escala horizontal em outro lugar não consegue elevar.

Tornem isso explícito. Mantenham um inventário escrito de todo limite rígido entre uma requisição e sua resposta: tamanhos de pools, valores de cotas, componentes de instância única, limites de taxa de terceiros, números de licenças. Para cada um, registrem o valor atual, o uso atual e a carga em que ele trava. Esse inventário é a diferença entre um plano de capacidade que descreve o sistema inteiro e um que descreve apenas as partes fáceis e elásticas enquanto um pool de conexões espera em silêncio para acabar com o lançamento de vocês. Elevem as cotas antes da necessidade, porque os aumentos de cota do provedor podem levar dias para ser aprovados.

Provisione para os eventos de pico, não apenas para a média

As médias escondem os momentos que importam. Um sistema dimensionado para a carga média falhará no pico, e para muitas organizações o pico é o ponto inteiro: a onda do varejo no maior dia de compras, o pico de streaming numa final ao vivo, o portal de impostos no prazo de declaração, o site de benefícios quando a inscrição abre. Planejem esses eventos nomeados individualmente. Estimem o pico a partir do negócio (usuários concorrentes esperados, requisições por sessão, o múltiplo sobre um dia normal), provisionem para esse pico com folga, façam teste de carga nesse nível e montem a capacidade antes do evento e não numa correria durante ele.

Tratem um lançamento ou um prazo como um evento operacional com um runbook. Pré-aqueçam caches e pools-tampão, elevem as cotas com antecedência, congelem implantações arriscadas durante a janela e ponham de sobreaviso humanos que possam agir se a previsão se revelar baixa. Depois do evento, capturem o pico real e quão perto dos limites vocês chegaram, porque esse número é o melhor insumo para o plano do ano seguinte. Os prazos governamentais merecem cuidado especial: são autoimpostos, publicamente conhecidos e inamovíveis, de modo que não há desculpa para ser pego de surpresa nem como esconder-se quando se é.

Instrumente a capacidade e revise-a numa cadência

O planejamento de capacidade corre sobre dados, e os dados vêm da observabilidade do capítulo 9.2. Acompanhem a utilização de todo recurso restrito (CPU, memória, disco, rede, pools de conexões, profundidade de filas) contra o seu limite, para ver a folga encolhendo antes que desapareça. Vigiem diretamente os sinais de saturação: comprimentos de fila, tempos de espera e taxas de rejeição revelam o precipício das filas se aproximando. Acompanhem a tendência ao longo de semanas para projetar quando um recurso baterá no teto na taxa de crescimento atual e alertem sobre a projeção e não apenas sobre o valor atual, para provisionar antes do muro e não junto a ele.

Façam revisões de capacidade numa cadência regular, mensal ou trimestral, e não apenas depois de um incidente. Em cada revisão, comparem a previsão com a demanda real e corrijam o modelo, percorram o inventário de limites rígidos e confiram a folga de cada um, olhem os eventos próximos e os planos de negócio e decidam o que reservar, elevar ou aposentar. Mantenham um modelo vivo de capacidade: um documento ou planilha simples que mapeia os condutores de demanda para as necessidades de recursos, para que qualquer pessoa possa perguntar “o que acontece com o banco de dados se o tráfego dobrar” e obter uma resposta do modelo em vez de uma interrupção. O modelo nunca é perfeito, mas um modelo escrito e corrigido regularmente vence a intuição sempre.

Compromissos: prós e contras

Abordagem	Prós	Contras
Meta alta de utilização	Menor custo por unidade. Menos capacidade ociosa	A latência explode perto da saturação. Sem espaço para picos ou failover
Folga generosa	Latência previsível. Absorve picos e failover	Custo estável mais alto. Pode esconder ineficiência
Capacidade reservada	Menor preço unitário para a linha de base estável	Risco de compromisso se a demanda cair ou mudar
Capacidade sob demanda	Flexível. Acompanha a carga variável minuto a minuto	Maior preço unitário. Pode surpreender o orçamento
Instâncias spot	Grande desconto para trabalho interrompível	Recuperadas sem aviso. Inadequadas para trabalho com estado ou crítico em latência
Autoescalonamento	Acompanha a carga automaticamente dentro do envelope	Não pode exceder a cota reservada. Partidas a frio. Mascara limites a jusante
Pool-tampão (capacidade aquecida)	Absorve picos repentinos na hora	Paga por capacidade ociosa entre os picos

A tensão central é custo contra confiabilidade, e não há ajuste que otimize ambos. Rodem enxutos e vocês economizam dinheiro até o dia em que um pico encontra um recurso saturado e a latência despenca do precipício das filas. Rodem com folga e vocês dormem bem enquanto pagam por uma folga que fica ociosa na maior parte do tempo. Resolvam a tensão com o SLO e não com medo nem mesquinhez. Provisionem folga suficiente para cumprir a meta de confiabilidade nos picos previstos mais uma margem, e não mais que isso, e deixem o FinOps (operações financeiras para o gasto em nuvem, capítulo 9.4) caçar o desperdício que não defende um SLO. O objetivo é um equilíbrio deliberado: cada dólar de folga comprado de propósito para comprar uma quantidade conhecida de confiabilidade e cada dólar de desperdício removido de propósito porque não compra nenhuma.

Perguntas para discutir com sua equipe

Nós de fato sabemos a carga em que cada um dos nossos gargalos rígidos trava, ou estamos presumindo que o autoescalonamento nos salvará? A maioria das equipes sabe dizer que suas instâncias autoescalam, e a maioria não sabe dizer o limite de conexões concorrentes do seu banco de dados primário, o limite de taxa de API do seu terceiro mais importante ou a cota da conta que limita a concorrência das suas funções. São esses os limites que acabam com os lançamentos, e eles não se movem quando a camada sem estado escala. Levem o inventário escrito de limites rígidos, se tiverem um, e se não tiverem, essa ausência é o achado. Para cada limite, vocês querem três números: o teto, o uso de hoje e o nível de demanda em que os dois se encontram. Em qualquer lugar em que vocês não consigam produzir os três, há um gargalo que vocês gerenciam por esperança.
Quando fizemos pela última vez um teste de carga no nível do nosso pior pico futuro, com dados semelhantes aos de produção, e o SLO se manteve com folga? Um plano de capacidade é um conjunto de alegações sobre como o sistema se comporta sob carga, e uma alegação não testada é um chute de terno e gravata. O pico que importa não é a média do mês passado e sim o próximo lançamento, feriado ou prazo, e o teste só significa algo se os dados e a topologia se parecerem com a produção, porque um limite medido num conjunto de brinquedo mente. Levem os resultados dos seus testes de estresse e de resistência mais recentes, incluindo onde o sistema quebrou e como falhou quando quebrou. Se a resposta honesta é que vocês nunca conduziram o sistema ao ponto de ruptura de propósito, vocês descobrirão esse ponto em produção, no pior momento possível, com os usuários olhando.
Como produto, marketing e operações avisam a engenharia sobre um pico antes de ele acontecer, e com quanta antecedência? As falhas de capacidade mais caras não são erros de modelagem; são eventos de que a engenharia nunca ouviu falar até o tráfego chegar. Uma previsão consegue extrapolar tendência e sazonalidade do histórico, mas um evento não tem histórico, então só pode vir das pessoas que o planejam. Levem os três últimos picos de demanda e perguntem, para cada um, quantos dias de aviso a engenharia recebeu e se foi o bastante para reservar capacidade e fazer teste de carga. A evidência que vocês querem é um canal permanente com um prazo de antecedência longo o bastante para provisionar contra ele, porque só os aumentos de cota na nuvem já podem levar dias. Se o canal não existe, o seu plano de capacidade é cego justamente para os momentos que ele existe para proteger.
A que meta de utilização cada serviço sensível à latência de fato roda, e conseguimos rastrear esse número até o seu SLO e não até uma meta de custo? Isso importa porque a pressão para rodar a infraestrutura quente é constante e vem da parte da organização que vê a conta mas não o precipício das filas, então, a menos que a meta esteja escrita e justificada a partir do objetivo de latência, ela deriva para cima até um pico encontrar a borda. As considerações concorrentes são dinheiro real de um lado e latência de cauda do outro, e a posição honesta é que a folga abaixo de 100% é o preço da latência previsível, não desperdício a ser aparado. Levem a utilização atual dos seus principais serviços, o SLO que cada um defende e a latência que vocês mediram nessa utilização sob carga, para que a discussão argumente a partir de evidências e não de instinto. Numa plataforma corporativa ou governamental em que um pool compartilhado sustenta muitos serviços, combinem a meta centralmente e registrem quem pode mudá-la, porque uma única equipe elevando em silêncio o seu teto pode empurrar um recurso de que outras dependem por cima do precipício para todos.
Qual é a nossa mistura de capacidade reservada, sob demanda e spot, quando a revisitamos pela última vez, e ela ainda combina com o formato da nossa demanda? A mistura é onde se escondem tanto a maior economia sustentada quanto o maior desperdício sustentado, porque uma linha de base estável paga a tarifas sob demanda queima dinheiro a cada hora, enquanto uma posição reservada comprometida em excesso paga por capacidade que a demanda já superou ou ficou abaixo. A tensão é custo contra flexibilidade e risco de compromisso: a capacidade reservada é a mais barata por unidade mas prende vocês, o spot é ainda mais barato mas pode ser recuperado sem aviso e o sob demanda compra liberdade a um prêmio. Levem a divisão atual por custo, a curva de demanda que ela deve cobrir e a taxa de recuperação e o raio de impacto de quaisquer cargas spot, para que a sala veja se o trabalho interrompível de fato é interrompível. Em contextos corporativos e governamentais, liguem os compromissos reservados ao ciclo de contratação e de orçamento, porque compromissos de vários anos e planos de economia são obrigações financeiras que as finanças e a auditoria vão querer ver justificadas contra a demanda prevista e não contra a conveniência do último trimestre.
Quando um evento de pico nomeado está chegando, quem é dono do pré-aquecimento, dos aumentos de cota, dos congelamentos de implantação e da decisão de seguir ou não, e isso está escrito como um runbook que ensaiamos? Os eventos de pico são os momentos que o planejamento de capacidade existe para proteger, e falham com mais frequência não porque o plano estava errado, mas porque ninguém era responsável por executá-lo sob pressão no dia. As considerações que competem aqui são velocidade e autonomia contra coordenação: as equipes querem continuar entregando, mas uma implantação arriscada durante a janela do pico pode desfazer meses de provisionamento, então alguém precisa deter a autoridade de congelar e de parar o lançamento. Levem o runbook do seu próximo grande evento, os prazos de aumento de cota e de aquecimento do pool-tampão e o registro de quem ocupou cada papel da última vez e se as passagens de bastão se sustentaram. Para um prazo governamental autoimposto, publicamente conhecido e inamovível, nomeiem explicitamente o dono responsável e o caminho de escalonamento, porque não há a opção de descartar carga nem de pedir aos cidadãos que voltem depois, e um pico de que ninguém é dono é um pico que ninguém defenderá quando chegar.

Perspectiva por setor

Startup. O seu recurso mais escasso é a atenção da engenharia, então mantenham o planejamento de capacidade barato e apoiem-se na elasticidade do provedor de nuvem para a variação diária. A única coisa que vocês não podem pular é uma lista escrita dos limites rígidos que não autoescalam: o teto de conexões do seu banco de dados primário, o limite de taxa do seu terceiro mais importante e as cotas da conta que vocês bateriam sob um pico repentino de funcionalidade ou de imprensa. Façam teste de carga em vários múltiplos do seu pico normal com dados do tamanho da produção antes do primeiro pico real, porque a frágil confiança que o autoescalonamento dá é exatamente o que quebra quando um banco de dados recusa conexões.

Pequena empresa. Vocês não têm especialista em capacidade e têm orçamento apertado, então tratem isto como um problema de comprar e configurar e não como um projeto de modelagem. Favoreçam serviços gerenciados que absorvem a escala por vocês, definam alertas de gasto e painéis simples de utilização para que uma conta descontrolada ou um recurso saturando fique visível cedo e conheçam os poucos eventos nomeados (uma corrida sazonal, um grande cliente entrando no ar) que definirão o seu ano. Reservem capacidade para a linha de base estável para cortar a conta e resistam a construir maquinaria de previsão que vocês não conseguem manter quando o formato da demanda mal se move.

Grande empresa. O problema é um conjunto compartilhado e finito de pools atrás de centenas de serviços, então a capacidade vira governança de portfólio: um inventário mantido de limites rígidos, metas de utilização derivadas centralmente dos SLOs e uma mistura deliberada de capacidade reservada, sob demanda e spot, revisitada contra os preços ao vivo. Padronizem os testes de carga, estresse, resistência e pico para que toda equipe meça do mesmo jeito em dados semelhantes aos de produção e rodem revisões de capacidade numa cadência que pegue uma folga encolhendo antes de um incidente. Orcem explicitamente a coordenação, porque o crescimento de uma equipe pode esgotar o de outra quando ninguém detém o modelo inteiro.

Governo. A demanda costuma estar concentrada por lei num prazo inamovível e publicamente conhecido, então planejem especificamente esse pico nomeado e provisionem uma ampla margem de segurança, já que vocês não podem descartar carga nem pedir aos cidadãos que voltem depois. As regras de contratação moldam o provisionamento: compromissos reservados de vários anos e acordos de cota com fornecedores precisam ser justificados contra a demanda prevista e sobreviver à auditoria, então mantenham documentados e defensáveis a previsão, a evidência dos testes de carga e o inventário de limites rígidos. Publiquem expectativas realistas onde puderem, elevem os limites do provedor bem antes da janela e registrem o pico verdadeiro a cada ciclo, porque a prestação de contas públicas significa que um portal que cede sob um prazo que ele mesmo fixou é uma falha que o país inteiro vê.

Exemplos

Startup. Uma startup de dez pessoas roda um aplicativo de consumo sobre infraestrutura de nuvem com autoescalonamento e se sente segura porque a contagem de instâncias cresce com a carga. Seu primeiro destaque na televisão triplica o tráfego em uma hora, a camada sem estado escala lindamente e o aplicativo cai de qualquer modo: cada nova instância abriu conexões de banco de dados até o banco bater o teto de conexões e começar a recusá-las. A lição remodela a prática deles. Acrescentam um agrupador de conexões na frente do banco de dados, escrevem todo limite rígido entre uma requisição e uma resposta e fazem teste de carga em vários múltiplos do pico normal num conjunto de dados do tamanho da produção. Cobrem a linha de base estável com um compromisso de capacidade reservada pelo desconto e mantêm um pequeno pool-tampão aquecido para que o próximo pico encontre capacidade pronta. As mudanças custam uma semana e convertem uma confiança frágil num plano que eles podem defender.

Grande empresa. Uma varejista global trata seu maior dia de vendas como o evento de capacidade do ano. Meses antes, uma equipe multifuncional constrói uma previsão de demanda a partir da tendência e da sazonalidade dos anos anteriores mais o plano de merchandising, traduz a previsão em necessidades de recursos por meio de um modelo de capacidade e provisiona para o pico projetado com ampla folga. Ela testa em carga, estresse, resistência e pico todo o caminho em dados semelhantes aos de produção, eleva todas as cotas de nuvem relevantes com semanas de antecedência, pré-aquece caches e pools-tampão e congela implantações arriscadas na janela ao redor. A capacidade reservada cobre a linha de base estável pelo custo, o autoescalonamento sob demanda absorve a curva diária e o trabalho em lote interrompível roda no spot. A observabilidade acompanha cada recurso restrito contra seu limite em tempo real durante o evento, com alertas sobre a saturação projetada e não sobre o valor atual. O dia passa sem drama, que é exatamente o resultado que o planejamento comprou.

Governo. Uma autoridade tributária nacional roda um portal de declaração cuja demanda está concentrada por lei nos dias antes de um prazo inamovível, quando um país inteiro declara de uma vez. A autoridade planeja especificamente para esse pico e não para uma média anual que seria sem sentido. Estima os declarantes concorrentes a partir dos anos anteriores e de dados populacionais, provisiona para esse pico com ampla margem de segurança porque não há a opção de descartar carga nem de pedir aos cidadãos que voltem depois e faz teste de carga na concorrência projetada com dados realistas. A equipe mantém um inventário escrito de toda cota e ponto único de falha, eleva os limites com os provedores bem antes da janela e define metas de utilização baixas o bastante para que o precipício das filas fique longe do pico do prazo. Depois de cada temporada de declarações, registra o pico verdadeiro e quanta folga restou, alimentando o modelo do ano seguinte. O público vê um portal que fica no ar no dia para o qual foi projetado, que é todo o ponto da promessa da instituição.

Justificativa de negócio: motivações, ROI e TCO

O retorno do planejamento de capacidade aparece como dois custos evitados que puxam em direções opostas, o que é o que torna a disciplina valiosa. O subprovisionamento custa interrupções, e as interrupções durante eventos de pico custam mais: receita perdida, transações perdidas e dano à reputação justamente quando o público é maior. Um site de varejo fora do ar no seu maior dia ou um portal governamental colapsando no prazo de declaração paga anos de planejamento numa única hora ruim. O superprovisionamento custa no sentido contrário, em contas de nuvem por capacidade que fica ociosa, e em escala corporativa alguns pontos de superprovisionamento crônico numa frota chegam a milhões de dólares por ano. O planejamento de capacidade é a prática que acha o meio deliberado: o suficiente para defender o SLO nos picos, e não mais que isso.

O custo de adoção é sobretudo disciplina e não ferramentas. Vocês constroem uma previsão de demanda, escrevem os limites rígidos, rodam testes de carga numa cadência, misturam as estratégias de provisionamento e fazem revisões regulares de capacidade. O custo total de propriedade (TCO) melhora dos dois lados ao mesmo tempo: menos incidentes causados por capacidade baixam o custo da indisponibilidade e da resposta de emergência, e o dimensionamento correto contínuo mais uma mistura sensata de reservado e spot baixam a conta estável de infraestrutura. Para defender o caso junto à liderança, liguem a capacidade aos números que ela já acompanha. Liguem o subprovisionamento à receita perdida por hora de indisponibilidade no pico e às violações de SLO com penalidades contratuais e liguem o superprovisionamento ao relatório de desperdício de FinOps do capítulo 9.4. O argumento não é prudência abstrata; é dinheiro nos dois lados de um mostrador que vocês podem ajustar de propósito.

Antipadrões e armadilhas

Autoescalonamento como plano: confiar em instâncias elásticas enquanto um pool de conexões de banco de dados, uma cota de conta ou um ponto único limita em silêncio o sistema inteiro.
Rodar quente para economizar dinheiro: mirar utilização de 90% ou mais e encontrar o precipício das filas, onde a latência explode e o SLO quebra.
Médias em vez de picos: dimensionar para a carga média, de modo que o sistema falha exatamente no evento de pico que justificou construí-lo.
Prever só pelo histórico: extrapolar tendência e sazonalidade e perder o lançamento ou a campanha de que a engenharia nunca foi informada.
Limites não testados: planejar em torno de um ponto de ruptura que ninguém mediu e depois descobri-lo em produção no pior momento.
Testes de carga com dados de brinquedo: medir a capacidade em dados e topologia irrealistas, produzindo números que mentem sobre o sistema real.
Sem inventário de limites rígidos: gerenciar cotas, pools e pontos únicos de memória e por esperança em vez de uma lista escrita e mantida.
Reservar tudo ou não reservar nada: comprometer-se demais com capacidade reservada que a demanda supera ou fica abaixo, ou pagar tarifas cheias sob demanda por uma linha de base estável.
Revisão de capacidade só depois de incidentes: tratar o planejamento como combate reativo a incêndios em vez de uma cadência regular que provisiona antes da necessidade.

Modelo de maturidade

Nível 1, Iniciar: A capacidade é reativa e ad hoc. As equipes acrescentam recursos depois de eles acabarem, confiam no autoescalonamento para tratar tudo e não têm previsão, nem inventário de limites rígidos, nem testes de carga. Os eventos de pico são enfrentados com esperança, e as interrupções durante lançamentos e prazos são tratadas como má sorte.
Nível 2, Desenvolver: Aparecem práticas básicas, mas variam por equipe. Algum monitoramento mostra a utilização, algum teste de carga acontece antes de grandes eventos, as principais cotas são conhecidas e existe uma previsão aproximada em alguns lugares, mas o modelo não é mantido, os gargalos a jusante muitas vezes passam despercebidos e a folga é definida por regra de bolso e não a partir do SLO.
Nível 3, Padronizar: O planejamento de capacidade é uma disciplina documentada e imposta em toda a organização. Uma previsão de demanda combina tendência, sazonalidade, eventos e crescimento do negócio; um inventário escrito de limites rígidos é mantido; as metas de utilização derivam dos SLOs; testes de carga, estresse, resistência e pico rodam numa cadência contra dados semelhantes aos de produção; e o provisionamento mistura deliberadamente reservado, sob demanda e spot. Um canal permanente leva os avisos de eventos de produto e marketing para a engenharia.
Nível 4, Gerenciar: A capacidade é medida e controlada em relação a linhas de base. A previsão é comparada com a demanda real a cada ciclo e o erro é acompanhado e reduzido; a utilização, os sinais de saturação e a folga contra todo limite rígido são acompanhados em tendência e alertados como projeções e não como valores atuais; os eventos de pico são revisados depois contra o pico real observado; e a mistura de provisionamento, a cobertura de compromisso reservado e o custo por SLO são relatados como métricas que condicionam as decisões de ir ou não ir. Dados, e não intuição, decidem o que reservar, elevar ou aposentar.
Nível 5, Orquestrar: O planejamento de capacidade é continuamente melhorado e integrado em toda a organização. As previsões são validadas e refinadas automaticamente, a saturação é projetada e provisionada antes de chegar, as misturas de provisionamento são otimizadas contra os preços ao vivo, os eventos de pico rodam a partir de runbooks ensaiados e custo e confiabilidade são equilibrados deliberadamente contra o SLO em toda a plataforma. O modelo de capacidade é um ativo compartilhado e adaptativo que reequilibra a frota conforme o formato da demanda e os preços do provedor mudam.

Ideias para discussão

Qual é a sua meta atual de utilização para serviços sensíveis à latência, e vocês conseguem justificá-la pelo SLO e pelo comportamento das filas e não por um desejo de economizar dinheiro?
Quais dos seus componentes não conseguem autoescalar de modo algum, e o que acontece com o resto do sistema quando um deles satura?
Se o seu tráfego dobrasse no próximo trimestre, qual recurso bateria primeiro no teto, e de quantos dias de antecedência vocês precisariam para elevá-lo?
Como vocês decidem a mistura de capacidade reservada, sob demanda e spot, e quando a revisitaram pela última vez contra o formato real da sua demanda?
Quando um evento de pico está chegando, quem é dono do pré-aquecimento, dos aumentos de cota e da decisão de seguir ou não, e isso está escrito como um runbook?
Os seus alertas de capacidade disparam sobre a saturação projetada com semanas de antecedência, ou só sobre a utilização atual quando o muro já está perto?

Principais conclusões

O planejamento de capacidade ajusta a oferta à demanda prevista com folga deliberada. É distinto do autoescalonamento (curto prazo, dentro do envelope) e da engenharia de desempenho (unidades de trabalho mais baratas).
Prevejam a partir da tendência, da sazonalidade, dos eventos conhecidos e do crescimento do negócio e obtenham avisos de eventos do produto e do marketing, porque os eventos não têm histórico a extrapolar.
Respeitem o precipício da teoria das filas (capítulo 11.3): a latência explode perto da saturação, então definam as metas de utilização a partir do SLO e mantenham folga real.
Achem os limites por testes de carga, estresse, resistência e pico em dados semelhantes aos de produção e mantenham um inventário escrito dos gargalos rígidos que não autoescalam.
Misturem capacidade reservada, sob demanda e spot com pools-tampão aquecidos, planejem individualmente os eventos de pico nomeados e revisem a capacidade numa cadência e não depois de interrupções.

Referências e leitura complementar

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management