Benötigt Ihre selbstgehostete Anwendung einen Scheduler? Checkliste zur Bereitschaft für geplante Aufgaben

Warum geplante Aufgaben eine betriebliche Abhängigkeit und kein Implementierungsdetail sind

Eine Weboberfläche beweist, dass Nutzende Seiten öffnen und Daten übermitteln können. Sie beweist nicht, dass die Anwendung Arbeiten abschließt, die später und ohne anwesende Nutzende erfolgen sollen. Bei vielen selbstgehosteten Anwendungen ist diese unbeaufsichtigte Arbeit für den erwarteten Dienst essenziell.

Die [Dokumentation zu Hintergrundaufgaben von Nextcloud Server 26](https://docs.nextcloud.com/server/26/admin_manual/configuration_server/background_jobs_configuration.html) liefert ein versionsspezifisches Beispiel für den Umfang: Die dokumentierten Hintergrundaufgaben umfassen Datenbankbereinigung, Bereinigung temporärer Dateien, Dateiprüfungen externer Speicher, Aktivitäts-E-Mails und das Ablaufen des Papierkorbs. Die genaue Aufgabenmenge unterscheidet sich je nach Anwendung, doch die betriebliche Erkenntnis ist allgemein gültig: Geplante Arbeit kann Datenhygiene, Benachrichtigungen, Importe, Berichte, Integrationen und Wartung betreffen.

Behandeln Sie jeden geplanten Workflow als Produktionsabhängigkeit mit einem definierten Ergebnis und einer Fehlerfolge. Eine Aufgabe, die lediglich alte temporäre Dateien entfernt, kann Verzögerungen tolerieren. Eine Aufgabe, die zeitkritische Nachrichten versendet, einen Kundenimport verarbeitet oder Geschäftsdaten abstimmt, kann dies möglicherweise nicht.

• Betrachten Sie „die Anwendung funktioniert im Browser“ nicht als Nachweis dafür, dass unbeaufsichtigte Workflows funktionieren.
• Klassifizieren Sie jede Aufgabe nach Geschäftsauswirkung: Komfortfunktion, betrieblich wichtig oder kritisch.
• Legen Sie für jede wichtige und kritische Aufgabe eine maximal tolerierbare Verzögerung fest.
• Weisen Sie eine verantwortliche Person sowie einen Eskalationsweg für Untersuchung und Wiederherstellung nach einem fehlgeschlagenen Lauf zu.
• Nutzen Sie die aktuelle Administrations- und Bereitstellungsdokumentation des Anbieters als maßgebliche Quelle für Aufgabenanforderungen.

Scheduler, Hintergrund-Worker und Webanfrage: Unterschiede mit Auswirkungen auf die Bereitstellung

Diese Begriffe werden oft ungenau verwendet, beschreiben jedoch unterschiedliche Ausführungsmuster. Werden sie verwechselt, kann eine Bereitstellung gesund wirken, obwohl wichtige Arbeit verzögert wird oder nie beginnt.

Ein Scheduler startet Arbeit zu einem festgelegten Zeitpunkt oder Intervall. Ein Cron-Eintrag auf dem Host, ein systemd-Timer oder ein Kubernetes-CronJob sind Beispiele für Planungsmechanismen. Ein Hintergrund-Worker ist ein Prozess, der verfügbar bleibt und Arbeit aus dem Job-System einer Anwendung abfragt oder verarbeitet. Ein durch Webanfragen ausgelöster Mechanismus versucht Arbeit nur dann, wenn jemand die Anwendung besucht.

Die Nextcloud-Dokumentation liefert Beispiele für alle drei Muster. Die [Dokumentation zu Hintergrundaufgaben von Server 26](https://docs.nextcloud.com/server/26/admin_manual/configuration_server/background_jobs_configuration.html) besagt, dass im AJAX-Modus bei einem Seitenbesuch eine Aufgabe ausgeführt wird, und bezeichnet ihn als die am wenigsten zuverlässige Option, weil er von regelmäßigen Besuchen abhängt. Die aktuelle [Dokumentation zu Nextcloud-System- und Wartungsbefehlen](https://docs.nextcloud.com/server/latest/admin_manual/occ_system.html) unterscheidet außerdem zwischen einem periodischen Cron-Aufruf und einem persistenten Hintergrundaufgaben-Worker, der unbegrenzt abfragt; wird dieser Worker nur einmal ausgeführt, entspricht dies einem einzelnen Cron-Lauf. Ihre gewählte Anwendung kann andere Muster unterstützen. Prüfen Sie daher das unterstützte Modell, statt Annahmen aus einem anderen Produkt zu übertragen.

• Webanfrage: Nur geeignet, wenn die offizielle Dokumentation dies ausdrücklich erlaubt und eine unregelmäßige Ausführung akzeptabel ist.
• Periodischer Scheduler: Führt einen dokumentierten Befehl oder Job in einer festgelegten Frequenz aus.
• Kontinuierlicher Worker: Bleibt aktiv, um Aufgaben aus einer Warteschlange oder neu verfügbare Arbeit zu verarbeiten.
• Warteschlange: Speicher oder Mechanismus, der Arbeit zur späteren Verarbeitung bereithält; sie ist nicht zwangsläufig selbst der Worker.
• Gehen Sie nicht davon aus, dass ein Scheduler automatisch die Warteschlangenverarbeitung bereitstellt oder dass ein Worker automatisch wiederkehrende Wartung erledigt.

Anforderungen an geplante Aufgaben in der offiziellen Anwendungsdokumentation finden

Beginnen Sie mit der Administrations-, Installations-, Bereitstellungs-, Befehlszeilen- und Hintergrundaufgaben-Dokumentation des Anbieters. Suchen Sie in diesen Quellen nach Begriffen wie Cron, Scheduler, geplante Aufgaben, Hintergrundaufgaben, Warteschlange, Worker, Timer, Wartung, Warteschlangen-Consumer, Befehlszeilenschnittstelle und wiederkehrende Jobs.

Achten Sie auf explizite Betriebsanweisungen, statt sich nur auf Funktionsseiten zu verlassen. Starke Belege sind ein dokumentierter Befehl, der periodisch ausgeführt werden soll, ein dokumentierter Worker-Prozess, eine Umgebungseinstellung zur Auswahl eines Planungsmodus oder Verwaltungsbefehle, die Jobs und Verlauf auflisten. Die [Dokumentation zu Nextcloud-System- und Wartungsbefehlen](https://docs.nextcloud.com/server/latest/admin_manual/occ_system.html) dokumentiert beispielsweise Befehle zum Auflisten registrierter Jobs, Anzeigen laufender Jobs, Prüfen des Job-Verlaufs und manuellen Ausführen eines Jobs.

Halten Sie die Dokumentations-URL und den bewerteten Anwendungsrelease oder Dokumentationsbranch fest. Anforderungen können sich zwischen Releases ändern, und diese Aufzeichnung erleichtert eine sichere Prüfung von Upgrades.

• Identifizieren Sie jeden dokumentierten Befehl für geplante Aufgaben, Worker und Wartung.
• Prüfen Sie, ob der Anbieter eine Methode als bevorzugt oder für den Produktionseinsatz unterstützt bezeichnet.
• Ermitteln Sie den erforderlichen Ausführungsbenutzer, das Arbeitsverzeichnis, die Umgebungsvariablen und Berechtigungen.
• Klären Sie, ob Jobs dynamisch durch Plugins, Module oder die Anwendungskonfiguration registriert werden.
• Prüfen Sie, ob die Anwendung Status, Verlauf, einen Befehl zur manuellen Ausführung oder eine Testaktion bereitstellt.
• Eskalieren Sie Unklarheiten an den Anbieter, Maintainer oder eine erfahrene Betriebskraft, bevor Sie die Arbeitslast als produktionsreif behandeln.

Vor der Infrastrukturwahl ein Inventar geplanter Aufgaben erstellen

Ein Inventar verwandelt eine vage Anforderung – „Cron einrichten“ – in einen betreibbaren Plan. Erstellen Sie einen Eintrag pro Aufgabe oder Aufgabenfamilie. Berücksichtigen Sie wiederkehrende Arbeit und einmalige ereignisgesteuerte Arbeit, denn beide können von Workern, Warteschlangen oder Wiederherstellungsverfahren abhängen.

Der [Entwicklerleifaden für Nextcloud Server 26](https://docs.nextcloud.com/server/26/developer_manual/basics/backgroundjobs.html) unterscheidet einmalige Aufgaben in Warteschlangen von zeitgesteuerten Aufgaben mit einem Mindestintervall zwischen Läufen. Diese versionsspezifische Unterscheidung ist für jedes Inventar hilfreich: Ein wiederkehrender Bericht hat einen Zeitplan; ein durch Upload oder API-Ereignis ausgelöster Import benötigt dagegen möglicherweise eine zuverlässige Warteschlangenverarbeitung. Die betrieblichen Kontrollen können sich überschneiden, doch Auslöser und Wiederherstellungsansatz können unterschiedlich sein.

Bewahren Sie das Inventar zusammen mit der Bereitstellungsdokumentation auf und aktualisieren Sie es beim Aktivieren von Modulen, Ändern von Integrationen oder Aktualisieren der Anwendung.

• Aufgabenname und Referenz zur Anbieterdokumentation.
• Geschäftszweck sowie betroffene Nutzende oder Prozesse.
• Auslösertyp: wiederkehrender Zeitplan, ereignisgesteuerte Warteschlange, manuelle Wartung oder gemischt.
• Erwartete Frequenz, akzeptable Verzögerung und Frist, jeweils in einer benannten Zeitzone.
• Ausführungsmodell und exakter unterstützter Befehl, Worker oder Konfiguration.
• Verantwortliche Person für die routinemäßige Prüfung und verantwortliche Person für die Reaktion auf Vorfälle.
• Eingaben: Datenbankeinträge, Dateien, Warteschlangen, APIs oder Konfiguration.
• Ausgaben: Nachrichten, Berichte, Statusänderungen, erzeugte Dateien, Löschvorgänge oder externe API-Aufrufe. Das Inventar sollte außerdem Abhängigkeiten, Fehlerauswirkung, Wiederholungsverhalten, Überlappungsrichtlinie, Erfolgsnachweise und Wiederherstellungsschritte erfassen.

Verhalten für verpasste Läufe, Duplikate, Überlappungen und Wiederholungen festlegen

Ein Zeitplan beschreibt, wann ein Versuch starten soll; er legt nicht fest, was geschehen soll, wenn Systeme nicht verfügbar sind oder ein vorheriger Versuch noch läuft. Für kritische Workflows müssen diese Entscheidungen ausdrücklich getroffen werden.

Die [Kubernetes-CronJob-Dokumentation](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) besagt, dass die Planung nur annähernd erfolgt: Unter bestimmten Umständen können zwei Jobs oder gar kein Job erstellt werden. Sie empfiehlt, Jobs idempotent zu gestalten. Idempotenz bedeutet, dass die Wiederholung eines Vorgangs keine zusätzliche falsche Wirkung erzeugt – beispielsweise sollte ein Wiederholungsversuch nicht dieselbe geschäftliche Nachricht zweimal senden oder dieselbe finanzielle Aktualisierung erneut anwenden.

Kubernetes veranschaulicht außerdem Entscheidungen, die in vielen Planungssystemen bestehen, auch wenn die Bezeichnungen abweichen. Seine [CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) können überlappende Ausführungen zulassen, eine neue Ausführung verhindern, solange die vorherige noch aktiv ist, oder eine aktive Ausführung ersetzen. Sie können einen verspäteten Start nach Ablauf einer festgelegten Frist überspringen; hat ein nicht ausgesetzter CronJob keine solche Frist, können verpasste Ausführungen sofort geplant werden. Prüfen Sie das tatsächliche Verhalten Ihrer Anwendung und Ihres gewählten Schedulers, statt anzunehmen, dass diese genauen Kontrollen verfügbar sind.

• Verpasster Lauf: Überspringen, nach Wiederherstellung einmal ausführen oder eine manuelle Prüfung verlangen?
• Doppelte Ausführung: Was macht die Aufgabe sicher, wenn sie mehr als einmal ausgeführt wird?
• Überlappung: Können zwei Instanzen sicher auf dieselben Daten oder denselben externen Dienst zugreifen?
• Wiederholung: Wie viele Versuche, wie lange zwischen den Versuchen und welche Fehler sind wiederholbar?
• Zeitüberschreitung: Wann sollte ein festgefahrener Lauf als fehlgeschlagen gelten?
• Teilweiser Abschluss: Kann die Aufgabe fortgesetzt, kompensiert oder sicher erneut ausgeführt werden?
• Externe Seiteneffekte: Schützen Sie vor doppelten E-Mails, doppelten API-Aufrufen und wiederholter Dateiverarbeitung.

Zeit, Zeitzone und Regeln für die Sommerzeit bewusst festlegen

Eine Wiederholung ohne Zeitzone ist unvollständig. Derselbe Ausdruck kann nach einem Serverumzug, Plattformwechsel oder einer Konfigurationsänderung zu einer anderen Ortszeit ausgeführt werden. [Kubernetes-CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) verwenden die lokale Zeitzone des Controller Managers, wenn keine Zeitzone explizit gesetzt ist; in ihrer Spezifikation kann jedoch eine benannte Zeitzone wie Etc/UTC festgelegt werden.

Für betriebliche Aufgaben ist UTC oft die am wenigsten missverständliche Wahl. Für geschäftsorientierte Aufgaben – etwa einen täglichen Bericht, der zu einer lokalen Geschäftszeit erwartet wird – halten Sie die relevante benannte regionale Zeitzone fest und entscheiden Sie, wie Übergänge zur Sommerzeit behandelt werden sollen. Eine Ortszeit kann bei einer Zeitumstellung zweimal auftreten oder ganz ausfallen.

Unterscheiden Sie außerdem zwischen dem Zeitpunkt, zu dem ein Scheduler eine Aufgabe startet, und dem Geschäftszeitraum, den die Aufgabe verarbeitet. Ein täglicher Bericht, der um 00:05 Uhr startet, enthält nicht zwangsläufig vollständige Daten des vorangegangenen Tages, wenn verbundene Systeme Daten verspätet liefern.

• Halten Sie die Zeitzone im Inventar fest, nicht nur in einer Scheduler-Konfigurationsdatei.
• Verwenden Sie eine benannte Zeitzone, keine undokumentierte Annahme zur lokalen Serverzeit.
• Legen Sie das erwartete Verhalten für Zeitumstellungen und Kalenderausnahmen fest.
• Setzen Sie einen Datenstichtag oder ein Wasserzeichen für Berichte, Importe und Abstimmungsaufgaben.
• Prüfen Sie Zeitsynchronisierung und Zeitstempel in Anwendung, Datenbank, Worker und Protokollierungssystem.
• Testen Sie vor dem Go-live mindestens eine Zeitplangrenze und ein Wiederherstellungsszenario.

Abhängigkeiten verbundener Dienste und Startbereitschaft abbilden

Eine geplante Aufgabe kann erfolgreich starten und dennoch fehlschlagen, weil eine Abhängigkeit nicht bereit ist. Typische Abhängigkeiten sind die Anwendungsdatenbank, ein E-Mail-Zustelldienst, Objekt- oder Dateispeicher, externe APIs, DNS und Zugangsdaten. Behandeln Sie diese als Teil des Betriebsdesigns der Aufgabe.

Die [Docker-Compose-Dokumentation](https://docs.docker.com/compose/how-tos/startup-order/) erklärt, dass Compose Container in Abhängigkeitsreihenfolge startet, jedoch nicht darauf wartet, dass ein Container bereit ist. Ein Datenbankcontainer kann bereits laufen, bevor er SQL-Verbindungen akzeptiert. Compose unterstützt gesundheitsprüfungsbasierte Bedingungen, einschließlich `service_healthy`, wenn ein Dienst auf die Bereitschaft einer Abhängigkeit warten muss. Dies ist ein nützliches Muster, das Sie immer dann bewerten sollten, wenn ein geplanter Prozess zusammen mit dem Rest eines Anwendungsstacks startet.

Trennen Sie Startreihenfolge von fortlaufender Resilienz. Eine Zustandsprüfung kann vermeidbare Fehler unmittelbar nach einer Bereitstellung verringern, doch eine Aufgabe benötigt weiterhin ein festgelegtes Vorgehen für einen späteren Datenbankneustart, abgelaufene Zugangsdaten, eine nicht verfügbare API oder einen temporären Speicherausfall.

• Datenbank: Verfügbarkeit von Verbindungen, Schemaverträglichkeit, Abfragesperren sowie Backup- oder Wartungsfenster.
• E-Mail-Dienst: Authentifizierung, Absenderkonfiguration, Raten- oder Zustellfehler und Schutz vor Doppelversand.
• Externe APIs: Zugangsdaten, Ratenbegrenzungen, Anfragezeitüberschreitungen, Paginierung und sicheres Wiederholungsverhalten.
• Speicher: Berechtigungen, Kapazität, Objektverfügbarkeit und Schutzmaßnahmen bei Bereinigungen.
• DNS und TLS: Nur wenn die Aufgabe öffentliche Endpunkte aufruft oder von externen Callback-Pfaden abhängt.
• Secrets: Sichere Verfügbarkeit für den unterstützten Prozess, ohne sie in Protokollen oder der Aufgabenausgabe offenzulegen.

Ein unterstütztes Bereitstellungsmodell wählen und dessen Grenzen prüfen

Es gibt keinen universell besten Ort, um geplante Arbeit auszuführen. Wählen Sie das Modell, das die Anwendung offiziell unterstützt, und bewerten Sie anschließend, ob es zu Ihren Betriebskapazitäten und Fehleranforderungen passt.

Ein anwendungsverwalteter Scheduler kann geeignet sein, wenn der Anbieter ihn klar dokumentiert und die Anwendung ihre wiederkehrende Arbeit sicher selbst ausführen kann. Ein Scheduler auf Host-Ebene kann für eine Anwendung passen, die einen Cron-Befehl oder Timer des Betriebssystems dokumentiert. Als versionsspezifisches Beispiel beschreibt die [Dokumentation zu Hintergrundaufgaben von Nextcloud Server 26](https://docs.nextcloud.com/server/26/admin_manual/configuration_server/background_jobs_configuration.html) Betriebssystem-Cron als bevorzugte Methode für regelmäßige Aufgaben und stellt einen systemd-Timer als Alternative dar. Ein dedizierter Worker-Prozess kann für Anwendungen geeignet sein, die kontinuierliche Warteschlangenverarbeitung benötigen oder einen persistenten Worker dokumentieren.

Für containerisierte Umgebungen kann ein geplanter Job auf Plattformebene geeignet sein, wenn die Anwendung einen Befehl dokumentiert, der als isolierter Aufruf ausgeführt werden kann, und die Semantik der Plattform verstanden wird. [Kubernetes-CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) bieten Kontrollen für Fristen, Überlappung und Zeitzone, doch ihre nur annähernde Planung bedeutet, dass das Aufgabendesign weiterhin gegen Duplikate geschützt sein muss. Ersetzen Sie eine von der Anwendung unterstützte Ausführungsmethode nicht durch eine Plattformfunktion.

Verwaltete Infrastruktur kann den Aufwand rund um das Hosting einer Anwendung verringern, entscheidet jedoch nicht über die Aufgabensemantik der Anwendung, geschäftliche Fristen, Zugriffsregeln oder Wiederherstellungsrichtlinien. Airbip stellt Katalog-Anwendungsinstanzen als Docker-Workloads auf Cloud-Servern bereit und bietet Infrastrukturkapazitäten wie Routing- und TLS-Automatisierung, DNS-Prüfungen, Verwaltung des Dienstlebenszyklus sowie konfigurierbare tägliche, wöchentliche und monatliche Backups. Verfügbarkeit, Einrichtung und betriebliche Verantwortung für anwendungsspezifische Scheduler, Worker, Warteschlangen und Überwachung werden durch diese Infrastrukturkapazitäten nicht festgelegt und müssen vor der Bereitstellung für die gewählte Anwendung mit Airbip bestätigt werden.

• Anwendungsverwalteter Zeitplan: Prüfen Sie, wie er Neustarts übersteht, wie er überwacht wird und ob die Anbieterdokumentation seinen Produktionseinsatz unterstützt.
• Host-Cron oder systemd-Timer: Prüfen Sie Befehl, Ausführungsbenutzer, Umgebung, Protokolle, Sperrmechanismen und das Persistenzverhalten des Timers.
• Dedizierter Worker: Prüfen Sie Prozessüberwachung, Neustartverhalten, Sichtbarkeit der Warteschlange, Skalierungsgrenzen und kontrolliertes Herunterfahren.
• Plattform-Scheduler: Prüfen Sie Zeitplanzweitzone, Regeln für verpasste Läufe, Nebenläufigkeitsregeln, Berechtigungen und Beobachtbarkeit.
• Für jedes Modell: Halten Sie die genaue Unterstützungsgrenze in der offiziellen Dokumentation fest und testen Sie das Modell unter Fehlerbedingungen.