In hochskalierenden Multi-Tenant-Umgebungen wird die Verwaltung dutzender heterogener Hintergrundprozesse — von automatisierten QA-Audits über B2B-Lead-Erkennung und OAuth-gestütztes E-Mail-Routing bis hin zur verteilten Content-Synchronisation — schnell unbeherrschbar, wenn sie als unkoordinierte Cronjobs oder lose Shell-Skripte ausgeführt werden. Ohne ein zentrales Orchestrierungs-Framework drohen verwaiste Prozesse (Orphan Processes), 100-%-CPU-Spitzen durch hängende Headless-Browser und fehlende Echtzeit-Observability.

Um diese architektonische Herausforderung zu lösen, haben wir Job Runner v2.0 entwickelt: eine fehlertolerante TypeScript- und Node.js-Plattform auf Basis einer modularen Plugin-Architektur. Durch streng typisierte Subsystem-Verträge konsolidiert der Job Runner drei zuvor getrennte Automatisierungs-Engines — QA Watchdog, Lead Hunter und Article Sync — auf einem dedizierten Worker-Knoten (192.168.11.18:8084) mit strikter Prozessisolierung.

1. Das Problem fragmentierter Hintergrundskripte

Vor der Konsolidierung unter einem einheitlichen Orchestrator arbeitete jedes operative Werkzeug in einem isolierten Silo:

• QA Watchdog: Startete eigenständige Headless-Playwright-Spider, um HTTP-404-Fehler zu prüfen, dynamische Kontaktformulare zu verifizieren und JSON-LD-Schemata über mehr als 130 Produktiv-Domains hinweg zu validieren.
• Lead Hunter: Führte mehrstufige Discovery-Schleifen über regionale Unternehmensverzeichnisse aus, versandte technische Website-Audits über die Google Gmail API und synchronisierte Datensätze mit Frappe CRM.
• Article Sync & SEO-Indexierung: Synchronisierte flache JSON-Shards mit MongoDB Atlas und übermittelte aktualisierte URLs unmittelbar an IndexNow-Endpunkte.

Bei der Ausführung über abgekoppelte SSH-Sitzungen oder klassische System-Crons konnten unbehandelte Promise-Rejections oder Endlosschleifen in DOM-Parsern einzelne CPU-Kerne dauerhaft blockieren, während den DevOps-Teams eine zentrale Übersicht über Warteschlangen, Log-Streams und laufende Kindprozesse fehlte.

2. Die modulare Plugin-Architektur in TypeScript

Job Runner v2.0 abstrahiert jeden Aufgabenbereich in ein streng typisiertes Modul unter src/modules/. Jedes Subsystem registriert seine Jobs über einen deklarativen Definition-Contract:

export interface JobDef {
  key: string;
  name: string;
  description: string;
  queue: 'qa' | 'lead-hunter' | 'seo' | 'maintenance' | 'social';
  bin: 'node' | 'bash';
  script: string;
  cwd: string;
  baseArgs: string[];
  schedule?: string;
  retries: number;
  logFile: string;
}

A. Integration von QA-Watchdog (src/modules/qa/)

Sämtliche Test-Suites wurden als native TypeScript-Spider migriert: der 404 Fast Spider (qa:spider) prüft HTTPS-Antwortcodes und 301-Weiterleitungen, der Contact Form Auditor (qa:contact-forms) validiert öffentliche Anfrageformulare, der Static Asset Auditor (qa:asset-audit) verifiziert CSS/JS-Bundles und der SEO Schema Validator (qa:seo-audit) prüft über 3.400 veröffentlichte Artikel auf Schema.org-Konformität.

B. Integration von Lead-Hunter (src/modules/marketing/)

Die Outreach-Engine arbeitet als fünfstufige Pipeline: regionale KMU-Erkennung, automatisierte technische Schwachstellenanalyse (fehlendes SSL, langsamer LCP, fehlendes Viewport-Meta-Tag), REST-basierte Deduplizierung in Frappe CRM v15, authentifizierter Versand über den Google Gmail API Microservice auf Port 8085 sowie automatische Bounce-Auswertung.

C. Integration von Article Sync & Versionierter Content-Engine (src/modules/content/)

Die Content-Synchronisation nutzt atomares Dual-Writing zwischen JSON-Shards, SQLite-Revisionsdatenbank (data/revisions.db) und MongoDB inklusive unveränderlicher Revisions-Snapshots (v1 → v2) und sofortiger IndexNow-Benachrichtigung.

3. Harte POSIX-Prozessgruppen-Isolierung & Telemetrie

Um CPU-Sättigung und verwaiste Chromium-Prozesse zuverlässig auszuschließen, setzt der Job Runner zwei zentrale Stabilitätsinvarianten durch:

• Prozessgruppen-Sandboxing (-pid): Jeder Worker wird mit detached: true in einer eigenen POSIX-Prozessgruppe gestartet. Beim Stoppen oder nach einem Timeout sendet der Runner SIGTERM / SIGKILL an die negative Prozessgruppen-ID (process.kill(-child.pid, 'SIGTERM')), sodass sämtliche Kind- und Kindeskindprozesse rückstandslos beendet werden.
• Dual-Push-Telemetrie: Alle Log-Streams und Laufzeitmetriken fließen in Echtzeit an Prometheus und Promtail/Loki und speisen interaktive Grafana-Dashboards auf dem primären Web-Knoten (192.168.11.32) sowie dem Worker-Knoten (192.168.11.18).

4. Fazit

Durch die Zusammenführung von QA-Validierung, Marketing-Automatisierung und Content-Synchronisation in einer modularen TypeScript-Plugin-Architektur entstand aus isolierten Skripten eine hochverfügbare Enterprise-Plattform mit vollständiger Observability und null Ausfallzeiten.