Wir prüfen, bevor wir zusagen. Wir dokumentieren, bevor wir übernehmen. Und wir regeln, was bei Änderungen und Störungen passiert.
Amber = noch offen, Green = geprüft/organisiert. Coral wird ausschließlich für tatsächliche Störungen oder Risiken verwendet. Der Exit ist optional und gehört zur Übergabefähigkeit.
Was passiert: Ihr beschreibt Anwendung, Zweck, Hosting und aktuelle Sorgen.
Was wir brauchen: Kurze Systembeschreibung, Kontaktperson, keine Zugangsdaten.
Was ihr bekommt: Einordnung, ob RTT grundsätzlich passt.
Zeitrahmen: Üblicherweise wenige Werktage bis zur Terminabstimmung; kein Serviceversprechen.
Was passiert: Wir klären Kritikalität, Stack, Betriebsmodell und Prüfbedarf.
Was wir brauchen: Fachlicher und technischer Ansprechpartner, grobe Architektur.
Was ihr bekommt: Vorschlag für den Umfang des Betriebschecks.
Zeitrahmen: 30 Minuten, kostenlos.
Was passiert: Wir prüfen Repository, Infrastruktur, Sicherheit, Backups und Deployments.
Was wir brauchen: Vertraulichkeitsvereinbarung, zeitlich begrenzte Lesezugänge zu Repository und Infrastruktur, vorhandene Dokumentation.
Was ihr bekommt: Zustandsbericht, priorisierte Findings und Annahmeempfehlung.
Zeitrahmen: In der Regel ein bis zwei Wochen, je nach Größe des Systems.
Was passiert: Wir bewerten Risiken und legen gemeinsam den weiteren Weg fest. Auch ein Nein ist möglich.
Was wir brauchen: Risikofreigaben, interne Zuständigkeiten und Budgetrahmen.
Was ihr bekommt: Maßnahmen- und Übernahmeentscheidung.
Zeitrahmen: Nach Befund: von wenigen Tagen bis mehreren Abstimmungsrunden.
Was passiert: Wir schließen die priorisierten Betriebsrisiken.
Was wir brauchen: Testzugänge, Freigaben, technische Ansprechpartner.
Was ihr bekommt: Nachweisbare Maßnahmen und verbleibende Restrisiken.
Zeitrahmen: Je nach Befund: Tage bis mehrere Wochen oder länger.
Was passiert: Wir richten Betriebsabläufe, Alarmierung, Runbook und Ansprechpartner ein.
Was wir brauchen: Verbindliche Freigaben, Betriebsdaten und Eskalationskontakte.
Was ihr bekommt: Dokumentierte Betriebsübergabe mit vereinbartem Leistungsrahmen.
Zeitrahmen: Meist mehrere Abstimmungen; genaue Dauer abhängig vom System.
Was passiert: Monitoring, Pflege, Updates, Incidents und Reporting nach Vereinbarung.
Was wir brauchen: Change-Freigaben, Ansprechpartner und laufende Abstimmung.
Was ihr bekommt: Regelmäßiger Bericht und nachvollziehbarer Servicebetrieb.
Zeitrahmen: Laufende Leistung innerhalb der vertraglichen Servicezeiten.
Was passiert: Wir organisieren die Übergabe an euch oder einen neuen Betreiber.
Was wir brauchen: Empfänger, Zugangswege, Übergabetermin und Datenexport-Anforderungen.
Was ihr bekommt: Code, Daten, Infrastruktur-Dokumentation, Runbook und Übergabeprotokoll.
Zeitrahmen: Abhängig von Umfang und Vertrag: üblicherweise Tage bis mehrere Wochen.
| Thema | Kunde | RTT | Gemeinsam |
|---|---|---|---|
| Quellcode & Anwendungslogik | Verantwortet Inhalt/Rechte | Review betriebsrelevanter Änderungen | Grenzen dokumentieren |
| Infrastruktur | Eigentümer / Freigabe | Betrieb nach Vertrag | Architektur- und Kostengrundlagen |
| Daten & Datenschutz | Verantwortlicher | Technische Maßnahmen im vereinbarten Rahmen | AVV, Löschung und Export |
| Zugänge | Benennung/Berechtigung | Technische Verwaltung nach Mandat | Least-Privilege & Rotation |
| Updates | Fachliche Abnahme | Prüfung, Planung, Umsetzung im Umfang | Change-Freigabe |
| Incidents | Auswirkungen/Business-Priorität | Erkennen, Reagieren nach SLA | Eskalation und Nachbericht |
| Weiterentwicklung | Produktverantwortung | Nur gesondert beauftragt | Review und Release-Freigabe |
Diese Matrix illustriert die Aufteilung. Verbindlich ist ausschließlich die pro System vereinbarte Leistungs- und Verantwortungsmatrix.
Erkennen → Einordnen → Reagieren → Beheben → Nachbericht.
● GREEN / operational: Normalbetrieb bestätigt.
● AMBER / unclear: Ursache oder Auswirkung noch unklar.
● CORAL / incident: Bestätigte Störung oder konkretes Risiko.
Die Bearbeitung richtet sich nach tatsächlichen Servicezeiten und Eskalationsregeln.
Änderung einreichen → Code-/Dependency-Review → Tests und Staging → fachliche Freigabe → kontrolliertes Deployment → Monitoring → Rollback bei Bedarf.
Kein direkter Prompt-to-Production-Durchmarsch ohne Prüf- und Rückfallweg.
Wie wir die Prüfstrecke einrichten: Baustein Automatisieren →
Geheimnisse und Credentials nicht über Formular oder unverschlüsselte Mail übermitteln. Freigabe über abgestimmten sicheren Kanal; zeitlich begrenzte Least-Privilege-Konten, getrennte Rollen und Vier-Augen-Prinzip für kritische Aktionen.
Ihr bekommt im vereinbarten Rahmen Quellcode, Datenexport, Infrastruktur-Beschreibung, Runbook, Zugangsübersicht und ein Übergabeprotokoll. Der Zeitraum wird vorab nach Systemumfang abgestimmt – keine pauschale Tagesgarantie.
Schematische Muster – keine echten Kundendaten oder echten Betriebskennzahlen.
Die Balken zeigen Bandbreiten und Überschneidungen, keine festen Zusagen. Ein Incident oder fehlende Zugänge kann das Vorgehen verändern.
Beispielrhythmus, vor Vertragsabschluss je System zu vereinbaren.
Checks und Alarmwege testen, Ansprechpartner bestätigen.
Wiederherstellung in isolierter Umgebung prüfen und protokollieren.
Updates bewerten, Change-Fenster und Tests abstimmen.
Incidents, Updates, Risiken und nächste Maßnahmen zusammenfassen.
Wir prüfen erst, bevor wir Verantwortung übernehmen.
Betriebscheck anfragen ↗