WAF++ WAF++
Back to WAF++ Homepage

WAF-PERF-100 – Performance Debt Register & Quarterly Review

Beschreibung

Alle bekannten Performance-Limitierungen und bewusst akzeptierten Performance-Einschränkungen MÜSSEN in einem Performance-Schuld-Register dokumentiert werden. Jeder Eintrag MUSS enthalten: ID, Titel, Beschreibung, geschätzter Impact, betroffene Services, Owner, Priorität, Zieldatum und Remediation-Plan oder Akzeptanzrationale. Das Register MUSS quartalsweise von Engineering-Leadership reviewt werden. Jeder Performance-Incident MUSS innerhalb von 30 Tagen einen Register-Eintrag erzeugen.

Rationale

Performance-Schuld verhält sich wie technische Schuld: Einzelne Entscheidungen sind rational, aber untracked werden sie zu unsichtbarem Risiko. Ein Team ohne Performance-Schuld-Register kann keine informierten Entscheidungen treffen über Performance-Investitionen vs. neue Features. Das Register erzeugt Transparenz, ermöglicht Priorisierung und verhindert Wissenverlust wenn Mitarbeitende das Unternehmen verlassen.

Dokumentierte Performance-Schulden können priorisiert und abgebaut werden. Undokumentierte Performance-Schulden akkumulieren als stille Risiken.

Bedrohungskontext

Risiko Beschreibung

Unsichtbare Risiko-Akkumulation

Performance-Einschränkungen ohne Register bleiben unsichtbar und kumulieren.

Wiederholende Incidents

Gleiche Performance-Probleme treten wiederholt auf, weil Root Causes nicht dokumentiert wurden.

Wissensverlust

Engineer kennt Systemlimitation; verlässt Unternehmen; Limitation ist jetzt unbekannt.

Fehlende Priorisierungsgrundlage

Ohne Register kein Überblick: Wie viel Performance-Schuld haben wir? Was ist am riskantesten?

Anforderung

  • Performance-Schuld-Register MUSS geführt werden mit allen Pflichtfeldern (ID, Beschreibung, Impact, Owner, Priorität)

  • Quarterly Reviews MÜSSEN stattfinden und protokolliert werden

  • Jeder Performance-Incident MUSS Register-Eintrag erzeugen (innerhalb 30 Tage)

  • Neue Features MÜSSEN auf Performance-Schuld-Entstehung bewertet werden (ADR-Performance-Sektion)

Implementierungsanleitung

  1. Register anlegen: Wiki, Jira-Epic oder versioniertes YAML-Dokument; mindestens 6 Pflichtfelder

  2. Initiales Befüllen: Workshop mit Engineering-Team: "Was wissen wir, aber haben nie aufgeschrieben?"

  3. Quarterly-Review-Termin: Fixer Kalendertermin mit Engineering-Leadership; 60-Minuten-Meeting

  4. Postmortem-Integration: Template erweitern: "Performance-Schuld-Eintrag erstellt? Y/N. Eintrag-ID: ?"

  5. ADR-Performance-Sektion: ADR-Template erweitern mit "Performance Debt Created" Sektion

  6. Priorisierung: High-Impact + High-Probability = Top-Priorität für Paydown

  7. Fortschritt messen: Offene Einträge, Abbaurate, durchschnittliches Alter als KPIs

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Keine Dokumentation

Bekannte Performance-Probleme sind Tribal Knowledge; kein Register.

2

Informelles Tracking

Performance-Issues in Tickets, aber kein strukturiertes Register; kein Quarterly Review.

3

Register + Quarterly Review

Register mit Pflichtfeldern; Quarterly Review etabliert; Postmortem-Integration.

4

Business-Impact sichtbar

Einträge mit quantifiziertem Business-Impact; Paydown im Sprint priorisiert; Trend-Tracking.

5

Proaktive Performance-Governance

Performance-Schuld-Budget definiert; automatische Debt-Erkennung; KPI in Engineering-Reviews.

Terraform Checks

waf-perf-100.tf.aws.config-performance-rules

Prüft: AWS Config sollte Performance-Governance-Regeln für automatische Debt-Erkennung haben.

Compliant Non-Compliant
resource "aws_config_config_rule" "rds_insights" {
  name        = "rds-performance-insights-enabled"
  description = "WAF-PERF-040: Performance Insights check"
  source {
    owner             = "AWS"
    source_identifier = "RDS_INSTANCE_PUBLIC_ACCESS_CHECK"
  }
  tags = {
    pillar  = "performance"
    control = "WAF-PERF-040"
  }
}
# Keine AWS Config Rules für
# Performance-Governance definiert
# Performance-Schulden nicht
# automatisch detektierbar
# WAF-PERF-100 Advisory

Remediation: AWS Config Rules für Performance-Governance erstellen. AWS Security Hub für zentralisiertes Findings-Management konfigurieren. Findings mit Performance-Schuld-Register verknüpfen.

Evidenz

Typ Pflicht Beschreibung

Governance

✅ Pflicht

Performance-Schuld-Register mit allen Pflichtfeldern (ID, Impact, Owner, Priorität, Zieldatum).

Process

✅ Pflicht

Quarterly-Review-Meeting-Protokoll oder Kalendereinladung als Nachweis regulärer Reviews.

Process

Optional

Sprint-Backlog mit priorisierten Performance-Schuld-Tickets.

Config

Optional

Dashboard mit Performance-Schuld-Metriken (offene Items, Alter, Abbaurate).

Regulatorisches Mapping

Framework Controls

ISO/IEC 25010:2011

8.3.2 – Performance efficiency; 8.3.2.1 – Time behaviour; 8.3.2.2 – Resource utilisation; 8.3.2.3 – Capacity

AWS Well-Architected Framework

Performance Efficiency Pillar – Selection; Performance Efficiency Pillar – Review; Performance Efficiency Pillar – Efficiency

Azure Well-Architected Framework

Performance – Performance monitoring; Performance – Load and stress testing; Performance – Auto-scaling

Google Cloud Architecture Framework

Performance – Performance design principles; Performance – Monitoring and debugging

TOGAF 10

ADM Phase B – Business architecture; ADM Phase C – Application architecture; ADM Phase D – Technology architecture

DORA

DORA 2024 – Technical practices; DORA 2024 – Performance monitoring

ISO/IEC 29119

4.4.3 – Test design techniques; 4.5.3 – Test execution; 5.3.3 – Test reporting

ISO/IEC 12207

8.2.2.3 – Design and development of software; 9.4.2 – Verification

ITIL 4

SVS – Service value system; DP – Design principle; OV – Operation value chain

BSI C5:2020

OPS-01 – Operational monitoring; OPS-02 – Operational control; OPS-03 – Operational capacity

CIS Controls v8

CIS 8 – Continuous Vulnerability Management; CIS 8.1 – Vulnerability scanning

NIST SP 800-53

RA-1 – Security assessment policy; RA-2 – Security assessment controls; RA-5 – Security assessments; RA-9 – External information system attacks

NIST CSF 2.0

DE.CM – Continuous monitoring; DE.AE – Anomaly detection; DE.DP – Data performance

FedRAMP

RA-2, RA-5, RA-9 (Moderate/High baseline)

SOC 2 Type II

CC6.1 – Logical access security software; CC7.1 – Infrastructure and software monitoring

TISAX

Information security – Performance monitoring

ANSSI SecNumCloud

Domain – Performance monitoring

BIO

BIO – Prestatiedoelstellingen

ENS High

op.exp.2 – Configuración de seguridad; op.exp.3 – Gestión de la configuración

UK NCSC CAF

B4 – System security; B5 – System performance

CMMC 2.0

RA.L2-3.8.1 – Automated monitoring

IRAP

ISM – Performance monitoring

CCCS PBMM

RA-2 – Security assessment controls; RA-5 – Security assessments

MAS TRM

Ch.5 – Technology risk governance

ISMAP

Performance monitoring and validation

FISC

Technical measures – Performance monitoring