Kapasitets- og ytelsesovervåking: lesing av beregninger og planlegging for fremtiden

Gevinster:

• Evne til å tolke beregninger riktig med støtte for kunstig intelligens ved å bruke persentil (p95/p99) og baseline i stedet for gjennomsnitt
• Evne til å skille sesongvariasjoner fra trend og produsere kapasitetsprognose som et optimistisk-pessimistisk område i stedet for et enkelt tall
• Forstå at ressursinvesteringer og alarmterskelbeslutninger er menneskelige, sammen med ressursens ledetid og forretningskontekst.

Kapasitets- og ytelsesovervåking: Lese beregninger med AI og planlegge fremtiden

Du kan ikke se helsen til et system med dine egne øyne; Du forstår det gjennom beregninger. En metrikk er en tidsavhengig numerisk verdi av en målbar egenskap ved et system: CPU-bruk, minnebelegg, ledig diskplass, nettverksforsinkelse, forespørsler per sekund. Ytelsesovervåking samler kontinuerlig inn disse beregningene og svarer på spørsmålet "er systemet OK nå?" Kapasitetsplanlegging går ett skritt videre: Den svarer på spørsmålet "med denne hastigheten, når vil jeg bli utilstrekkelig, når bør jeg kjøpe nye ressurser?" Her er AI en svært dyktig assistent i å tolke hauger med beregninger, markere anomalier, lese trenden og produsere fremtidig projeksjon. Men ett forbehold råder fremfor alt: AI trekker ut mønstre fra historiske data; Du er den som tar beslutninger om ressursinvesteringer, skalering og varslingsterskel med kontekst.

I denne enheten overvåkingsbegreper som baseline (normal atferdslinje), anomali (avvik fra normalen), persentil (persentil); Metrisk tolkning med AI; trend- og vekstprognose; og du vil lære å stille inn riktig alarmterskel.

Gjennomsnittet ligger: hvorfor prosentil?

Den vanligste feilen ved sporing er å måle alt med et gjennomsnitt. La oss si at responstiden din er 200 ms i gjennomsnitt. Høres bra ut. Men 5 % av brukerne kan vente i 8 sekunder; Gjennomsnittet skjuler dette. Det er derfor fagfolk bruker persentil: p95 = "95 % av forespørslene er under denne tidsperioden." Hvis p95-svartiden er 8 sekunder, har én av tjue brukere en forferdelig opplevelse - gjennomsnittet viser aldri det. Når du gir beregninger til AI, vær klar over hvilken statistikk du vil ha: "tolk p50, p95 og p99 for meg, ikke gjennomsnittet." Denne ene vanen avslører skjulte problemer.

Tips: Se på persentilen for hver beregning som angår brukeropplevelse (responstid, latens); p95/p99 i stedet for gjennomsnitt bringer deg til den virkelig lidende minoriteten. I ressursberegninger (CPU, minne), se på både topp- og vedvarende verdier.

Det er ingen anomali uten en grunnlinje

Før du kan se om en beregning er "unormal", må du vite "normal". Baseline er det typiske atferdsområdet til systemet på friske dager: "denne tjenesten ukedag middag CPU er typisk 40–60 %". Uten en baseline kan du ikke vite om en 70 % verdi er skummel eller normal. Du kan angi en grunnlinje ved å gi historiske sunne data til AI og si "trekk ut normalområdet og det daglige/ukentlige mønsteret til denne beregningen". Deretter tolker du de nye dataene i henhold til denne grunnlinjen: "hvor er denne verdien i normalen?" En anomali er et betydelig og vedvarende avvik fra baseline - et enkelt plutselig hopp er ofte støy.

Trinn for trinn: kapasitetsprojeksjon

1. Samle en ren og tilstrekkelig historie. En trend krever minst noen uker med data, helst månedlig. En projeksjon laget med lite data er en gjetning, ikke en prediksjon.
2. Separat sesongvariasjon. Trafikken synker i helgen, øker i slutten av måneden og eksploderer under kampanjen. Fortell AI disse syklusene slik at det ikke forveksler vekst med sesongmessige svingninger.
3. Ta av trenden. "Hvor mange GB i gjennomsnitt har denne disken vokst per uke de siste 8 ukene?" AI beregner vekstrate.
4. Be om projeksjon, plasser det ut. "Med denne hastigheten, når vil disken være 90 % full?" — men be om en optimistisk/pessimistisk rekkevidde, ikke en enkelt date. Fremtiden er usikker; oddetall er falsk presisjon.
5. Bestem beslutningsterskelen med folk. Hvis projeksjonen sier "Det vil bli fullført om 6 uker", vurderer du innkjøpstiden (kjøp, godkjenning) og bestemmer deg for om du vil iverksette tiltak i dag.
6. Still inn alarmen riktig. Svært følsom alarm produserer støy og alarmtretthet; for løs alarmen vil gå glipp av hendelsen. Få en terskelanbefaling fra AI, men bestem den endelige terskelen med din egen risikotoleranse.

tre minisaker

Tilfelle 1 — Gjennomsnitt skjult, s99 viste. Ett team trodde deres API var "180 ms i gjennomsnitt, helt greit." Da jeg matet beregningene til AI og ba om prosentiltolkning, viste det seg at p99 var 6400 ms - én av hundre forespørsler var tregere enn 6 sekunder. Grunnårsaken var en treg databasespørring. Mens gjennomsnittet virket sunt, hadde minoriteten en forferdelig opplevelse.

Tilfelle 2 — Projeksjon varslet 3 uker i forveien. En administrator ga loggdiskbeleggsdataene til AI. AI antydet en ukentlig veksttrend på ~7 GB og anslått at med dagens hastighet ville 90 % nås innen 19 dager, med et optimistisk-pessimistisk område på 16–23 dager. Siden det tok 10 dager å levere nye disker, bestilte teamet umiddelbart og forhindret strømbruddet før det skjedde.

Tilfelle 3 — Retur fra falsk anomali. En overvåkingsalarm gikk hver søndag kveld som sa at CPU-en gikk opp til 95 %. Før han fikk panikk, fikk ingeniøren AI til å øke grunnlinjen: dette hoppet var en planlagt reservejobb som skjedde på samme tid hver uke, så det var en del av normen. Det var ikke en anomali; grunnlinjen manglet. Alarmterskelen er korrigert for den tidsperioden, og unødvendige nattvekker er borte.

Fire kopierbare maler

1) Metrisk tolkning (persentil):

Nedenfor er [service] responstid-beregninger (maskert). Kommenter til meg p50, p95 og p99, ikke gjennomsnittet. Hva betyr forskjellen mellom p99 og p50, hvilket brukeropplevelsesproblem indikerer det? Ikke legg til oppdiktede verdier, bare tolk dataene jeg gir deg. Data: [metrics]

2) Grunnlinjesubtraksjon:

Nedenfor er de sunne [metriske] dataene for de siste 4 ukene. Trekk ut det (1) normalområdet (2) daglige og ukentlige mønsteret (f.eks. natt lav, middag høy) for denne beregningen. Da vil jeg gi en enkelt ny verdi; klassifiser det som "normalt/forsiktig/unormalt" basert på denne grunnlinjen. Data: [historisk metrikk]

3) Kapasitetsprojeksjon (med rekkevidde):

Nedenfor er de siste 8 ukene med beleggsdata for [ressurs]. (1) Beregn den ukentlige gjennomsnittlige vekstraten, (2) angi sesongmessige effekter, (3) estimer tiden for å nå 90 %-terskelen ved gjeldende hastighet, med OPTIMISTISKE og PESIMISTISKE områder. Angi en enkelt dato, gi en rekkevidde og skriv ned dine antakelser. Data: [tidsserie]

4) Alarmterskelanbefaling:

Min grunnlinje for [metrisk] er [område]. Målet mitt er å minimere falske alarmer uten å gå glipp av reelle problemer. Gi meg en anbefaling for (1) advarsel og (2) kritisk terskel, begrunn hver enkelt og vurder risikoen for alarmtretthet. Jeg vil bestemme den endelige terskelen.

Svak forespørsel / Sterk forespørsel

Svak melding:

Er serveren min treg?

Det er ingen kontekst, ingen beregninger og ingen grunnlinje. AI kjenner verken definisjonen av "sakte" eller har en normal verdi å sammenligne den med. Svaret er en tom gjetning.

Kraftig ledetekst:

Din rolle: spesialist i kapasitetsplanlegging. Nedenfor er de siste 14 dagene med p95-svartid og forespørsler/sekunddata fra en API (maskert). Min grunnlinje er 250-400 ms for p95. Fortell meg (1) marker dagene som gikk ut av baseline de siste 14 dagene, (2) fortell meg om det er en synlig sammenheng mellom responstid og forespørselsbelastning (som en hypotese), (3) forutsi hvor p95 vil gå om 30 dager hvis denne trenden fortsetter. Data: [tidsserie]

Metrisk type

feil måling

nøyaktig måling

responstid

Bare gjennomsnittlig

s50, s95, s99

CPU/minne

øyeblikkelig verdi

Topp + vedvarende + grunnlinje

skivevekst

Dagens belegg

Ukentlig trend + anslag

Anomali

enkelt sprett

Kontinuerlig avvik fra baseline

alarm

Vilkårlig enkelt terskel

Begrunnet advarsel + kritisk terskel

Vanlige feil

• Måler alt med et gjennomsnitt. Gjennomsnittet skjuler den dårlige opplevelsen til de få; Se prosentil.
• Søker etter anomalier uten grunnlinje. Du kan ikke si at en verdi er unormal uten å vite hva som er normalt; Du oppretter en falsk alarm.
• Misforstå sesongmessighet for en trend. Å behandle kampanjetoppen som permanent vekst og ta unødvendige ressurser koster penger.
• Stoler på oddetallsprojeksjon. "Nøyaktig 19 dager" er falsk presisjon; Bruk det optimistisk-pessimistiske området.
• Glemmer innkjøpstid. Teamet som ikke vurderer projeksjonsterskel og kjøpstid sammen vil bli fanget i avbruddet.

Forsiktig: AIs trendprojeksjon antar at fortiden vil fortsette inn i fremtiden. En ny produktlansering, en kundemigrering eller en arkitektonisk endring forstyrrer denne antagelsen. Det er din jobb å korrigere projeksjonen med konteksten din.

Oppsummert

Ytelsesovervåking svarer på spørsmålet "er det bra nå?" og kapasitetsplanlegging svarer på spørsmålet "når er det ikke nok?" AI er en sterk partner i å tolke beregninger, etablere grunnlinjer, flagge anomalier og projisere trender. Men gjennomsnittet ligger - bruk persentil; Uten baseline er det ingen anomali - etablere det normale først; skille sesongvariasjoner fra trend; og ta projeksjonen som et område, ikke et enkelt tall. Beslutninger om ressursinvesteringer og varslingsterskel er menneskelige, sammen med ressursens ledetid og forretningskontekst.

Søknadsoppgave

Ta de siste ukene med data for en ressurs (disk, minne, responstid) fra dine egne systemer og masker sensitive områder. Trekk fra normalområdet og mønsteret med malen "Baseline subtraksjon" ovenfor. La deretter malen "Kapasitetsprojeksjon" forutsi når du vil nå en terskel, med et optimistisk-pessimistisk område. Få også responstidsberegningen din tolket ved å bruke "persentil"-malen og se om det er noe gjennomsnittet skjuler. Skriv ned funnene dine og handlingen du vil ta i 5 elementer.

sjekkliste

• [ ] Så jeg på p95/p99 i stedet for gjennomsnittlig responstid?
• [ ] Har jeg etablert en baseline fra sunne data før jeg ser etter uregelmessigheter?
• [ ] Har jeg skilt sesongmessige svingninger fra permanente trender?
• [ ] Tok jeg anslaget som en optimistisk-pessimistisk rekkevidde i stedet for en enkelt dato?
• [ ] Har jeg evaluert innkjøpstiden sammen med projeksjonsterskelen?
• [ ] Har jeg satt alarmterskelen basert på min egen risikotoleranse og ikke en AI-anbefaling?