Lektion 7 12 Min.

Zeitplanung & Fehlerbehandlung

Führe Python-Skripte automatisch nach Zeitplan aus und mach sie produktionsreif — mit Fehlerbehandlung, Logging, Retry-Logik und Monitoring.

🔄 Kurzer Rückblick: In der letzten Lektion hast du E-Mail- und Benachrichtigungsversand automatisiert — Reports und Alerts aus deinen Skripten verschicken. Jetzt sorgen wir dafür, dass deine Skripte automatisch nach Zeitplan laufen und Fehler elegant überstehen.

Ein Skript, das funktioniert wenn du es manuell aufrufst, ist ein Tool. Ein Skript, das nach Zeitplan läuft, Fehler behandelt und dich bei Problemen benachrichtigt, ist ein Automatisierungssystem. Diese Lektion schließt die Lücke.

Zeitplanungs-Optionen

Tool	Plattform	Ideal für
cron	macOS/Linux	Einfach, zuverlässig, vorinstalliert
Aufgabenplanung	Windows	Windows-native Planung
schedule (Python-Library)	Alle Plattformen	Lesbare Zeitpläne in Python-Code
APScheduler	Alle Plattformen	Fortgeschrittene Planung mit Persistenz
launchd	macOS	macOS-spezifisch, mehr Features als cron
systemd Timer	Linux	Moderner cron-Ersatz mit Logging

Option 1: cron (macOS/Linux)

KI-Prompt:

Generiere cron-Ausdrücke für diese Zeitpläne: (1) Jeden Werktag um 8 Uhr, (2) Jeden Montag um 9 Uhr, (3) Alle 6 Stunden, (4) Erster Tag jedes Monats um Mitternacht. Zeig den vollständigen Crontab-Eintrag mit vollem Pfad zu python3 und Skript, Ausgabe in Logdatei umleiten.

Häufige cron-Muster:

Zeitplan	Cron-Ausdruck
Täglich um 8 Uhr	`0 8 * * *`
Werktags um 8 Uhr	`0 8 * * 1-5`
Jeden Montag um 9 Uhr	`0 9 * * 1`
Alle 6 Stunden	`0 /6 * *`
Monatserster um Mitternacht	`0 0 1 * *`

Crontab-Eintrag:

# Crontab bearbeiten
crontab -e

# Format: Minute Stunde Tag Monat Wochentag Befehl
0 8 * * 1-5 /usr/bin/python3 /home/user/scripts/daily_report.py >> /home/user/logs/daily_report.log 2>&1

Option 2: Python schedule-Library

pip install schedule

KI-Prompt:

Schreib ein Python-Scheduler-Skript mit der schedule-Library: (1) daily_report() jeden Werktag um 8 Uhr, (2) weekly_summary() jeden Freitag um 17 Uhr, (3) price_check() alle 6 Stunden, (4) Loggen wann jeder Task startet und endet, (5) Fehler abfangen und loggen ohne den Scheduler zu crashen, (6) Alert senden wenn ein Task fehlschlägt. Scheduler dauerhaft laufen lassen.

Produktionsreife Fehlerbehandlung

Die Fehlerbehandlungs-Hierarchie:

Ebene	Behandelt	Beispiel
try/except pro Operation	Einzelne Fehler	Eine Datei schlägt fehl, andere laufen weiter
Retry mit Backoff	Temporäre Fehler	Netzwerk-Timeout → Retry nach 30s
Fehler-Benachrichtigung	Erschöpfte Retries	Mail-Alert: „Skript nach 3 Versuchen fehlgeschlagen"
Heartbeat-Monitoring	Stille Fehler	„Skript hat bis 8:15 keinen Erfolg gemeldet"

KI-Prompt für robuste Fehlerbehandlung:

Füge produktionsreife Fehlerbehandlung zu meinem Automatisierungsskript hinzu: (1) Jede Hauptoperation in try/except mit spezifischen Exception-Typen (kein bloßes except), (2) Retry-Logik für Netzwerk-Operationen: 3 Versuche mit exponentiellem Backoff (30s, 60s, 120s), (3) Alle Fehler mit vollem Traceback in rotierende Logdatei (max 10MB, 5 Rotationen behalten), (4) Bei komplettem Fehlschlag Alert-Mail mit Fehlerdetails, (5) Bei Erfolg Heartbeat-Datei mit Zeitstempel schreiben.

Logging einrichten

KI-Prompt:

Richte Python-Logging für mein Automatisierungsskript ein: (1) Auf Konsole und in Datei loggen, (2) Konsole zeigt INFO aufwärts, Datei zeigt DEBUG aufwärts, (3) Format mit Zeitstempel, Level, Funktionsname und Nachricht, (4) Logdateien täglich rotieren, 30 Tage aufheben, (5) Wiederverwendbare setup_logging()-Funktion zum Importieren.

Log-Level-Richtlinien:

Level	Wofür	Beispiel
DEBUG	Detaillierte Fehlersuche	„Verarbeite Zeile 142 von 5.000"
INFO	Normale Meilensteine	„Report erstellt: 500 Zeilen, gespeichert als output.xlsx"
WARNING	Unerwartetes, aber behandelt	„3 Zeilen ohne E-Mail, mit Standard gefüllt"
ERROR	Operation fehlgeschlagen, Skript läuft weiter	„Seite 15 nicht abrufbar, überspringe"
CRITICAL	Skript kann nicht fortfahren	„Datenbankverbindung nach 3 Versuchen fehlgeschlagen"

✅ Quick Check: Dein Skript benutzt ein blankes except: das ALLE Exceptions fängt, auch KeyboardInterrupt und SystemExit. Warum ist das ein Problem? (Antwort: Blankes except: fängt ALLES, auch Exceptions die das Skript stoppen sollten: KeyboardInterrupt (Strg+C), SystemExit (sys.exit()), MemoryError. Das macht es unmöglich, das Skript sauber zu beenden. Immer spezifische Exceptions fangen: except (requests.RequestException, ValueError) as e: — oder mindestens except Exception as e: was KeyboardInterrupt und SystemExit ausschließt.)

Monitoring deiner Automatisierungen

KI-Prompt für Heartbeat-Monitoring:

Schreib ein Monitoring-Skript das prüft ob meine Automatisierungsskripte erfolgreich gelaufen sind: (1) Jedes Skript schreibt nach Erfolg eine Heartbeat-Datei: {skript_name}_heartbeat.json mit {“letzter_erfolg”: zeitstempel, “verarbeitete_datensaetze”: anzahl}, (2) Der Monitor prüft alle Heartbeat-Dateien und alarmiert wenn der letzte Erfolg eines Skripts älter als sein erwarteter Zeitplan ist (tägliche Skripte → Alert nach > 25 Stunden, stündliche Skripte → Alert nach > 90 Minuten), (3) Tägliche Statuszusammenfassung: welche Skripte liefen, wann, wie viele Datensätze, Fehler. Monitor alle 30 Minuten ausführen.

Key Takeaways

Produktionsautomatisierung braucht drei Schutzschichten: Retry-Logik für temporäre Fehler (Netzwerk-Timeouts lösen sich von selbst), Fehler-Benachrichtigung bei erschöpften Retries (du erfährst sofort von Problemen) und Heartbeat-Monitoring für stille Fehler (Skript ist gar nicht gelaufen) — ohne alle drei entdeckst du Ausfälle Stunden oder Tage zu spät
Pythons logging-Modul statt print() für Automatisierungsskripte nutzen — logging liefert Zeitstempel, Schweregrade, Datei-Ausgabe und Rotation, genau das was du brauchst um 3-Uhr-morgens-Fehler zu debuggen; das Setup dauert 5 Zeilen und spart Stunden an Fehlersuche
Zeitplanung und Fehlerbehandlung zentralisieren wenn deine Automatisierung wächst — ein Scheduler-Skript mit konsistentem Logging, Retries und Alerts über alle Tasks ist wartbarer als fünf unabhängige Skripte mit jeweils eigenem Ad-hoc-Fehlerhandling

Up Next

In der letzten Lektion baust du dein persönliches Automatisierungs-Toolkit — die wertvollsten Automatisierungsmöglichkeiten identifizieren, dein Skript-Portfolio aufbauen und eine Wartungsroutine etablieren.

Wissenscheck

1. Dein Skript läuft jeden Morgen um 8 Uhr per Cron. Eines Tages schlägt es fehl, weil die Ziel-Website vorübergehend down ist (503 Error). Das Skript loggt den Fehler und beendet sich. Du merkst es erst um 15 Uhr, weil du nicht in die Logs geschaut hast. Wie verhinderst du das?

Jeden Morgen die Logs prüfen, um sicherzustellen dass das Skript gelaufen ist Das Skript zweimal laufen lassen — um 8 und nochmal um 10 Uhr als Backup Monitoring auf drei Ebenen einbauen: (1) Retry-Logik im Skript — bei 503 drei Versuche mit steigenden Pausen (30s, 60s, 120s). Die meisten temporären Ausfälle lösen sich in Minuten. (2) Fehler-Benachrichtigung — wenn alle Retries scheitern, dir eine Mail/Slack-Nachricht senden: 'Tägliches Report-Skript um 8:03 fehlgeschlagen. Fehler: 503 nach 3 Versuchen.' (3) Heartbeat-Monitoring — ein Dienst der ein 'Erfolg'-Signal von deinem Skript erwartet. Kein Signal bis 8:15 → Alert. Das fängt stille Fehler ab (Skript nicht mal gestartet — Cron falsch konfiguriert, Rechner aus)

2. Dein Automatisierungsskript nutzt print()-Anweisungen für Fortschritt und Fehler. Ein Kollege sagt, du sollst Pythons logging-Modul nutzen. Ist das ein echter Unterschied oder nur Stilsache?

Ein echter Unterschied für Automatisierungsskripte. logging bietet Features, die print() nicht kann: (1) Log-Levels — DEBUG, INFO, WARNING, ERROR, CRITICAL — nach Schweregrad filtern ohne Code zu ändern. In der Entwicklung alles sehen, in Produktion nur Warnungen aufwärts. (2) Automatische Zeitstempel — jeder Eintrag mit Zeitpunkt. (3) Datei-Ausgabe — in Datei loggen für spätere Analyse, nicht nur auf die Konsole (die verschwindet wenn das Skript endet). (4) Rotation — automatisch neue Logdateien täglich oder bei Größenlimit, Speicherplatz bleibt beherrschbar. (5) Kontext — Funktionsname, Zeilennummer und Traceback automatisch. Für Skripte die unbeaufsichtigt laufen (Cron, Aufgabenplanung) ist logging essenziell, weil print()-Ausgabe nirgends Sinnvolles landet Nur Stilsache — print() und logging machen im Grunde dasselbe Nur relevant wenn du eine Library schreibst — für Skripte ist print() okay

3. Du hast 5 Automatisierungsskripte mit verschiedenen Zeitplänen. Du verwaltest sie mit 5 separaten Cron-Einträgen. Das wird unübersichtlich. Besserer Ansatz?

5 Cron-Einträge behalten — Cron ist das Standardtool für Zeitplanung Alle 5 Skripte in ein großes Skript packen das alles nacheinander ausführt Zentralen Scheduler-Skript erstellen: (1) Pythons schedule-Library — alle Zeitpläne in einer Python-Datei: schedule.every().day.at('08:00').do(run_daily_report). Lesbarer als Crontab-Syntax. (2) Konfigurationsdatei — YAML oder JSON mit jedem Skript, seinem Zeitplan, Retry-Policy und Benachrichtigungseinstellungen. Ein Ort für alle Automatisierungen. (3) Cron als Trigger behalten, aber ein Wrapper-Skript das Logging, Fehler-Benachrichtigung und Erfolgs-Tracking für ALLE Skripte konsistent handhabt. Die Erkenntnis: 5 unabhängige Skripte werden 15 wenn du Retries, Benachrichtigungen und Logging einzeln hinzufügst. Ein zentrales System erledigt das einmal

Beantworte alle Fragen zum Prüfen

Erst das Quiz oben abschließen

Passende Skills

Python Testing Patterns Async Python