18 — Anti-Pattern im Überblick

Nachschlagen. Zurück zur Übersicht.

Sammlung aller Anti-Pattern aus dieser Unterlage — als Nachschlagewerk, zur Prüfungsvorbereitung und als Gesprächsgrundlage im Team.

Wie man diese Seite benutzt

Nicht von oben nach unten lesen. Nimm dir eine Spalte vor und frage für jede Zeile: Trifft das bei uns zu? Drei ehrliche Treffer sind ein besseres Ergebnis als vierzig durchgelesene Zeilen.

Als Teamübung: Jeder markiert für sich die fünf zutreffendsten Punkte. Anschließend vergleichen. Die Punkte, die alle markiert haben, sind der Arbeitsvorrat. Die, bei denen die Einschätzungen auseinandergehen, sind das interessantere Gespräch.

18.1 Organisation und Kultur

Anti-Pattern Woran man es erkennt Kapitel
Das DevOps-Team Neue Abteilung, alte Übergaben — drei Silos statt zwei 01
Werkzeug zuerst „Wir führen X ein, dann wird alles gut„ 01
Lokale Optimierung Ein Team wird schneller, die Durchlaufzeit bleibt gleich 01
Kultur per Dekret Werteplakate im Flur, unveränderte Zielvorgaben 02
Automatisierung ohne Kultur Pipeline da, aber niemand traut sich auszuliefern 02
Architektur ohne Organisation Microservices im Entwurf, zentrale Freigabe im Alltag 02
Kennzahlen als Druckmittel Teams werden anhand ihrer Zahlen verglichen 15
Verbesserung ohne Zeitbudget „wenn mal Luft ist“ — also nie 16

18.2 Code und Versionsverwaltung

Anti-Pattern Woran man es erkennt Kapitel
Langlebige Feature-Branches Zweige leben Wochen, Zusammenführung schmerzt 03
Sammelcommits „Änderungen an 47 Dateien„ 03
Direkt auf main pushen Kein Branch-Schutz aktiv 03
Geheimnisse im Repository Passwörter in der Historie 03
Build-Ergebnisse eingecheckt Repository wird groß, ständige Konflikte 03
Riesige Pull Requests 2.000 Zeilen, Prüfung wird zur Formalie 03
–force auf gemeinsame Zweige Fremde Arbeit verschwindet 03

18.3 Testen

Anti-Pattern Woran man es erkennt Kapitel
Eistüte statt Pyramide Viele E2E-Tests, kaum Unit-Tests, 20 Minuten Laufzeit 04
Abdeckung als Zielvorgabe Tests ohne Zusicherungen, nur zur Quotenerfüllung 04
Produktivdaten im Test Datenbankabzug auf dem Testsystem 04
Sporadische Fehlschläge geduldet „Einfach nochmal laufen lassen“ 04
Manuelle Regressionstests Eine Liste, die jemand durchklickt 04
Nur der Gutfall wird getestet Randfälle brechen erst in Produktion 04
Tests erst am Projektende Befunde, wenn ihre Behebung am teuersten ist 04

18.4 Pipeline und Auslieferung

Anti-Pattern Woran man es erkennt Kapitel
Nächtlicher Build Rückmeldung nach 14 Stunden 05
Roter main wird toleriert Niemand weiß, was funktioniert 05
Pipeline dauert 45 Minuten Niemand wartet die Rückmeldung ab 05
Pipeline zusammengeklickt Nicht versioniert, nicht reproduzierbar 07
Pro Umgebung neu bauen Getestet wurde nie das Produktivartefakt 06
Konfiguration im Artefakt Ein Image je Umgebung 06
Migration ohne Rückwärtskompatibilität Rollback unmöglich 06
Kein Rauchtest nach dem Ausrollen Störung fällt Anwendern zuerst auf 06
latest als Tag Unklar, was läuft 07
Geheimnisse im Protokoll set -x in Skripten mit Zugangsdaten 07
Fremde Actions auf beweglichen Tags Lieferkettenrisiko 07
Dauerhafte Runner mit Rückständen „Läuft mal, läuft mal nicht„ 07
Scan ohne Konsequenz Bericht wird erzeugt und abgelegt 07
Ausrollen ohne Rückweg Rollback wurde nie geübt 08
Canary ohne Messung Man merkt nichts und schaltet trotzdem weiter 08
Feature Flags ohne Ablaufdatum Codepfad-Wildwuchs nach zwei Jahren 08
Rollback erst nach der Ursachenanalyse Ausfallzeit verlängert sich 08

18.5 Infrastruktur und Betrieb

Anti-Pattern Woran man es erkennt Kapitel
Shell-Skripte statt deklarativer Beschreibung Zweiter Durchlauf richtet Schaden an 09
Nach dem Automatismus von Hand nachbessern Drift kehrt sofort zurück 09
Einmal ausgeführt und nie wieder Drift wächst unbemerkt 09
Schneeflockenumgebungen „Auf der Abnahme läuft es aber“ 06
Terraform-Zustandsdatei im Git Geheimnisse öffentlich 09
Mehrere Dienste in einem Container Eine VM im Container-Gewand 10
SSH-Server im Container Änderungen, die beim Neustart verschwinden 10
Container als Root Läuft nicht unter OpenShift, unnötige Angriffsfläche 10
SIGTERM ignoriert Fehler bei jedem Rolling Update 10
Kubernetes für drei Container Aufwand ohne Gegenwert 10
Änderungen von Hand am Zielsystem Werden beim nächsten Abgleich überschrieben 11
Anwendungs- und Konfigurationsrepo vermischt Keine saubere Freigabe möglich 11

18.6 Überwachung und Störungen

Anti-Pattern Woran man es erkennt Kapitel
Alarm auf Ursachen statt Symptome „CPU über 80 %„ weckt jemanden 12
Durchschnittslatenz Ausreißer verschwinden im Mittelwert 12
Alarme ohne Handlungsanweisung Ratlosigkeit um drei Uhr nachts 12
Zu viele Alarme Echte Meldungen gehen unter 12
Personenbezogene Daten in Logs Vertragsdaten in der zentralen Sammlung 12
/health prüft auch die Datenbank Neustartkaskade bei DB-Störung 12
Erst überwachen, wenn es brennt Störung ohne Datenlage 12
Ursachensuche vor Wiederherstellung Ausfallzeit verlängert sich 13
Incident Commander tippt mit Niemand koordiniert 13
Postmortem endet beim Menschen Dieselbe Störung kommt wieder 13
Maßnahmen ohne Termin und Verantwortliche Werden nie umgesetzt 13
Runbooks veralten Bereitschaft steht ohne Anleitung da 13
Bereitschaft ohne Ausgleich Erschöpfung, Kündigungen 13

18.7 Sicherheit und Regulierung

Anti-Pattern Woran man es erkennt Kapitel
Sicherheitsprüfung erst am Ende Ausnahmegenehmigungen statt behobener Befunde 14
Scanner ohne Bearbeitungsverfahren 1.400 Befunde, die niemand ansieht 14
Unbefristete Ausnahmen „Temporär“ seit drei Jahren 14
Automatische Updates ohne Tests Fremder Code ungeprüft in Produktion 14
Kein SBOM „Sind wir betroffen?„ bleibt tagelang offen 14
Sicherheit mit Vetorecht ohne Beteiligung Umgehung, Schattenprozesse 14
„Regulierung verbietet Automatisierung“ Stillstand mit falscher Begründung 17
Freigabe als Formalie Vier-Augen-Prinzip nur auf dem Papier 17
Notfalländerung als Regelweg Ein Drittel aller Änderungen ist „dringend„ 17
Nachweise nachträglich erzeugen Lückenhaft und angreifbar 17
Personenkonten mit Produktionszugriff Funktionstrennung nicht belegbar 17
Papierprozess parallel zur Automatik Doppelter Aufwand, widersprüchliche Stände 17

18.8 Die sieben schwersten

Wenn nur sieben Punkte bearbeitet werden können, dann diese — sortiert nach Wirkung:

  1. Kein Rollback geübt. Ohne erprobten Rückweg ist jede Auslieferung ein Wagnis, und alles Weitere baut darauf auf.
  2. Roter Hauptzweig toleriert. Damit ist Continuous Integration wirkungslos, egal welche Werkzeuge installiert sind.
  3. Produktivdaten im Testsystem. Ein Datenschutzverstoß mit Meldepflicht, unabhängig von allem anderen.
  4. Postmortem endet beim menschlichen Fehler. Garantiert die Wiederholung derselben Störung.
  5. Schuldsuche nach Störungen. Zerstört die Meldebereitschaft und damit die Informationsgrundlage.
  6. Langlebige Feature-Branches. Verhindert alles, was in Teil C beschrieben wird.
  7. Kennzahlen zum Teamvergleich. Verdirbt die Zahlen und das Vertrauen gleichzeitig.

18.9 Reflexionsfrage

Welches Anti-Pattern auf dieser Seite kennst du aus eigener Erfahrung so gut, dass du es jemandem erklären könntest — und was war damals der Grund, warum es so gemacht wurde?

Der zweite Teil ist der wichtigere. Anti-Pattern entstehen fast nie aus Nachlässigkeit, sondern aus einer Entscheidung, die damals vernünftig war. Wer den ursprünglichen Grund kennt, argumentiert beim Ändern deutlich überzeugender.

Weiter mit Kapitel 19 — Glossar und Literatur