Wat is een statuspagina en wat hoort erop
Een statuspagina is een pagina die los van uw dienst wordt gehost en die laat zien of elk onderdeel ervan op dit moment werkt, plus een logboek van huidige en eerdere incidenten. Zijn taak is om "ligt het aan jou of aan mij" te beantwoorden zonder dat iemand een supportticket hoeft te openen.
Wat er op een statuspagina staat
Een statuspagina heeft drie lagen, en het meeste van de waarde zit in de eerste twee.
De bovenste laag is de huidige status van elk onderdeel dat u vermeldt. Onderdelen zijn de stukken die een klant uit elkaar kan houden: de website, de API, het dashboard, inloggen, het betaalproces, de backend van een mobiele app. De status is meestal een korte ladder in plaats van een simpel aan-of-uit, zodat u "verminderd" kunt zeggen voor een dienst die traag is maar wel antwoordt, in plaats van te moeten kiezen tussen een groen vinkje dat onjuist is en een rood kruis dat erger is.
De middelste laag is de incidentfeed. Elk incident is een korte vermelding met een starttijd, een gewone beschrijving van wat klanten zullen merken, en updates die worden toegevoegd naarmate de situatie verandert, eindigend met een oplossingsnotitie. Eerdere incidenten blijven zichtbaar, en dat is wat de pagina tot een archief maakt in plaats van een lichtknop.
De onderste laag is geschiedenis: uptime over de afgelopen 30 of 90 dagen per onderdeel. Het is het minst urgente deel, en het deel dat het vaakst wordt gelezen door mensen die u beoordelen.
Publiek of privé
Een publieke statuspagina staat open voor iedereen met de link, en dat is de juiste keuze wanneer uw klanten het brede publiek zijn of wanneer u een SLA publiceert. Ze vangt tijdens een storing ook verkeer op van mensen die helemaal geen klant zijn.
Een private statuspagina is beperkt tot aangemelde klanten of tot een intern publiek. Teams gebruiken die wanneer de lijst met onderdelen interne architectuur zou blootleggen, wanneer incidenten met naam genoemde zakelijke klanten betreffen, of wanneer de pagina interne systemen dekt die geen buitenstaander zou moeten kunnen opsommen. De prijs is dat iedereen die er niet bij kan, in plaats daarvan contact opneemt met support.
Welke u ook kiest, host de pagina los van de infrastructuur waarover ze rapporteert. Een statuspagina die samen met de dienst uitvalt, is erger dan helemaal geen statuspagina, want haar stilte tijdens een storing wordt gelezen als een bewering dat er niets aan de hand is.
Een incident schrijven
Een incidentvermelding is geschreven voor een klant, niet voor de engineers die het oplossen. Dat betekent eerst het symptoom, en pas daarna de oorzaak, als die er al bij staat.
- Open het incident zodra u het probleem heeft bevestigd, ook als u de oorzaak nog niet kent. "We onderzoeken meldingen van fouten bij het afrekenen", geplaatst op minuut twee, is meer waard dan een volledige verklaring op minuut negentig.
- Zeg wat een klant zal zien en wat die eraan kan doen, inclusief een workaround als die er is.
- Update in een ritme dat u vooraf aangeeft, en plaats de update ook wanneer die luidt "nog geen verandering". Stilte wordt gelezen als verwaarlozing.
- Sluit af met een oplossingstijd en, bij alles wat lang duurde of ernstig was, een korte notitie over wat er daarna is gebeurd.
Laat de status van het onderdeel overeenkomen met het incident. Een open incident op een onderdeel dat nog steeds groen toont, is de snelste manier om het vertrouwen in de pagina te verliezen. Is de onderliggende fout een server die verzoeken weigert, dan is 503 Service Unavailable de reactie die uw klanten u waarschijnlijk voorhouden.
Gepland onderhoud
Gepland werk hoort op dezelfde pagina, vooraf aangekondigd met een venster en een verwachte impact. Het van tevoren plaatsen maakt van een storing een afspraak: klanten die de melding zagen, dienen geen tickets in, en zij die dat niet zagen, kunnen tenminste de uitleg vinden terwijl het gebeurt.
Onderscheid onderhoud van een incident, visueel en in het logboek, en houd het aangekondigde venster eerlijk. Een onderhoudsvenster dat steeds uitloopt, leert mensen om het volgende te negeren.
Waarom het de supportdruk verlaagt
Tijdens een storing loopt de supportwachtrij vol met één vraag die vele keren wordt gesteld. Een statuspagina beantwoordt die eenmaal, op een adres waarnaar u kunt verwijzen vanuit uw supportautoresponder, de foutstatus van uw app en uw sociale accounts. Dat zet een uur repetitieve triage om in een link.
Het secundaire effect zit in vertrouwen. Incidenten publiceren kost minder dan het lijkt, want de klanten die de storing merkten, weten al dat die is gebeurd. Waar ze op beoordelen, is of u het hen heeft verteld.
Waar de status vandaan komt
Een statuspagina is maar zo goed als de monitoring erachter. Moet een mens eerst een storing opmerken voordat de pagina verandert, dan loopt de pagina altijd achter op de klanten die haar lezen, dus de status van de onderdelen moet worden aangestuurd door controles die continu van buiten uw netwerk draaien. HostTracker host statuspagina's die worden gevoed door zijn eigen monitoring, die controleert vanaf 300+ controlepunten in 158 steden over 13 monitortypes, zodat de status van een onderdeel de controleresultaten volgt in plaats van iemand die eraan moet denken om het bij te werken. Voor hoe die controles eruitzien, zie de handleiding voor de HTTP-controle, en de rest van het onderdeel over monitoringbegrippen voor de omringende termen.