Hur skulle du som teknisk ledare planera för tio gånger fler användare?

Question

IT Interview Practice · Accepted Answer

Som tech lead skulle jag först omvandla **”tio gånger fler användare” till förväntad användning, tjänstemål och en plan teamet kan leverera**. Antalet registrerade konton säger inte ensamt hur många anrop som kommer vid högsta belastning.

Anta att verksamheten planerar en kampanj för en orderplattform. Frågan är om kunder fortfarande kan bläddra, köpa och få bekräftelse under kampanjen, inom tillgänglig tid och budget.

## 1. Översätt tillväxt till arbetsbelastning

Fråga produktansvariga när användarna kommer och vad de ska göra. En gradvis ökning under ett år skiljer sig från en kampanj där alla kommer online samtidigt.

Som illustration ger 100 000 registrerade konton med 1 % samtidigt aktiva 1 000 samtidiga användare. Med 5 % blir det 5 000. Det är exempelantaganden, inte standardandelar. Anropsfrekvens och arbete per anrop måste fortfarande uppskattas.

Lista belastningen som kampanjen skapar:

- Bläddring och sökning, inklusive populära produkter.
- Order- och betalningsskrivningar vid belastningstoppar.
- Växande lagring och sparad historik.
- Bakgrundsarbete som aviseringar och rapporter.

Det ger testbara arbetsbelastningar i stället för en vag instruktion att tiodubbla antalet servrar.

## 2. Enas om vad som måste fungera bra

Definiera acceptabel svarstid, felfrekvens och slutförande för kritiska användarflöden. Definiera även dataaktualitet och återställningsförväntningar där de spelar roll. En försenad rapport kan vara acceptabel medan ett misslyckat köp inte är det.

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

Målen kopplar tekniskt arbete till kundresultat. De hjälper oss avgöra när en förbättring räcker och vilken försämring som kan tolereras under press.

## 3. Mät den nuvarande gränsen innan ändringar väljs

Använd produktionsobservationer och representativa belastningstester. Granska långsamma frågor, databasanslutningar, CPU, minne, köålder och externa tjänsters kvoter. Ta med ojämn trafik till populära objekt i stället för bara slumpmässiga anrop.

Om databasanslutningar är gränsen kan fler applikationsnoder öka konkurrensen. Om betalningsleverantörens kvot är gränsen höjer en snabbare applikation inte kvoten.

Testa kalla cacher och bortfall av en instans, liksom normal drift. Vi behöver kapacitet för återhämtning under kampanjen, inte bara för en idealisk testkörning.

## 4. Gör fynden till arbete med tydligt ansvar

| Fynd | Möjlig åtgärd | Nödvändigt belägg |
| --- | --- | --- |
| Upprepade dyra läsningar | Förbättra frågan eller cacha lämpliga resultat | Mindre databasarbete med acceptabel aktualitet. |
| Bakgrundsuppgifter konkurrerar med köp | Begränsa eller separera deras kapacitet | Kassaflödet fungerar under bakgrundsbelastning. |
| Ett beroendes kvot är otillräcklig | Ordna högre kvot eller begränsa insläpp | Bekräftad kvot och testat beteende vid gränsen. |
| Kapaciteten är otillräcklig efter mindre förbättringar | Utvärdera skalning eller större designändring | Uppmätt nytta, migreringsplan och kostnad. |

Ge varje åtgärd ansvarig, budget, beroenden, slutdatum och acceptanstest. Ta med driftsättning, driftutbildning och jourförberedelser, inte bara implementation.

Prioritera efter kundpåverkan och leveransrisk. En stor omskrivning eller sharding kräver ett påvisat skäl och tillräcklig tid för migrering och verifiering.

## 5. Öva kampanjen och öka trafiken gradvis

Släpp ändringar i hanterbara steg och testa de förväntade flödena tillsammans. Definiera när trafiken ska ökas, ökningen pausas eller ändringen rullas tillbaka. Dataformatsändringar kan kräva återställning framåt i stället för enkel rollback.

Förbered kontrollerad försämring: senarelägg valfria exporter, begränsa bakgrundsarbete eller avvisa överflödiga anrop samtidigt som kritiska operationer bevaras. Kontrollera att åtgärderna verkligen minskar belastningen och ger kunderna tydliga besked.

Om målet inte ryms inom datum eller budget, ge produktansvariga konkreta alternativ: etappvis kundanskaffning, minskning av en dyr funktion eller finansiering av den uppmätta flaskhalsen. Förklara kundpåverkan och osäkerheten i varje alternativ.

**Kom ihåg:** tillväxtantaganden → tjänstemål → uppmätta gränser → färdplan med ansvar → övad utrullning. Tech lead levererar en kapacitetsplan som inkluderar människor, pengar och återställning.

Fynd	Möjlig åtgärd	Nödvändigt belägg
Upprepade dyra läsningar	Förbättra frågan eller cacha lämpliga resultat	Mindre databasarbete med acceptabel aktualitet.
Bakgrundsuppgifter konkurrerar med köp	Begränsa eller separera deras kapacitet	Kassaflödet fungerar under bakgrundsbelastning.
Ett beroendes kvot är otillräcklig	Ordna högre kvot eller begränsa insläpp	Bekräftad kvot och testat beteende vid gränsen.
Kapaciteten är otillräcklig efter mindre förbättringar	Utvärdera skalning eller större designändring	Uppmätt nytta, migreringsplan och kostnad.

1. Översätt tillväxt till arbetsbelastning

2. Enas om vad som måste fungera bra

3. Mät den nuvarande gränsen innan ändringar väljs

4. Gör fynden till arbete med tydligt ansvar

5. Öva kampanjen och öka trafiken gradvis

Relaterade frågor