Betrieb & DevOps

04 · Aus der Praxis

Drei Fälle aus dem Betrieb.

Der Fehler, der nur an manchen Tagen auftrat und im Durchschnitt verschwand.

Eine Schnittstelle, über die Antworten an Nutzer ausgeliefert werden, zeigte an einzelnen Tagen eine deutlich erhöhte Fehlerquote, an den meisten Tagen null. Im Wochenmittel war davon nichts zu sehen, Beschwerden gab es keine. Der Agent fand das Muster in den Protokollen, verband es mit einer passenden Meldung aus der Fehler-Überwachung und bezifferte, was es bedeutet. Die Ursache lag tiefer als seine erste Vermutung: Ein vorgelagerter Dienst lieferte dieselbe Nachricht mehrfach innerhalb weniger Millisekunden, wodurch parallele Sitzungen mit unterschiedlichen Zugangsschlüsseln entstanden und die zweite abgewiesen wurde. Der Fix ist ausgeliefert.

Ein Angriff, erkannt bevor er teuer wurde.

Automatisierter Fremdzugriff auf einen öffentlichen Endpunkt, in drei Tagen auf das Zehnfache des Normalwerts gestiegen. Der Agent belegte anhand der Daten, dass es Bots waren und nicht Wachstum: zielgruppenfremde Herkunftsländer, vollständig als „organisch“ ausgewiesen, und vor allem keine Konversion. Er bewertete den Schaden nüchtern und lieferte drei Gegenmaßnahmen in der Reihenfolge ihrer Eignung, für die empfohlene die fertigen Konfigurationszeilen auf Gateway-Ebene, ohne dass dafür neu ausgeliefert werden musste. Vier Tage vom Ticket bis erledigt.

Der Fall, in dem die richtige Antwort lautete: nicht entwickeln.

Nach dem Rollout einer neuen App-Version häuften sich Fehler beim Bezahlvorgang. Der naheliegende Reflex: Rollout stoppen. Der Agent schlüsselte die Betroffenen stattdessen nach Gerät und Betriebssystemstand auf und fand, dass die große Mehrheit auf einer Vorabversion des Handy-Betriebssystems lief, die mit der Bezahl-Bibliothek des Plattformbetreibers nicht zusammenarbeitet. Kein Fehler im eigenen Code. Die Empfehlung lautete entsprechend nicht „stoppen“, sondern vollständig ausrollen. Dieser Fall endete ohne eine einzige Zeile Entwicklungsarbeit. Ein Team unter Zeitdruck hätte den Rollout gestoppt und tagelang im eigenen Code gesucht.

06 · Wer entscheidet was

Wer entscheidet was.

Auffälligkeit finden → Ursache eingrenzen → Wirkung beziffern → Ticket mit Belegen und Vorschlag anlegen → bewerten und priorisieren → umsetzen → freigeben → testen → Wirkung nachmessen

Die hervorgehobenen Schritte liegen beim Menschen, gesetzt über die vergebenen Rechte. Der Betriebs-Agent deployt nicht (Release- und Konfigurationsvariablen der Produktion sind gesperrt), schreibt keinen Produktivcode (sein Zugang zur Code-Verwaltung steht auf der niedrigsten schreibenden Stufe: Tickets und Kommentare), priorisiert nicht und entscheidet nicht über Geld oder Personal.

Jede Agenten-Aktion landet mit Zeitstempel im Aktivitätsprotokoll. Jedes maschinell erzeugte Ticket trägt eine Kopfzeile mit dem auslösenden Menschen, das ist im Werkzeug erzwungen, ein Ticket ohne diese Zuordnung kann nicht entstehen.

08 · Grenzen

Grenzen, und was sich mit der Zeit ändert.

Ein Agent ist so gut wie seine Datenquellen. Er erkennt einen Fehler in den Daten, aber nicht ohne Weiteres deren Ausbleiben: Liefert eine Quelle still nichts mehr, entsteht ein Bericht, der normal aussieht und trotzdem leer ist. Wer Überwachung einführt, muss die Überwachung mitprüfen. Deshalb gehört eine Vollständigkeitsprüfung von Anfang an dazu.

Das Tempo bestimmt nicht der Agent. Seinen Teil liefert er in Minuten. Bis daraus eine ausgelieferte Änderung wird, vergeht die Zeit, die Bewertung, Freigabe und Release-Rhythmus brauchen. Der Gewinn liegt am Anfang der Kette, nicht am Ende.

Die ersten Wochen sind die teuersten. Am Anfang kennt das Team weder die Eigenheiten der Daten noch die stillen Konventionen des Betriebs: welche Ausschläge normal sind, welche Systeme wann gewartet werden, welcher Befund wen etwas angeht. Jede Korrektur wird als Regel hinterlegt und gilt ab dann. Wer nach zwei Wochen bewertet, sieht die Lernkurve, nicht das Ergebnis.