Under et driftsavbrudd bedømmer kundene deg på to ting: hvor raskt problemet blir løst, og hva de får høre mens det løses. Det første kan du ikke alltid styre. Det andre er helt opp til deg, og det er den delen de fleste team improviserer.
Improvisasjon går galt på forutsigbare måter. Ingen legger ut noe på en time fordi alle er opptatt med å fikse problemet. Tre personer legger ut tre ulike versjoner. Oppdateringen sier «en degradering i eu-west-klyngen», og kundene aner ikke om det gjelder dem. Denne guiden gir deg en plan på én side for å avgjøre dette på forhånd, og maler du kan kopiere.
Planen på én side
Skriv den ned én gang, legg den der vakthavende finner den, og gå gjennom den to ganger i året.
Roller
Hendelsesleder: eier hendelsen, bestemmer alvorlighetsgrad og koordinerer løsningen.
Kommunikatør: skriver og publiserer alle oppdateringer til kundene. Ikke den samme personen som fikser problemet; å fikse og skrive samtidig betyr at det ene går ut over det andre.
Kundestøtte: svarer på innkommende spørsmål med en lenke til statussiden og bringer videre det kundene melder.
I et lite team har de samme personene flere roller. Poenget er å bestemme hvem som gjør hva før driftsavbruddet, ikke underveis. Kombinerer du dette med en vaktplan, har de to første rollene alltid et navn.
Alvorlighetsgrader
Tre nivåer holder for de fleste team:
Alvorlig: produktet, kassen eller innloggingen er nede eller ubrukelig for de fleste kunder. Oppdater hvert 30. minutt.
Mindre: én funksjon er ødelagt eller treg, eller en del av kundene dine er berørt. Oppdater hver time.
Vedlikehold: planlagt arbeid. Varsle på forhånd, og oppdater når det starter og avsluttes.
Kanaler
Statusside: alltid, for alle hendelser som berører kunder. Den er fasiten som de andre kanalene lenker til.
Varsler til abonnenter: e-post- og chatvarsler fra statussiden, så kundene slipper å oppdatere siden hele tiden.
Banner i appen: for alvorlige hendelser, hvis produktet ditt har et.
Direkte e-post: for alvorlige hendelser som har rammet nøkkelkunder, og for oppsummeringen i etterkant.
Sosiale medier: for alvorlige hendelser, med en lenke til statussiden, ikke en egen versjon av historien.
Løfter
Første oppdatering innen 15 minutter etter at dere vet om et problem som berører kunder.
Hver oppdatering sier når den neste kommer.
Hver hendelse avsluttes med en oppdatering om at den er løst.
Alvorlige hendelser får en kort skriftlig oppsummering innen fem virkedager.
Dette inneholder en god oppdatering
Hver oppdatering, i hver fase, svarer på fire spørsmål i denne rekkefølgen:
Hva som er berørt, med ordene kundene bruker: «kassen», «mobilappen», «innloggingen», ikke det interne tjenestenavnet.
Hva de merker: feil, treghet, e-poster som ikke kommer.
Hva de kan gjøre, om noe: en midlertidig løsning, eller «du trenger ikke gjøre noe».
Når de får høre mer.
Dette bør du utelate: gjetninger om årsaken, interne navn og sjargong, skyld på en navngitt leverandør eller kollega, og løfter om når det blir løst, med mindre du er sikker. «Vi regner med å ha løst dette innen 30 minutter» er et løfte kundene vil holde deg til.
Maler for hver fase
Bytt ut delene i hakeparentes. Hold tonen enkel og rolig.
Undersøker
Vi undersøker meldinger om [feil / treg innlasting] når [kunder prøver å fullføre kjøpet]. [Resten av nettstedet fungerer som normalt.] Vi legger ut en oppdatering innen [30 minutter].
Identifisert
Vi har funnet årsaken: [et problem hos betalingsleverandøren vår / en feilaktig oppdatering vi rullet ut kl. 14.05]. [Kortbetalinger feiler; faktura og Swish er ikke berørt.] Vi [ruller tilbake oppdateringen / jobber sammen med leverandøren] og oppdaterer igjen innen [30 minutter].
Overvåker
En løsning er på plass, og [kassen] fungerer igjen. Vi følger med for å sikre at den forblir stabil. [Bestillinger lagt inn mellom kl. 14.05 og 14.40 kan vises som ventende; de blir behandlet automatisk.] Neste oppdatering innen [én time], eller tidligere hvis noe endrer seg.
Løst
Denne hendelsen er løst. Mellom [kl. 14.05 og 14.40 CET] [feilet kortbetalinger i kassen for de fleste kunder]. [Årsaken var en feilaktig oppdatering, som vi har rullet tilbake.] [Vi legger til en sjekk slik at denne typen feil stopper en utrulling før den når kundene.] Vi beklager ulempene.
Ikke noe nytt ennå
Vi jobber fortsatt med [feilene i kassen]. Det er ingen endring siden forrige oppdatering. Neste oppdatering innen [30 minutter].
Den siste betyr mer enn det ser ut til. En statusside som ikke har endret seg på en time, får kundene til å tro at ingen jobber med saken.
E-post til berørte kunder
Ved alvorlige hendelser som rammer nøkkelkunder, er en kort e-post etter hendelsen verdt mer enn noen statusside. Send den fra en person, ikke fra en no-reply-adresse.
Emne: Om dagens driftsavbrudd i kassen
Hei [navn], mellom kl. 14.05 og 14.40 i dag feilet kortbetalinger i kassen for de fleste av kundene våre, også for deg. Årsaken var en feilaktig oppdatering hos oss, som vi rullet tilbake. [Bestillingene du la inn i det tidsrommet, er nå behandlet.] Vi [legger til en automatisk sjekk som stopper denne typen utrulling]. Hvis du så noe som ikke stemmer med dette, kan du svare på denne e-posten, så ser jeg på det personlig. [Navn, rolle]
Sosiale medier
Hold det kort og vis til statussiden for detaljer:
Vi ser feil i kassen og jobber med saken. Oppdateringer her: [lenke til statussiden]
Kassen fungerer igjen. Takk for tålmodigheten, og beklager bryderiet. Oppsummering: [lenke til statussiden]
Etter hendelsen
Ved alvorlige hendelser publiserer du en kort oppsummering på statussiden eller per e-post innen noen dager: hva som skjedde, hvor lenge, hvem som ble berørt, hva som var årsaken og hva dere endrer. Postmortem-malen vår dekker den interne gjennomgangen som kommer først, og hvordan du gjør den om til en versjon for kundene.
Se deretter på selve kommunikasjonen. Hvor lang tid tok den første oppdateringen? Ble de lovede oppdateringstidene holdt? Fikk kundestøtte spørsmål som oppdateringene burde ha besvart? Forbedre planen, ikke bare systemet.
Gjør det enkelt å følge planen
En plan fungerer bare hvis det er raskere å følge den enn å ignorere den. Noen få ting utgjør forskjellen:
Vit det før kundene gjør det. Uptimecheck sjekker nettstedene og API-ene dine så ofte som hvert minutt fra Stockholm, London og New York, bekrefter hver feil fra en annen lokasjon og varsler vakthavende, slik at 15-minuttersklokken starter når problemet oppstår, ikke når den første henvendelsen til kundestøtte kommer.
Maler klare i verktøyet. Statussidene i Uptimecheck gir deg et ferdig førsteutkast for hver fase (undersøker, identifisert, overvåker, løst) på sidens språk, og dine egne lagrede maler, der {components} fyller inn de berørte delene.
Varsle de riktige personene. Abonnenter følger hele siden eller bare komponentene de bruker, via e-post, Slack, Microsoft Teams, Discord eller webhook, og bare de som følger de berørte komponentene, blir varslet.
Varsle vedlikehold på forhånd. Planlagt vedlikehold vises på siden og sendes på e-post til abonnentene før det starter.
Guiden vår om å lage en statusside kundene stoler på dekker hva som bør stå på selve siden.
Sjekkliste
Bestem på forhånd hvem som er hendelsesleder, kommunikatør og kundestøtte.
Bli enige om tre alvorlighetsgrader og en oppdateringsfrekvens for hver.
Bruk statussiden som fasit; de andre kanalene lenker dit.
Legg ut den første oppdateringen innen 15 minutter, selv om alt du vet er at dere undersøker saken.
Svar på hva som er berørt, hva kundene merker, hva de kan gjøre og når de får høre mer.
Oppgi tidspunktet for neste oppdatering, og hold det.
Avslutt hver hendelse med en oppdatering om at den er løst.
Send en kort oppsummering etter alvorlige hendelser, og gå gjennom kommunikasjonen like grundig som løsningen.