Der Business Analyst als Bindeglied zwischen Entwicklung und stabilem Betrieb
Bevor ein System produktiv geht, sorgt der BA dafür, dass das Betriebsteam die Lösung fachlich verstehen, betreuen und weiterentwickeln kann. Er macht die Blackbox der Entwicklung transparent.
Die Recruiter-UI und der KI-Chat-Assistent dieser Arbeitsprobe greifen auf einen lokal betriebenen KI-/LLM-Server zurück. Dieser läuft auf einem kompakten Mini-PC mit der Modellbezeichnung „NAB9" (Intel i9-12900HK, integrierte GPU). Die Wahl fiel bewusst auf lokale Hardware, um ohne Cloud-Abhängigkeit und ohne laufende Betriebskosten zu arbeiten. Unter realer Last während der Entwicklung kam die Hardware thermisch und rechenseitig an Grenzen. Anstatt das mit grösserer Hardware zu erschlagen, wurde es als Operations-Fragestellung behandelt. Daraus entstand ein eigenes kleines agiles Projekt, das die OPS-Themen dieser Seite praktisch validiert: Monitoring, Alerting, Eskalation, Logging und Betriebsübergabe. Konzeptioneller Ursprung ist das Decision- und Process-Simulation-Framework.
Die Recruiter-UI und der KI-Chat-Assistent dieser Arbeitsprobe greifen auf einen lokal betriebenen KI-/LLM-Server zurück. Diese Wahl ist bewusst getroffen, um ohne Cloud-Abhängigkeit und ohne laufende Betriebskosten zu arbeiten. Während der Entwicklung zeigte sich, dass die kompakte Hardware (Intel i9-12900HK, integrierte GPU) unter realer Last thermisch und rechenseitig an Grenzen kommt.
Anstatt das Problem mit grösserer Hardware zu lösen, wurde es als Operations-Fragestellung behandelt: Wie würde ein Betriebsteam diesen Server überwachen? Wann muss eskaliert werden? Wie reduziert man Fehlalarme? Wie übergibt man das Ganze sauber an OPS? Daraus wurde ein eigenes kleines agiles Projekt mit Epic, sechs Sprints und 15 User Stories.
Parallel entstand eine klare Skalierungs-Roadmap: Die lokale NAB9-Hardware reicht für eine Demo bis zu fünf Agents. Für die „Hardcore Full Simulation Group" mit 16 Agents wird die Plattform in einen GPU-Cloud-Pod (2× RTX 3090) ausgelagert. Endstation ist der direkte Zugriff auf produktive Online-Modelle. Roadmap-Details auf der NAB9-Detailseite.
Sensor-Rohwerte sind für den Betrieb nicht nutzbar. Der PoC übersetzt Temperatur und Last in vier klare Betriebszustände: OK · WARN · CRIT · SENSORERROR. Schwellwerte sind konfigurierbar und ohne Code-Anpassung änderbar.
Ohne Hysterese würde das System bei Temperaturschwankungen um die Schwelle herum ständig zwischen OK und WARN wechseln. Mit Hysterese erfolgt ein Downgrade erst, wenn die Temperatur klar unter Schwelle − Hysterese fällt. Das verhindert Flatter-Alarme.
Overshoot erzeugt ein zusätzliches Label (WARN_OS, CRIT_OS),
wenn der Wert deutlich über der Schwelle liegt. Der Betrieb erkennt damit nicht nur „Warnung",
sondern „kritische Warnung mit Überschuss", ohne dass das Statusmodell dadurch komplexer wird.
Eine einzige Sensorquelle ist ein Single Point of Failure. Der PoC nutzt eine Kaskade:
Jeder Quellen-Fehler wird einzeln protokolliert, damit OPS unterscheiden kann, ob das Monitoring oder die Hardware das Problem ist.
Der Operations-Kanal erhält strukturierte Alerts mit Host, Statuslabel, CPU-Temperatur, Load, Zeitstempel und Sensorquelle. Dank Statefile und Hysterese werden Meldungen nur bei echten Statuswechseln gesendet, nicht bei jeder Messung.
Jeder Skriptlauf, jeder Statuswechsel, jeder Sensorfehler und jeder Telegram-Versand wird protokolliert. Eine konfigurierbare Log-Retention entfernt alte Einträge automatisch, sodass das Logfile langfristig wartbar bleibt.
Die strukturierten Alert-Felder sind so vorbereitet, dass sie sich später in ein ITSM-/Ticket-System überführen lassen. Sie sind konzeptionell anschlussfähig an Jira-/Servicedesk-Prozesse.
Auch ein kleines Betriebsprojekt verdient saubere Struktur. Der PoC wurde als Epic „Local LLM Runtime Monitoring Platform" mit sechs Sprints und 15 User Stories aufgesetzt, inklusive Acceptance Criteria und technischen Tasks.
So entstand aus einem realen Last-Problem nicht ein Quickfix, sondern ein nachvollziehbares, übergabefähiges Betriebsmodell.
Auf der NAB9-Detailseite finden Sie die technische Tiefe: Skriptaufbau, Sensor-Stack, Alert-Logik, Telegram-Beispiele und das vollständige Story-/Sprint-Backlog.
NAB9 Detailseite öffnen →Was im NAB9-PoC als „Vorbereitung für ITSM/Ticket-Integration" beschrieben ist, läuft hier produktiv: ein eigener Servicedesk-Touchpoint. Er ist offen für Fragen, Feedback oder direkte Kontaktaufnahme.
OPS-Übergabe ist kein Abschluss, sondern ein Stabwechsel. Der BA stellt sicher, dass das System nicht nur läuft, sondern verstanden wird.