Enterprise Delivery, OpenShift & Observability Praxispaket

Großer weiterer Ausbau für produktionsreife Java-Enterprise-Systeme: CI/CD, Maven Quality Gates, Container, OpenShift, Security, Observability, Resilience, Pipeline-Testing und Betrieb.

MarkdownPDFCode README

Was wurde ergänzt?

Dieses Paket verbindet Architektur mit Lieferung und Betrieb. Es zeigt, wie Maven, Container, OpenShift, Security, Observability, Release-Strategien und Runbooks zusammen eine produktionsfähige Enterprise-Plattform bilden.

code/enterprise-production-readiness-lab/
├─ src/main/java/com/acme/enterprise/ops/
├─ deploy/openshift/
├─ deploy/kustomize/
├─ ci/github-actions/
├─ ci/jenkins/
└─ docs/design-patterns.md

CI/CD und Maven Quality Gates10 Einträge

d001: Reproduzierbarer Maven-Build

Englischer technischer Begriff: Reproducible Maven Build
Priorität: 10/10
Warum wichtig: Reproduzierbarer Maven-Build macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Reproducible Maven Build als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d002: Maven Wrapper verpflichtend machen

Englischer technischer Begriff: Maven Wrapper Enforcement
Priorität: 9/10
Warum wichtig: Maven Wrapper verpflichtend machen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Maven Wrapper Enforcement als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d003: Java-21-CI-Matrix sauber definieren

Englischer technischer Begriff: Java 21 CI Matrix
Priorität: 8/10
Warum wichtig: Java-21-CI-Matrix sauber definieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Java 21 CI Matrix als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d004: Dependency Cache kontrolliert nutzen

Englischer technischer Begriff: Controlled Dependency Cache
Priorität: 7/10
Warum wichtig: Dependency Cache kontrolliert nutzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Controlled Dependency Cache als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d005: Quality-Gate-Profil im Parent-POM

Englischer technischer Begriff: Quality Gate Maven Profile
Priorität: 10/10
Warum wichtig: Quality-Gate-Profil im Parent-POM macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Quality Gate Maven Profile als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d006: Unit- und Integrationstests trennen

Englischer technischer Begriff: Unit and Integration Test Separation
Priorität: 10/10
Warum wichtig: Unit- und Integrationstests trennen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Unit and Integration Test Separation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d007: Failsafe für echte Integrationsprüfungen

Englischer technischer Begriff: Maven Failsafe Integration Tests
Priorität: 9/10
Warum wichtig: Failsafe für echte Integrationsprüfungen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Maven Failsafe Integration Tests als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d008: Statische Analyse als Build-Gate

Englischer technischer Begriff: Static Analysis Build Gate
Priorität: 9/10
Warum wichtig: Statische Analyse als Build-Gate macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Static Analysis Build Gate als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d009: OWASP Dependency Check als Sicherheitsstufe

Englischer technischer Begriff: Dependency Vulnerability Gate
Priorität: 9/10
Warum wichtig: OWASP Dependency Check als Sicherheitsstufe macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Dependency Vulnerability Gate als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

d010: CycloneDX SBOM im Build erzeugen

Englischer technischer Begriff: Software Bill of Materials
Priorität: 8/10
Warum wichtig: CycloneDX SBOM im Build erzeugen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Software Bill of Materials als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

<profile>
  <id>ci</id>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</profile>

Ziel-Code

<profile>
  <id>quality-gate</id>
  <activation><property><name>quality</name></property></activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>3.5.0</version>
        <executions><execution><goals><goal>enforce</goal></goals></execution></executions>
        <configuration>
          <rules>
            <requireJavaVersion><version>[21,22)</version></requireJavaVersion>
            <dependencyConvergence/>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

Container Image und Runtime9 Einträge

d011: Multi-Stage-Containerbuild verwenden

Englischer technischer Begriff: Multi-stage Container Build
Priorität: 10/10
Warum wichtig: Multi-Stage-Containerbuild verwenden macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Multi-stage Container Build als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d012: Container nicht als root ausführen

Englischer technischer Begriff: Non-root Container Runtime
Priorität: 10/10
Warum wichtig: Container nicht als root ausführen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Non-root Container Runtime als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d013: Image-Tags unveränderlich behandeln

Englischer technischer Begriff: Immutable Image Tagging
Priorität: 9/10
Warum wichtig: Image-Tags unveränderlich behandeln macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Immutable Image Tagging als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d014: JVM-Speicher an Containergrenzen koppeln

Englischer technischer Begriff: Container-aware JVM Memory
Priorität: 9/10
Warum wichtig: JVM-Speicher an Containergrenzen koppeln macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Container-aware JVM Memory als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d015: Layered JAR für schnelle Rollouts nutzen

Englischer technischer Begriff: Layered Application Image
Priorität: 7/10
Warum wichtig: Layered JAR für schnelle Rollouts nutzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Layered Application Image als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d016: Runtime-Umgebung minimal halten

Englischer technischer Begriff: Minimal Runtime Image
Priorität: 8/10
Warum wichtig: Runtime-Umgebung minimal halten macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Minimal Runtime Image als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d017: Startkommando explizit dokumentieren

Englischer technischer Begriff: Explicit Runtime Command
Priorität: 7/10
Warum wichtig: Startkommando explizit dokumentieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Explicit Runtime Command als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d018: Environment-Variablen typisiert validieren

Englischer technischer Begriff: Typed Runtime Configuration
Priorität: 8/10
Warum wichtig: Environment-Variablen typisiert validieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Typed Runtime Configuration als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

d019: Container-Healthcheck nicht mit Readiness verwechseln

Englischer technischer Begriff: Container Healthcheck Boundary
Priorität: 8/10
Warum wichtig: Container-Healthcheck nicht mit Readiness verwechseln macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Container Healthcheck Boundary als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

FROM eclipse-temurin:21
COPY target/order-service.jar /app.jar
CMD java -jar /app.jar

Ziel-Code

FROM eclipse-temurin:21-jre AS runtime
WORKDIR /opt/app
RUN useradd --uid 10001 --home-dir /opt/app --shell /sbin/nologin appuser
COPY --chown=10001:10001 target/order-service.jar ./order-service.jar
USER 10001
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["java","-jar","/opt/app/order-service.jar"]

OpenShift und Kubernetes Deployment11 Einträge

d020: Resource Requests und Limits setzen

Englischer technischer Begriff: Resource Requests and Limits
Priorität: 10/10
Warum wichtig: Resource Requests und Limits setzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Resource Requests and Limits als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d021: Readiness Probe fachlich korrekt bauen

Englischer technischer Begriff: Readiness Probe
Priorität: 10/10
Warum wichtig: Readiness Probe fachlich korrekt bauen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Readiness Probe als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 1

Ziel-Code

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

d022: Liveness Probe vorsichtig einsetzen

Englischer technischer Begriff: Liveness Probe
Priorität: 9/10
Warum wichtig: Liveness Probe vorsichtig einsetzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Liveness Probe als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d023: Startup Probe für langsame Starts nutzen

Englischer technischer Begriff: Startup Probe
Priorität: 8/10
Warum wichtig: Startup Probe für langsame Starts nutzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Startup Probe als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d024: ConfigMap als Konfigurationsgrenze

Englischer technischer Begriff: ConfigMap Boundary
Priorität: 8/10
Warum wichtig: ConfigMap als Konfigurationsgrenze macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, ConfigMap Boundary als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d025: Secrets nicht in Images oder Git speichern

Englischer technischer Begriff: Secret Externalization
Priorität: 10/10
Warum wichtig: Secrets nicht in Images oder Git speichern macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Secret Externalization als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d026: ServiceAccount minimal berechtigen

Englischer technischer Begriff: Least Privilege Service Account
Priorität: 9/10
Warum wichtig: ServiceAccount minimal berechtigen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Least Privilege Service Account als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d027: NetworkPolicy für Ost-West-Traffic

Englischer technischer Begriff: Network Policy Segmentation
Priorität: 9/10
Warum wichtig: NetworkPolicy für Ost-West-Traffic macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Network Policy Segmentation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d028: PodDisruptionBudget für stabile Wartung

Englischer technischer Begriff: Pod Disruption Budget
Priorität: 8/10
Warum wichtig: PodDisruptionBudget für stabile Wartung macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Pod Disruption Budget als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d029: Horizontal Pod Autoscaler fachlich begrenzen

Englischer technischer Begriff: Horizontal Pod Autoscaler
Priorität: 8/10
Warum wichtig: Horizontal Pod Autoscaler fachlich begrenzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Horizontal Pod Autoscaler als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

d030: Route/Ingress bewusst kapseln

Englischer technischer Begriff: Route and Ingress Boundary
Priorität: 7/10
Warum wichtig: Route/Ingress bewusst kapseln macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Route and Ingress Boundary als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

resources: {}
securityContext:
  privileged: true

Ziel-Code

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

Security und Compliance9 Einträge

d031: TLS-Terminierung bewusst entscheiden

Englischer technischer Begriff: TLS Termination Strategy
Priorität: 9/10
Warum wichtig: TLS-Terminierung bewusst entscheiden macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, TLS Termination Strategy als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

d032: Secret Rotation operativ vorbereiten

Englischer technischer Begriff: Secret Rotation
Priorität: 9/10
Warum wichtig: Secret Rotation operativ vorbereiten macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Secret Rotation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

d033: PII in Logs maskieren

Englischer technischer Begriff: PII Log Masking
Priorität: 10/10
Warum wichtig: PII in Logs maskieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, PII Log Masking als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

d034: Audit Events strukturiert schreiben

Englischer technischer Begriff: Structured Audit Trail
Priorität: 9/10
Warum wichtig: Audit Events strukturiert schreiben macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Structured Audit Trail als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

d035: RBAC nicht mit Admin-Rechten starten

Englischer technischer Begriff: RBAC Least Privilege
Priorität: 10/10
Warum wichtig: RBAC nicht mit Admin-Rechten starten macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, RBAC Least Privilege als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

d036: Container Images signieren oder nachweisen

Englischer technischer Begriff: Image Signing Evidence
Priorität: 8/10
Warum wichtig: Container Images signieren oder nachweisen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Image Signing Evidence als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

d037: SAST als Pipeline-Gate einsetzen

Englischer technischer Begriff: Static Application Security Testing
Priorität: 8/10
Warum wichtig: SAST als Pipeline-Gate einsetzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Static Application Security Testing als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

d038: XML External Entities deaktivieren

Englischer technischer Begriff: XXE Protection
Priorität: 10/10
Warum wichtig: XML External Entities deaktivieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, XXE Protection als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
DocumentBuilder b = f.newDocumentBuilder();
Document doc = b.parse(uploadedXml);

Ziel-Code

DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
f.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
f.setFeature("http://xml.org/sax/features/external-general-entities", false);
f.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
f.setXIncludeAware(false);
f.setExpandEntityReferences(false);
Document doc = f.newDocumentBuilder().parse(uploadedXml);

d039: Uploads serverseitig validieren

Englischer technischer Begriff: Server-side Upload Validation
Priorität: 10/10
Warum wichtig: Uploads serverseitig validieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Server-side Upload Validation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

logger.info("customer={} iban={} token={}", customerId, iban, accessToken);

Ziel-Code

// Pattern: Adapter + Policy Object - Masking wird zentral erzwungen.
AuditLogEvent event = AuditLogEvent.orderViewed(customerId)
        .withMasked("iban", IbanMasker.mask(iban))
        .withoutSecret("accessToken");
auditLogger.write(event);

Observability und Diagnose9 Einträge

d040: Strukturierte JSON-Logs verwenden

Englischer technischer Begriff: Structured JSON Logging
Priorität: 10/10
Warum wichtig: Strukturierte JSON-Logs verwenden macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Structured JSON Logging als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d041: Correlation-ID durch alle Schichten tragen

Englischer technischer Begriff: Correlation ID Propagation
Priorität: 10/10
Warum wichtig: Correlation-ID durch alle Schichten tragen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Correlation ID Propagation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d042: Trace-Kontext bei HTTP weiterreichen

Englischer technischer Begriff: Trace Context Propagation
Priorität: 9/10
Warum wichtig: Trace-Kontext bei HTTP weiterreichen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Trace Context Propagation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d043: Metriknamen stabil und niedrig kardinal halten

Englischer technischer Begriff: Metric Cardinality Control
Priorität: 9/10
Warum wichtig: Metriknamen stabil und niedrig kardinal halten macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Metric Cardinality Control als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d044: Health von Readiness trennen

Englischer technischer Begriff: Health and Readiness Separation
Priorität: 10/10
Warum wichtig: Health von Readiness trennen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Health and Readiness Separation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d045: Fachliche Business-Metriken ergänzen

Englischer technischer Begriff: Business Metrics
Priorität: 8/10
Warum wichtig: Fachliche Business-Metriken ergänzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Business Metrics als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d046: Abhängigkeitslatenz messen

Englischer technischer Begriff: Dependency Latency Timing
Priorität: 9/10
Warum wichtig: Abhängigkeitslatenz messen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Dependency Latency Timing als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d047: Log-Sampling nur kontrolliert einsetzen

Englischer technischer Begriff: Controlled Log Sampling
Priorität: 7/10
Warum wichtig: Log-Sampling nur kontrolliert einsetzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Controlled Log Sampling als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

d048: Error-Budget-Signale definieren

Englischer technischer Begriff: Error Budget Signals
Priorität: 8/10
Warum wichtig: Error-Budget-Signale definieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Error Budget Signals als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

System.out.println("order failed " + orderId);

Ziel-Code

// Pattern: Facade - fachlicher Log-Aufruf kapselt technische Logstruktur.
StructuredLog.info("order.payment.failed")
        .field("orderId", orderId.value())
        .field("correlationId", CorrelationIds.current())
        .field("partner", "payment-gateway")
        .field("retryable", false)
        .write();

Resilience und Release Strategien10 Einträge

d049: Timeout-Budget pro Use Case definieren

Englischer technischer Begriff: Timeout Budget
Priorität: 10/10
Warum wichtig: Timeout-Budget pro Use Case definieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Timeout Budget als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d050: Retry nur mit Backoff und Jitter

Englischer technischer Begriff: Retry with Backoff and Jitter
Priorität: 10/10
Warum wichtig: Retry nur mit Backoff und Jitter macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Retry with Backoff and Jitter als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d051: Circuit Breaker an Integrationsgrenzen setzen

Englischer technischer Begriff: Circuit Breaker Boundary
Priorität: 9/10
Warum wichtig: Circuit Breaker an Integrationsgrenzen setzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Circuit Breaker Boundary als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d052: Bulkhead für teure Abhängigkeiten

Englischer technischer Begriff: Bulkhead Isolation
Priorität: 9/10
Warum wichtig: Bulkhead für teure Abhängigkeiten macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Bulkhead Isolation als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d053: Rate Limiting vor Fachservice setzen

Englischer technischer Begriff: Rate Limiting
Priorität: 8/10
Warum wichtig: Rate Limiting vor Fachservice setzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Rate Limiting als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d054: Idempotency-Key für Schreiboperationen

Englischer technischer Begriff: Idempotency Key
Priorität: 10/10
Warum wichtig: Idempotency-Key für Schreiboperationen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Idempotency Key als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d055: Outbox-Delivery nachvollziehbar machen

Englischer technischer Begriff: Outbox Delivery Tracking
Priorität: 9/10
Warum wichtig: Outbox-Delivery nachvollziehbar machen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Outbox Delivery Tracking als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d056: Blue/Green Release planen

Englischer technischer Begriff: Blue Green Deployment
Priorität: 8/10
Warum wichtig: Blue/Green Release planen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Blue Green Deployment als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d057: Canary Release mit Metriken koppeln

Englischer technischer Begriff: Canary Release Metrics
Priorität: 8/10
Warum wichtig: Canary Release mit Metriken koppeln macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Canary Release Metrics als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

d058: Rollback vor Deployment dokumentieren

Englischer technischer Begriff: Rollback Plan
Priorität: 10/10
Warum wichtig: Rollback vor Deployment dokumentieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Rollback Plan als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

for (int i = 0; i < 5; i++) {
    paymentClient.reserve(orderId, amount);
}

Ziel-Code

// Pattern: Policy Object - Retry-Regel ist testbar und nicht im Use Case versteckt.
RetryPolicy policy = RetryPolicy.exponentialBackoff(
        Duration.ofMillis(100), Duration.ofSeconds(2), 3, true);
PaymentReservation reservation = policy.execute(() ->
        paymentClient.reserve(orderId, amount, IdempotencyKey.forOrder(orderId)));

Testing und Verifikation in der Pipeline9 Einträge

d059: Smoke-Test nach Deployment ausführen

Englischer technischer Begriff: Deployment Smoke Test
Priorität: 10/10
Warum wichtig: Smoke-Test nach Deployment ausführen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Deployment Smoke Test als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d060: Consumer Contract Tests versionieren

Englischer technischer Begriff: Consumer Contract Testing
Priorität: 9/10
Warum wichtig: Consumer Contract Tests versionieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Consumer Contract Testing als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d061: HTTP-Stubs realistisch konfigurieren

Englischer technischer Begriff: HTTP Service Stubbing
Priorität: 8/10
Warum wichtig: HTTP-Stubs realistisch konfigurieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, HTTP Service Stubbing als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d062: Testcontainers bewusst kapseln

Englischer technischer Begriff: Testcontainers Boundary
Priorität: 8/10
Warum wichtig: Testcontainers bewusst kapseln macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Testcontainers Boundary als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d063: Performance-Baseline in CI erfassen

Englischer technischer Begriff: Performance Baseline
Priorität: 7/10
Warum wichtig: Performance-Baseline in CI erfassen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Performance Baseline als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d064: Mutation Testing selektiv nutzen

Englischer technischer Begriff: Selective Mutation Testing
Priorität: 7/10
Warum wichtig: Mutation Testing selektiv nutzen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Selective Mutation Testing als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d065: Nebenläufigkeit deterministisch testen

Englischer technischer Begriff: Deterministic Concurrent Testing
Priorität: 9/10
Warum wichtig: Nebenläufigkeit deterministisch testen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Deterministic Concurrent Testing als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d066: Datenbankmigration vor App-Rollout prüfen

Englischer technischer Begriff: Database Migration Gate
Priorität: 9/10
Warum wichtig: Datenbankmigration vor App-Rollout prüfen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Database Migration Gate als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

d067: OpenAPI-Spezifikation gegen Controller prüfen

Englischer technischer Begriff: OpenAPI Contract Verification
Priorität: 8/10
Warum wichtig: OpenAPI-Spezifikation gegen Controller prüfen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, OpenAPI Contract Verification als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

@Test
void deploymentWorks() {
    assertTrue(true);
}

Ziel-Code

@Test
void deployedServiceAcceptsHealthAndCreateOrder() throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest health = HttpRequest.newBuilder(URI.create(baseUrl + "/actuator/health/readiness"))
            .timeout(Duration.ofSeconds(2)).GET().build();
    assertEquals(200, client.send(health, BodyHandlers.discarding()).statusCode());
}

Betrieb, Runbooks und Incident Readiness8 Einträge

d068: Runbook pro kritischem Flow pflegen

Englischer technischer Begriff: Operational Runbook
Priorität: 10/10
Warum wichtig: Runbook pro kritischem Flow pflegen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Operational Runbook als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren

d069: Incident Severity eindeutig definieren

Englischer technischer Begriff: Incident Severity Model
Priorität: 8/10
Warum wichtig: Incident Severity eindeutig definieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Incident Severity Model als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren

d070: Feature Flag als Not-Aus vorbereiten

Englischer technischer Begriff: Emergency Feature Flag
Priorität: 9/10
Warum wichtig: Feature Flag als Not-Aus vorbereiten macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Emergency Feature Flag als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren

d071: Backup-Restore regelmäßig üben

Englischer technischer Begriff: Backup Restore Drill
Priorität: 9/10
Warum wichtig: Backup-Restore regelmäßig üben macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Backup Restore Drill als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren

d072: Kapazitätsreview als Routine etablieren

Englischer technischer Begriff: Capacity Review
Priorität: 8/10
Warum wichtig: Kapazitätsreview als Routine etablieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Capacity Review als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren

d073: Postmortem ohne Schuldzuweisung schreiben

Englischer technischer Begriff: Blameless Postmortem
Priorität: 8/10
Warum wichtig: Postmortem ohne Schuldzuweisung schreiben macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Blameless Postmortem als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren

d074: Change-Freeze-Regeln dokumentieren

Englischer technischer Begriff: Change Freeze Policy
Priorität: 7/10
Warum wichtig: Change-Freeze-Regeln dokumentieren macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, Change Freeze Policy als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren

d075: On-Call-Handbuch mit Diagnosepfaden pflegen

Englischer technischer Begriff: On-call Diagnostic Guide
Priorität: 8/10
Warum wichtig: On-Call-Handbuch mit Diagnosepfaden pflegen macht Lieferbarkeit, Betrieb und Fehlersuche in einer Enterprise-Plattform nachvollziehbar. Der Punkt verhindert, dass Architektur nur lokal funktioniert, aber in CI/CD, OpenShift oder Incident-Situationen bricht.
Typischer Fehler: Typisch ist, On-call Diagnostic Guide als nachträgliche Kleinigkeit zu behandeln. Dadurch entstehen fragile Builds, unklare Betriebszustände oder Sicherheitslücken, die erst im produktionsnahen Betrieb auffallen.
Enterprise-Einordnung: Relevant für Senior-Java-Teams, die Maven, OpenShift, Security, Observability und Release-Prozesse als Teil derselben Enterprise-Verantwortung betrachten.

Ausgangspunkt-Code

# Incident: Order Export kaputt
- App neu starten
- Logs anschauen

Ziel-Code

# Runbook: Order Export stuck
1. Prüfen: `kubectl get pods -l app=order-service`
2. Metrik: `order_export_queue_depth > 1000` bewerten
3. Logs mit Correlation-ID filtern: `order.export.failed`
4. Not-Aus: Feature Flag `order.export.enabled=false`
5. Wiederanlauf: Outbox ab Offset `last_successful_event_id` starten
6. Nachweis im Incident-Ticket dokumentieren