Beispiele

Vier Fälle aus dem Alltag der Beispiel GmbH, Schritt für Schritt, mit Bildern aus der Anwendung. Jeder zeigt, was ein Mensch eingibt und was Heinzel Pro daraufhin tut: einmal ganz allein, dreimal mit Freigabe.

Die Stufe steht an jedem Beispiel. Lesende Befehle laufen auf jeder Stufe sofort; was etwas ändert, wartet auf rw- auf einen Menschen und läuft auf rwx allein. Was die Stufen genau bedeuten, steht unter Sessions.

Backup-Alarm um 02:10 Uhr

Das nächtliche Backup ist fehlgeschlagen, die Bereitschaft wird geweckt. Statt sich anzumelden und zu suchen, tippt sie einen Satz ins Handy. Heinzel Pro liest, findet die Ursache und wartet mit der Reparatur auf einen Tipp.

Schritt 1: Sie beschreiben das Problem

Eingabe: Ich habe gerade einen Alarm bekommen. Wir haben 02:10 Uhr. Warum geht das Backup auf backup2 nicht?

Kein Befehl, kein Fachbegriff. Sie wählen den Server aus der Liste und lassen die Stufe auf „Fragt vor Änderungen“: Heinzel Pro liest allein, jede Änderung wartet auf Sie.

Schritt 2: Heinzel Pro liest, ohne zu fragen

Lesende Befehle laufen sofort. Jeder trägt seine Einstufung und bleibt im Protokoll, mit Ausgabe und Dauer.

Drei Befehle später steht die Ursache: Das Backup meldet sich per Kerberos am Dateiserver an, und Kerberos lehnt ab, wenn die Uhr mehr als fünf Minuten abweicht. Die Uhr von backup2 geht sechs Minuten nach, weil der Zeitserver nicht mehr antwortet.

Schritt 3: Heinzel Pro schlägt vor und wartet

Der nächste Befehl ändert etwas, also wartet er. Die Bereitschaft bekommt eine Nachricht und sieht auf dem Handy, was laufen soll und warum: Zeitserver umstellen, Uhr stellen lassen, Backup nachholen. Zwei Knöpfe, Freigeben oder Ablehnen.

Schritt 4: Sie geben frei, Heinzel Pro macht fertig

Ein Tipp. Der Befehl läuft siebzehn Minuten, weil das Backup an ihm hängt. Danach prüft Heinzel Pro Uhr und Log, schreibt ins Journal des Servers, was war und was offen bleibt, und meldet sich ab.

Die nächste Session auf backup2 liest dieses Journal, ob in einer Woche oder in einem Jahr.

Sicherheitsupdates jede Nacht

Zwölf Webserver, jede Nacht um drei. Niemand schaut zu, niemand wird geweckt. Was Heinzel Pro nicht allein entscheiden darf, lässt es stehen und meldet es; am Morgen liegt eine Mail vor.

Schritt 1: Sie legen den Zeitplan an

Eingabe: Spiele auf allen Servern die anstehenden Sicherheitsupdates ein und prüfe danach, ob alle Dienste laufen. Was das Journal eines Servers ausnimmt, lass stehen und melde es als Befund.

Einmal, am Tag. Name, Servergruppe, Uhrzeit, die Aufgabe in Ihren Worten, die Stufe „Ändert allein“ und wohin der Bericht geht. Mehr nicht.

Schritt 2: Um drei Uhr liest Heinzel Pro auf allen zwölf

Der Zeitplan öffnet eine Session über die ganze Gruppe. Heinzel Pro sieht auf jedem Server nach, was ansteht, und liest das Journal des Servers.

Auf web07 hat ein Kollege im März zwei PHP-Pakete zurückgehalten, weil eine Fachanwendung nach dem Update nicht mehr antwortete. Das steht im Journal, also hält sich Heinzel Pro daran.

Schritt 3: Es spielt ein, was es darf, und hält an, wo das Journal es sagt

Auf allen zwölf Servern laufen die Updates allein durch; auf web07 bleiben die zwei gehaltenen Pakete stehen. Danach prüft Heinzel Pro, ob irgendwo ein Dienst fehlgeschlagen ist.

Was zurückbleibt, wird ein Befund in der Liste, keine Mail um drei.

Schritt 4: Morgens lesen Sie den Bericht

Eine Mail kurz nach drei, gelesen um acht: zwölf Server aktualisiert, alle Dienste laufen, ein Befund auf web07. Wie es damit weitergeht, zeigt das nächste Beispiel.

Ein Befund wird behoben

Der Nachtlauf hat auf web07 zwei Sicherheitsupdates stehen lassen, weil das Journal es verlangte. Am Vormittag wird daraus mit einem Klick eine Session: Heinzel Pro liest nach, schlägt zwei Wege vor, Sie entscheiden.

Schritt 1: Sie öffnen den Befund

Die Seite Befunde sammelt, was die Nachtläufe nicht allein entscheiden durften, mit Schweregrad und einem Vorschlag, was zu tun wäre. Ein Klick auf „Neue Session zum Beheben öffnen“, nichts zu tippen.

Schritt 2: Die Session ist vorbereitet

Server, Aufgabe und der Befund stehen schon drin. Die Stufe bleibt auf „Fragt vor Änderungen“, denn diesmal soll ein Mensch entscheiden. Sie starten.

Schritt 3: Heinzel Pro liest nach und schlägt zwei Wege vor

Es findet im Changelog der Anwendung, warum das Update im März schiefging, und dass der Grund seit Mai behoben ist. Dann zwei Wege: heute die zwei Pakete aktualisieren, oder die Anwendung auf PHP 8.3 heben. Es empfiehlt den ersten und wartet.

Schritt 4: Sie antworten und geben frei

Eingabe: Erster Weg. Den zweiten bitte als Befund festhalten, damit wir ihn nächsten Monat angehen.

Heinzel Pro aktualisiert, startet den Dienst neu, prüft die Anmeldeseite der Anwendung und schreibt das Journal. Der Befund aus der Nacht ist geschlossen, und der neue steht mit Ihrem Satz in der Liste, für nächsten Monat.

php2shell auf 13 Servern

Zwei Lücken in PHP, am Nachmittag veröffentlicht, jede Webanwendung betroffen. Ein Satz vom Handy, und Heinzel Pro recherchiert, prüft jeden Server und spielt den Fix ein: erst auf einem, nach Ihrem Los auf allen.

Schritt 1: Sie beschreiben die Aufgabe, für alle Server

Eingabe: Recherchiere php2shell und fixe das Problem auf allen davon betroffenen Servern.

Ein Satz, wie Sie ihn einem Kollegen schreiben würden. „Dasselbe auf vielen“ macht daraus einen Rollout: eine Session je Server, erst auf web01, die anderen nach Ihrem Los. Die Stufe bleibt „Fragt vor Änderungen“.

Schritt 2: Es recherchiert, und selbst dafür fragt es

Heinzel Pro will die Meldung von php.net lesen. Ein Abruf aus dem Netz kann auch Daten senden, also wartet er auf Ihren Tipp. Danach liest es allein: welche PHP-Pakete auf web01 liegen, ob die neue Version schon im Spiegel ist, welche Dienste laufen.

Dann steht es: web01 ist betroffen, PHP 8.2.29 als php-fpm hinter nginx, und der Fix liegt bereit.

Schritt 3: Sie lesen den Plan und geben ihn frei

Drei Schritte, jeder mit Befehl, Server und Einstufung: Paket, Dienst, nur lesen. Dazu, was schiefgehen kann und wie es zurückgeht. Ein Tipp gibt alle drei frei; sie laufen in dieser Reihenfolge, jeder erst, wenn der vorige gelang.

Schritt 4: Nach Ihrem Los folgen die anderen zwölf

web01 ist nach 24 Sekunden dicht, das Portal antwortet mit 200. Sie sagen Los, und die anderen Server bekommen je eine eigene Session, vier gleichzeitig. Was auf web01 freigegeben wurde und gelang, läuft dort ohne Nachfrage. backup2 hat kein PHP: seine Session meldet das und ändert nichts.

Ein fünftes Beispiel als Film

Die Datenbank zieht um, während die Webseite läuft: 55 Sekunden auf heinzel-pro.de, aus einer Session in Heinzel Pro.