Hvordan ville du som teknisk leder planlagt tidobling av antall brukere?

Question

IT Interview Practice · Accepted Answer

Som tech lead ville jeg først gjort **«ti ganger flere brukere» om til forventet bruk, tjenestemål og en plan teamet kan levere**. Registrerte kontoer alene sier ikke hvor mange forespørsler som kommer på det travleste tidspunktet.

Anta at virksomheten planlegger en kampanje for en ordreplattform. Spørsmålet er om kunder fortsatt kan se på varer, kjøpe og få bekreftelse under kampanjen, innenfor tilgjengelig tid og budsjett.

## 1. Oversett vekst til arbeidsbelastning

Spør produktteamet når brukerne kommer, og hvilke handlinger de vil utføre. Gradvis vekst gjennom et år er annerledes enn en kampanje som får alle på nett samtidig.

Som eksempel gir 100 000 registrerte kontoer med 1 % aktive samtidig 1 000 samtidige brukere. Med 5 % blir det 5 000. Dette er eksempelantakelser, ikke standardforhold. Forespørselsfrekvens og arbeid per forespørsel må fortsatt anslås.

List opp belastningen kampanjen skaper:

- Navigasjon og søk, inkludert populære produkter.
- Ordre- og betalingsskriving ved trafikktopper.
- Økende lagring og beholdt historikk.
- Bakgrunnsarbeid som varsler og rapporter.

Dette gir konkrete belastninger å teste fremfor en vag beskjed om å tidoble antallet servere.

## 2. Avtal hva som må forbli bra

Definer akseptabel svartid, feilrate og fullføring for kritiske brukerreiser. Definer også dataferskhet og forventninger til gjenoppretting der det er viktig. En forsinket rapport kan være akseptabel, mens en feilet betaling ikke er det.

```text
[Campaign assumptions] -> [Expected workload] -> [Service targets]
                                                   |
                                            [Acceptance tests]
```

Målene knytter teknisk arbeid til kundens resultat. De hjelper oss å avgjøre om en forbedring er tilstrekkelig, og hvilken svekkelse som kan tolereres under press.

## 3. Mål dagens grense før endringer velges

Bruk produksjonsobservasjoner og representative belastningstester. Undersøk trege spørringer, databaseforbindelser, CPU, minne, køalder og eksterne tjenestekvoter. Ta med skjev trafikk mot populære varer, ikke bare tilfeldige forespørsler.

Hvis databaseforbindelser er grensen, kan flere applikasjonsnoder øke konkurransen. Hvis betalingsleverandørens kvote er grensen, øker ikke en raskere applikasjon kvoten.

Test kalde cacher og tap av en instans i tillegg til normal drift. Vi trenger kapasitet til å hente oss inn under kampanjen, ikke bare nok til en ideell test.

## 4. Gjør funn om til arbeid med eierskap

| Funn | Mulig tiltak | Nødvendig bevis |
| --- | --- | --- |
| Gjentatte kostbare lesinger | Forbedre spørringen eller cache egnede resultater | Mindre databasearbeid med akseptabel ferskhet. |
| Bakgrunnsoppgaver konkurrerer med kjøp | Begrens eller skill kapasiteten | Utsjekking fungerer godt under bakgrunnsbelastning. |
| En avhengighetskvote er for lav | Avtal økning eller kontroller inntak | Bekreftet kvote og testet atferd ved grensen. |
| Kapasiteten er fortsatt for lav etter mindre tiltak | Vurder skalering eller større designendring | Målt effekt, migreringsplan og kostnad. |

Gi hvert tiltak en eier, budsjett, avhengigheter, frist og akseptansetest. Inkluder utrulling, driftsopplæring og vaktberedskap, ikke bare implementering.

Prioriter etter kundepåvirkning og leveranserisiko. En stor omskriving eller sharding krever en påvist grunn og nok tid til migrering og verifisering.

## 5. Øv på kampanjen og øk trafikken gradvis

Lever endringer i håndterbare trinn og test forventede brukerreiser sammen. Definer når trafikken skal økes, økningen pauses eller endringer rulles tilbake. Dataformatendringer kan kreve fremoverrettet gjenoppretting i stedet for enkel tilbakeføring.

Forbered kontrollert nedgradering: utsett valgfrie eksporter, begrens bakgrunnsarbeid eller avvis overskytende forespørsler mens kritiske operasjoner beskyttes. Kontroller at tiltakene faktisk reduserer belastningen, og at kunden får et tydelig resultat.

Hvis målet ikke passer dato eller budsjett, presenter konkrete alternativer for produktteamet: trinnvis brukerinnslipp, reduksjon av en dyr funksjon eller finansiering av den målte flaskehalsen. Forklar kundepåvirkning og usikkerhet ved hvert alternativ.

**Husk:** vekstantakelser → tjenestemål → målte grenser → plan med eiere → innøvd utrulling. Tech lead leverer en kapasitetsplan som inkluderer mennesker, penger og gjenoppretting.

Funn	Mulig tiltak	Nødvendig bevis
Gjentatte kostbare lesinger	Forbedre spørringen eller cache egnede resultater	Mindre databasearbeid med akseptabel ferskhet.
Bakgrunnsoppgaver konkurrerer med kjøp	Begrens eller skill kapasiteten	Utsjekking fungerer godt under bakgrunnsbelastning.
En avhengighetskvote er for lav	Avtal økning eller kontroller inntak	Bekreftet kvote og testet atferd ved grensen.
Kapasiteten er fortsatt for lav etter mindre tiltak	Vurder skalering eller større designendring	Målt effekt, migreringsplan og kostnad.

1. Oversett vekst til arbeidsbelastning

2. Avtal hva som må forbli bra

3. Mål dagens grense før endringer velges

4. Gjør funn om til arbeid med eierskap

5. Øv på kampanjen og øk trafikken gradvis

Relaterte spørsmål