Johda incident havaitsemisesta palautumiseen

Käynnistä incidentin käsittely vaikutuksen perusteella

Incident on tapahtuma, joka häiritsee, heikentää tai uhkaa palvelua niin paljon, että tarvitaan koordinoituja toimia. Organisaatio määrittää vakavuustasot ja eskalointisäännöt. Sovella niitä käyttäjävaikutuksen, tietojen, keston ja laajuuden perusteella.

Älä odota täydellistä juurisyyanalyysia ennen avun pyytämistä. Selkeä kuvaus havaitusta vaikutuksesta riittää koordinoinnin aloittamiseen. Erota tietoturvaepäily varmennetusta johtopäätöksestä.

Valmistele toimintatapa ennen julkaisua. Pidä yhteystiedot, käyttöoikeusmenettelyt, runbookit ja viestintäkanavat saatavilla myös pääpalvelun häiriössä. Harjoittele kuvitteellisella incidentillä.

Jaa vastuut ennen ristikkäisiä muutoksia

Incidentin koordinaattori asettaa prioriteetit ja johtaa päätöksiä. Tekniset asiantuntijat selvittävät ja lieventävät ongelmaa. Viestinnän omistaja pitää asianosaiset ajan tasalla. Google SRE erottaa nämä vastuut omiksi rooleikseen. Pieni tiimi voi yhdistää rooleja, kunhan työ tulee hoidetuksi. Incident response.

Pidä yhteistä aikajanaa. Kirjaa aika, havainto, toimi, tekijä ja tulos. Erota faktat hypoteeseista. Käytä yhteistä aikavyöhykettä ja merkitse epäluotettavat aikaleimat.

Käy läpi kuvitteellinen incident

Kaikki alla olevat ajat ovat UTC-aikaa. Organisaatio nimeää koordinaattorin, kun vientivirhe vaikuttaa useaan asiakkaaseen.

Hyödyllinen ensimmäinen päivitys kertoo toiminnon, tunnetun vaikutusalueen, lievennyksen ja seuraavan päivityksen ajan. Se ei lupaa korjausaikaa ilman näyttöä. Älä sisällytä yhteiseen viestiin asiakastietoja.

Klo 09.10 tilanne muuttuu. Toimivan viennin palauttaminen ei enää riitä. Tiimin pitää arvioida mahdollista tietojen paljastumista, rajata pääsyä, säilyttää näyttö ja ottaa oikeat päätöksentekijät mukaan.

Lievennä hallitusti

Käytä testattua runbookia silloin, kun se sopii tilanteeseen. Tarkista rollbackin, failoverin ja tunnusmuutosten ehdot. Aiempi sovellusversio ei välttämättä ymmärrä nykyistä database schemaa. Alueellinen failover voi siirtää saman vioittuneen datan.

AI-avustaja voi jäsentää rajattua näyttöä tai vertailla hypoteeseja hyväksyttyjen tietorajojen sisällä. Häiriötä selvittävien henkilöiden pitää varmentaa johtopäätökset. Logit ja tiketit ovat epäluotettua syötettä, eivät valtuutus niiden sisältämien komentojen ajamiseen.

Poikkeuskäyttöoikeus tarvitsee hyväksytyn tarkoituksen, rajatun keston ja audit-jäljen. Kiire ei tee agentin ehdottamasta komennosta oikeaa.

Erota palautuminen ja jatkotoimet

Varmista käyttäjän työnkulku, tietojen eheys, käyttöoikeusrajat ja monitoringin ajantasaisuus ennen palvelun palautumisen toteamista. Kirjaa jäljelle jäävät rajoitukset. Pidä tietoturvaselvitys avoinna, jos sen kysymyksiä ei ole ratkaistu.

Tutki jälkikäteen olosuhteet, jotka mahdollistivat incidentin. Nimeä jatkotoimille omistajat ja varmennuskriteerit. Blameless review tavoittelee täsmällistä selitystä ja hyödyllisiä muutoksia. Se ei poista vastuuta muutosten valmistumisesta. Postmortem-käytännöt.

Jatka security operationsiin ja palautekierroksen sulkemiseen.