Bei Unternehmensübernahmen steht oft wenig Zeit zur Verfügung und die Integrationslandschaft ist heterogen: on‑premise Legacy‑Systeme, Cloud‑Services, APIs, Middleware und SaaS‑Applikationen müssen schnell sichtbar und zuverlässig überwacht werden. Aus meiner Erfahrung lässt sich ein einheitliches Monitoring in 30 Tagen einführen, wenn man pragmatisch vorgeht und Prioritäten setzt. Im folgenden Artikel teile ich meine erprobte Methode, Checklisten, Tool‑Empfehlungen und einen konkreten 30‑Tage‑Fahrplan, den Sie direkt anwenden können.

Warum in 30 Tagen und nicht länger?

Bei M&A gibt es zwei Treiber: Risikominimierung und Entscheidungsfähigkeit. Wenn Sie innerhalb eines Monats verlässliche Telemetrie haben, können Sie Risiken in Produktionsumgebungen erkennen, SLA‑Abweichungen und Integrationsfehler priorisieren und fundierte Entscheidungen zur Harmonisierung treffen. Ziel ist nicht, sofort ein perfektes Monitoring zu bauen, sondern eine operative Grundlage, die schnell Wert liefert und erweiterbar ist.

Meine Prinzipien für die 30‑Tage‑Einführung

  • Pragmatismus vor Perfektion: Erst sichtbar machen, dann verfeinern.
  • Iterativ und inkrementell: Kernmetriken zuerst, dann Kontext und Deep‑Dives.
  • Standardisierung minimal: Gemeinsame KPIs definieren, aber individuelle Adapter zulassen.
  • Ownership klären: Wer reagiert auf Alerts? Wer pflegt Dashboards?
  • Wiederverwendbare Bausteine: Templates für Dashboards, Alerts und Integrationsskripte.

Was gehört unbedingt ins Monitoring?

Ich priorisiere drei Ebenen von Telemetrie:

  • Infrastruktur: CPU, Memory, Disk, Netzwerklatenz für Hosts und Container.
  • Plattform/Middleware: Message‑Queue‑Längen, Threadpools, Datenbankverbindungen, Integrations‑Broker‑Latenzen.
  • Transaktional/Business: API‑Antwortzeiten, Fehlerraten, Durchsatz, SLAs pro Geschäftsfunktion.

Zusätzlich sollten Logs (structured logs), Traces (distributed tracing) und Konfigurations‑/Deployment‑Events zusammengeführt werden, um Incidents schnell zu rekonstruieren.

Toolauswahl — pragmatische Optionen

Die Auswahl hängt von Budget, vorhandener Toolchain und Skillset ab. Meine Empfehlungen für schnelle, praktikable Lösungen:

  • Open‑Source, schnell aufzusetzen: Prometheus + Grafana für Metrics; ELK/Opensearch oder Loki + Grafana für Logs; Jaeger oder Tempo für Traces.
  • Managed/Enterprise: Datadog, Dynatrace oder New Relic — schneller Rollout, weniger Betrieb, aber Kosten berücksichtigen.
  • Hybridansatz: Prometheus für Hosts/Containers + Datadog für SaaS/APM oder Cloud‑native Services.

Ich habe oft Prometheus/Grafana eingesetzt, weil sie flexibel, leicht integrierbar und gut dokumentiert sind. Für schnelle Integrationen mit SaaS empfehle ich Datadog, wenn das Budget es zulässt — viele Cloud‑Provider haben native Integrationen.

Konkreter 30‑Tage‑Fahrplan

Hier zeige ich meinen typischen Zeitplan mit Wochenzielen und Deliverables. Passen Sie die Reihenfolge an kritische Systeme an.

Tag Aktivität Deliverable
1–3 Assess: Topologie, kritische Systeme, bestehende Tools, Team‑Owner Inventory + Prioritätenliste
4–7 Minimalarchitektur & Tool‑Decision; Prototypaufbau (z. B. Prometheus/Grafana) Working PoC‑Stack
8–14 Onboarding kritischer Targets (DB, APIs, Message‑Brokers); Standard Dashboards Dashboards für Top‑5 Komponenten
15–20 Log‑Ingestion & erste Traces; Alerts definieren und Eskalationswege festlegen Alert Playbooks + Alerting in Ops‑Tool
21–26 Business‑KPIs integrieren; Sourcing von Daten aus SaaS/Cloud Business Dashboard + Reporting
27–30 Handover, Schulung der Teams, Roadmap für Erweiterungen Handover‑Dokument, Workshop, Governance‑Plan

Wie ich die Inventarisierung mache (Praxis‑Checklist)

Im Assessment nutze ich folgende Fragen, um Prioritäten zu setzen:

  • Welche Systeme tragen unmittelbar Umsatz oder kritische Prozesse?
  • Wo gab es in den letzten 12 Monaten Incidents?
  • Welche Extern‑Abhängigkeiten existieren (APIs, Payment Provider)?
  • Welche Monitoring‑Daten sind bereits vorhanden und in welchem Format?
  • Wer sind Owner und wer ist für Eskalationen zuständig?

Alerting & Runbooks — sofort umsetzbar

Alerts sollten knapp und handlungsorientiert sein. Ich empfehle:

  • Alert = Symptom + betroffene Komponente + Schwellwert + konkrete Aktion
  • Kategorisierung: P1 (total outage), P2 (degraded), P3 (warning/Trend)
  • Jeder Alert hat ein Runbook: Was prüfen, welche Logs/Traces, Hotfixes und Owner.

Beispiel für einen API‑Alert: "P2: API Response Time > 1200ms für 5 min — Prüfe Queue‑Länge, Datenbank‑Latency, recent deploys; falls Regressionsrate > 5% --> Page on‑call." Solche Playbooks reduzieren Noise und reagieren schnell auf echte Incidents.

Governance & Rollen

Erfolgreiches Monitoring hängt weniger von Technik als von klaren Verantwortlichkeiten ab. Ich setze typischerweise folgende Rollen:

  • Monitoring Owner: Verantwortlich für Architektur, Tooling, Dashboards.
  • Service Owner: Verantwortlich für Alerts und Runbooks pro Applikation.
  • On‑Call Team: Reagiert operational auf P1/P2 Alerts.
  • Integration Architect: Koordiniert zwischen den Teams und stellt Konsistenz sicher.

Häufige Fallstricke — und wie ich sie vermeide

  • Zu viele Metriken: Fokus auf Signal, nicht auf Datenmüll. Starten Sie mit 10–15 Metriken pro System.
  • Unklare Ownership: Alerts ohne Owner werden ignoriert — klare SLAs vereinbaren.
  • Keine Business‑KPIs: Technikmetriken ohne Businesskontext helfen wenig — verbinden Sie technische KPIs mit Umsatz/Prozess‑KPIs.
  • Kein Training: Dashboards ohne Schulung bleiben ungenutzt — kurze Workshops und Playbooks sind Pflicht.

Quick wins, die ich oft einsetze

  • Automatische Exporter/Agenten (Node Exporter, Prometheus‑Exporter, Datadog Agent) für Hosts sofort deployen.
  • Vordefinierte Grafana‑Dashboards importieren (z. B. MySQL, Kafka, Kubernetes) und anpassen.
  • Critical Path Alerts zuerst: DB‑Connection‑Pool Exhaustion, Queue‑Backlog, API‑Error‑Rates.
  • Ein tägliches 15‑minutes "Monitoring Triage" Meeting in der ersten Woche einplanen.

Wenn Sie möchten, sende ich Ihnen ein Template für die Inventory‑Liste, ein Beispiel‑Runbook und ein Grafana‑Dashboard JSON, das ich für M&A‑Projekte nutze. Auf Projectintegration (https://www.projectintegration.ch) finden Sie ergänzende Checklisten und Case Studies, die diesen Fahrplan unterstützen — schreiben Sie mir gern mit Ihren konkreten Systemen, dann passe ich die Empfehlung an Ihre Situation an.