Bei einem Ausfall beurteilen Kunden Sie nach zwei Dingen: wie schnell das Problem behoben ist und was sie hören, während es behoben wird. Das Erste haben Sie nicht immer in der Hand. Das Zweite liegt ganz bei Ihnen, und genau hier improvisieren die meisten Teams.
Improvisation geht auf vorhersehbare Weise schief. Eine Stunde lang postet niemand etwas, weil alle das Problem beheben. Drei Leute posten drei verschiedene Versionen. Im Update steht „eine Beeinträchtigung im eu-west-Cluster“, und Kunden haben keine Ahnung, ob sie betroffen sind. Dieser Ratgeber gibt Ihnen einen einseitigen Plan, mit dem Sie diese Dinge vorab festlegen, und Vorlagen zum Kopieren.
Der einseitige Plan
Schreiben Sie ihn einmal auf, legen Sie ihn dort ab, wo die Person in Rufbereitschaft ihn findet, und überprüfen Sie ihn zweimal im Jahr.
Rollen
Incident-Leitung: verantwortet den Vorfall, legt den Schweregrad fest, koordiniert die Behebung.
Kommunikation: schreibt und veröffentlicht jedes Update für Kunden. Nicht dieselbe Person, die das Problem behebt; wer gleichzeitig repariert und schreibt, macht eines von beiden schlechter.
Support: beantwortet eingehende Fragen mit einem Link zur Statusseite und gibt weiter, was Kunden melden.
In einem kleinen Team tragen dieselben Leute mehrere Hüte. Entscheidend ist, vor dem Ausfall festzulegen, wer was tut, nicht währenddessen. Mit einem Bereitschaftsplan haben die ersten beiden Rollen immer einen Namen.
Schweregrade
Drei Stufen reichen für die meisten Teams:
Schwer: Das Produkt, der Checkout oder der Login ist für die meisten Kunden down oder unbrauchbar. Update alle 30 Minuten.
Leicht: Eine Funktion ist kaputt oder langsam, oder ein Teil Ihrer Kunden ist betroffen. Update jede Stunde.
Wartung: geplante Arbeiten. Vorab ankündigen, bei Beginn und Ende ein Update.
Kanäle
Statusseite: immer, bei jedem Vorfall, der Kunden betrifft. Sie ist die verbindliche Quelle, auf die die anderen Kanäle verlinken.
Benachrichtigungen an Abonnenten: E-Mail- und Chat-Benachrichtigungen von der Statusseite, damit Kunden nicht ständig neu laden müssen.
Banner in der App: bei schweren Vorfällen, sofern Ihr Produkt eines hat.
Direkte E-Mail: bei schweren Vorfällen, die Schlüsselkunden betroffen haben, und für die abschließende Zusammenfassung.
Social Media: bei schweren Vorfällen, mit einem Link zur Statusseite statt einer eigenen Version der Geschichte.
Zusagen
Erstes Update innerhalb von 15 Minuten, nachdem Sie von einem Problem erfahren, das Kunden betrifft.
Jedes Update nennt den Zeitpunkt des nächsten.
Jeder Vorfall endet mit einem Update „Behoben“.
Schwere Vorfälle bekommen innerhalb von fünf Arbeitstagen eine kurze schriftliche Zusammenfassung.
Was ein gutes Update enthält
Jedes Update beantwortet in jeder Phase vier Fragen in dieser Reihenfolge:
Was betroffen ist, in den Worten Ihrer Kunden: „der Checkout“, „die mobile App“, „die Anmeldung“, nicht der interne Dienstname.
Was sie bemerken: Fehler, Langsamkeit, fehlende E-Mails.
Was sie tun können, falls überhaupt: einen Workaround oder „Sie müssen nichts tun“.
Wann sie mehr erfahren.
Was Sie weglassen sollten: Vermutungen zur Ursache, interne Namen und Fachjargon, Schuldzuweisungen an namentlich genannte Dienstleister oder Kollegen und Zusagen, wann es behoben sein wird, sofern Sie nicht sicher sind. „Wir gehen davon aus, das Problem innerhalb von 30 Minuten zu beheben“ ist ein Versprechen, an dem Kunden Sie messen werden.
Vorlagen für jede Phase
Ersetzen Sie die Teile in Klammern. Bleiben Sie im Ton schlicht und ruhig.
Untersuchung
Wir untersuchen Meldungen über [Fehler / langsame Ladezeiten], wenn [Kunden zur Kasse gehen]. [Die übrigen Bereiche der Website funktionieren normal.] Wir melden uns innerhalb von [30 Minuten] mit einem Update.
Ursache gefunden
Wir haben die Ursache gefunden: [ein Problem bei unserem Zahlungsdienstleister / ein fehlerhaftes Update, das wir um 14:05 veröffentlicht haben]. [Kartenzahlungen schlagen fehl; Rechnungskauf und Swish sind nicht betroffen.] Wir [nehmen das Update zurück / arbeiten mit dem Dienstleister an einer Lösung] und melden uns innerhalb von [30 Minuten] erneut.
Beobachtung
Eine Korrektur ist eingespielt, und [der Checkout] funktioniert wieder. Wir beobachten die Lage, um sicherzugehen, dass alles stabil bleibt. [Bestellungen zwischen 14:05 und 14:40 werden möglicherweise als ausstehend angezeigt; sie werden automatisch verarbeitet.] Nächstes Update innerhalb von [einer Stunde] oder früher, falls sich etwas ändert.
Behoben
Dieser Vorfall ist behoben. Zwischen [14:05 und 14:40 MEZ] [schlugen Kartenzahlungen im Checkout für die meisten Kunden fehl]. [Ursache war ein fehlerhaftes Update, das wir zurückgenommen haben.] [Wir ergänzen eine Prüfung, damit ein solcher Fehler ein Release stoppt, bevor er Kunden erreicht.] Wir entschuldigen uns für die Störung.
Noch nichts Neues
Wir arbeiten weiter an [den Fehlern im Checkout]. Seit dem letzten Update hat sich nichts geändert. Nächstes Update innerhalb von [30 Minuten].
Diese letzte Vorlage ist wichtiger, als sie aussieht. Eine Statusseite, die sich seit einer Stunde nicht verändert hat, lässt Kunden glauben, dass niemand daran arbeitet.
E-Mail an betroffene Kunden
Bei schweren Vorfällen, die Schlüsselkunden treffen, ist eine kurze E-Mail nach dem Vorfall mehr wert als jede Statusseite. Senden Sie sie von einer Person, nicht von einer No-Reply-Adresse.
Betreff: Zum heutigen Ausfall im Checkout
Hallo [Name], heute zwischen 14:05 und 14:40 schlugen Kartenzahlungen im Checkout für die meisten unserer Kunden fehl, auch für Sie. Ursache war ein fehlerhaftes Update auf unserer Seite, das wir zurückgenommen haben. [Bestellungen, die Sie in diesem Zeitraum aufgegeben haben, sind inzwischen verarbeitet.] Wir [ergänzen eine automatische Prüfung, die ein solches Release stoppt]. Wenn Ihnen etwas aufgefallen ist, das nicht dazu passt, antworten Sie einfach auf diese E-Mail, und ich kümmere mich persönlich darum. [Name, Funktion]
Social Media
Fassen Sie sich kurz und verweisen Sie für Details auf die Statusseite:
Im Checkout treten Fehler auf, wir arbeiten daran. Updates hier: [Link zur Statusseite]
Der Checkout funktioniert wieder. Danke für Ihre Geduld, und entschuldigen Sie die Unannehmlichkeiten. Zusammenfassung: [Link zur Statusseite]
Nach dem Vorfall
Veröffentlichen Sie bei schweren Vorfällen innerhalb weniger Tage eine kurze Zusammenfassung auf der Statusseite oder per E-Mail: was passiert ist, wie lange, wer betroffen war, was die Ursache war und was Sie ändern. Unsere Postmortem-Vorlage deckt die interne Auswertung ab, die zuerst kommt, und zeigt, wie Sie daraus eine Version für Kunden machen.
Sehen Sie sich danach die Kommunikation selbst an. Wie lange hat das erste Update gedauert? Wurden die angekündigten Update-Zeiten eingehalten? Hat der Support Fragen bekommen, die die Updates hätten beantworten sollen? Verbessern Sie den Plan, nicht nur das System.
Machen Sie es leicht, dem Plan zu folgen
Ein Plan funktioniert nur, wenn es schneller geht, ihm zu folgen, als ihn zu ignorieren. Ein paar Dinge machen den Unterschied:
Vor den Kunden Bescheid wissen. Uptimecheck prüft Ihre Websites und APIs bis zu jede Minute aus Stockholm, London und New York, bestätigt jeden Fehler von einem zweiten Standort aus und alarmiert die Person in Rufbereitschaft. So beginnt die 15-Minuten-Frist, wenn das Problem beginnt, und nicht erst mit dem ersten Support-Ticket.
Vorlagen direkt im Tool. Statusseiten von Uptimecheck bieten für jede Phase (Untersuchung, Ursache gefunden, Beobachtung, Behoben) einen fertigen ersten Entwurf in der Sprache der Seite sowie Ihre eigenen gespeicherten Vorlagen, in denen {components} die betroffenen Bereiche einsetzt.
Die richtigen Personen benachrichtigen. Abonnenten folgen der ganzen Seite oder nur den Komponenten, die sie nutzen, per E-Mail, Slack, Microsoft Teams, Discord oder Webhook, und benachrichtigt werden nur diejenigen, die den betroffenen Komponenten folgen.
Wartungen vorab ankündigen. Geplante Wartungen erscheinen auf der Seite und gehen vor Beginn per E-Mail an die Abonnenten.
Unser Ratgeber So erstellen Sie eine Statusseite, der Kunden vertrauen zeigt, was auf die Seite selbst gehört.
Checkliste
Benennen Sie Incident-Leitung, Kommunikation und Support vorab.
Einigen Sie sich auf drei Schweregrade und jeweils einen Update-Rhythmus.
Nutzen Sie die Statusseite als verbindliche Quelle; die anderen Kanäle verlinken darauf.
Veröffentlichen Sie das erste Update innerhalb von 15 Minuten, auch wenn Sie nur wissen, dass Sie das Problem untersuchen.
Beantworten Sie, was betroffen ist, was Kunden bemerken, was sie tun können und wann sie mehr erfahren.
Nennen Sie den Zeitpunkt des nächsten Updates und halten Sie ihn ein.
Schließen Sie jeden Vorfall mit einem Update „Behoben“ ab.
Senden Sie nach schweren Vorfällen eine kurze Zusammenfassung und werten Sie neben der Behebung auch die Kommunikation aus.