Kama kiongozi wa kiufundi, utapangaje ongezeko la watumiaji mara kumi?

Question

IT Interview Practice · Accepted Answer

Kama tech lead, kwanza ningebadilisha **“watumiaji mara kumi zaidi” kuwa matumizi yanayotarajiwa, malengo ya huduma na mpango ambao timu inaweza kutekeleza**. Akaunti zilizosajiliwa pekee hazituambii requests zinazofika wakati wa kilele.

Tuseme biashara inapanga kampeni ya jukwaa la oda. Swali ni kama wateja wanaweza bado kuvinjari, kununua na kupokea uthibitisho wakati wa kampeni, ndani ya muda na bajeti iliyopo.

## 1. Geuza ukuaji kuwa mzigo wa kazi

Uliza product watumiaji watafika lini na watafanya vitendo gani. Ongezeko la taratibu kwa mwaka linatofautiana na kampeni inayowaleta wote online pamoja.

Kwa mfano, akaunti 100,000 zilizosajiliwa zikiwa na 1% active kwa wakati mmoja ni watumiaji 1,000 concurrent. Kwa 5% ni 5,000. Haya ni mawazo ya mfano, si uwiano wa kawaida. Marudio ya requests na kazi kwa kila request bado vinahitaji kukadiriwa.

Orodhesha mzigo ambao kampeni huleta:

- Requests za kuvinjari na search, zikiwemo bidhaa maarufu.
- Uandishi wa oda na malipo wakati wa kilele.
- Hifadhi inayokua na historia inayohifadhiwa.
- Kazi za background kama notifications na ripoti.

Hii hutupa mizigo ya kujaribu badala ya agizo lisilo wazi la kuzidisha servers mara kumi.

## 2. Kubalianeni kinachopaswa kubaki kizuri

Fafanua muda wa majibu, kiwango cha makosa na ukamilishaji unaokubalika kwa safari muhimu. Fafanua pia upya wa data na matarajio ya urejeshaji yanapohusika. Ripoti kuchelewa inaweza kukubalika wakati checkout kushindwa haikubaliki.

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

Malengo yanaunganisha kazi ya kiufundi na matokeo ya wateja. Yanatusaidia kuamua kama uboreshaji unatosha na upungufu upi unaweza kuvumiliwa chini ya shinikizo.

## 3. Pima kikomo cha sasa kabla ya kuchagua mabadiliko

Tumia uchunguzi wa production na load tests wakilishi. Kagua slow queries, database connections, CPU, memory, umri wa queue na quotas za huduma za nje. Jumuisha traffic isiyo sawa kwa bidhaa maarufu badala ya random requests pekee.

Ikiwa database connections ndizo kikomo, kuongeza application nodes kunaweza kuongeza ushindani. Ikiwa quota ya payment provider ndiyo kikomo, programu ya haraka haiiongezi quota hiyo.

Jaribu cold caches na kupotea kwa instance pamoja na hali ya kawaida. Tunahitaji uwezo wa kupona wakati wa kampeni, si wa test run bora pekee.

## 4. Geuza matokeo kuwa kazi zenye watu wanaowajibika

| Kilichogunduliwa | Hatua inayowezekana | Ushahidi unaohitajika |
| --- | --- | --- |
| Usomaji ghali unaorudiwa | Boresha query au cache matokeo yanayofaa | Kazi ndogo ya database yenye upya unaokubalika. |
| Kazi za background zinashindana na manunuzi | Punguza au tenganisha uwezo wake | Checkout inaendelea vizuri chini ya background load. |
| Quota ya dependency haitoshi | Panga ongezeko au dhibiti admission | Quota iliyothibitishwa na tabia iliyojaribiwa kwenye kikomo. |
| Uwezo wa sasa hautoshi baada ya marekebisho madogo | Tathmini scaling au badiliko kubwa la design | Faida iliyopimwa, mpango wa migration na gharama. |

Ipe kila hatua mtu anayewajibika, bajeti, dependencies, tarehe ya mwisho na acceptance test. Jumuisha deployment, mafunzo ya uendeshaji na maandalizi ya on-call, si implementation tu.

Panga kipaumbele kwa athari kwa mteja na hatari ya delivery. Rewrite kubwa au sharding inahitaji sababu iliyothibitishwa na muda wa kutosha wa migration na verification.

## 5. Fanya mazoezi ya kampeni na ongeza traffic hatua kwa hatua

Toa mabadiliko kwa hatua zinazodhibitika na jaribu safari zinazotarajiwa pamoja. Fafanua lini kupanua traffic, kusitisha upanuzi au kufanya rollback. Mabadiliko ya data format yanaweza kuhitaji forward recovery badala ya rollback rahisi.

Andaa upunguzaji unaodhibitiwa: chelewesha exports za hiari, weka kikomo cha background work au kataa requests zinazozidi huku ukihifadhi operations muhimu. Hakiki vidhibiti hivi vinapunguza mzigo kweli na wateja wanapata matokeo yaliyo wazi.

Ikiwa lengo haliendani na tarehe au bajeti, mpe product chaguo mahususi: leta watumiaji kwa awamu, punguza kipengele ghali au lipia kikwazo kilichopimwa. Eleza athari kwa wateja na kutokuwa na uhakika kwa kila chaguo.

**Kumbuka:** mawazo ya ukuaji → malengo ya huduma → mipaka iliyopimwa → roadmap yenye watu wanaowajibika → rollout iliyofanyiwa mazoezi. Tech lead hutoa mpango wa uwezo unaojumuisha watu, fedha na urejeshaji.

Usomaji ghali unaorudiwa	Boresha query au cache matokeo yanayofaa	Kazi ndogo ya database yenye upya unaokubalika.
Kazi za background zinashindana na manunuzi	Punguza au tenganisha uwezo wake	Checkout inaendelea vizuri chini ya background load.
Quota ya dependency haitoshi	Panga ongezeko au dhibiti admission	Quota iliyothibitishwa na tabia iliyojaribiwa kwenye kikomo.
Uwezo wa sasa hautoshi baada ya marekebisho madogo	Tathmini scaling au badiliko kubwa la design	Faida iliyopimwa, mpango wa migration na gharama.

1. Geuza ukuaji kuwa mzigo wa kazi

2. Kubalianeni kinachopaswa kubaki kizuri

3. Pima kikomo cha sasa kabla ya kuchagua mabadiliko

4. Geuza matokeo kuwa kazi zenye watu wanaowajibika

5. Fanya mazoezi ya kampeni na ongeza traffic hatua kwa hatua

Maswali yanayohusiana