Under et nedbrud bedømmer kunderne dig på to ting: hvor hurtigt problemet bliver løst, og hvad de hører, mens det bliver løst. Det første kan du ikke altid styre. Det andet er helt op til dig, og det er den del, de fleste teams improviserer.
Improvisation går galt på forudsigelige måder. Ingen skriver noget i en time, fordi alle er i gang med at løse problemet. Tre personer skriver tre forskellige versioner. Opdateringen siger “en forringelse i eu-west-klyngen”, og kunderne aner ikke, om det berører dem. Denne guide giver dig en plan på én side, så du kan beslutte de ting på forhånd, og skabeloner, du kan kopiere.
Planen på én side
Skriv den ned én gang, læg den, hvor den vagthavende kan finde den, og gennemgå den to gange om året.
Roller
Incident lead: ejer hændelsen, fastsætter alvorligheden og koordinerer løsningen.
Kommunikator: skriver og offentliggør alle opdateringer til kunderne. Ikke den samme person som den, der løser problemet; skal man løse og skrive på samme tid, går det ud over det ene af dem.
Support: besvarer indkomne spørgsmål med et link til statussiden og giver det videre, som kunderne rapporterer.
I et lille team har de samme personer flere kasketter på. Pointen er at beslutte, hvem der gør hvad, før nedbruddet, ikke under det. Kombinerer du det med en vagtplan, har de to første roller altid et navn.
Alvorlighedsniveauer
Tre niveauer er nok for de fleste teams:
Større: produktet, checkout eller login er nede eller ubrugeligt for de fleste kunder. Opdater hvert 30. minut.
Mindre: én funktion er i stykker eller langsom, eller en del af dine kunder er berørt. Opdater hver time.
Vedligeholdelse: planlagt arbejde. Annoncer det på forhånd, og opdater, når det starter og slutter.
Kanaler
Statusside: altid, ved enhver hændelse, der rammer kunderne. Den er sandhedskilden, som de andre kanaler linker til.
Notifikationer til abonnenter: e-mail- og chatnotifikationer fra statussiden, så kunderne ikke behøver at opdatere siden igen og igen.
Banner i appen: ved større hændelser, hvis dit produkt har et.
Direkte e-mail: ved større hændelser, der ramte nøglekunder, og til den opfølgende opsummering.
Sociale medier: ved større hændelser, med et link til statussiden, ikke en separat version af historien.
Løfter
Første opdatering senest 15 minutter efter, at du kender til et problem, der rammer kunderne.
Hver opdatering siger, hvornår den næste kommer.
Hver hændelse slutter med en opdatering om, at den er løst.
Større hændelser får en kort skriftlig opsummering inden for fem arbejdsdage.
Hvad en god opdatering indeholder
Hver opdatering, i hver fase, besvarer fire spørgsmål i denne rækkefølge:
Hvad der er berørt, med de ord kunderne bruger: “checkout”, “mobilappen”, “login”, ikke det interne servicenavn.
Hvad de oplever: fejl, langsomhed, manglende e-mails.
Hvad de kan gøre, hvis noget: en midlertidig løsning eller “du behøver ikke gøre noget”.
Hvornår de hører mere.
Det skal du udelade: gæt om årsagen, interne navne og fagjargon, skyld på en navngiven leverandør eller kollega og løfter om, hvornår det er løst, medmindre du er sikker. “Vi forventer at have løst det inden for 30 minutter” er et løfte, kunderne vil holde dig op på.
Skabeloner til hver fase
Erstat delene i firkantede parenteser. Hold tonen enkel og rolig.
Undersøger
Vi undersøger meldinger om [fejl / langsom indlæsning], når [kunder forsøger at gennemføre et køb]. [Resten af sitet fungerer normalt.] Vi sender en opdatering inden for [30 minutter].
Årsag fundet
Vi har fundet årsagen: [et problem hos vores betalingsudbyder / en fejlbehæftet opdatering, vi udgav kl. 14:05]. [Kortbetalinger fejler; faktura og Swish er ikke berørt.] Vi [ruller opdateringen tilbage / arbejder sammen med udbyderen] og opdaterer igen inden for [30 minutter].
Overvåger
En rettelse er på plads, og [checkout] virker igen. Vi overvåger situationen for at sikre, at den forbliver stabil. [Ordrer afgivet mellem 14:05 og 14:40 kan stå som afventende; de bliver behandlet automatisk.] Næste opdatering inden for [en time] eller før, hvis noget ændrer sig.
Løst
Denne hændelse er løst. Mellem [14:05 og 14:40 CET] [fejlede kortbetalinger i checkout for de fleste kunder]. [Årsagen var en fejlbehæftet opdatering, som vi har rullet tilbage.] [Vi tilføjer et tjek, så denne type fejl stopper en release, før den når kunderne.] Vi beklager ulejligheden.
Intet nyt endnu
Vi arbejder stadig på [fejlene i checkout]. Der er ingen ændringer siden sidste opdatering. Næste opdatering inden for [30 minutter].
Den sidste betyder mere, end man skulle tro. En statusside, der ikke har ændret sig i en time, får kunderne til at tro, at ingen arbejder på sagen.
E-mail til berørte kunder
Ved større hændelser, der rammer nøglekunder, er en kort e-mail efter hændelsen mere værd end nogen statusside. Send den fra en person, ikke fra en no-reply-adresse.
Emne: Om dagens nedbrud i checkout
Hej [navn], mellem 14:05 og 14:40 i dag fejlede kortbetalinger i checkout for de fleste af vores kunder, også dig. Årsagen var en fejlbehæftet opdatering hos os, som vi har rullet tilbage. [Ordrer, du afgav i det tidsrum, er nu behandlet.] Vi [tilføjer et automatisk tjek, der stopper den slags releases]. Hvis du har set noget, der ikke stemmer med dette, så svar på denne e-mail, så ser jeg personligt på det. [Navn, rolle]
Sociale medier
Hold det kort, og henvis til statussiden for detaljer:
Vi ser fejl i checkout og arbejder på sagen. Opdateringer her: [link til statusside]
Checkout virker igen. Tak for jeres tålmodighed, og undskyld besværet. Opsummering: [link til statusside]
Efter hændelsen
Ved større hændelser skal du offentliggøre en kort opsummering på statussiden eller via e-mail inden for få dage: hvad der skete, hvor længe, hvem der var berørt, hvad der var årsagen, og hvad I ændrer. Vores postmortem-skabelon dækker den interne gennemgang, der kommer først, og hvordan du gør den til en version til kunderne.
Se derefter på selve kommunikationen. Hvor lang tid tog den første opdatering? Blev de lovede opdateringstider overholdt? Fik support spørgsmål, som opdateringerne burde have besvaret? Ret planen, ikke kun systemet.
Gør det nemt at følge planen
En plan virker kun, hvis det er hurtigere at følge den end at ignorere den. Et par ting gør forskellen:
Vid det før kunderne. Uptimecheck tjekker dine websites og API’er helt ned til hvert minut fra Stockholm, London og New York, bekræfter hver fejl fra en anden lokation og alarmerer den vagthavende, så 15-minutters-uret starter, når problemet starter, ikke når den første supporthenvendelse kommer ind.
Skabeloner klar i værktøjet. Uptimechecks statussider tilbyder et færdigt første udkast til hver fase (undersøger, årsag fundet, overvåger, løst) på sidens sprog og dine egne gemte skabeloner, hvor {components} udfylder de berørte dele.
Giv de rigtige personer besked. Abonnenter følger hele siden eller kun de komponenter, de bruger, via e-mail, Slack, Microsoft Teams, Discord eller webhook, og kun dem, der følger de berørte komponenter, får besked.
Annoncer vedligeholdelse på forhånd. Planlagt vedligeholdelse vises på siden og sendes på e-mail til abonnenterne, før den starter.
Vores guide til at lave en statusside, kunderne har tillid til, dækker, hvad du skal have på selve siden.
Tjekliste
Udpeg incident lead, kommunikator og support på forhånd.
Bliv enige om tre alvorlighedsniveauer og en opdateringsrytme for hvert.
Brug statussiden som sandhedskilde; andre kanaler linker til den.
Send den første opdatering inden for 15 minutter, selv hvis du kun ved, at I undersøger sagen.
Svar på, hvad der er berørt, hvad kunderne oplever, hvad de kan gøre, og hvornår de hører mere.
Oplys tidspunktet for næste opdatering, og overhold det.
Afslut hver hændelse med en opdatering om, at den er løst.
Send en kort opsummering efter større hændelser, og gennemgå kommunikationen såvel som løsningen.