Si e udhëzoni një incident në prodhim?

Question

Accepted Answer

Gjatë një incidenti puna juaj është të **rivendosni shërbimin me qetësi dhe koordinoni përgjigjen**, jo të jeni heroi që e rregullon vetëm. Rolet e qarta, komunikimi i qetë dhe një prirje për zbutje të parë ndjesin një përgjigje të butë nga kaosi.

## Si të drejtoni një incident

```text
1. ASSIGN roles — incident commander (coordinates), responders (fix),
   comms (updates stakeholders). One person can't do all three.
2. MITIGATE first — stop the bleeding (roll back, feature-flag off)
   before chasing root cause.
3. COMMUNICATE on a cadence — even "still investigating" every 15-30 min.
4. STAY CALM — the team mirrors your energy. Blame comes later, or never.
5. After: BLAMELESS post-mortem — fix the system, not the person.
```

## Zbutni para diagnozës

Instikti për të gjetur shkakun rrënjësor është i fortë, kundërshtojeni atë. Nëse një kthim në të mbrapa rivendos shërbimin, bëjeni atë *parë*, pastaj hetoni me qetësi me presionin të ulur. Përdoruesit interesohen të jenë të çblokirë, jo të diagnostikës tuaj.

## Një shembull konkret

Un deploy prisht pagesën. Mos debugoni kodin e ri drejtpërdrejt nën presion. Kthehuni në të mbrapa menjëherë, konfirmoni se pagesë funksionon, postoni një përditësim, *pastaj* hetoni deploy-in e keq në kushte të qeta.

## Një gropë

Një post-mortem i plotë fajit e mëson njerëzit të fshehni problemet. Mbajeni bezdisne, fokusojuni në boshllëqet sistemike (pa kanari, pa alarm) që e lejuan.

## Pse ka rëndësi

Incidentet janë me stress të lartë dhe me vizibilitet të lartë, si e udhëzoni formativet si rezultatin ashtu edhe besimin e ekipit tek ju.

Koordinimi i qetë dhe mësimet bezdisne e kthejnë një ndërprerje në një sistem që është më i vështirë të thyhet herën tjetër.