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:
- Kein Rollback geübt. Ohne erprobten Rückweg ist jede Auslieferung ein Wagnis, und alles Weitere baut darauf auf.
- Roter Hauptzweig toleriert. Damit ist Continuous Integration wirkungslos, egal welche Werkzeuge installiert sind.
- Produktivdaten im Testsystem. Ein Datenschutzverstoß mit Meldepflicht, unabhängig von allem anderen.
- Postmortem endet beim menschlichen Fehler. Garantiert die Wiederholung derselben Störung.
- Schuldsuche nach Störungen. Zerstört die Meldebereitschaft und damit die Informationsgrundlage.
- Langlebige Feature-Branches. Verhindert alles, was in Teil C beschrieben wird.
- 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