Vier Jahre IT-Verwaltungsportal — ein Formular statt fünf Admin-Konsolen

Ausgangslage

Wie Austritte, Passwort-Rücksetzungen und Lizenzbereinigung vor dem Portal abliefen, ist im Projekt nicht dokumentiert — vermutlich von Hand in den Microsoft-Konsolen, aber das ist eine Annahme.

Belegt ist ein späteres, konkreteres Problem: Der Austrittsprozess lief ursprünglich synchron innerhalb des Web-Requests und lief in Zeitüberschreitungen, sobald mehrere Anfragen gleichzeitig kamen. Dazu kam ein zweiter Schmerzpunkt: Aktionen gegen das lokale Active Directory waren fire-and-forget — der Webhook antwortete „eingereiht“, und ein fehlgeschlagener Auftrag blieb unsichtbar, bis jemand zufällig nachsah.

Ansatz

Eine Flask-Anwendung mit einem Modul je Aufgabe: Austritt, Konten- und Passwort-Rücksetzung, Lizenzbereinigung, Teams-Rufnummern, Gerätelöschung, Copilot-Verwaltung, Postfach-Zugriffe, Auswertungen. Administratoren melden sich mit ihrem normalen Firmenkonto an; jede geschützte Route prüft die Sitzung serverseitig.

Das bestimmende Muster: Was langsam ist, läuft nicht im Web-Request. Die Route prüft die Eingaben, schreibt eine Zeile mit Status pending in eine Warteschlangentabelle und liefert sofort eine sich selbst aktualisierende Statusseite zurück. Zeitgesteuerte Funktionen arbeiten diese Warteschlangen ab und erledigen die eigentliche Arbeit gegen Microsoft Graph, Exchange Online, OneDrive und — über einen Automation-Webhook — das lokale Active Directory.

Der Fortschritt wird in dieselbe Zeile zurückgeschrieben, über einen einheitlichen Lebenszyklus: pending → processing → completed | partial | failed. Jede Zeile hält fest, welche Teilschritte bereits erfolgreich waren, sodass begrenzte automatische Wiederholungen überspringen, was schon erledigt ist, statt es zu wiederholen.

Der Punkt, an dem es anders hätte laufen können

Die vorhandene SQL-Datenbank wurde zur Warteschlange gemacht, statt einen Message Broker einzuführen.

Der Commit, der das entschied, heißt schlicht „move leaver process to queueing“. Er wandelte den Austrittsprozess von der Ausführung im Request auf das Muster Warteschlangentabelle plus zeitgesteuerte Funktion um — und dieses Muster wurde danach für Gerätelöschung und Rufnummern wiederverwendet.

Die Alternative, ein Service Bus oder eine Celery-artige Architektur, hätte Infrastruktur hinzugefügt. Eine schlichte SQL-Tabelle gibt dafür Beobachtbarkeit mit einem SELECT, einen natürlichen Ort für den Fortschritt je Teilschritt und idempotente Wiederholungen über die protokollierten erledigten Schritte.

Dieselbe Abwägung zeigt einen bewussten Haltepunkt: Für den einen Schritt, der nicht sicher wiederholbar ist — die Umbenennung des lokalen Kontos —, wird ein bestätigter Fehlschlag als partial ausgewiesen und an einen Menschen übergeben. Im Änderungsprotokoll steht das ausdrücklich: keine automatische Wiederholung, weil dieser Schritt nicht idempotent ist. Das System automatisiert aggressiv und weigert sich, dort zu wiederholen, wo eine Wiederholung Schaden anrichten könnte.

Ergebnis

310 Commits zwischen 2022 und 2026 — kein einmaliger Wurf, sondern ein System, das vier Jahre lang im Betrieb weitergewachsen ist. 36 Funktionsmodule, rund 100 Endpunkte, etwa 10 separat ausgelieferte Funktions-Projekte, rund 13.700 Zeilen Python.

2026 durchlief die Codebasis eine dokumentierte Härtungsrunde — CSRF, Header-Vertrauen, XSS, Injection, Rechteausweitung, dazu eine Sperrliste geschützter Konten. In derselben Runde entstand die Testsuite mit 67 Fällen.

Bewusst außerhalb: Privilegierte Konten. Eine Sperrliste verweigert die Automatisierung gegen Administrator-, Dienst- und Notfallkonten sowie gegen das Konto der bedienenden Person selbst. Nur reguläre Nutzer laufen durch. Ebenfalls bewusst manuell: Schemaänderungen laufen als SQL-Skripte, die Auslieferung als dokumentierte Checkliste mit Staging und Smoke-Test.

Offen benannt: Die Funktions-Projekte haben keine automatisierten Tests, ältere Codepfade bauen SQL noch als Zeichenkette, und es gibt genau einen Betreuer.