Was genau überwachen Sie?
Den Weg einer Anfrage bis zu einem Menschen, nicht die Verfügbarkeit des Servers. `GET /api/health/contact` prüft mit einer einzigen Anfrage zwei Dinge: dass das Token des Benachrichtigungskanals noch gültig ist — über einen echten Aufruf beim Anbieter, mit einem Timeout von 8 Sekunden — und dass das Anfragenprotokoll geschrieben werden kann. Es antwortet mit 200, wenn beides wahr ist, und mit 503, wenn nicht. Sie können es genau jetzt auf dieser Website aufrufen: Es ist öffentlich, gerade weil es nur logische Werte zurückgibt.
Warum würde ein Formular ausfallen, ohne dass es jemand bemerkt?
Weil der sichtbare Teil weiter funktioniert. Die Seite lädt, der Button reagiert, der Server gibt auf allen Seiten 200 zurück — nur die letzte Verknüpfung bricht, die keine Oberfläche hat. Auf dieser Website wurde das Token des Benachrichtigungs-Bots widerrufen: Der Anbieter antwortete mit `401 Unauthorized`, die Route gab 500 zurück, und die Anfrage wurde nirgendwo geschrieben. Drei reale Ausfälle in etwa sieben Stunden, nur im Fehlerprotokoll des Prozesses sichtbar. Deshalb wird das Protokoll jetzt vor der Zustellung geschrieben: Selbst wenn die Benachrichtigung ausfällt, existiert die Anfrage.
Was passiert, wenn die Benachrichtigung nach Ihrer Reparatur fehlschlägt?
Die Anfrage ist bereits mit einer eigenen Kennung im Protokoll geschrieben, und die zweite Zeile im Protokoll sagt `failed` und den Grund. Dem Besucher wird getrennt geantwortet — „Wir haben die Anfrage erhalten, konnten aber nicht benachrichtigen“ — nicht mit einem falschen Erfolg. Der Antwortcode unterscheidet die Ursache: 502 bedeutet, dass der Anbieter schlecht geantwortet hat, 503, dass uns die Zugangsdaten fehlen. Um 3 Uhr morgens entscheidet der Unterschied zwischen den beiden, ob Sie jemanden anrufen oder nicht.
Aktualisieren Sie Abhängigkeiten automatisch?
Nicht ohne Freigabe. Die Veröffentlichung führt `npm audit` auf `high`-Niveau aus und bricht bei Schwachstellen dieses Niveaus ab, wenn das Fortsetzen nicht ausdrücklich bestätigt wird; zuerst prüft sie auch den verfügbaren Speicher des Servers, mit einer Schwelle von 500 MB, denn ein Build auf einem engen Server lässt die Anwendung angehalten. Der Build erfolgt aus einem sauberen Zustand: Das Build-Verzeichnis und die Abhängigkeiten werden gelöscht, die Installation erfolgt aus der Lock-Datei. Was automatisch aktualisiert wird und was eine manuelle Prüfung durchläuft, wird pro Projekt festgelegt, nicht standardmäßig.
Woran erkennen Sie, dass eine Veröffentlichung nichts anderes beschädigt hat?
Durch ein nach der Veröffentlichung ausgeführtes Prüfskript, das jede Produktseite öffnet und fehlschlägt, wenn der 200-Code, der Fragen-Anchor, der Beispiel-Anchor oder die kanonische Adresse fehlt. Danach prüft es die Sitemap — ob jedes Produkt enthalten ist und keine Sprachvarianten enthält, die sich nicht öffnen lassen — sowie `robots.txt`, damit keine Rendering-Ressourcen blockiert werden. Jede Prüfung in der Liste entspricht etwas, das schon einmal kaputtgegangen ist. Das Skript wird mit dem Projekt übergeben.
Was tun Sie, wenn die Anwendung blockiert oder Speicher verbraucht?
Der Prozess wird automatisch neu gestartet, wenn er die Schwelle von 500 MB überschreitet, mit 4 Sekunden Verzögerung zwischen den Versuchen und exponentiellem Wachstum, stoppt aber nach 10 instabilen Neustarts in einem kurzen Zeitraum. Das ist wichtig: Eine Ausfallschleife, die unendlich neu startet, sieht in einem Dashboard gesund aus und verbraucht den Server stillschweigend. Wir bevorzugen, dass der Prozess angehalten und sichtbar bleibt.
Wie lange bewahren Sie die Formulardaten auf und wer kann sie lesen?
24 Monate, per Code angewendet, nicht nur erklärt: Die Schwelle ist eine Variable mit dem Standardwert 730 Tage, und ältere Dateien werden bei jedem neuen Schreiben gelöscht, ohne einen Planer, der vergessen werden kann. Das Verzeichnis hat die Rechte `0700`, die Dateien `0600`, und der Pfad liegt außerhalb des Versionsverzeichnisses, damit die Historie die Veröffentlichung überlebt. Die IP-Adresse wird nicht vollständig gespeichert: Sie wird bei IPv4 auf `/24` und bei IPv6 auf `/48` gekürzt, indem der letzte Hop im Header gelesen wird, nicht der erste — der erste wird vom Client gesendet und bedeutet nichts.
Finden Sie auch Probleme, die wir nicht gemeldet haben?
Das passiert, und normalerweise sind das die teuren. Derselbe Code-Durchlauf, der das Formular repariert hat, hat zwei Dinge aufgedeckt, die niemand gemeldet hatte: Das Anfragenlimit ließ sich vollständig umgehen, weil das erste Element aus dem Header der weitergeleiteten Adressen gelesen wurde — genau das, was der Client sendet; und eine Route, die Telefonanrufe initiiert, war anonym offen, auf unsere Kosten, obwohl die Komponente, die sie nutzte, bereits entfernt worden war. Beides wurde repariert und in der Produktion überprüft. Was wir nicht versprechen können, ist, dass wir alles finden; was wir versprechen können, ist, dass wir auch das melden, was Sie nicht angefordert haben.
Was deckt die Wartung nicht ab?
Kein Sicherheitsdienst mit 24/7-Überwachung und kein Operations Center. Wir garantieren keinen Verfügbarkeitsprozentsatz ohne eine Messung, die ihn stützt — und, um es klar zu sagen, im Moment veröffentlichen wir für die eigene Website keine solche Zahl. Wir übernehmen nicht die Verantwortung für eine Drittplattform, auf die wir keinen Zugriff haben. Und wir behandeln eine Seite, die 200 antwortet, nicht als Beweis dafür, dass alles funktioniert: Genau das war das Problem, von dem alles oben Geschriebene ausgegangen ist.