Tuotantosivustosi meni juuri nurin. Miten hoidat tilanteen?

Question

IT Interview Practice · Accepted Answer

Ensimmäinen prioriteetti on **palauttaa palvelu, sitten löytää syy** — mitigointi tulee ennen diagnoosia. Julistaisin incidentin, määräisin selkeät roolit ja ajaisin kohti nopeinta turvallista palautumista, viestien koko ajan.

## Vakauta ensin

- **Julista incident** ja avaa yksi kanava (war room / Slack-säie), jotta koordinointi ei hajaannu.
- **Määrää roolit**: **Incident Commander** tekemään päätökset, **viestintävastaava** päivittämään stakeholdereita ja **vastaajat** tutkimaan. Tech Leadina otan usein IC-roolin, jotta insinöörit voivat keskittyä ongelmaan.
- **Tartu nopeimpaan peruutettavissa olevaan korjaukseen.** Jos deploy korreloi katkoksen kanssa, **rollback** ensin ja kysy myöhemmin — käyttäjien palauttaminen voittaa oikeassa olemisen.

## Diagnosoi rinnakkain

- Tarkista **ilmeiset signaalit**: dashboardit, virhetasot, viimeaikaiset deployt, infra-muutokset, liikennepiikit, vanhentuneet sertit.
- Muodosta hypoteesi, testaa halvin ensin, ja **vältä muuttamasta viittä asiaa kerralla** — et tiedä, mikä toimi.

## Viesti jatkuvasti

Hiljaisuus synnyttää paniikkia. Lähetän päivityksiä tasaisella rytmillä, vaikka uutta ei olisi:

```
[14:05] Tutkitaan — kassa on alhaalla, ~40 % käyttäjistä kärsii. Seuraava päivitys 14:20.
[14:20] Tunnistettu: huono deploy. Rollback käynnissä nyt. ETA 10 min.
[14:35] Palvelu palautettu. Seurataan. Postmortem seuraa.
```

## Palautumisen jälkeen

- Vahvista täysi palautuminen, ei vain "näyttää paremmalta".
- Tee **syyllistämätön postmortem** muutaman päivän sisällä: aikajana, juurisyy, mikä teki havaitsemisesta/korjaamisesta hidasta, ja **konkreettiset toimenpiteet omistajineen**.
- Lopputulos on järjestelmällinen parannus (paremmat hälytykset, suojakaiteet, rollback-automaatio) — ei syyllinen.

## Sudenkuopat

- **Debuggaaminen ennen mitigointia** käyttäjien kärsiessä.
- **Ei yhtä päätöksentekijää**, jolloin viisi ihmistä arvaa rinnakkain.
- **Pimentoon meno** stakeholdereilta.
- **Yksilöiden syyllistäminen**, mikä tappaa rehellisyyden, josta tulevat incidentit riippuvat.

## Miksi se on tärkeää

Katkokset ovat väistämättömiä; se, miten niitä hoidat, määrittää tiimin luottamuksen ja asiakkaiden uskon. Rauhallinen, roolipohjainen koordinointi yhdistettynä syyllistämättömään jälkihoitoon muuttaa huonon päivän vahvemmaksi järjestelmäksi — ja viestii insinööreillesi, että on turvallista liikkua nopeasti, koska epäonnistuminen hoidetaan prosessina, ei noitavainona.

Vakauta ensin

Diagnosoi rinnakkain

Viesti jatkuvasti

Palautumisen jälkeen

Sudenkuopat

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset