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
-
Register anlegen: Wiki, Jira-Epic oder versioniertes YAML-Dokument; mindestens 6 Pflichtfelder
-
Initiales Befüllen: Workshop mit Engineering-Team: "Was wissen wir, aber haben nie aufgeschrieben?"
-
Quarterly-Review-Termin: Fixer Kalendertermin mit Engineering-Leadership; 60-Minuten-Meeting
-
Postmortem-Integration: Template erweitern: "Performance-Schuld-Eintrag erstellt? Y/N. Eintrag-ID: ?"
-
ADR-Performance-Sektion: ADR-Template erweitern mit "Performance Debt Created" Sektion
-
Priorisierung: High-Impact + High-Probability = Top-Priorität für Paydown
-
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 |
|---|---|
|
|
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 – Select the right resource types and sizes |
Azure Well-Architected Framework |
Performance Efficiency – Choose the right resources |
Google Cloud Architecture Framework |
Performance optimization – Right-size your instances |
TOGAF 10 |
ADM Phase B – Business architecture; ADM Phase C – Application architecture |
DORA |
DORA 2024 – Technical practices; DORA 2024 – Performance monitoring |
ISO/IEC 29119 |
4.4.3 – Test design techniques; 4.5.3 – Test execution |
ISO/IEC 12207 |
8.2.2.3 – Design and development of software |
ITIL 4 |
SVS – Service value system; DP – Design principle |
BSI C5:2020 |
OPS-01 – Operational monitoring; OPS-02 – Operational control |
CIS Controls v8 |
CIS 8 – Continuous Vulnerability Management |
NIST SP 800-53 |
RA-1 – Security assessment policy; RA-2 – Security assessment controls |
NIST CSF 2.0 |
DE.CM – Continuous monitoring; DE.AE – Anomaly detection |
FedRAMP |
RA-2, RA-5 (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 |
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 |