Si do ta planifikoje rritjen dhjetëfish të përdoruesve si drejtues teknik?

Question

IT Interview Practice · Accepted Answer

Si drejtues teknik, fillimisht do ta ktheja **“dhjetë herë më shumë përdorues” në përdorim të pritshëm, objektiva shërbimi dhe plan që ekipi mund ta realizojë**. Vetëm llogaritë e regjistruara nuk tregojnë sa kërkesa mbërrijnë në çastin më të ngarkuar.

Supozoni se biznesi planifikon një fushatë për një platformë porosish. Pyetja është nëse klientët ende mund të shfletojnë, blejnë dhe marrin konfirmim gjatë fushatës, brenda kohës dhe buxhetit të disponueshëm.

## 1. Kthejeni rritjen në ngarkesë pune

Pyesni ekipin e produktit kur do të vijnë përdoruesit dhe cilat veprime do të kryejnë. Rritja graduale gjatë një viti ndryshon nga fushata që i sjell të gjithë online njëherësh.

Për ilustrim, 100.000 llogari të regjistruara me 1% aktive njëkohësisht nënkuptojnë 1.000 përdorues të njëkohshëm. Me 5% janë 5.000. Këto janë supozime shembull, jo raporte standarde. Ende duhet vlerësuar shpeshtësia e kërkesave dhe puna për çdo kërkesë.

Renditni ngarkesën që krijon fushata:

- Kërkesat për shfletim dhe kërkim, përfshirë produktet popullore.
- Shkrimet e porosive dhe pagesave në orët e pikut.
- Rritjen e ruajtjes dhe historikut të mbajtur.
- Punën në sfond, si njoftimet dhe raportet.

Kjo na jep ngarkesa për t’u testuar, në vend të një udhëzimi të paqartë për ta shumëzuar numrin e serverëve me dhjetë.

## 2. Bini dakord çfarë duhet të mbetet në nivel të mirë

Përcaktoni kohën e pranueshme të përgjigjes, shkallën e gabimeve dhe përfundimin e rrjedhave kritike. Përcaktoni edhe freskinë e të dhënave dhe pritjet e rikuperimit aty ku kanë rëndësi. Një raport i vonuar mund të pranohet, ndërsa një blerje e dështuar jo.

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

Objektivat lidhin punën teknike me rezultatet për klientin. Ato lejojnë të vendosim nëse përmirësimi mjafton dhe cilën ulje shërbimi mund ta tolerojmë nën presion.

## 3. Matni kufirin aktual përpara zgjedhjes së ndryshimeve

Përdorni vëzhgimet nga prodhimi dhe teste përfaqësuese ngarkese. Kontrolloni query-t e ngadalta, lidhjet e databazës, CPU-në, memorien, moshën e punëve në radhë dhe kuotat e shërbimeve të jashtme. Përfshini trafik të pabarabartë drejt artikujve popullorë, jo vetëm kërkesa të rastësishme.

Nëse kufiri janë lidhjet e databazës, shtimi i nyjeve të aplikacionit mund të rrisë konkurrimin për burime. Nëse kufiri është kuota e ofruesit të pagesave, një aplikacion më i shpejtë nuk e rrit atë kuotë.

Testoni cache të ftohta dhe humbjen e një instance krahas funksionimit normal. Na duhet kapacitet për rikuperim gjatë fushatës, jo thjesht mjaftueshëm për një test ideal.

## 4. Kthejini gjetjet në punë me përgjegjës

| Gjetja | Veprimi kandidat | Prova e kërkuar |
| --- | --- | --- |
| Lexime të kushtueshme të përsëritura | Përmirësoni query-n ose ruani rezultatet e përshtatshme në cache | Më pak punë në databazë me freski të pranueshme. |
| Detyrat në sfond konkurrojnë me blerjet | Kufizoni ose ndani kapacitetin e tyre | Blerja mbetet e shëndetshme gjatë ngarkesës në sfond. |
| Kuota e një varësie nuk mjafton | Siguroni rritje ose kontrolloni pranimin | Kuotë e konfirmuar dhe sjellje e testuar në kufi. |
| Kapaciteti ende nuk mjafton pas rregullimeve më të vogla | Vlerësoni shkallëzimin ose ndryshim më të madh projektimi | Përfitim i matur, plan migrimi dhe kosto. |

Jepini çdo veprimi një përgjegjës, buxhet, varësi, afat dhe test pranimi. Përfshini vendosjen, trajnimin operacional dhe përgatitjen e shërbimit të gatishmërisë, jo vetëm zbatimin.

Jepni përparësi sipas ndikimit te klienti dhe rrezikut të realizimit. Një rishkrim i madh ose projekt sharding kërkon arsye të provuar dhe kohë të mjaftueshme për migrim e verifikim.

## 5. Bëni provë të fushatës dhe rriteni trafikun gradualisht

Publikoni ndryshimet në hapa të menaxhueshëm dhe testoni së bashku rrjedhat e pritshme. Përcaktoni kur të rritni trafikun, të ndaloni rritjen ose të riktheheni pas. Ndryshimet e formatit të të dhënave mund të kërkojnë rikuperim duke korrigjuar përpara, jo thjesht rikthim te versioni i mëparshëm.

Përgatitni ulje të kontrolluar shërbimi: shtyni eksportet opsionale, kufizoni punën në sfond ose refuzoni kërkesat e tepërta duke ruajtur operacionet kritike. Kontrolloni që këto masa vërtet ulin ngarkesën dhe klientët marrin rezultat të qartë.

Nëse objektivi nuk përshtatet me afatin ose buxhetin, paraqitini ekipit të produktit mundësi konkrete: sillni përdoruesit me faza, zvogëloni një veçori të kushtueshme ose financoni pengesën e matur. Shpjegoni ndikimin te klientët dhe pasigurinë e secilës mundësi.

**Mbani mend:** supozimet e rritjes → objektivat e shërbimit → kufijtë e matur → plani me përgjegjës → publikimi i provuar. Drejtuesi teknik dorëzon një plan kapaciteti që përfshin njerëzit, paratë dhe rikuperimin.

Gjetja	Veprimi kandidat	Prova e kërkuar
Lexime të kushtueshme të përsëritura	Përmirësoni query-n ose ruani rezultatet e përshtatshme në cache	Më pak punë në databazë me freski të pranueshme.
Detyrat në sfond konkurrojnë me blerjet	Kufizoni ose ndani kapacitetin e tyre	Blerja mbetet e shëndetshme gjatë ngarkesës në sfond.
Kuota e një varësie nuk mjafton	Siguroni rritje ose kontrolloni pranimin	Kuotë e konfirmuar dhe sjellje e testuar në kufi.
Kapaciteti ende nuk mjafton pas rregullimeve më të vogla	Vlerësoni shkallëzimin ose ndryshim më të madh projektimi	Përfitim i matur, plan migrimi dhe kosto.

1. Kthejeni rritjen në ngarkesë pune

2. Bini dakord çfarë duhet të mbetet në nivel të mirë

3. Matni kufirin aktual përpara zgjedhjes së ndryshimeve

4. Kthejini gjetjet në punë me përgjegjës

5. Bëni provë të fushatës dhe rriteni trafikun gradualisht

Pyetje të ngjashme