Cum ai planifica o creștere de zece ori a utilizatorilor ca lider tehnic?

Question

IT Interview Practice · Accepted Answer

Ca tech lead, aș transforma mai întâi **„de zece ori mai mulți utilizatori” în utilizare estimată, obiective de serviciu și un plan pe care echipa îl poate livra**. Numărul conturilor înregistrate nu spune singur câte cereri sosesc în momentul cel mai aglomerat.

Să presupunem că firma planifică o campanie pentru o platformă de comenzi. Întrebarea este dacă clienții mai pot naviga, cumpăra și primi confirmarea în timpul campaniei, în limita timpului și bugetului disponibile.

## 1. Tradu creșterea în sarcină de lucru

Întreabă echipa de produs când vor veni utilizatorii și ce acțiuni vor efectua. O creștere graduală pe durata unui an diferă de o campanie care aduce pe toată lumea online simultan.

Ca exemplu, 100.000 de conturi înregistrate, cu 1% active simultan, înseamnă 1.000 de utilizatori concurenți. La 5%, sunt 5.000. Acestea sunt ipoteze ilustrative, nu proporții implicite. Frecvența cererilor și munca fiecărei cereri trebuie estimate separat.

Enumeră sarcina creată de campanie:

- Cereri de navigare și căutare, inclusiv pentru produse populare.
- Scrieri de comenzi și plăți la orele de vârf.
- Creșterea stocării și a istoricului păstrat.
- Muncă în fundal, precum notificări și rapoarte.

Astfel obținem sarcini testabile, în locul unei instrucțiuni vagi de a înmulți numărul serverelor cu zece.

## 2. Stabiliți ce trebuie să funcționeze în continuare bine

Definește timpul de răspuns, rata erorilor și finalizarea acceptabile pentru parcursurile critice. Definește și actualitatea datelor și așteptările de recuperare unde contează. Un raport întârziat poate fi acceptabil, dar o cumpărare eșuată nu.

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

Obiectivele leagă munca tehnică de rezultatele clienților. Ele permit stabilirea faptului că o îmbunătățire este suficientă și a degradării tolerabile sub presiune.

## 3. Măsoară limita actuală înainte de alegerea schimbărilor

Folosește observații din producție și teste de sarcină reprezentative. Inspectează interogările lente, conexiunile bazei de date, CPU, memoria, vechimea joburilor din coadă și cotele serviciilor externe. Include trafic neuniform către produse populare, nu doar cereri aleatoare.

Dacă limita o reprezintă conexiunile bazei de date, adăugarea nodurilor aplicației poate crește concurența pentru resurse. Dacă limita este cota furnizorului de plăți, o aplicație mai rapidă nu mărește acea cotă.

Testează cache-uri goale și pierderea unei instanțe, pe lângă funcționarea normală. Avem nevoie de capacitate de recuperare în campanie, nu doar de suficientă capacitate pentru un test ideal.

## 4. Transformă constatările în sarcini cu responsabili

| Constatare | Acțiune posibilă | Dovadă necesară |
| --- | --- | --- |
| Citiri costisitoare repetate | Îmbunătățește interogarea sau pune în cache rezultatele potrivite | Mai puțină muncă în bază, cu actualitate acceptabilă. |
| Sarcinile din fundal concurează cu cumpărăturile | Limitează sau separă capacitatea lor | Finalizarea cumpărăturilor rămâne sănătoasă sub sarcină de fundal. |
| Cota unei dependențe este insuficientă | Negociază creșterea sau controlează admiterea cererilor | Cotă confirmată și comportament testat la limită. |
| Capacitatea rămâne insuficientă după remedieri mici | Evaluează scalarea sau o schimbare mai mare de design | Beneficiu măsurat, plan de migrare și cost. |

Alocă fiecărei acțiuni un responsabil, buget, dependențe, termen și test de acceptanță. Include lansarea, instruirea operațională și pregătirea de gardă, nu doar implementarea.

Prioritizează după efectul asupra clienților și riscul livrării. O rescriere majoră sau un proiect de sharding necesită un motiv demonstrat și timp suficient pentru migrare și verificare.

## 5. Repetă scenariul campaniei și crește traficul gradual

Lansează modificările în pași controlabili și testează împreună parcursurile așteptate. Definește când crești traficul, oprești creșterea sau revii la versiunea anterioară. Schimbările formatului datelor pot necesita recuperare înainte, nu simplă revenire.

Pregătește degradarea controlată: amână exporturile opționale, limitează munca din fundal sau respinge cererile în exces, păstrând operațiile critice. Verifică dacă aceste măsuri reduc efectiv sarcina și dacă clienții primesc un rezultat clar.

Dacă obiectivul nu încape în termen sau buget, prezintă produsului opțiuni concrete: etapizarea atragerii utilizatorilor, reducerea unei funcții costisitoare sau finanțarea limitării măsurate. Explică efectul asupra clienților și incertitudinea fiecărei opțiuni.

**De reținut:** ipoteze de creștere → obiective de serviciu → limite măsurate → plan cu responsabili → lansare repetată în avans. Tech leadul livrează un plan de capacitate care include oameni, bani și recuperare.

Constatare	Acțiune posibilă	Dovadă necesară
Citiri costisitoare repetate	Îmbunătățește interogarea sau pune în cache rezultatele potrivite	Mai puțină muncă în bază, cu actualitate acceptabilă.
Sarcinile din fundal concurează cu cumpărăturile	Limitează sau separă capacitatea lor	Finalizarea cumpărăturilor rămâne sănătoasă sub sarcină de fundal.
Cota unei dependențe este insuficientă	Negociază creșterea sau controlează admiterea cererilor	Cotă confirmată și comportament testat la limită.
Capacitatea rămâne insuficientă după remedieri mici	Evaluează scalarea sau o schimbare mai mare de design	Beneficiu măsurat, plan de migrare și cost.

1. Tradu creșterea în sarcină de lucru

2. Stabiliți ce trebuie să funcționeze în continuare bine

3. Măsoară limita actuală înainte de alegerea schimbărilor

4. Transformă constatările în sarcini cu responsabili

5. Repetă scenariul campaniei și crește traficul gradual

Întrebări conexe