# Cos'è un feature flag e perché lo SRE dovrebbe usarlo URL: https://upstreamapi.com/it/journal/cos-e-un-feature-flag Type: blog Locale: it Published: 2026-10-17 Updated: 2026-10-17 --- > Cos'è un feature flag, cosa non è e come usarlo come controllo del blast radius: i quattro tipi di flag, il debito che generano e la lezione di Knight Capital. Sono le 03:12 e il tasso di errore del checkout ha appena superato il 4%. La modifica che lo ha causato è stata rilasciata sei ore fa. Nessuno vuole ripristinare l'intera release, perché contiene anche due correzioni non collegate. Allora, cos'è un feature flag in questa situazione? È un condizionale nel codice, letto a runtime, che decide se un percorso di codice viene eseguito. Lo disattivi e il nuovo percorso smette di girare, senza build e senza deploy. Tutto il concetto è questo. Il resto è operatività. ## Cos'è davvero un feature flag (e cosa non è) Un feature flag è un punto di decisione. Da qualche parte nel codice c'è un `if`, e il valore che legge arriva dall'esterno del binario: un servizio di configurazione, una riga di database, l'SDK di un fornitore, una variabile d'ambiente che puoi cambiare senza riavviare. `const useNewPricing = await flags.isEnabled("new-pricing-engine", { userId: user.id, plan: user.plan, region: request.region, }); return useNewPricing ? newPricingEngine.quote(cart) : legacyPricing.quote(cart);`Da questo snippet discendono tre cose. Il percorso vecchio deve esistere e deve continuare a funzionare. Il flag ha bisogno di un contesto (chi sta chiedendo) se vuoi qualcosa di più intelligente di acceso o spento. E la valutazione sta sul percorso caldo di ogni richiesta, quindi latenza e modalità di guasto diventano un tuo problema. Nella pratica «feature toggle» e «feature flag» si usano come sinonimi. La parola non conta. Conta il comportamento: separi il deploy del codice dal suo rilascio. Il codice va in produzione spento, e una persona o un sistema decide più tardi chi lo vede. ## I quattro tipi di flag, e perché mescolarli fa male Gran parte dei problemi con i flag nasce dal trattarli tutti allo stesso modo. La [tassonomia dei feature toggle](https://martinfowler.com/articles/feature-toggles.html) di Martin Fowler li divide in base a quanto vivono e a quanto è dinamica la decisione. Regge bene anche in pratica. I release toggle sono transitori. Nascondono lavoro non finito dietro un flag, così puoi fare merge sul trunk ogni giorno. Secondo Fowler dovrebbero raramente sopravvivere a una o due settimane. La decisione è statica: ogni richiesta per una certa release riceve la stessa risposta. Gli experiment toggle instradano utenti diversi verso varianti diverse. Restano accesi il tempo necessario a raggiungere la significatività statistica, da poche ore a qualche settimana, e non oltre. La decisione è per richiesta. Gli ops toggle controllano il comportamento operativo: sacrificare una funzione non critica sotto carico, passare a una dipendenza di fallback, disattivare una query costosa. Alcuni diventano kill switch a lunga durata. Devono cambiare in pochi secondi, il che esclude qualunque cosa che richieda una release. I permission toggle abilitano funzioni in base al piano o al diritto d'uso. Possono vivere per anni, e la decisione è per utente a ogni richiesta. L'errore è dare a tutti e quattro lo stesso ciclo di vita. Un permission toggle ha bisogno per sempre di un responsabile e di un audit trail. Un release toggle ha bisogno di una data di cancellazione il giorno stesso in cui viene creato. Se guardando il nome non riesci a capire di che tipo è un flag, non saprai nemmeno quali sono sicuri da rimuovere. ![Mano che tira la leva rossa di un kill switch su un quadro di controllo scuro](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/fa4827-i1.webp) ## Perché gli SRE se ne occupano: il flag come controllo del blast radius Per un platform team la proprietà interessante non è l'A/B testing. È che un flag trasforma un rilascio da evento in manopola. Senza flag, un deploy espone il 100% del traffico alla modifica in un colpo solo. L'unico rollback è un altro deploy, che richiede tanto tempo quanto la tua pipeline, più il tempo che un essere umano impiega per essere sicuro. Con i flag puoi esporre l'1% degli utenti, osservare tasso di errore e p99, poi passare al 5%, al 25%, al 50%. Il blast radius è la percentuale che hai scelto, e il ripristino è un cambio di configurazione che si propaga in pochi secondi. Questo cambia il tuo mean time to recover più della maggior parte degli investimenti in tooling. La domanda da post-mortem smette di essere «perché il rollback ha richiesto 40 minuti» e diventa «perché non l'avevamo messo dietro un flag». La manopola però ha un inganno. Qualcuno deve osservare i segnali e girarla. Alle 03:12 quel qualcuno è stanco. La versione utile di un sistema di flag collega la manopola a un service level objective: se il tasso di errore consuma una quota fissata del budget, il rollout si ferma e torna indietro senza un essere umano nel loop. La maggior parte dei team lo costruisce a mano, con un webhook dal proprio tool di alerting verso l'API dei flag. Sono qualche centinaio di righe, e si ripagano la prima notte in cui scattano. ## Il conto arriva: il debito dei flag e la lezione di Knight Capital In teoria ogni flag aggiunto raddoppia il numero di percorsi attraverso quel codice. In pratica ne testi qualche combinazione e speri nel meglio. Fowler raccomanda di trattare i flag come inventario con un costo di mantenimento: aggiungi un task di rimozione nel backlog al momento della creazione, metti date di scadenza e, nei team più rigorosi, fai fallire la build quando un flag scaduto è ancora nel codice. La versione costosa di questa lezione è Knight Capital. Il 1 agosto 2012 un nuovo deployment riutilizzò un vecchio flag che un tempo controllava una funzione ritirata. Un server non ricevette il deployment e continuò a girare il codice vecchio. Nei primi 45 minuti dopo l'apertura, il router della società inviò più di 4 milioni di ordini sul mercato mentre cercava di evadere 212 ordini di clienti, come riporta il [provvedimento della SEC contro Knight Capital](https://www.sec.gov/newsroom/press-releases/2013-222). L'articolo di Fowler indica la perdita, intorno ai $460 milioni, come monito su flag che nessuno gestisce. Il flag non è stato l'unico fallimento. Deploy manuale, nessun kill switch e rilevamento lento hanno contribuito. Ma il riutilizzo di un nome di flag morto è il dettaglio che ogni platform team dovrebbe tenere appeso al muro. Non riutilizzare mai un flag. Elimina quello vecchio, creane uno nuovo e rendi la rimozione un passaggio di primo livello. ![Taccuino con diagrammi di flusso disegnati a mano accanto a tastiera e portatile su una scrivania di legno](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/652884-i2.webp) ## Costruirlo da soli o comprare una piattaforma? Un sistema di flag fatto in casa nasce come un file di configurazione e un booleano. Va bene per la prima dozzina di release toggle su un servizio. Smette di andare bene quando servono rollout percentuali stabili per utente, regole di targeting per segmento, un audit log di chi ha cambiato cosa, e un cambio di flag che raggiunge ogni istanza in pochi secondi senza un thundering herd sul tuo store di configurazione. A quel punto stai confrontando piattaforme su criteri misurabili: latenza di valutazione dell'SDK (valutazione locale contro chiamata di rete), streaming contro polling per gli aggiornamenti, granularità delle regole di targeting, supporto multi-ambiente, e come il contatore di prezzo scala con il tuo traffico. I contatori differiscono più delle liste di funzionalità. LaunchDarkly è l'implementazione di riferimento della categoria: targeting maturo, rilasci protetti e una superficie di integrazione profonda. I suoi piani a consumo fatturano per connessione di servizio e per mille utenti attivi mensili lato client, quindi un'app consumer con un grande pubblico anonimo può vedere la fattura muoversi in modi che un team solo backend non vedrà. Il caso a suo favore è reale: se ti servono governance e audit su scala enterprise, è la piattaforma che ha avuto più tempo per consolidarsi. Statsig unisce flag, sperimentazione e product analytics, e fattura sugli eventi. Va bene ai team che trattano i flag soprattutto come superficie di esperimento. Se il tuo caso d'uso sono per lo più ops toggle e kill switch, paghi un'analitica che forse non leggerai. Nota anche che il fornitore ha cambiato proprietario due volte da settembre 2025, il che merita una riga nella tua valutazione del rischio fornitori. Qualunque scelta tu faccia, testa la modalità di guasto prima di firmare. Blocca l'accesso di rete dell'SDK in staging e verifica cosa fa l'applicazione. Un buon SDK serve gli ultimi valori noti dei flag dalla cache e registra l'anomalia in modo chiaro. Uno cattivo blocca il percorso della richiesta. ## L'osservabilità è metà del sistema di flag Un flag senza telemetria è un'ipotesi. Il minimo utile è allegare lo stato del flag a ogni trace e a ogni riga di log della richiesta, così quando compare un picco di errori puoi raggruppare per variante e vedere se il nuovo percorso è la causa. Datadog e le piattaforme all-in-one simili rendono facile la suddivisione per variante, una volta che l'SDK etichetta gli span. Attenzione però: la fatturazione per host e per segnale cresce in fretta quando aggiungi tag ad alta cardinalità, come chiave del flag più variante più segmento utente. Scegli con cura quali dimensioni etichettare. Grafana è la strada più economica se usi già Prometheus e OpenTelemetry. Le dashboard consapevoli dei flag le costruisci tu, il che costa tempo di ingegneria ma ti dà il pieno controllo delle label che emetti. Per un team da 50 a 500 ingegneri con un gruppo platform, questo compromesso è spesso quello giusto. ![Ingegnere che percorre un corridoio tra rack di server illuminato di blu e ambra](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/3ea456-i3.webp) ## Un breve runbook per il tuo primo flag in produzione Se stai introducendo i flag in un team che non ne ha, tieni il primo rilascio noioso. - Scegli una modifica con una metrica di successo chiara, come il tasso di errore del checkout o la p99 di un endpoint. - Dai al flag un nome che riporti tipo e responsabile, per esempio `release.checkout.new-tax-calc.owner-payments`. - Scrivi subito il ticket di rimozione e allega una data di scadenza non oltre due settimane. - Rilascia all'1%, tieni per un intero ciclo di traffico, poi aumenta. Definisci in anticipo la soglia alla quale torni indietro. - Fai del ripristino un singolo comando o un pulsante, e provalo una volta in staging prima di averne bisogno di notte. - Dopo che il 100% ha retto per qualche giorno, elimina il flag e il vecchio percorso di codice nello stesso cambiamento. La parte poco glamour è il punto 6. I team che la saltano finiscono con qualche centinaio di flag, nessuno che sappia cosa fa metà di loro e un rischio alla Knight Capital annidato nel repository. ## Come sarebbe andato il tuo ultimo incidente dietro un flag? Prendi l'ultimo incidente di produzione che il tuo team ha documentato e fatti tre domande. La modifica sarebbe potuta uscire spenta? Una persona avrebbe potuto disattivarla in meno di un minuto, senza un deploy? Un alert ti avrebbe detto quale variante stava fallendo? Se le risposte sono no, no e no, hai il tuo primo candidato a flag e la tua prima stima onesta di quanto costa oggi un rollback. Il post-mortem dirà quello che dirà. La domanda migliore è quanto di quell'incidente avresti potuto rendere più piccolo prima che il pager suonasse. ## FAQ ### Un feature flag è la stessa cosa di un feature toggle? Nella pratica i due termini si usano come sinonimi. Ciò che conta è il comportamento: separare il deploy del codice dal suo rilascio. ### Quanto deve durare un release flag? Secondo Martin Fowler dovrebbe vivere raramente più di una o due settimane. Per questo va creato insieme a un ticket di rimozione con data di scadenza. ### Qual è la differenza tra un experiment toggle e un ops toggle? Un experiment toggle instrada utenti diversi verso varianti diverse per il tempo necessario a raggiungere la significatività statistica. Un ops toggle controlla il comportamento operativo, come disattivare una funzione sotto carico, e deve cambiare in pochi secondi. ### Posso costruire un sistema di feature flag da solo? Sì, per i primi release toggle su un singolo servizio basta un file di configurazione. Diventa più difficile quando servono rollout percentuali stabili per utente, regole di targeting, audit log e propagazione rapida su ogni istanza. ### Cosa succede se il servizio dei flag non risponde? Dipende dall'SDK. Uno buono serve gli ultimi valori noti dalla cache e registra l'anomalia. Uno cattivo blocca il percorso della richiesta. Testa questo scenario in staging bloccando la rete dell'SDK prima di scegliere un fornitore. ### Come collego un flag all'osservabilità? Allega lo stato del flag a ogni trace e riga di log della richiesta, così puoi raggruppare gli errori per variante. Scegli con attenzione le dimensioni da etichettare, perché le etichette ad alta cardinalità fanno crescere in fretta i costi.