Ausfall durch ConfigMap-Tippfehler
Produktion 2 Stunden down. Root Cause: ein einziger Tippfehler.
Die Änderung:
# ConfigMap update
data:
DATABASE_CONNECITON_TIMEOUT: "30000" # typo: CONNECITONWas passierte:
- Die App suchte nach DATABASE_CONNECTION_TIMEOUT
- Fand ihn nicht (Tippfehler), und kein Default war gesetzt
- Der Config-Loader reichte stillschweigend 0 an den Datenbanktreiber weiter
- In unserem Treiber — wie in JDBC und libpq — bedeutet ein Timeout von 0 kein Timeout
- Queries gegen eine ohnehin langsame Replica hingen endlos, der Connection Pool füllte sich mit festhängenden Verbindungen, und jeder Request dahinter stand in der Warteschlange, bis der Service nicht mehr reagierte
Warum es nicht aufgefallen ist:
- ConfigMaps sind nur YAML—kein Schema
- Kubernetes validiert keine Key-Namen
- Das PR-Review hat den Tippfehler übersehen
- Integrationstests nutzten eine andere Config
Die Fixes:
- Die App validiert beim Start die erforderlichen Env-Variablen
- Fail fast, wenn kritische Config fehlt
- Schema-Validierung für ConfigMaps in der CI
- Canary Deployments, um Probleme früh zu erwischen
Config-Schema-Checks gehören zu den günstigsten Gates, die Sie einer CI/CD-Pipeline hinzufügen können — ein paar Zeilen Validierung gegen zwei Stunden Downtime.
Lektion: ConfigMaps sind kein Code—behandeln Sie sie, als wären sie welcher.
Incidents wie dieser sind vermeidbar. Unser Team für AWS Managed Services überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.