Come pianificare la capacità nel calendario di prodotto

Il pager sembra arrivare all’improvviso, ma spesso il problema era già leggibile altrove: nella data di una campagna, nel lancio di una funzione, nel rinnovo di un contratto o in una previsione di utilizzo rimasta confinata in una presentazione. La capacità non diventa urgente quando cresce il traffico; lo diventa quando manca una decisione tecnica esplicita.

Per chi guida un sistema in crescita, pianificare non significa fingere di conoscere il futuro. Significa prendere sul serio ciò che è già noto, dichiarare l’incertezza e associare entrambe le cose a una data. Un’incertezza scritta è gestibile; una promessa implicita diventa un incidente.

La previsione commerciale come forma della domanda #

Una previsione di ricavi o di adozione non è ancora un piano di capacità. Dice che potrebbe accadere qualcosa, ma non dice quando arriveranno le richieste, come si distribuiranno durante la giornata, quali endpoint toccheranno o quali componenti sosterranno la parte meno elastica del flusso.

La prima traduzione utile non è da «utenti» a «server». È da evento di business a forma della domanda: una finestra di iscrizione concentra scritture, una scadenza fiscale concentra letture e riconciliazioni, un’integrazione può aggiungere chiamate lente o retry. Conta meno il volume totale del tratto in cui la domanda supera il comportamento normale del sistema.

Questa distinzione evita un errore frequente: trattare allo stesso modo una crescita stabile e un picco concentrato. Crescita stabile e picco datato chiedono decisioni diverse: la prima lascia spazio per modificare architettura, contratti e processi; il secondo richiede margine disponibile, limiti espliciti e una decisione anticipata su cosa degradare se la previsione è sbagliata.

Forma della domanda	Segnale iniziale	Vincolo da verificare	Decisione utile	Rischio se rimandi
Crescita stabile	Aumento graduale di utilizzo e dati	Throughput sostenuto, dimensione degli indici, code di lavoro	Pianificare interventi strutturali e osservare la tendenza	Il degrado lento viene scambiato per rumore operativo
Picco legato a un evento	Data, campagna, rinnovo o apertura delle vendite	Concorrenza, limiti esterni, code, connessioni e percorsi critici	Riservare margine e definire modalità degradate	La scelta viene presa durante l’incidente, senza reversibilità
Cambio di modello o di utilizzo	Nuova funzione, integrazione o comportamento inatteso	Nuovi hot path, cardinalità, retry e dipendenze condivise	Formulare ipotesi e fissare una revisione ravvicinata	Un’assunzione nascosta viene trattata come capacità garantita

La tabella non sostituisce l’osservabilità, ma impedisce che l’osservabilità diventi l’unica fonte di pianificazione. Un dashboard descrive ciò che il sistema ha già fatto; il calendario di capacità prepara il sistema a ciò che il prodotto sta per chiedergli.

Il calendario che rende discutibili le ipotesi #

Un calendario di capacità è un artefatto semplice: raccoglie gli eventi che possono cambiare la domanda, le ipotesi tecniche che ne derivano, il tempo necessario per intervenire e la prossima data in cui rivedere la decisione. Non è una previsione perfetta, né un documento da aggiornare per dovere: è il punto in cui calendari incompatibili di roadmap, vendite, prodotto e operazioni diventano discutibili insieme.

Per ogni evento, conviene annotare quale componente rischia di diventare il vincolo prima delle altre. Potrebbe essere un database che sostiene più scritture, un provider con un limite di rate, una coda che accumula lavoro, oppure un team che non avrebbe tempo per un deploy delicato durante il periodo critico. Il valore sta nel rendere il vincolo contestabile: se l’ipotesi è errata, la si modifica prima di aver investito troppo.

flowchart LR
    A[Previsione di prodotto o commerciale] --> B[Ipotesi sulla forma della domanda]
    B --> C[Calendario di capacità]
    C --> D[Vincoli e tempi di intervento]
    D --> E{Data di revisione}
    E -->|Ipotesi confermata| F[Azione graduale o riserva di margine]
    E -->|Ipotesi cambiata| G[Aggiorna ipotesi e scenario]
    G --> C
    F --> H[Monitoraggio durante l'evento]

Il diagramma mostra una disciplina, non una catena lineare. Una previsione può cambiare; la risposta corretta non è difendere il primo numero ricevuto, ma correggere l’ipotesi insieme all’azione e alla data del controllo. Il calendario è utile proprio perché rende normale correggere una decisione prima che diventi costosa.

La frequenza delle revisioni dipende dalla distanza dell’evento e dal tempo di intervento. Se l’unica correzione possibile richiede settimane — per esempio cambiare un percorso di scrittura o negoziare limiti con un fornitore — aspettare l’ultimo ciclo di planning non conserva flessibilità: la elimina. Il lead time del vincolo deve comparire nel calendario quanto la data dell’evento.

I vincoli che arrivano prima della saturazione #

Molti piani di capacità falliscono perché cercano un unico indicatore, di solito CPU o traffico medio. Eppure un sistema può restare apparentemente tranquillo mentre aumenta il rischio in un punto diverso: una coda cresce più rapidamente di quanto venga smaltita, una query peggiora con la dimensione dei dati, un servizio esterno avvicina il proprio rate limit, oppure i retry moltiplicano il lavoro nei momenti meno tolleranti agli errori.

Per questo conviene seguire indicatori anticipatori, non soltanto soglie di saturazione. Un indicatore anticipatore non promette che si verificherà un incidente; mostra che l’ipotesi di capacità va riesaminata. La sua utilità è organizzativa oltre che tecnica: dà al team una ragione concreta per decidere con calma invece di attendere un allarme.

La domanda da porre per ogni percorso critico è quale risorsa perde margine per prima e quanto tempo serve per recuperarlo. Per una coda, può essere il tempo necessario a ridurre l’arretrato; per un database, l’aumento delle letture o delle scritture che amplifica il costo di un indice mancante; per un’integrazione, il comportamento quando il downstream rallenta. Non serve indovinare il punto esatto di rottura per identificare la direzione del rischio.

Questo è anche il momento di separare la capacità disponibile dalla capacità utilizzabile. Aggiungere istanze può aumentare la prima, ma non risolve una dipendenza seriale, un lock conteso o una quota esterna. Avere più risorse non equivale automaticamente ad avere un percorso che scala.

Quando il vincolo è incerto, una piccola verifica mirata vale più di una previsione molto dettagliata ma non controllabile. Si può tracciare un singolo flusso, misurare dove si accumula l’attesa, rivedere il piano di query o simulare il comportamento di retry in un ambiente che non esponga utenti reali. L’obiettivo non è produrre un numero rassicurante, ma restringere la decisione che dovrà essere presa.

Le azioni reversibili prima del picco #

Una pianificazione utile non termina con «comprare più capacità». Costruisce una sequenza di decisioni in cui le prime mosse sono azioni reversibili, economiche da annullare e capaci di produrre informazioni per la mossa successiva. Può voler dire introdurre limiti per tenant, preparare una feature flag, isolare un job non essenziale, aumentare temporaneamente un margine noto oppure concordare un comportamento degradato per una funzione secondaria.

La reversibilità è una proprietà del piano, non soltanto del deploy. Un deploy può essere facile da rollbackare e restare comunque una cattiva scelta se richiede una migrazione dei dati, cambia un contratto con un partner o consuma tutto il tempo del team prima di un evento. Nel calendario, ogni azione dovrebbe indicare anche il proprio costo di ritorno.

C’è un trade-off reale. Dedicare tempo a scenari, revisioni e margini sottrae attenzione alla roadmap nel breve periodo; saltarli conserva quella velocità solo finché la previsione non incontra un vincolo. A quel punto clienti e persone on-call pagano per la decisione rinviata, mentre il team sceglie sotto pressione tra affidabilità, funzionalità e costo.

Vale la pena collegare questo punto alla bolletta cloud che cresce più del traffico. Un costo inatteso non indica sempre spreco: può essere il segnale che si è comprato margine in fretta perché il sistema non aveva una decisione già pronta. Il problema non è spendere per la capacità, ma sapere quale vincolo si sta acquistando.

Per questo una scelta anticipata può anche essere quella di non ottimizzare subito. Se il picco è vicino e il vincolo è noto, aggiungere capacità temporanea può essere più ragionevole di una modifica architetturale rischiosa. Se invece la crescita è sostenuta, continuare ad aggiungere margine rimanda un problema di struttura e rende più difficile capire il costo reale del sistema. La decisione corretta dipende dalla forma della domanda e dal tempo che hai per renderla sicura.

Un rituale condiviso per la capacità #

Il calendario funziona soltanto se ha un proprietario operativo e partecipanti che portano informazioni diverse. Il prodotto conosce gli eventi che cambiano il comportamento degli utenti; chi segue il commerciale conosce le date che rendono una previsione più concreta; il team tecnico conosce dipendenze, tempi di deploy e punti di fragilità. Nessun ruolo possiede da solo la forma della domanda.

Non serve trasformare la revisione in una riunione lunga. Un incontro breve e ricorrente può chiedere quattro domande con una data: quali eventi sono cambiati, quali ipotesi non reggono più, quale vincolo richiede attenzione prima della prossima revisione e quale azione resta reversibile oggi. Il risultato dovrebbe essere un calendario aggiornato, non una lista di preoccupazioni senza data.

Quando una previsione è troppo vaga, trattala come un intervallo e non come una promessa. Si possono annotare uno scenario prudente, uno più impegnativo e la condizione che farebbe passare dall’uno all’altro. Dire «non lo sappiamo ancora» è una buona informazione se include quando verificarlo e quale decisione cambierà.

Questa pratica richiede disciplina, ma riduce la forma più costosa di lavoro reattivo: quella in cui il team scopre un vincolo prevedibile mentre sta già cercando di proteggere gli utenti. Per un supporto nel trasformare questi segnali in decisioni tecniche e operative, il lavoro di scaling dei sistemi parte proprio dalla connessione tra domanda, vincoli e tempi di intervento.

Domande frequenti #

Come si pianifica se la previsione di domanda è incerta? #

Non è necessario scegliere un solo numero e difenderlo. Usa scenari espliciti, indica quale segnale farebbe cambiare scenario e fissa una data di revisione prima dell’evento. In questo modo l’incertezza resta visibile e non viene convertita, senza discuterne, in un impegno tecnico.

Questa disciplina serve anche a un sistema ancora piccolo? #

Sì, ma il calendario può essere molto leggero. Un sistema piccolo ha spesso meno ridondanza, meno tempo operativo e meno persone disponibili durante un problema; il vantaggio non è costruire una macchina complessa, ma conoscere il limite da controllare prima di una data importante.

Quando conviene aggiungere capacità invece di ottimizzare? #

Se il picco è vicino, il vincolo è noto e l’intervento strutturale introduce rischio, aggiungere margine temporaneo può essere la scelta più sicura. Non chiamarla ottimizzazione: registrala come misura con una scadenza, poi torna a verificare se la crescita sostenuta richiede un intervento diverso.

Con quale cadenza va rivisto il calendario? #

La cadenza deve essere più ravvicinata del tempo necessario per intervenire sul vincolo principale. Per eventi lontani può bastare una revisione periodica; quando si avvicina una data rigida o cambia la previsione, accorcia il ciclo finché esiste ancora una decisione reversibile.

Apri il prossimo planning e aggiungi una sola riga: il prossimo evento che può cambiare la domanda, l’ipotesi tecnica che comporta, il vincolo da controllare e la data entro cui dovrai scegliere.