Schulungen

Manche Fehler zeigen sich erst, wenn man wie ein Nutzer handelt: ein Login-Formular, das gültige Zugangsdaten ablehnt, ein Dashboard, das leer lädt, ein Checkout, der nach dem Warenkorb einen Fehler liefert. Eine einfache HTTP-Prüfung sieht das nicht.

In diesem Video erstellen Sie eine JavaScript-Prüfung in SolidPing. Das Skript läuft in einer isolierten Engine, lädt eine Login-Seite, meldet sich mit einem Testkonto an und prüft, was das Dashboard anzeigt. Sie sehen, wie Sie das Passwort als verschlüsseltes Secret speichern, wie Sie das Skript mit „Run now“ testen und wie ein fehlgeschlagener Schritt im Ergebnis angezeigt wird.

JavaScript-Prüfungen laufen einmal pro Intervall in jeder Region, öffnen Incidents wie jede andere Prüfung und benachrichtigen Ihre Kanäle.

Beschreiben Sie in einfachen Worten, was Sie überwachen möchten, und lassen Sie SolidPing die Prüfung schreiben.

In diesem Video nutzen Sie die KI-Engine: Sie schreiben eine Beschreibung in einem Satz, prüfen den vorgeschlagenen Vertrag aus Assertions und sehen zu, wie sie die Seite erkundet und live ein Skript testet. Das Ergebnis speichern Sie als normale JavaScript-Prüfung. Danach läuft das Skript wie jede andere Prüfung auf den Workern, ohne KI-Aufruf pro Durchlauf.

Ändert das Ziel seine Seiten und das Skript bricht, kann SolidPing es reparieren. Eine Reparatur startet nur, wenn das Skript selbst kaputt ist (es findet ein Feld oder eine Seite nicht mehr), 3 Läufe in Folge, während die Website antwortet. Ein echter Ausfall löst also nie eine aus. Die KI schreibt das Skript mit demselben Vertrag neu, und die neue Version muss einen Prüflauf bestehen, darf keinen neuen Host kontaktieren und muss weiterhin einen Ausfall melden können. Den Modus wählen Sie unter „Wenn das Skript abweicht“: „Reparatur vorschlagen“ (Standard) wartet auf Ihre Freigabe auf der Verlaufsseite der Prüfung, „Automatisch reparieren“ wendet sie an, löst den Vorfall beim nächsten Lauf auf und schickt Ihnen den Diff per E-Mail.

Die Funktion setzt einen auf dem Server konfigurierten KI-Anbieter voraus. Ohne ihn ist der Button ausgeblendet.

Cloud-Worker erreichen keine Datenbank in einem privaten Netz, keinen Host, der nur per VPN erreichbar ist, und kein abgeschottetes Segment. Private Standorte lösen das: Sie betreiben einen SolidPing-Agent in Ihrem Netz, und er führt die Prüfungen für Sie aus.

In diesem Video erstellen Sie einen privaten Standort, erzeugen ein einmalig gültiges Registrierungstoken, starten einen Agent und führen eine Prüfung darüber aus. Der Agent baut selbst eine ausgehende WebSocket-Verbindung auf, ein eingehender Port ist also nicht nötig. Er kann nur Jobs abholen und Ergebnisse senden, und Secrets von Prüfungen, die nur privat laufen, werden mit den Schlüsseln der Agents verschlüsselt, sodass der Server sie nicht entschlüsseln kann.

Eine TCP-Prüfung auf Port 3389 beweist nur, dass ein Port offen ist. Die RDP-Prüfung führt den Remote-Desktop-Handshake vor der Authentifizierung aus, eine gültige Antwort beweist also, dass der Dienst die Anfrage wirklich verarbeitet hat.

In diesem Video erstellen Sie eine RDP-Prüfung, führen sie aus, lesen das ausgehandelte Sicherheitsprotokoll (TLS, NLA usw.) und das Ablaufdatum des Serverzertifikats, und stoppen dann den Dienst, um zu sehen, wie die Prüfung auf „down“ geht und ein Incident öffnet. Es sind keine Zugangsdaten nötig und es wird keine Sitzung geöffnet, Ihre Windows-Ereignisprotokolle füllen sich also nicht mit Anmeldefehlern.

RDP-Hosts sind meist privat: Führen Sie die Prüfung von einem Worker oder privaten Agent aus, der sie erreicht.

Die VNC-Prüfung spricht das echte RFB-Protokoll: Er liest das Banner, handelt eine Version aus und listet die Authentifizierungsmethoden, die der Server anbietet. Ein Server ohne Authentifizierung gilt standardmäßig als „down“, denn ein offener Desktop ist fast immer ein Fehler.

In diesem Video führen Sie eine reine Handshake-Prüfung aus, fügen dann ein Passwort hinzu, damit sich die Prüfung anmeldet und Namen und Größe des Desktops meldet, und aktivieren schließlich die Screenshot-Option, um ein Bild des Desktops an das Ergebnis anzuhängen.

Während eines Ausfalls ist der schlechteste Ort für Kontext ein Kanal mit fünf verstreuten Nachrichten. SolidPing führt einen Slack-Thread pro Incident.

In diesem Video verbinden Sie Slack, ordnen einer Prüfung einen Kanal zu und sehen, wie ein Incident als Nachricht mit einem Acknowledge-Button erscheint. Sie bestätigen ihn direkt in Slack, fügen mit dem Slash-Befehl einen Kommentar hinzu und sehen die Wiederherstellung im selben Thread. Kommentare aus dem Dashboard erscheinen ebenfalls als Antworten im Thread.

Ein Bereitschaftsplan beantwortet eine einfache Frage: Wer ist gerade zuständig?

In diesem Video erstellen Sie eine wöchentliche Rotation mit einer Übergabezeit in Ihrer eigenen Zeitzone, fügen drei Personen hinzu, sehen, wer jetzt und als Nächstes Bereitschaft hat, legen eine Vertretung für eine Schicht an und veröffentlichen den Plan als iCal-Feed für Ihren Kalender. Übergaben folgen der Ortszeit, die Sommerzeit verschiebt Ihre Schichten also nicht.

Jemanden zu alarmieren ist einfach. Sicherzustellen, dass jemand reagiert, ist der schwierige Teil. Eine Eskalationsrichtlinie ist eine geordnete Liste von Schritten mit Wartezeiten, und jeder Schritt kann mehrere Ziele gleichzeitig benachrichtigen: einen Nutzer, einen Bereitschaftsplan oder einen Kanal.

In diesem Video bauen Sie eine Richtlinie mit drei Schritten (die Person in Bereitschaft, nach zehn Minuten eine namentlich genannte Person, nach zwanzig Minuten ein Team-Kanal), ordnen sie einer Prüfung zu, lösen einen Incident aus und lesen die Zeitleiste. Wird der Incident im Dashboard, in Slack oder in Telegram bestätigt, entfallen die ausstehenden Schritte.

Eine Statusseite sagt Ihren Kunden, was los ist, damit sie nicht mehr bei Ihnen nachfragen.

In diesem Video erstellen Sie eine Statusseite, gliedern sie in Abschnitte, fügen Komponenten hinzu und stellen einen Abschnitt auf automatische Zuordnung um (alle Prüfungen, nach Label oder nach Gruppe), damit neue Prüfungen ohne Handarbeit erscheinen. Dann öffnen Sie die öffentliche Seite, sehen, wie sie auf eine fehlschlagende Prüfung reagiert, und veröffentlichen ein Incident-Update.

Die automatische Aufnahme auf eine öffentliche Seite ist eine Entscheidung darüber, was Sie veröffentlichen: Aktivieren Sie sie nur für Abschnitte, die Sie gern öffentlich zeigen.

Ein Datenbankausfall sollte mitten in der Nacht nicht vier Alarme auslösen.

In diesem Video legen Sie Abhängigkeiten zwischen Prüfungen an. Eine harte Abhängigkeit besagt, dass der Ausfall eines Elternteils den Ausfall seiner Kinder verursacht: Die Incidents der Kinder erscheinen weiter in der Zeitleiste, alarmieren aber niemanden. Eine weiche Abhängigkeit hält nur eine Korrelation fest, der Incident alarmiert trotzdem. Sie sehen die Wirkung, wenn eine Datenbank ausfällt, wie die Bündelung funktioniert, auch wenn das Elternteil seinen Ausfall als Letztes bestätigt, und was passiert, wenn es sich erholt.

Erreichbar zu sein reicht nicht. Ist es erreichbar genug? Ein SLO legt ein Ziel fest, zum Beispiel 99,9 % pro Monat, und SolidPing verfolgt das Fehlerbudget: wie viele Fehler Sie sich noch leisten können, wie schnell Sie es verbrauchen und wann es aufgebraucht sein wird.

In diesem Video legen Sie ein Ziel für eine Prüfung an, lesen die Statuskarte (Zielerreichung, verbrauchtes Budget, Rest, Statusanzeige), verstehen die Burn Rate und das voraussichtliche Aufbrauchdatum und lesen das Burn-down-Diagramm. Geplante Wartungen sind standardmäßig ausgenommen, und Sie können sich die Zahlen regelmäßig als Verfügbarkeitsbericht per E-Mail schicken lassen.

E-Mail ist der eine Kanal, den jeder schon hat.

In diesem Video legen Sie einen E-Mail-Kanal an und ordnen ihn einer Prüfung zu. Sie sehen die Incident-E-Mail, wenn eine Prüfung fehlschlägt, und die Entwarnung, wenn er sich erholt: zwei Nachrichten pro Incident, nicht eine pro fehlgeschlagener Prüfung. Ein Incident, der wegen einer ausgefallenen Abhängigkeit unterdrückt wird, verschickt nichts. Danach planen Sie einen wöchentlichen Verfügbarkeitsbericht und lesen die Zusammenfassung: Verfügbarkeit im Vergleich zum Vorzeitraum, Incident-Übersicht und Stand Ihrer Fehlerbudgets.