Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum eine öffentliche Statusseite ehrlich bleiben sollte
Eine Statusseite soll eine bestimmte Frage schnell beantworten: Funktioniert das, wovon ich abhänge, gerade, und falls nicht, weiß der Anbieter schon davon? Das ist ein enger, nützlicher Zweck, und er funktioniert nur, wenn die Seite die Realität so genau abbildet, dass man ihr an dem Tag vertrauen kann, an dem es wirklich darauf ankommt, nämlich an dem Tag, an dem etwas kaputt ist. Eine Statusseite, die zwei Jahre am Stück nur Grün zeigt, beschreibt entweder ein wirklich fehlerfreies System, was selten ist, oder eine Seite, die nach einem Zeitplan aktualisiert wird, der wenig mit dem zu tun hat, was Kunden tatsächlich erleben.
Der Wert einer Statusseite konzentriert sich fast vollständig auf die Momente, in denen eine ehrliche Aktualisierung am unbequemsten ist: während einer laufenden Störung, wenn der Instinkt sagt, erst abzuwarten, ob sie sich schnell von selbst löst, bevor man sich öffentlich festlegt. Dieser Instinkt ist verständlich, und er ist zugleich genau das Gegenteil dessen, was eine Statusseite nützlich macht. Ein Entwickler, der während eines Ausfalls auf seiner Seite die Statusseite prüft, will so früh wie möglich wissen, ob das Problem bei ihm oder beim Anbieter liegt. Eine Seite, die eine Störung erst bestätigt, wenn sie vollständig verstanden und behoben ist, beantwortet diese Frage zu spät, um noch viel wert zu sein.
Wir halten es für ehrlich, eine Statusseite als operatives Werkzeug zu behandeln, das Kunden zur Verfügung gestellt wird, und nicht als Marketingfläche. Das bedeutet, eine echte Störung zu melden, wenn eine echte Störung stattfindet, noch bevor jedes Detail bekannt ist, und sie zu aktualisieren, während das Bild klarer wird, statt die Seite grün zu halten, bis eine saubere, vollständig abgeschlossene Zusammenfassung veröffentlicht werden kann. Eine grobe, frühe Bestätigung ist für jemanden, der gerade in Echtzeit sein eigenes System debuggt, nützlicher als eine polierte, verspätete.
Das hängt mit etwas zusammen, über das wir im gesamten Produkt nachdenken, nicht nur bei der Kommunikation von Störungen: Entwicklern Informationen zu geben, auf deren Grundlage sie handeln können, so nah an Echtzeit wie möglich. Kontingent-Header in jeder Antwort gibt es aus demselben Grund, aus dem eine Statusseite während einer Störung ehrlich sein sollte. Beides soll verhindern, dass jemand erst im Nachhinein etwas erfährt, das sein Handeln im Moment verändert hätte.
Eine Statusseite mit gelegentlichen gelben oder roten Einträgen spricht nicht gegen den Anbieter. Sie ist ein Beleg dafür, dass die Seite tatsächlich mit etwas Realem verbunden ist. Die Seite, die einen potenziellen Kunden eher beunruhigen sollte, ist die, die nie einen Makel zeigt, denn ein System mit wirklich null Störungen über einen nennenswerten Zeitraum ist so selten, dass das Fehlen von Störungen auf der Seite meist mehr über die Seite aussagt als über das System.