Governance, Monitoring und KI-Unterstützung

Governance, Monitoring und KI-Unterstützung

0:00 Zum Abschluss verlassen wir die einzelne Pipeline und sehen auf das Ganze. Eine Pipeline, die niemand auswertet, wird nicht besser — sie wird nur älter. In diesem Modul geht es um die drei Dinge, die eine Automatisierung über Jahre tragfähig halten: klare Vorgaben auf Organisationsebene, Kennzahlen, die Verfall sichtbar machen, und der kontrollierte Umgang mit KI-Assistenten, die inzwischen den Großteil neuer Workflow-Dateien vorschlagen.

0:25 Der letzte Punkt ist neu genug, dass es dafür kaum etablierte Praxis gibt — umso wichtiger, dass Sie Ihre eigene formulieren.

Governance, Monitoring und KI-Unterstützung

0:32 Letztes Modul. Erst die Vorgaben auf Organisations- und Unternehmensebene, dann die Kennzahlen und die systematische Fehlersuche, zuletzt der Umgang mit KI-Vorschlägen. Am Ende schicken Sie einen generierten Deployment-Workflow durch Ihr eigenes Review — und wenden dabei alles an, was Sie an den drei Tagen gelernt haben.

Governance in Organisation und Enterprise

0:51 Beginnen wir mit den Vorgaben. Vieles, worüber wir in den letzten Modulen gesprochen haben, lässt sich zentral festlegen — statt es in jedem Repository neu zu verhandeln. Auf Organisations- und Unternehmensebene lässt sich festlegen, welche Actions und wiederverwendbaren Workflows überhaupt verwendet werden dürfen. Es gibt drei Stufen: alles erlauben, nur eigene erlauben, oder eine Auswahlliste pflegen. Die mittlere Variante ist streng und für sicherheitskritische Umgebungen durchaus üblich.

1:20 Die Auswahlliste ist der Kompromiss für den Alltag. Wichtig zu wissen: Lokale Actions und Workflows des eigenen Repositories sind dabei immer erlaubt — die Vorgabe richtet sich gegen fremden Code, nicht gegen eigene Automatisierung. Vier Einträge, die die Möglichkeiten zeigen. Der erste nennt eine einzelne Action mit Version. Der zweite gibt eine ganze Organisation frei — praktisch für die eigene.

1:44 Der dritte ist die interessanteste Zeile: eine Ausnahme von dieser Freigabe, mit einem Ausrufezeichen davor. So lässt sich ein einzelnes Repository ausschließen, etwa ein Experimentierkasten, der nicht in Produktionspipelines gehört. Und der vierte zeigt, dass auch wiederverwendbare Workflows so gesteuert werden — mit Pfad und Version, genau wie im Aufruf.

2:07 Vier Fragen, die jede Organisation beantworten muss — bewusst oder unbewusst. Welche fremden Actions dürfen in die Pipelines? Welche Standardrechte bekommt das Token in neuen Repositories, denn diese Voreinstellung wirkt auf alles, was künftig entsteht? Wer darf Workflows von Fork-Beiträgen freigeben? Und welche Vorlage bekommt ein neues Projekt? Der Punkt ist: Diese Fragen sind längst beantwortet, auch wenn niemand sie gestellt hat — dann eben durch die Voreinstellungen.

2:36 Governance heißt hier nur, die Antwort bewusst zu wählen. Der erste Punkt ist die typische Überreaktion: Die Liste ist so eng, dass Teams anfangen, fremde Actions in eigene Repositories zu kopieren — damit haben Sie die Abhängigkeit nicht beseitigt, sondern nur unsichtbar gemacht und die Aktualisierung verloren. Der zweite ist der häufigste Governance-Fehler überhaupt: Die Vorgabe steht in einem Dokument statt in einer Einstellung.

3:01 Der dritte ist der Golden Path, der einmal definiert und nie gepflegt wurde. Und der vierte ist die Auditierbarkeit, die technisch existiert und praktisch niemanden interessiert.

Pipelines beobachten und verbessern

3:11 Jetzt zu den Zahlen. Eine Pipeline ist ein Produkt mit Nutzern — und wie jedes Produkt lässt sich ihr Zustand messen, statt ihn zu vermuten. GitHub weist Nutzung, Laufzeiten und Kosten je Repository und Organisation aus. Zusammen mit der Fehlerquote und der Wartezeit auf Runner entsteht daraus ein Bild davon, ob die Pipeline dem Team hilft oder im Weg steht.

3:33 Diese Daten liegen bereit, werden aber selten angesehen — und deshalb fällt der schleichende Verfall niemandem auf. Kein Team beschließt, eine schlechte Pipeline zu haben; sie entsteht dadurch, dass jede einzelne Verschlechterung für sich genommen zu klein war, um jemanden zu stören. Die vier Zeilen decken die Beschwerden ab, die man im Alltag hört. Die erste ist die wichtigste: Zeit bis zur Rückmeldung.

3:57 Über einer Viertelstunde beginnen Leute, parallel weiterzuarbeiten, und der Zweck der schnellen Rückmeldung ist dahin. Die dritte Zeile ist die heimtückischste — eine Fehlerquote ohne Codefehler, also instabile Tests. Ab etwa fünf Prozent lernt ein Team, Rot zu ignorieren, und ab dann schützt Sie keine Prüfung mehr. Und die Fußzeile enthält die Regel des ganzen Seminars: ohne Ausgangsmessung kein Nachweis.

4:22 Der rote Faden dieser vier Schritte ist: einordnen vor reparieren. Zuerst die Kategorie bestimmen — Codefehler, Umgebung, Zeitverhalten oder externer Dienst —, denn jede erfordert eine andere Antwort. Dann in die Historie sehen: Ist derselbe Job schon vorher sporadisch gescheitert? Dann haben Sie kein Einzelereignis, sondern ein Muster.

4:42 Instabile Tests gehören markiert und getrennt behandelt, nicht durch Neustarts kaschiert. Und nach der Behebung die Kennzahl erneut ablesen — sonst wissen Sie nicht, ob es geholfen hat. Der erste und der zweite Punkt bilden zusammen den Teufelskreis, den wir am ersten Tag schon angesprochen haben: Rote Läufe werden zur Gewohnheit, Neustarts zur Lösung, und irgendwann meldet die Pipeline etwas Wichtiges, das niemand mehr liest.

5:07 Der dritte ist die Kostenfalle, die uns durch mehrere Module begleitet hat. Und der vierte ist der stille Verfall: Workflow-Dateien wachsen über Jahre, tote Zweige bleiben stehen, und niemand traut sich, etwas zu löschen, weil unklar ist, wofür es einmal da war.

KI-Assistenten kontrolliert einsetzen

5:22 Und zum Schluss ein Thema, das es vor drei Jahren so nicht gab: Ein erheblicher Teil neuer Workflow-Dateien wird heute vorgeschlagen, nicht geschrieben. Was heißt das für die Prüfung? Assistenten erzeugen Workflow-Dateien schnell und formal korrekt — das ist der angenehme Teil. Was sie nicht kennen, ist der Kontext Ihrer Organisation: welche Rechte bei Ihnen üblich sind, welche Actions erlaubt sind, welche Freigaben vor Produktion stehen.

5:48 Ein Vorschlag ist deshalb ein Entwurf, kein Ergebnis. Das ist keine Kritik an den Werkzeugen — sie können diesen Kontext gar nicht kennen, wenn niemand ihn ihnen gibt. Es verschiebt nur die Arbeit: weg vom Schreiben, hin zum Prüfen. Und Prüfen ist die anspruchsvollere Tätigkeit. Vier Fragen, und sie fassen die letzten Module zusammen. Welche Berechtigungen fordert der Workflow an — das ist Modul zwölf. Sind fremde Actions gepinnt — Modul dreizehn.

6:16 Fließen Werte aus Ereignissen ungeprüft in Kommandos — ebenfalls Modul dreizehn. Fehlen Umgebung, Freigabe oder Prüfschritt vor dem Ausrollen — die Module elf und vierzehn. Machen Sie sich daraus eine Checkliste. Vier Fragen an eine generierte Datei dauern zwei Minuten und finden genau die Fehler, die ein Assistent systematisch macht.

6:38 Fünf Schritte, und der zweite ist der wichtigste: Die Quality Gates müssen vorher stehen, damit das Ergebnis des Agenten daran scheitern kann. Ein Agent, der in eine Umgebung ohne Prüfungen arbeitet, produziert Vorschläge, die niemand widerlegen kann. Dazu ein Token mit engen Rechten und der Weg ausschließlich über Pull Requests. Sicherheitsrelevante Stellen prüfen Sie von Hand — Rechte, Auslöser, Freigaben.

7:02 Und die Fußzeile ist die Regel, die alles zusammenhält: Ein Agent, der seine eigenen Prüfungen ändern darf, prüft sich selbst. Der erste Punkt ist das häufigste Muster bei generierten Workflows: großzügige Rechte, weil die immer funktionieren. Der zweite ist typisch für Sprachmodelle — erfundene Actions oder Schlüssel, die plausibel aussehen und erst im Lauf scheitern.

7:24 Der dritte ist ein Reflex, den man sich verbieten sollte: Dem Agenten Produktionszugänge zu geben, damit er einen Fehler nachstellen kann. Und der vierte ist der grundlegende Denkfehler: Grün heißt, dass der Workflow läuft. Über Rechte, Herkunft und Freigaben sagt ein grüner Lauf nichts.

Übung

7:42 Die letzte Übung führt alles zusammen. Sie lassen sich einen Workflow vorschlagen und prüfen ihn mit dem, was Sie in drei Tagen gelernt haben. Zwei Teile. Im ersten prüfen Sie einen generierten Deployment-Workflow gegen die vier Fragen von eben und korrigieren, was fehlt. Der Hinweis ist ernst gemeint: Der korrigierte Workflow muss die Prüfungen der Module zwölf bis vierzehn bestehen — enge Rechte, gepinnte Actions, Environment mit Freigabe, Prüfung der Attestation.

8:09 Im zweiten Teil sehen Sie sich Laufzeit und Kosten der fertigen Pipeline an und notieren drei Verbesserungen. Das ist zugleich Ihre Mitnahme für den Alltag: die Liste, mit der Sie am Montag anfangen. Die Schritte zwei bis vier sind Ihre Checkliste in Aktion — Rechte, Referenzen, Schutzregeln. Arbeiten Sie sie in dieser Reihenfolge ab, dann finden Sie die schwerwiegenden Punkte zuerst.

8:31 Schritt fünf ist der Blick auf die Kennzahlen, und dabei gilt die Regel aus dem zweiten Kapitel: Verbesserungen werden mit Zahlen begründet, nicht mit Eindrücken. Wenn Sie nur eine Sache aus diesem Modul mitnehmen, dann diese — sie unterscheidet eine gepflegte Pipeline von einer, die einfach nur alt wird. Der erste Punkt ist der Denkfehler, mit dem wir dieses Modul begonnen haben: Grün ist kein Sicherheitsnachweis.

8:55 Der zweite ist die halbherzige Prüfung, die nur Formales betrachtet und die Rechte auslässt — ausgerechnet die Stelle, an der Assistenten am zuverlässigsten zu großzügig sind. Der dritte ist die Verbesserung ohne Messung. Und der vierte schließt den Kreis zum ganzen Seminar: Wer einem Werkzeug für eine Übung mehr Rechte gibt, als der fertige Workflow je braucht, hat das Prinzip verstanden, aber nicht angewendet.

9:18 Damit sind wir am Ende — vielen Dank für drei Tage Aufmerksamkeit.