Direkt zum Hauptinhalt

myLab Service-Level

Diese Service-Level werden pragmatisch gelebt: Das myLab arbeitet mit sehr wenig Personal. Die Level beschreiben, was Du realistisch von einem Dienst erwarten kannst – von „Sandkasten zum Ausprobieren" bis „dauerhaft betriebenes Flaggschiff".

Die drei Level auf einen Blick

🟣 Experimentell 🔵 Pilotbetrieb 🟢 Etabliert
Charakter Explorativer Sandkasten & Entry-Level Strukturierte Erprobung im Live-Betrieb Stabiler Dauerbetrieb
Betrieb Kein garantierter Betrieb Im Rahmen verfügbarer Ressourcen Dauerbetrieb, geplante Wartungsfenster
Monitoring Optional, nach Ermessen Verbindliches Uptime-Monitoring Verbindliches Uptime-Monitoring
Reaktionszeit Keine zugesichert Angestrebt 2–3 Arbeitstage (meist schneller) Angestrebt 24 h an Arbeitstagen
Abkündigung Jederzeit, ohne Vorankündigung Zum Semesterende; mind. bis Semesterende gesichert Mind. ein Semester im Voraus

🟣 Experimentell (Sandbox)

Charakter: experimentell / explorativ – unser Sandkasten zum Spielen und der Entry-Level für alles, was neu ins myLab kommt.

  • Experimentelle Systeme (z. B. Codepad, während Corona als „Krücke" für Online-Formate zum schnellen Austausch von Code-Snippets entstanden; oder n8n und AIStor/MinIO S3 Storage, die wir gerade initial erproben).
  • Individuelle Betreuung durch den Betreiber (meist die Personen, die den Dienst selbst nutzen) – nicht notwendigerweise mit personeller Hinterlegung im myLab.
  • Kein garantierter Betrieb.
  • Keine zugesicherte Reaktionszeit (nach Verfügbarkeit des Betreibers).
  • Kein verbindliches Uptime-Monitoring (nach Ermessen des Betreibers).
  • Kann jederzeit ohne Vorankündigung abgeschaltet werden.
  • Dient Tests, Prototyping und frühen Pilotphasen sowie ggf. der Einphasung in den regulären myLab-Betrieb.
  • Bewährt sich der Dienst und besteht breiterer Bedarf, wandert er in die Stufe Pilotbetrieb (ansonsten bleibt er hier oder wird eingestellt).

🔵 Pilotbetrieb (Evaluation)

Charakter: Pilotbetrieb / strukturierte Erprobung – könnte wirklich etwas sein; wir schauen es uns genauer an und investieren Ressourcen.

  • Der Dienst wird produktiv erprobt (z. B. unsere AI-Services im Rahmen der Campus-Plattform).
  • Verbindliches Uptime-Monitoring (ggf. noch nicht für alle erforderlichen Subkomponenten).
  • Reaktionszeit innerhalb von 2–3 Arbeitstagen angestrebt (meist schneller).
  • Betrieb im Rahmen verfügbarer Personal-Ressourcen (meist noch als Zusatzaufgabe zu „Etabliert"-Aufgaben).
  • Geplante Änderungen oder Abschaltungen werden zum Ende eines Semesters angekündigt; der Betrieb wird mindestens bis zum Ende des laufenden Semesters sichergestellt.
  • Ziel: Erfahrungen im Live-Betrieb und Nutzerbedarf sammeln – und über die Überführung in Etabliert oder die Einstellung entscheiden.

🟢 Etabliert (Graduated)

Charakter: etabliert / dauerhaft betrieben.

  • Stabile Systeme im dauerhaften Betrieb (z. B. GitLab oder JupyterHub – unsere beiden Flaggschiffe).
  • Verbindliches Uptime-Monitoring.
  • Reaktionszeit innerhalb von 24 h an Arbeitstagen angestrebt (in VL-freien Zeiten kann es länger dauern).
  • Geplante Wartungsfenster.
  • Abschaltung wird mindestens ein Semester im Voraus angekündigt (das laufende und das darauffolgende Semester kann verlässlich eingeplant werden).
  • Klare personelle Zuständigkeiten im myLab definiert.
  • Langfristiger Betrieb wird angestrebt.

Zuordnung der Dienste (Stand Juli 2026)

Diese Einstufung ist die Grundlage für die Tags in Uptime Kuma. Kursive Einträge sind eine initiale Einschätzung und können jederzeit angepasst werden.

Level Dienste
🟣 Experimentell Codepad, n8n, AIStor / MinIO
🔵 Pilotbetrieb Campus Plattform (alle Modelle, KIRA, OpenAI-API-Proxy), Jupyter Hub
🟢 Etabliert GitLab (+ Container Registry, Pipeline), K8s Cluster Athena, Virtualisierung (Proxmox)*