11.3 Køteori

Overblik og motivation

Køteori er den matematiske undersøgelse af ventelinjer. I softwareudvikling er den den stille teori bag en enorm mængde praksis. Kundeserviceresponsivitet, kanban-planlægning (en pull-baseret metode, der begrænser igangværende arbejde for at forbedre flow), meddelelseskøer mellem processer, kontinuerlige udrulningspipelines: det er alle køer, og de adlyder alle de samme love. At forstå de love lader et team ræsonnere om ledetider, gennemløb, kapacitet og den sande omkostning ved at køre systemer tæt på deres grænser i stedet for at blive overrasket af dem i produktion. Dette kapitel hører til i Flow-delen, fordi køteori er det formelle fundament for flow: den forklarer, hvorfor arbejde venter, og hvad der faktisk reducerer ventetiden.

Her er motivationen: intuition om køer er pålideligt forkert, og forkert på dyre måder. Folk antager, at en server, der kører på 90 % udnyttelse, er “10 % fra problemer”, når ventetider i virkeligheden eksploderer ikke-lineært, når udnyttelsen nærmer sig 100 %. De antager, at tilføjelse af igangværende arbejde (WIP) fremskynder levering, når det forlænger ledetider. De planlægger kapacitet efter gennemsnit og bliver så knust af variabilitet. Lidt køteori erstatter disse dyre intuitioner med et lille antal robuste sammenhænge, vigtigst Littles lov, der gælder på tværs af kundekøer, opgavetavler og CI/CD-pipelines.

For store teams, virksomheder og det offentlige er køteori et fælles sprog for kapacitet og flow, et der forbinder roller, som ellers taler forbi hinanden. Produktchefer interesserer sig for ledetid fra idé til kunde. SRE’er interesserer sig for serverudnyttelse og latens. DevOps-teams interesserer sig for udrulningsfrekvens. Supportledere interesserer sig for svartider. Det er alle kømålinger, og at udtrykke dem i ét rammeværk (ankomstrate, servicerate, udnyttelse, ventetid) lader en organisation planlægge kapacitet, sætte realistiske SLO’er (servicemål) og retfærdiggøre investering med matematik frem for anekdote.

Grundprincipper

Alt med en ventetid er en kø: tickets, opgaver, meddelelser og udrulninger inklusive.
Littles lov er ankeret: poster i systemet = ankomstrate × tid i systemet (κ = λτ).
Udnyttelse og ventetid er ikke-lineære: de sidste 15 % af kapaciteten er de dyreste.
Variabilitet er flowets fjende: gennemsnit skjuler smerten; varians skaber køer.
At reducere igangværende arbejde reducerer ledetid: flow, ikke travlhed, er målet.
Mål hele flowet: ankomster, service, succeser, fejl, spring over og ventetider.
En proces er en kø af køer: modellér trin, og optimér så det begrænsende.

Anbefalinger

Lær den grundlæggende notation, og brug den konsekvent

En håndfuld størrelser beskriver enhver kø. At standardisere på dem (græske bogstaver er konventionen) fjerner tvetydighed på tværs af teams:

λ (lambda), ankomstrate: hvor hurtigt nye poster kommer ind.
μ (my), servicerate: hvor hurtigt poster håndteres. Fordi “servicerate” bruges tvetydigt, er det ofte værd eksplicit at opdele gennemløb i samlet rate (χ), succesrate (α), fejlrate (β) og springrate (σ), hvor χ = α + β + σ.
ρ (rho), udnyttelse / trafikintensitet = λ / μ: den enkelt vigtigste opsummering. ρ < 1 betyder, at køen tømmes; ρ ≥ 1 betyder, at den vokser uden grænse.
Tider: ledetid (τ, start til slut), arbejdstid (φ, egentlig behandling), ventetid (ω, afventende) og trintid (θ, mellem afslutninger).
ε (epsilon), fejlforhold: fejl ÷ i alt.

At navngive fejl og spring over eksplicit betyder noget i software: en post, der opgives (en kunde, der giver op, en forladt kurv, en afvist arbejdsticket), forlader køen uden at blive betjent, og at lade som om den blev “betjent” korrumperer jeres målinger. Følg balking (at beslutte ikke at slutte sig til), reneging (at give op efter at have ventet) og jockeying (at skifte kø) som førsteklasses udfald.

Forankr planlægningen i Littles lov

Littles lov siger, at det langsigtede gennemsnitlige antal poster i et stabilt system er lig den gennemsnitlige ankomstrate gange den gennemsnitlige tid, hver post bruger i systemet: κ = λ τ (klassisk L = λW). Den er forbløffende generel (den kræver ingen antagelse om ankomstfordelingen eller serviceordenen), hvilket gør den til flowplanlægningens arbejdshest. Omarrangeret fortæller den jer, at ledetid = igangværende arbejde ÷ gennemløb. Det er det matematiske grundlag for kanban og lean: hvis I vil have kortere ledetider og ikke kan hæve gennemløbet, må I sænke WIP. Den giver også hurtige fornuftstjek. Hvis 40 tickets er åbne, og I lukker 8 om dagen, tager den gennemsnitlige ticket omkring 5 dage, uanset hvor travlt nogen føler sig. Dens ene krav er stabilitet: ankomster må ikke vedvarende overstige afgange (ρ < 1), ellers bryder køen, og lovens antagelser, sammen.

Respektér udnyttelsens ikke-linearitet

Køteoriens vigtigste operationelle lektie er, at svartid stiger skarpt, ikke gradvist, når udnyttelsen nærmer sig 100 %. Bob Wescotts Seven insights into queueing theory indfanger de praktiske konsekvenser levende:

Jo langsommere servicecentret, desto lavere spidsudnyttelse bør I planlægge for.
Det er meget svært at bruge de sidste 15 % af noget.
Jo tættere I kører på kanten, desto højere pris for at tage fejl.
Svartidsvækst er begrænset af, hvor mange poster der kan vente.
Det er gennemsnit, ikke maksima: planlæg for halen.
Vogt jer for den menneskelige fornægtelseseffekt på tværs af flere servicecentre.
Vis små forbedringer fra deres bedste side.

Designimplikationen: sørg bevidst for ekstra plads. At sigte efter 70–80 % udnyttelse for latensfølsomme systemer er ikke spild; det er at købe forudsigelig svartid. Det informerer direkte kapacitetsplanlægning og SLO’er (kapitel 3.5 og 9.1).

Modellér processer som en kø af køer

Reelt arbejde flyder gennem trin, og en flertrinsproces er blot en kø, hvis poster selv står i kø ved hvert trin. Modellér den sådan: procesankomstraten er trin 1’s ankomstrate; processens succesrate er det sidste trins succesrate; processens fejl- og springtal er summerne på tværs af trin. To almindelige former går igen:

Tragte, hvor antallet af poster skrumper for hvert trin (ansættelse: opsøgning → interview → tilbud; indkøb: gennemse → kurv → betal; levering: integrér → UAT → produktion). Optimér det trin, der betyder mest: maksimér ankomster øverst i tragten, minimér spring over midt i tragten (forladte kurve) eller minimér fejl i det sidste trin (dårlige produktionsudrulninger).
Dobbelt-diamant-opdagelses- og leveringsflow (opdag → definér → udvikl → lever), som denne bogs Flow-del behandler direkte (kapitel 11.1).

At finde og lindre det begrænsende trin (flaskehalsen) er, hvor flowforbedring betaler sig; at optimere ikke-begrænsninger flytter blot køen.

Forbind kømålinger med de KPI’er, teams allerede bruger

Køstørrelser kortlægges rent på de leverings- og pålidelighedsmålinger andetsteds i denne bog, hvilket er det, der gør teorien praktisk frem for akademisk:

Leveringsledetid (Dτ), “koncept til kunde”, er et ledetidsmål (τ) og en DORA-måling (DevOps Research and Assessment) (kapitel 11.2).
Udrulningsfrekvens (Dμ) er et serviceratemål.
Ændringsfejlrate (Dε) er et fejlforhold.
Tid til genoprettelse (Rτ) er en genoprettelsesledetid, dvs. MTTR (kapitel 9.3).

Skeln mellem de forskellige MTTR’er (mean time to respond, repair, recover og resolve), fordi de måler forskellige segmenter af hændelseskøen og rutinemæssigt forveksles. At forankre SLI’er/SLO’er/SLA’er (kapitel 9.1) i køtermer holder mål ærlige og sammenlignelige.

Afvejninger: fordele og ulemper

Beslutning	Fordele	Ulemper
Kør systemer med høj udnyttelse	Lavere hardware-/omkostning pr. enhed	Ikke-lineære latenseksplosioner; skrøbeligt over for spidser
Sørg for rigelig ekstra plads	Forudsigelig latens; robust over for varians	Højere omkostning i stabil tilstand; ser “underudnyttet” ud
Begræns WIP (kanban)	Kortere ledetider; mindre kontekstskift	Føles langsommere; kræver disciplin at holde grænsen
Formel kømodellering	Kvantificerede kapacitetsbeslutninger; færre overraskelser	Indlæringskurve; modeller forenkler rodet virkelighed
Kun tommelfingerregler	Hurtigt, ingen matematik	Forkert netop, hvor det er dyrest (tæt på kapacitet)

Den tilbagevendende afvejning er effektivitet versus forudsigelighed: at presse udnyttelsen op sparer penge, til det pludselig ikke gør, og så overstiger latens-, fejl- og brandslukningsomkostninger besparelsen. Køteoriens bidrag er at fortælle jer, hvor den klippe er, så afvejningen er et valg, ikke en ulykke.

Spørgsmål til drøftelse med dit team

Hvad er jeres eksplicitte udnyttelsesmål for hvert latensfølsomt system, og hvem godkendte det? Ekstra plads er et bevidst køb af forudsigelig latens, så den bør være en angivet politik, ikke en tilfældighed af, hvilken belastning der nu tilfældigvis ankom. Fordi svartid stiger ikke-lineært, kan 85 % allerede betyde forhøjet halelatens, men økonomi ser ekstra plads som spild og presser udnyttelsen op. Tag tallene med: nuværende udnyttelse, den målte latenskurve og omkostningen ved jeres sidste latenshændelse, og vis så, hvor klippen sidder for hver tjeneste. For virksomheds- og offentlige systemer med sæsonbestemte spidser (indberetningssæson, tilmeldingsvinduer) så sæt målet ud fra spidsen, ikke gennemsnittet. Hvis ingen ejer udnyttelsesmålet, vil latenshændelser blive ved med at dukke op “ud af ingenting”.
Hvor i jeres systemer er en kø ubegrænset, uden modtryk til at afvise belastning, når den overvældes? En ubegrænset kø fejler ikke elegant; den degraderer til kollaps, fordi ankomster, der vedvarende overstiger afgange (rho >= 1), betyder, at køen vokser uden grænse. Gør status over jeres meddelelseskøer, trådpuljer og forespørgselsbuffere, og spørg, hvad der sker ved hver, når ankomstraten overstiger serviceraten: afviser den belastning, anvender modtryk eller vælter? Det betyder akut noget i virksomhedsskala, hvor én mættet downstream kan kaskadere på tværs af tjenester. Tag et belastningstestresultat eller en tidligere hændelse, hvor en kø løb fuld, med, og tjek, om systemet afviste overskydende arbejde eller forsøgte at holde det hele. Rettelsen er begrænsede køer med eksplicit modtryk og timeouts udledt af Littles lov, så en overbelastning afviser frem for at vælte.
Modellerer I jeres idé-til-produktion-flow som en kø af køer, og er jeres forbedringer rettet mod den reelle begrænsning? En flertrinsproces er en kø, hvis poster står i kø ved hvert trin, og at optimere andet end det begrænsende trin flytter blot køen. Kortlæg jeres leveringstragt (integrér til UAT til produktion, eller opdag til definér til udvikl til lever), og mål ankomst-, service-, vente- og springrater ved hvert trin for at finde, hvor arbejde faktisk hober sig op. Teams optimerer rutinemæssigt det trin, de forstår bedst, frem for flaskehalsen, hvilket bruger indsats og flytter intet. Tag ventetidsdata pr. trin med, ikke mavefornemmelse, for flaskehalsen er ofte en ventetilstand (gennemgang, godkendelse, miljøtilgængelighed) frem for en arbejdstilstand. Når I kender begrænsningen, ret mod den, og lad ikke-begrænsningerne være.
Bruger I Littles lov til at sætte WIP-grænser, eller tilføjer I kapacitet for at kurere ledetider, som kun mere disciplin ville rette? Littles lov siger, at ledetid er lig igangværende arbejde divideret med gennemløb, så hvis I ikke kan hæve gennemløbet, er den eneste løftestang tilbage for kortere ledetider at sænke WIP, hvilket ikke koster andet end tilbageholdenhed. Det modsatrettede træk er reelt: at begrænse igangværende arbejde føles langsommere og ledigt, og ledere under pres vil hellere ansætte eller købe hardware end fortælle teams at starte mindre og afslutte mere. Tag de hårde tal med, nuværende åbne poster og afslutningsrate pr. trin, og beregn den implicerede gennemsnitlige ledetid, og sammenlign så med, hvad folk tror den er; hullet er som regel stort og pinligt. I en stor virksomhed eller et stort agentur bør en ansættelses- eller indkøbsanmodning begrundet som en ledetidsrettelse først testes mod denne aritmetik, for en bemandingsforøgelse, der hæver WIP, kan forlænge netop de ledetider, den skulle forkorte.
Planlægger I kapacitet efter gennemsnit, eller har I kvantificeret den variabilitet, der faktisk skaber jeres køer? Køer opstår af varians, ikke af middelværdien, så to systemer med identisk gennemsnitsbelastning kan opføre sig helt forskelligt, hvis det ene har stødvise ankomster eller langhalede servicetider. Spændingen er, at gennemsnit er lette at indsamle og beroligende at rapportere, mens variansen og halen er sværere at måle og uvelkomne i en statusopdatering. Tag fordelingen med, ikke middelværdien: ankomststødvished, 95. og 99. percentil af service- og ventetider og de batchstørrelser, der koncentrerer arbejde i spidser. For virksomheds- og offentlige systemer med forudsigelige stigninger (indberetningssæson, lønkørsler, tilmeldingsvinduer, kvartalsafslutningsbelastninger) så planlæg bufferen og udnyttelsesmålet ud fra spidsperiodens varians, for et design dimensioneret til årsgennemsnittet vil fejle netop, når offentligheden ser på.
Hvilke af jeres køer tæller stille afbrydelser og afvisninger som om arbejdet blev betjent, og hvilken uopfyldt efterspørgsel skjuler det? En post, der balker, renegerer eller afvises, forlader køen uden at blive håndteret, og at registrere den som “betjent” korrumperer jeres gennemløb, jeres fejlforhold og jeres kapacitetsplan på én gang. Det modsatrettede hensyn er, at “besvarede opkald” eller “lukkede tickets” ser bedre ud på et dashboard end “ringere, der gav op”, så det ærlige tal er det, ingen melder sig til at fremlægge. Tag springraten (σ), balking- og reneging-tal og forskellen mellem tilbudt belastning og betjent belastning med, så den sande efterspørgsel bliver synlig. Det betyder skarpt noget i offentlig tjenesteleverance, hvor borgere, der opgiver en telefonkø eller en ydelsesansøgning, er uopfyldte forpligtelser frem for løste sager, og at rapportere dem som håndteret både forvrænger præstationen og undervurderer den kapacitet, offentligheden er skyldig.

Sektorperspektiv

Startup. I har ikke tid til formel kømodellering og intet behov for den. Ræk først efter de to billigste gevinster: anvend Littles lov på jeres efterslæb for at se den reelle ledetid, jeres WIP implicerer, og hold øje med jeres kanbantavle for det trin, hvor arbejde hober sig op, før I ansætter mod en flaskehals, der måske ikke findes. Hold udnyttelsen væk fra klippen på enhver latensfølsom sti ved at lade ekstra plads stå frem for at tune den væk, for et nedbrud under en vækstspids koster langt mere end lidt ledig kapacitet.

Lille virksomhed. Uden en kø-specialist på staben så køb målingerne frem for at bygge modellerne. Vælg en helpdesk, meddelelsesmægler eller hostingplatform, der allerede rapporterer ankomstrate, ventetid og afbrydelse, og læs de tal i stedet for at udlede dem. Ram beslutningen ind som at holde øje med to symptomer: ventetider, der stiger ikke-lineært, når I bliver travlere, og kunder, der giver op, før de er betjent, da en tabt kunde er den køomkostning, der gør mest ondt for en lille virksomhed.

Stor virksomhed. Arbejdet er at gøre køtænkning til en fælles disciplin på tværs af mange teams: én aftalt notation (λ, μ, ρ, ledetid), ensartede WIP- og udnyttelsesplads-politikker og modtryksstandarder, så en mættet downstream ikke kan kaskadere på tværs af tjenester. Sæt SLO’er og kapacitet ud fra køanalyse frem for gætværk, og styr jeres køer som en portefølje med baselines og gennemgange, så intet enkelt team kører varmt i isolation. Bag analysen ind i kapacitetsstyring og revision, så et mål for ekstra plads er en dokumenteret beslutning, nogen ejer.

Offentlig sektor. Indkøb, gennemsigtighed og offentlig ansvarlighed former hvert kapacitetsvalg. Dimensionér kontaktcentre og borgervendte systemer ud fra spidsperiodens varians (indberetningssæson, tilmeldingsvinduer), ikke årsgennemsnittet, og bemand for at holde udnyttelsen væk fra klippen, når efterspørgslen stiger. Følg balking og reneging som uopfyldt offentlig efterspørgsel frem for at skjule det inde i “besvarede opkald”, og begrund kapacitetsudgifter med Littles lov-estimater af ventetid, som giver revisorer og folkevalgte en forsvarlig, matematikbåret sag i stedet for en anekdote.

Eksempler

Startup. Et SaaS-team på fem personer, der drukner i et supportefterslæb, antager, at de må ansætte endnu en agent. Før de bruger pengene, anvender de Littles lov: 60 åbne tickets og 12 lukkede om dagen betyder, at en gennemsnitlig ticket venter omkring 5 dage, hvilket matcher de vrede e-mails. Mens de ser på deres kanbantavle, bemærker de, at tickets hober sig op i venten på ingeniørarbejde, ikke på support, så de begrænser igangværende arbejde og router fejlrapporter direkte ind i sprintet i stedet for at lade dem stå i kø. Ledetiden falder til under to dage uden nogen ny ansættelse, og de bruger det frigjorte budget på den egentlige flaskehals i stedet.

Stor virksomhed. En betalingsplatform, der dimensionerer sin autorisationstjeneste, måler λ ≈ 850 forespørgsler/sekund og pr. node μ ≈ 200/sekund. Naivt er det ~5 noder (ρ = 0,85), men med viden om at ρ = 0,85 allerede betyder skarpt forhøjet halelatens provisionerer teamet til ρ ≈ 0,65 og bruger Littles lov til at forudsige antallet af forespørgsler under behandling og sætte kødybder og timeouts. Hændelser i højsæsonen, der plejede at dukke op “ud af ingenting”, forsvinder, fordi teamet ikke længere opererede på den stejle del af kurven.

Offentlig sektor. En skattestyrelses kontaktcenter modellerer indberetningssæsonens support som en kø: ankomstspidser (λ), agentkapacitet (μ) og, afgørende, springraten (σ) for borgere, der opgiver efter lange ventetider. Ved at følge balking og reneging frem for kun “besvarede opkald” ser ledelsen den sande uopfyldte efterspørgsel, bemander for at holde udnyttelsen væk fra klippen i spidserne og begrunder den ekstra kapacitet med Littles lov-estimater af ventetid, en forsvarlig, matematikbåret sag for offentlige udgifter frem for en anekdotisk.

Business case: motivation, ROI og TCO

Køteori betaler sig ved at forhindre to dyre fejl: overprovisionering (at betale for ledig kapacitet, I ikke havde brug for) og, langt mere skadeligt, underprovisionering tæt på klippen (hvor små belastningsstigninger forårsager stor latens, brudte SLA’er, forladte kunder og nødudgifter). Fordi omkostningen ved at køre nær 100 % udnyttelse er ikke-lineær, er besparelserne ved “bare læg lidt mere belastning på” små, og ulempen katastrofal, netop den asymmetri som lidt matematik forvandler til en bevidst beslutning. Afkastet måles i undgåede nedbrud, opfyldte SLA’er, fastholdte kunder, der ellers ville balke, og roligere vagtrotationer.

På samlet ejeromkostning er rammeværket billigt at indføre (det er viden, ikke værktøj), og det forbedrer næsten enhver kapacitets-, latens- og flowbeslutning, en stor organisation træffer over et systems levetid. Littles lov og WIP-grænser reducerer ledetider uden at købe noget (en ren proces-gevinst), mens udnyttelsesdisciplin bytter en beskeden, forudsigelig omkostning i stabil tilstand for elimineringen af dyre, uforudsigelige fejl. For at fremlægge sagen for ledelsen så oversæt en nylig latenshændelse til udnyttelseskurven og vis, hvordan et mål for ekstra plads ville have forhindret den, og brug Littles lov til at forbinde WIP-reduktion direkte med hurtigere levering.

Anti-mønstre og faldgruber

Kapacitetsplanlægning efter gennemsnit: at ignorere varians, som er det, der faktisk skaber køer.
At køre varmt: at sigte efter 90 %+ udnyttelse på latensfølsomme systemer og blive chokeret over halelatens.
At tælle spring over som service: at behandle forladte kunder eller afviste tickets som håndteret og korrumpere målinger.
At stable WIP: at forveksle travlhed med gennemløb og forlænge ledetider.
At optimere en ikke-flaskehals: at forbedre trin, der ikke er begrænsningen, og flytte køen andetsteds.
At forveksle MTTR’erne: at rapportere “genoprettelse”, mens man måler “reparation”, eller omvendt.
Ubegrænsede køer: intet modtryk, så et overbelastet system degraderer til kollaps i stedet for at afvise belastning.
Gennemsnit som maksima: at designe til middelværdien og blive paget af halen.

Modenhedsmodel

Niveau 1, Opstart: Køer (tickets, opgaver, meddelelser, udrulninger) er ustyrede og reaktive; kapacitet gættes; udnyttelsen kører, hvor belastningen lander; latensproblemer overrasker teamet og brandslukkes bagefter.
Niveau 2, Udvikling: Nogle få teams indsamler grundlæggende målinger (gennemløb, gennemsnitlig ventetid), men læser dem som gennemsnit og anvender dem inkonsistent; nogle grupper begrænser WIP eller lader ekstra plads stå, mens andre kører varmt; der er ingen fælles notation, så praksisserne rejser ikke på tværs af teams.
Niveau 3, Standardisering: En fælles notation (λ, μ, ρ, ledetid) er dokumenteret og håndhævet organisationsdækkende; WIP-grænser og mål for udnyttelsesplads sættes bevidst for hvert latensfølsomt system; de forskellige MTTR’er skelnes; begrænsede køer med modtryk er standard på tværs af tjenester.
Niveau 4, Styring: Køerne måles og styres mod baselines: ankomstrate, servicerate, udnyttelse, halelatens (p95/p99) og ledetid følges mod definerede mål og SLO’er; kødybder, timeouts og ekstra plads udledes af Littles lov frem for gættes; balking, reneging og springrate tælles, så tilbudt belastning skelnes fra betjent belastning; kapacitetsbeslutninger gennemgås på denne dokumentation, ikke på fornemmelse.
Niveau 5, Orkestrering: Flow modelleres kontinuerligt som en kø af køer; flaskehalse identificeres og lindres som løbende praksis; kapacitet, SLO’er og modtryk tilpasser sig skiftende efterspørgsel og varians; kømålinger knyttes direkte til DORA og forretnings-KPI’er, og organisationen rebalancerer kapacitet på tværs af hele flowet, efterhånden som belastnings- og risikobilledet skifter.

Idéer til drøftelse

Hvilken udnyttelse kører jeres latensfølsomme systemer faktisk på, og hvor er deres klippe?
Anvend Littles lov på jeres nuværende efterslæb: hvilken ledetid implicerer jeres WIP ÷ gennemløb, og matcher den virkeligheden?
Hvilke af jeres køer tæller stille “spring over” (afbrydelser, afvisninger) som om de var betjent?
Hvor ville en lavere WIP forkorte ledetiden billigere end at tilføje kapacitet?
Hvilket trin i jeres idé-til-produktion-flow er den sande flaskehals, og er jeres forbedringer rettet derhen?
Viser jeres dashboards gennemsnit, hvor det er halen, der faktisk gør ondt?

Vigtigste pointer

Kundekøer, kanbantavler, meddelelseskøer og udrulningspipelines er alle køer styret af de samme love.
Littles lov (κ = λτ) forankrer flowplanlægning: ledetid = WIP ÷ gennemløb.
Udnyttelse og ventetid er ikke-lineære: sørg for ekstra plads; de sidste 15 % er de dyreste.
Følg hele billedet: ankomster, service, succeser, fejl og spring over og ventetider; lad ikke afbrydelse skjule sig.
Modellér processer som en kø af køer, og ret flaskehalsen, ikke travlheden.
Kømålinger kortlægges direkte på DORA-/flow- og SLI-/SLO-målinger (kapitel 11.1, 11.2, 9.1) og giver hele organisationen ét sprog for kapacitet og flow.

Referencer og videre læsning

Bob Wescott, Seven Insights into Queueing Theory (and The Every Computer Performance Book).
John D. C. Little, “A Proof for the Queuing Formula L = λW” (1961): Little’s Law.
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: flow-based DORA metrics that align with queue KPIs.
Donald Reinertsen, The Principles of Product Development Flow: queues, batch size, and WIP economics.
Daniel Vacanti, Actionable Agile Metrics for Predictability: Little’s Law applied to kanban.
Joel Parker Henderson, Queueing Theory: notation, KPIs, and queue-of-queues (github.com/joelparkerhenderson/queueing-theory).
Dan Slimmon, “The most important thing to understand about queues” (2016).
Wikipedia: “Queueing theory,” “M/M/1 queue,” “Little’s law,” “Markov chain.”