Průměrné vytížení lže. Výpadek začíná ve frontě, ne na 100 procentech CPU CIO MAG

Teorie front a výzkum rozsáhlých služeb vysvětlují, proč průměr kapacity často varuje pozdě. Littleův zákon spojuje průměrný počet položek v systému, rychlost příchodu a dobu, kterou položka v systému stráví. Výzkum The Tail at Scale zase ukazuje, že u distribuované služby roste význam pomalého konce latence s počtem zapojených komponent a s vyšším využitím.

Praktický důsledek je nepříjemný. Server může ukazovat průměrných 55 procent CPU, ale jeden pool vláken je vyčerpaný, požadavky čekají na databázová spojení a nejpomalejší procento odpovědí překračuje klientský timeout. Uživatel vidí výpadek, zatímco souhrnný dashboard stále vypadá zdravě.

Manažerské shrnutí

01Průměr schová rozdělení. Dvě služby se stejnou průměrnou latencí mohou mít zcela jiný počet extrémně pomalých požadavků.

02Fronta je zásoba nehotové práce. Její růst znamená, že příchod práce převyšuje dokončování, i když některý sledovaný zdroj ještě není na maximu.

03Kapacita se měří až do bodu zlomu. Bez zatěžovacího testu organizace neví, který zdroj se vyčerpá první ani jak služba za hranicí kapacity degraduje.

Uživatel čeká na celý řetězec

U požadavku, který prochází několika službami, nerozhoduje průměrná rychlost každé komponenty. Celkový čas ovlivní nejpomalejší větev. Pokud se odpověď skládá z desítek paralelních operací, pravděpodobnost, že alespoň jedna skončí v pomalém konci rozdělení, roste.

Slabý signál	Co může skrývat	Lepší provozní pohled
Průměrná latence	Malou skupinu požadavků s extrémním čekáním	p50, p95, p99 a nejhorší realistická uživatelská cesta
Průměrné CPU	Horké jádro, blokaci vláken, zámky nebo limit spojení	Využití konkrétních poolů, čekání a saturaci závislostí
Počet požadavků za sekundu	Rostoucí zásobu nedokončené práce	Délku fronty, věk nejstarší položky a rychlost dokončení
Celková chybovost	Selhání jedné důležité skupiny zákazníků	Chybovost podle cesty, regionu, tenantu a třídy práce

METRIKA PRO VEDENÍ

U kritické služby nestačí kapacitní report s průměrem CPU. Musí obsahovat nejméně p95 a p99 latence, délku nebo stáří hlavní fronty, rychlost dokončování a vzdálenost od experimentálně ověřeného bodu zlomu.

Velká fronta nevytváří kapacitu

Fronta dokáže absorbovat krátký náraz, ale dlouhá fronta pouze odkládá selhání a spotřebovává paměť. Google SRE uvádí ilustrativní případ, kdy fronta o velikosti desetinásobku počtu pracovních vláken a zpracování trvající 100 milisekund přidá při zaplnění zhruba sekundu čekání. Většinu výsledné latence tedy nevytváří samotná práce, ale pobyt před ní.

Ještě horší situace vznikne, když klient čekat přestane. Server může dál dokončovat výpočet, jehož výsledek už nikdo nepřevezme. Klient mezitím odešle nový pokus a zvyšuje zatížení. Fronta se tak nestává jen příznakem. Začne aktivně prodlužovat incident.

ZÁTĚŽOVÝ TEST

Zvyšujte provoz po krocích až za očekávanou špičku. U každého kroku měřte příchody, dokončení, p99, čekání ve frontách a odhozenou práci. Test neskončí prvním zvýšením chybovosti. Musí ukázat také chování při návratu pod kapacitu.

Modelový scénář z praxe: CPU bylo zdravé, spojení nebyla

Modelová platební služba měla během ranní špičky průměrné CPU pod 60 procenty. Přesto se zvyšoval počet timeoutů. Tým nejprve plánoval přidat aplikační instance, protože souhrnný dashboard neukazoval jinou zjevnou příčinu.

Rozpad metrik podle zdrojů ukázal, že aplikační pool čekal na omezený počet databázových spojení. Jedna pomalá analytická operace prodloužila dobu jejich držení. Přidání instancí by zvýšilo počet čekajících klientů, nikoli propustnost databáze. Tým oddělil analytickou práci, omezil její souběh a přidal metriku věku nejstaršího čekajícího požadavku. Kapacitní limit se tím neztratil, ale stal se viditelný a řiditelný.

POZNÁMKA Z PRAXE

Když přidání aplikačních instancí nezvyšuje počet dokončených transakcí, systém pravděpodobně nemá nedostatek aplikačního CPU. Má úzké hrdlo, ke kterému nové instance pouze přivádějí další práci.

Co z percentilů neplyne

Ani p99 není univerzální odpověď. Percentil bez objemu neukazuje, kolika uživatelů se problém týká. Agregace přes různé cesty může stále skrýt kritickou funkci. Littleův zákon navíc popisuje dlouhodobé průměry stabilního systému. Sám o sobě nepředpovídá krátký náraz ani konkrétní rozdělení čekání.

Proto je nutné propojit tři pohledy: uživatelský symptom, stav toku práce a konkrétní omezení zdrojů. Metrika má hodnotu pouze tehdy, když pomáhá rozhodnout, zda přidat kapacitu, omezit příchod, zkrátit práci, rozdělit třídy provozu nebo službu řízeně degradovat.

CO VÝZKUM NEPROKAZUJE

Vysoký percentil automaticky neznamená nedostatečnou kapacitu. Může jej způsobit chyba sítě, nevyvážené rozdělení provozu nebo malá skupina mimořádně drahých požadavků. Diagnóza musí spojit latenci s tokem a konkrétním omezením.

Bod zlomu patří do kapacitního rozhodnutí

Rozpočet na infrastrukturu se často opírá o růst objemu a průměrné využití. Spolehlivější rozhodnutí potřebuje experimentálně zjištěnou křivku. Dokud přidaný provoz zvyšuje dokončenou práci téměř lineárně, má systém rezervu. Jakmile dokončování stagnuje, fronta a p99 rostou nelineárně a návrat do normálu trvá déle, služba překročila bezpečnou provozní oblast.

Nosná teze zní: kapacita není procento jednoho zdroje. Je to množství užitečné práce, které celý řetězec dokončí při přijatelném čekání a při zachování schopnosti zotavit se po špičce.