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

WAF-OPS-100 – Operational Debt Register & Review

Pillar: Operational Excellence | Severity: Medium | Kategorie: Operational Governance | Automatisierbar: Niedrig

Beschreibung

Alle bekannten Operational Debt-Posten – manuelle Prozesse, Workarounds, Toil-Quellen, veraltete Runbooks, siloed Wissen – MÜSSEN in einem version-controlled Operational Debt Register dokumentiert werden. Das Register MUSS quartalsweise mit expliziter Priorisierung und Sprint-Kapazitätszuweisung für Abbau reviewed werden.

Rationale

Operational Debt ist die Akkumulation von Shortcuts, manuellen Prozessen und technischen Workarounds, die den Betriebsaufwand über Zeit erhöhen. Untrackierter Operational Debt bedeutet: Teams kämpfen reaktiv gegen Feuer statt proaktiv die operationale Last zu reduzieren. Toil zu messen ist der erste Schritt zur Eliminierung. Was nicht sichtbar ist, kann nicht priorisiert und nicht abgebaut werden.

Bedrohungskontext

Risiko Beschreibung

On-Call-Burnout

Stetig wachsender Toil ohne Tracking oder Abbau führt zu Engineer-Burnout und hoher Fluktuation.

Manuelle Prozesse als SPOF

Manuelle Operationen werden Single Points of Failure wenn die zuständige Person fehlt.

Stille Akkumulation

Operational Debt wächst unbemerkt bis er einen Major Incident verursacht.

Toil übersteigt Feature-Arbeit

Teams verbringen mehr Zeit mit Toil als mit Produkt-Entwicklung – Wettbewerbsnachteil.

Anforderung

  • Operational Debt Register MUSS in Version-Control gespeichert sein

  • Jeder Eintrag MUSS Severity, Toil-Stunden/Woche, Owner, Created Date und Target Date enthalten

  • Quarterly Review MUSS stattfinden: Priorisierung, Kapazitätszuweisung, Status-Update

  • Sprint-Kapazität für Debt-Abbau MUSS explizit zugewiesen sein (mindestens 10%)

  • Neue Einträge aus Postmortem-Action-Items MÜSSEN systematisch überführt werden

Implementierungsanleitung

  1. Register anlegen: ops-debt-register.yml im Team-Repository; Schema: id, title, category, severity, toil_hours_per_week, owner, status, target_date

  2. Kategorien definieren: manual-process, missing-automation, missing-runbook, configuration-drift, tech-debt, knowledge-silo

  3. Severity klassifizieren: Critical (>4h/Woche Toil oder wöchentliche Incidents), High (2–4h), Medium (1–2h), Low (<1h)

  4. Quarterly Review etablieren: Meeting-Einladung in Kalender; Outputs: Priorisierung, Sprint-Budget-Zuweisung, Status-Updates

  5. Postmortem-Integration: Action Items aus Postmortems werden systematisch in Register überführt

  6. Toil-Metrik tracken: Wöchentliche Stunden-Schätzung; Trend-Analyse; OKR: < 20% Ingenieurzeit für Toil

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Kein Tracking

Operational Debt existiert aber ist nicht anerkannt oder dokumentiert. Toil wird akzeptiert.

2

Informelle Awareness

Debt wird in Retrospektiven diskutiert. Keine formale Dokumentation. Ad-hoc-Verbesserungen.

3

Register gepflegt

Version-controlled Register mit allen bekannten Einträgen. Quarterly Review. Sprint-Budget.

4

Debt-Reduktions-Programm

Toil-Reduktion als explizites OKR. Trend positiv (Abbau > Zuwachs). Postmortem-Integration.

5

Kontinuierliche Verbesserung

Toil < 20% Ingenieurzeit (Google SRE-Ziel). Automation-Coverage-Report. Debt-Trend positiv.

Terraform Checks

waf-ops-100.tf.aws.eventbridge-ops-review-schedule

Prüft: EventBridge Scheduled Rule für quartalsliche Review-Erinnerungen konfiguriert.

Compliant Non-Compliant 
resource "aws_cloudwatch_event_rule" "ops_review" {
  name                = "quarterly-ops-debt-review"
  description         = "Quarterly Ops Debt Register review reminder"
  schedule_expression = "cron(0 9 1 1,4,7,10 ? *)"
  is_enabled          = true
}
resource "aws_cloudwatch_event_target" "ops_sns" {
  rule      = aws_cloudwatch_event_rule.ops_review.name
  target_id = "OpsReviewNotification"
  arn       = aws_sns_topic.team_notifications.arn
}
 
# Kein automatischer Review-Reminder konfiguriert
# Quarterly Review passiert ad-hoc oder gar nicht
# WAF-OPS-100 Violation

waf-ops-100.tf.aws.ssm-automation-runbook

Prüft: SSM Automation Documents für repetitive Operational Tasks existieren.

# Compliant
resource "aws_ssm_document" "rotate_instances" {
  name            = "RotateASGInstances"
  document_type   = "Automation"
  document_format = "YAML"
  content         = file("ssm-documents/rotate-asg-instances.yaml")
}

Remediation: EventBridge Scheduled Rule für quartalsliche Review-Benachrichtigungen konfigurieren. SSM Automation Documents für alle bekannten manuellen Routineaufgaben erstellen.

Evidenz

Typ Pflicht Beschreibung

Governance

✅ Pflicht

Operational Debt Register (version-controlled) mit Einträgen, Severity, Toil-Schätzungen, Owners, Status.

Process

✅ Pflicht

Quarterly-Review-Protokoll mit Priorisierungsentscheidungen und Sprint-Budget-Zuweisung.

Process

Optional

Sprint-Kapazitäts-Report: % des Sprints für Operational-Debt-Abbau.

Governance

Optional

Toil-Metriken-Report: wöchentliche Toil-Stunden pro Ingenieur, Trend der letzten 6 Monate.

Regulatorisches Mapping

Framework Controls

ISO/IEC 20000-1:2018

8.2.3 – Change management; 8.3.4 – Release management; 8.4.1 – Service delivery; 8.4.2 – Service reporting

ITIL 4

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

AWS Well-Architected Framework

Operational Excellence Pillar – Prepare; Operational Excellence Pillar – Deploy; Operational Excellence Pillar – Monitor; Operational Excellence Pillar – Improve

DORA

DORA 2024 – Technical practices; DORA 2024 – Organizational culture

SOC 2 Type II

CC4.1 – Monitoring activities; CC7.1 – Infrastructure and software monitoring; CC7.2 – Evaluation of system changes

Google SRE Book

Chapter 2 – SRE: The role of an SRE; Chapter 3 – Service Level Objectives; Chapter 4 – Eliminating toil

PCI DSS v4.0

Req 6.4 – Secure development lifecycle; Req 6.5 – Secure coding practices; Req 6.6 – Application security

FinOps Foundation

Core Module – Financial accountability; Management Layer – Cost governance

BSI C5:2020

OPS-01 – Operational monitoring; OPS-02 – Operational control; OPS-03 – Operational capacity; OPS-04 – Change management

NIST SP 800-53

CM-1 – Configuration management policy; CM-2 – Configuration management; CM-6 – Configuration settings; CM-8 – Information system integration; CA-7 – Continuous monitoring

NIST CSF 2.0

GV.PO – Policy; RC.RP – Recovery planning; DE.CM – Continuous monitoring

TISAX

Information security – Change management

ANSSI SecNumCloud

Domain – Change management

BIO

BIO – Veranderingenbeheer

ENS High

op.exp.6 – Gestión de cambios

UK NCSC CAF

A4 – Policy and assurance; A5 – Continual improvement

CMMC 2.0

CM.L2-3.4.1 – Establish baseline configurations; CA.L2-3.12.1 – Periodically assess security controls

IRAP

ISM – Change management

CCCS PBMM

CM-2 – Baseline configuration; CA-7 – Continuous monitoring

MAS TRM

Ch.3 – Technology risk governance; Ch.9 – Change management

ISMAP

Operational excellence and continuous improvement

FISC

Operational measures – Change management

Verwandte Controls

Best Practice