Vad är en feature flag? Så styr SRE-team sina releaser

Klockan är 03:12 och felprocenten i kassan har precis passerat 4 procent. Ändringen som orsakade det släpptes för sex timmar sedan. Ingen vill rulla tillbaka hela releasen, eftersom den också bär på två orelaterade fixar. Så vad är en feature flag i den här situationen? Det är ett villkor i din kod, läst vid körning, som avgör om en kodväg körs. Stänger du av det slutar den nya vägen att köras, utan build och utan deploy. Det är hela idén. Allt annat är drift.

Vad en feature flag faktiskt är (och vad den inte är)

En feature flag är en beslutspunkt. Någonstans i koden finns en if, och värdet den läser kommer utifrån binären: en konfigurationstjänst, en databasrad, en leverantörs-SDK eller en miljövariabel du kan ändra utan omstart.

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);

Tre saker följer av det utdraget. Den gamla vägen måste fortfarande finnas och fortfarande fungera. Flaggan behöver kontext (vem som frågar) om du vill ha något smartare än på eller av. Och utvärderingen ligger på den heta vägen för varje request, så dess latens och dess felläge är ditt problem nu.

Folk använder "feature toggle" och "feature flag" om varandra. Ordet spelar ingen roll. Beteendet gör det: du skiljer på att deploya kod och att släppa den till användarna. Koden går ut i produktion i mörker, och en person eller ett system bestämmer senare vem som ser den.

De fyra typerna av flagga, och varför det skadar att blanda dem

Det mesta besväret med flaggor kommer av att man behandlar alla flaggor som en och samma sak. Martin Fowlers taxonomi för feature toggles delar upp dem efter hur länge de lever och hur dynamiskt beslutet är. Den håller i praktiken.

Release-flaggor är tillfälliga. De döljer halvfärdigt arbete bakom en flagga så att du kan merga till trunk varje dag. Fowlers råd är att de sällan ska leva längre än en eller två veckor. Beslutet är statiskt: varje request för en given release får samma svar.

Experiment-flaggor skickar olika användare till olika varianter. De ligger uppe tillräckligt länge för att nå statistisk signifikans, alltså timmar till veckor, och inte längre. Beslutet tas per request.

Ops-flaggor styr operativt beteende: släpp en icke-kritisk funktion under belastning, byt till en reservberoende, stäng av en dyr fråga. Några av dem blir långlivade nödbrytare. De måste kunna vändas på sekunder, vilket utesluter allt som kräver en release.

Behörighetsflaggor styr funktioner per plan eller rättighet. De kan leva i flera år, och beslutet tas per användare vid varje request.

Misstaget är att ge alla fyra samma livscykel. En behörighetsflagga behöver en ägare och en granskningslogg för evigt. En release-flagga behöver ett raderingsdatum samma dag den skapas. Om du inte kan se vilken typ en flagga är bara genom att titta på namnet, kommer du inte heller kunna säga vilka som är säkra att ta bort.

Varför SRE:er bryr sig: flaggor som styrning av blast radius

För ett plattformsteam är den intressanta egenskapen inte A/B-testning. Det är att en flagga gör en release till en ratt i stället för en händelse.

Utan flaggor exponeras 100 procent av trafiken för ändringen på en gång. Den enda återställningen är ytterligare en deploy, och den tar lika lång tid som din pipeline plus den tid det tar för en människa att bli säker. Med flaggor kan du exponera 1 procent av användarna, titta på felprocenten och p99, och sedan gå vidare till 5, 25, 50. Blast radius är den procent du valt, och återställningen är en konfigändring som sprids på sekunder.

Det förändrar din mean time to recover mer än de flesta verktygsinvesteringar gör. Frågan i post-mortemen slutar vara "varför tog det 40 minuter att rulla tillbaka" och blir "varför hade vi inte detta bakom en flagga".

Ratten har en hake. Någon måste följa signalerna och vrida på den. Klockan 03:12 är den personen trött. Den användbara versionen av ett flaggsystem kopplar ratten till ett servicenivåmål (SLO): om felprocenten bränner upp en viss andel av budgeten stannar utrullningen och återställs, utan att en människa behöver vara med. De flesta team bygger detta för hand med en webhook från sitt larmverktyg till flagg-API:t. Det är några hundra rader kod, och det betalar sig första natten den löser ut.

Notan kommer: flaggskuld och lärdomen från Knight Capital

Varje flagga du lägger till fördubblar i teorin antalet vägar genom koden. I praktiken testar du en handfull kombinationer och hoppas. Fowler rekommenderar att man behandlar flaggor som lager med en bärkostnad: lägg en borttagningsuppgift i backloggen när flaggan skapas, sätt utgångsdatum, och i de strängaste teamen låter man bygget falla när en utgången flagga fortfarande finns kvar i koden.

Den dyra versionen av den här lärdomen är Knight Capital. Den 1 augusti 2012 återanvände en ny deploy en gammal flagga som en gång styrde en pensionerad funktion. En server missade deployen och körde fortfarande gammal kod. Under de första 45 minuterna efter öppningen skickade företagets router över 4 miljoner order till marknaden medan den försökte fylla 212 kundorder, enligt SEC:s beslut mot Knight Capital. Fowlers artikel pekar på förlusten, omkring 460 miljoner $, som en varningsberättelse om flaggor man inte håller ordning på.

Flaggan var inte det enda felet där. Manuell deploy, ingen nödbrytare och långsam upptäckt bidrog också. Men återanvändningen av ett dött flaggnamn är detaljen varje plattformsteam bör ha uppsatt på väggen. Återanvänd aldrig en flagga. Ta bort den gamla, skapa en ny, och gör borttagningen till ett förstaklassteg.

Bygga själv eller köpa en flagg-plattform?

Ett hemmasnickrat flaggsystem börjar som en konfigfil och en boolean. Det duger för de första dussin release-flaggorna i en tjänst. Det slutar duga när du behöver procentutrullningar som sitter fast per användare, målgruppsregler per segment, en granskningslogg över vem som ändrade vad, och en flaggändring som når varje instans på sekunder utan att konfigurationslagret drunknar i förfrågningar.

Då jämför du plattformar på mätbara kriterier: utvärderingslatens i SDK:n (lokal utvärdering jämfört med ett nätverksanrop), streaming jämfört med polling för uppdateringar, granularitet i målgruppsreglerna, stöd för flera miljöer och hur prismätaren skalar med din trafik.

Mätarna skiljer sig mer än funktionslistorna gör.

LaunchDarkly är referensimplementationen av kategorin: mogen målgruppsstyrning, skyddade releaser och en djup integrationsyta. Dess användningsbaserade planer tar betalt per tjänstanslutning och per tusen månatliga aktiva klientsidiga användare, så en konsumentapp med en stor anonym publik kan se notan röra sig på sätt som ett enbart backend-team inte märker. Det positiva argumentet är verkligt: om du behöver styrning och granskning i företagsskala har det haft längst tid på sig att härdas.

Statsig paketerar flaggor tillsammans med experimentering och produktanalys, och tar betalt per händelse. Det passar team som i huvudsak ser flaggor som en experimentyta. Om ditt användningsfall främst är ops-flaggor och nödbrytare betalar du för analys som du kanske aldrig läser. Notera också att leverantören bytt ägare två gånger sedan september 2025, vilket är värt en rad i din granskning av leverantörsrisker.

Oavsett vilken du väljer ska du testa felläget innan du skriver på. Blockera SDK:ns nätverksåtkomst i staging och kontrollera vad applikationen gör. En bra SDK serverar de senaste kända flaggvärdena från cache och loggar högljutt. En dålig blockerar requestvägen.

Observabilitet är halva flaggsystemet

En flagga utan telemetri är en gissning. Den minimala användbara uppsättningen fäster flaggtillståndet vid varje trace- och loggrad för requesten, så att du när en felspik dyker upp kan gruppera per flaggvariant och se om den nya vägen är orsaken.

Datadog och liknande allt-i-ett-plattformar gör uppdelningen per variant enkel när din SDK taggar spans. Förbehållet är att prissättningen per värd och per signal växer snabbt när du lägger till taggar med hög kardinalitet, som flaggnyckel plus variant plus användarsegment. Var medveten om vilka dimensioner du taggar.

Grafana är den billigare vägen om du redan kör Prometheus och OpenTelemetry. Du bygger de flaggmedvetna dashboarden själv, vilket kostar ingenjörstid men ger full kontroll över etiketterna du sänder. För ett team på 50 till 500 ingenjörer med en plattformsgrupp är den avvägningen ofta rätt.

En kort runbook för din första flagga i produktion

Om du inför flaggor i ett team som saknar dem, håll den första utrullningen tråkig.

1. Välj en ändring med ett tydligt framgångsmått, till exempel felprocent i kassan eller p99-latens för en endpoint.

2. Namnge flaggan med dess typ och ägare, till exempel release.checkout.new-tax-calc.owner-payments.

3. Skriv borttagningsuppgiften nu och sätt ett utgångsdatum högst två veckor framåt.

4. Rulla ut till 1 procent, håll i en full trafikcykel och gå sedan upp. Definiera i förväg tröskeln där du rullar tillbaka.

5. Gör återställningen till ett enda kommando eller en knapp, och öva en gång i staging innan du behöver den mitt i natten.

6. När 100 procent har hållit i några dagar, ta bort flaggan och den gamla kodvägen i samma ändring.

Det oglamorösa är steg 6. Team som hoppar över det hamnar med några hundra flaggor, ingen som vet vad hälften av dem gör, och en Knight-formad risk i repot.

Hur hade din senaste incident sett ut bakom en flagga?

Ta den senaste produktionsincident ditt team skrev upp. Ställ tre frågor. Kunde ändringen ha gått ut i mörker? Kunde en person ha stängt av den på under en minut utan deploy? Hade ett larm berättat vilken variant som föll?

Om svaren är nej, nej och nej har du din första flaggkandidat och din första ärliga uppskattning av vad en återställning kostar idag. Post-mortemen säger vad den säger. Den bättre frågan är hur mycket av den du hade kunnat göra mindre innan pagern gick.