Bayyana mafi munin matsalar production da ka fuskanta da mintuna 30 na farko.

Question

IT Interview Practice · Accepted Answer

**Amsa mai ƙarfi tana nuna yadda ka rage cutarwa ga customers, ka yanke shawara da bayanai marasa cika, kuma ka hana maimaita matsalar.** Bayyana naka aikin sosai maimakon ɗaukar duk aikin team a matsayin naka.

Yi amfani da incident da ka gani da gaske. Misalin da ke ƙasa ƙagagge ne don nuna tsarin amsa; maye gurbinsa da ayyukanka da verified results a interview. Lokutan misali ne, ba deadline na kowane incident ba.

## 1. Bayyana yanayin da alhakinka

A ce ni ne on-call backend lead lokacin da checkout failures suka ƙaru bayan release. Customers suna iya browsing amma wasu ba za su iya kammala oda ba. A wannan lokaci, kusancin lokutan ya sa release ya zama hypothesis, ba proven cause ba.

Zan bayyana alhakina: daidaita technical recovery, raba investigation da sanar da incident lead. Idan ni ne incident lead ma, zan faɗi hakan kuma in ba wani communication ko hands-on investigation don kada in zama bottleneck.

## 2. Minti biyar na farko: tabbatar da impact kuma tsara response

Duba checkout errors, latency da successful orders don sanin waɗanda abin ya shafa da ko matsalar tana nan. Buɗe incident channel ɗaya, raba responsibilities, dakatar da unrelated changes kuma fara timeline na observations da actions.

Dalilin wannan tsari na aiki ne: mutane da yawa suna canji daban-daban za su iya ɓoye cause ko ƙara matsalar. Update ya bambanta confirmed facts da hypotheses kuma ya bayyana lokacin update na gaba. Duba [jagorar incident response ta Google](https://sre.google/workbook/incident-response/).

## 3. Minti goma na gaba: zaɓi hanyar rage cutarwa cikin aminci

A ce bincike ya nuna database connections sun cika kuma release ya kawo reporting path mai tsada. Zan kwatanta rollback da kashe wannan path na ɗan lokaci tare da barin checkout yana aiki.

- Duba ko rollback ya dace da schema ko data changes da aka riga aka yi. Tsohon application version ba ya zama safe da database na yanzu kai tsaye.
- Idan tested switch zai iya kashe optional reporting, yi amfani da shi don rage load kuma a duba ko checkout ya inganta.
- Sanya wani ya binciki connection pressure yayin da wani yake tabbatar da recovery path, don investigation ya ci gaba ba tare da jinkirta reasonable mitigation ba.

Shawarar ta bi available evidence da reversibility. Ba zan jira cikakken tabbacin root cause ba yayin da customers suke a toshe, amma zan rubuta dalilin da aka sa ran action zai taimaka.

## 4. Zuwa minti talatin: tabbatar da useful service ta dawo

Faɗuwar CPU graph ba ta isa ba. Tabbatar real checkout attempts suna nasara, latency ta dawo iyakar da aka yarda da ita, kuma queued work yana raguwa ba tare da ƙirƙirar sabon pressure ba. Lura da system bayan mitigation maimakon sanar da recovery bayan request ɗaya.

Ga payment outcomes marasa tabbas, reconcile da payment system kafin retry charges. Timeout zai iya ɓoye payment da ya kammala. Faɗi abin da ya dawo, abin da bai tabbata ba da abin da customers za su yi, ba tare da ƙirƙirar recovery time da babu evidence ba.

## 5. Bayan recovery: sauya yanayin da ya ba failure dama

A wannan ƙagaggen misali, bincike zai iya nuna reporting da checkout suna raba connection budget kuma reports ba su da effective work limit. Follow-up ya magance wannan mechanism maimakon ƙarewa da “a ƙara hankali”.

- Takaita report work da concurrency don feature ɗaya kada ta cinye duk shared resource.
- Tantance resource isolation inda ya dace kuma gwada reporting tare da checkout ƙarƙashin representative load.
- Yi alert kan checkout success da latency, kuma a yi rehearsal na mitigation ko rollback procedure.
- Ba wa kowane corrective action owner, deadline da hanyar tabbatar da completion.

A real interview, rufe da actual recovery result da evidence daga follow-up tests ko aiki daga baya. Idan ba a tattara measurement ba, faɗi hakan maimakon ba da lamba mai ban sha’awa. Darasin ya haɗu kai tsaye da change da ka taimaka wajen deliver da verify.

1. Bayyana yanayin da alhakinka

2. Minti biyar na farko: tabbatar da impact kuma tsara response

3. Minti goma na gaba: zaɓi hanyar rage cutarwa cikin aminci

4. Zuwa minti talatin: tabbatar da useful service ta dawo

5. Bayan recovery: sauya yanayin da ya ba failure dama

Tambayoyi masu alaƙa