Als Inhaber von Simple Analytics halte ich es für sehr wichtig, das Vertrauen der Nutzer zu gewinnen. Es ist fast unmöglich, keine Fehler zu machen. Wenn ein Unternehmen also niemals seine Fehler mitteilt, sagt es Ihnen wahrscheinlich nicht die Wahrheit. Hier sind also meine.
Wenn Sie eine neue Funktion entwickeln, wollen Sie sie wahrscheinlich so schnell wie möglich bereitstellen, weil Sie zu aufgeregt sind, sie Ihren Kunden zu zeigen. Oder Sie fügen einen neuen Dienst zu Ihrem Server hinzu und wissen nicht, welche Auswirkungen er haben könnte. Letzteres ist mir passiert.
In den letzten Wochen habe ich eine neue Funktion namens Custom Domain eingeführt. Diese Funktion ermöglicht es den Benutzern von Simple Analytics, Werbe- und Tracking-Blocker zu umgehen. Ich bin der Meinung, dass Menschen die Möglichkeit haben sollten, Tracking zu blockieren, daher respektiert Simple Analytics die "Do Not Track"-Einstellung des Browsers. Leider wurde Simple Analytics zu einigen Datenschutz-Blockierlisten hinzugefügt - was meiner Meinung nach nicht fair ist, da wir den Datenschutz sehr ernst nehmen (Verlegung der Server in ein sehr datenschutzfreundliches Land: Island; Verschlüsselung unseres Datenbankservers; Entfernung von Daten aus der Datenbank, wenn ein Nutzer etwas löscht; Ermöglichung des Downloads von Daten). Die neue Funktion wurde also sehr begrüßt. Sobald sie bereitgestellt war, begannen einige Benutzer, sie zu nutzen.
Heute habe ich einen Fehler gefunden (zum Glück von mir selbst), als ich die Funktion "Benutzerdefinierte Domäne" verwendete, bei der das JavaScript geladen wurde, aber der API-Aufruf nach einem Passwort fragte. Ich habe mir die Website eines meiner Kunden angesehen ([excuseme.wtf](https://excuseme.wtf/?ref={{ site.hostname }})), von dem ich weiß, dass er die Funktion Benutzerdefinierte Domäne verwendet. Ich überprüfte seine Statistiken und musste mit Entsetzen feststellen, dass in der letzten Woche keine Besucher zu verzeichnen waren. Sofort begann ich, meine Server zu durchforsten, um nach Hinweisen zu suchen.
Aktuelle Einrichtung
Simple Analytics verwendet 4 Server, um alles so reibungslos wie möglich laufen zu lassen. Wir haben den Queue-Server, auf dem die Besuche von unseren JavaScripts gesammelt werden. Dies ist ein anderer Server als der Hauptserver, da der Hauptserver verschlüsselt ist. Wenn ein Server verschlüsselt ist, sollte er nur nach Eingabe eines Passworts booten (sonst ist die Verschlüsselung nutzlos). Für den unwahrscheinlichen Fall, dass ein Neustart erforderlich ist, möchte ich garantieren, dass keine Daten verloren gehen. Alle Daten werden an den Queue-Server gesendet, der sie dann an den Main-Server weiterleitet. Wenn der Hauptserver die Anfrage nicht annimmt, wird der Queue-Server die Anfrage in eine Warteschlange stellen (speichern), während der Hauptserver ein Backup durchführt.
Neben diesen Servern habe ich einen Testing-Server und einen External-Server. Der Testing-Server führt Akzeptanztests durch, um wichtige Abläufe und Endpunkte zu überwachen. Der External-Server wird für das Custom Domain-Feature benötigt. Aus Sicherheitsgründen möchte ich die SSL-Zertifikate der Kunden nicht auf demselben Server wie den Hauptserver haben.
Was ist schief gelaufen?
Ich beschloss, eine neue Überwachungsanwendung auf dem Queue-Server zu installieren, damit ich aus der Ferne überprüfen konnte, ob es Probleme mit dem Server gab. Außerdem erhielt ich so Einblicke in die CPU- und Speichernutzung. Ich fügte eine NGINX-Konfigurationsdatei für diese Anwendung hinzu, damit ich von außen auf sie zugreifen konnte. Wenn ich eine neue Anwendung hinzufüge, teste ich immer die NGINX-Konfiguration und lade sie bei Erfolg neu sudo nginx -t && sudo nginx -s reload. NGINX gab keine Fehlermeldung aus, so dass ich auf meine neu installierte Überwachungsanwendung zugreifen konnte; ich bin zufrieden.
Glücklicherweise habe ich ein Verzeichnis mit den NGINX-Protokollen, aus dem ich die meisten der verlorenen Anfragen wiederherstellen kann. Diese Protokolle enthielten damals weniger Informationen und zeichneten nur die Zeit, die URL und den Benutzeragenten auf.
Was habe ich getan, um zu verhindern, dass dieser Fehler erneut auftritt?
Obwohl dieser Fehler nicht viele Kunden betraf und keine großen Datenverluste zur Folge hatte, möchte ich alles tun, um dies in Zukunft zu verhindern. Der Fehler wurde durch das Hinzufügen einer anderen Anwendung auf demselben Server verursacht, für die keine Serverrichtlinie als Standardserver definiert war. NGINX versucht dann, einen Server als Standardserver auszuwählen und sendet die Anfragen an die auf diesem Server definierte Anwendung.
Zunächst fügte ich den Standardserver zur Listen-Direktive für Port 80 und 443 in der Hauptanwendung hinzu(nginx docs). Die Hauptanwendung auf diesem Server war die externe Anwendung, die die Zertifikate für die benutzerdefinierte Domänenfunktion verwaltet und mit einem Skript und einem API-Endpunkt antwortet, der keine Simple-Analytics-URLs verwendet, was es schwierig macht, ihn zu blockieren.
Zweitens habe ich den Protokollverlauf auf 90 Tage erhöht, damit ich Besuche für zukünftige Probleme wiederherstellen kann. Der Queue-Server und der Main-Server protokollieren jetzt jede fehlgeschlagene Anfrage von jedem. Das bedeutet, dass jede Anfrage, die einen HTTP-Code 5xx oder 4xx zurückgibt, in den Protokollen gespeichert wird und daraus wiederhergestellt werden kann. Es wird einige Arbeit erfordern, um dies bei Bedarf zu erledigen, aber es bedeutet keinen Datenverlust.
Ich habe Akzeptanztests für das Custom domain-feature hinzugefügt, die prüfen, ob beide Endpunkte noch wie erwartet funktionieren. Wenn das nicht der Fall ist, erhalte ich einen Anruf und eine Telegram-Nachricht.
Zu guter Letzt werde ich neue Funktionen als "Beta-Version" kennzeichnen, damit die Kunden wissen, dass sie Fehler haben können, da sie noch nicht für die endgültige Version fertiggestellt wurden. Daher liegt es an den Kunden, das Risiko einzugehen und die Funktion auf eigene Gefahr zu nutzen.
Ich habe mich mit den Kunden, die von diesem Fehler betroffen waren, in Verbindung gesetzt und ihnen angeboten, ihr Geld für diesen Monat zurückzugeben. Sie hielten das nicht für nötig und meinten, ich solle mir keine Sorgen machen. Ich habe mein Bestes getan, um die meisten ihrer Daten wiederherzustellen, und mit all den oben genannten Maßnahmen bin ich mir ziemlich sicher, dass so etwas nicht noch einmal passieren wird.
Lassen Sie uns die Transparenz im Zusammenhang mit Fehlern ändern, und ich glaube, dass die Leute Ihr Unternehmen ernster nehmen werden. Sie zeigen, was Sie getan haben und wie kompetent Sie sind. Manche Leute würden darüber streiten, ob das klug ist, aber ich sehe das als eine Gelegenheit, Transparenz zu zeigen.