Vereinbarung über Serviceleistungen (SLA, Service Level Agreement) für Support und Wartung

Kernfakten (Zusammenfassung)

• Dieses SLA beschreibt Zielwerte für Support und Wartung bei Störungen (Incidents), Fehlern (Bugs) und Sicherheitslücken.
• Standardabdeckung: Geschäftszeiten nach CET/CEST. Bereitschaftsdienst außerhalb der Geschäftszeiten / 24×7 (On-Call) — je nach Supportplan.
• Primärer Eingangskanal ist ein Ticketsystem. Anfragen aus Chats können in Tickets überführt werden, um die SLA-Erfassung sicherzustellen.
• Bei kritischen Störungen hat die Wiederherstellung des Dienstes Vorrang vor einer tiefgehenden Ursachenanalyse.
• Für realistische Zielwerte bei komplexen oder übernommenen Systemen ist ein Onboarding erforderlich.

Enthaltene Leistungen

Dieses SLA gilt für:

• Produktionsstörungen, die die Verfügbarkeit oder geschäftskritische Abläufe beeinträchtigen.
• Fehlerbehebung in der Produktionsumgebung (einschließlich kritischer Abläufe wie Bestellvorgang, Zahlungen, Kontozugang).
• Sicherheitslücken und Sicherheitsvorfälle (werden mit hoher Priorität behandelt).
• Koordination und technische Unterstützung bei Drittanbietern, sofern im Supportplan enthalten.

Nicht enthaltene Leistungen (Ausschlüsse)

Dieses SLA deckt keine Probleme ab, die außerhalb der operativen Kontrolle liegen, darunter:

• Ausfälle von Rechenzentren oder Infrastruktur, die nicht von unserem Team betrieben werden.
• Ausfälle oder API-Änderungen von Drittanbieterdiensten (Beispiele: Zahlungsanbieter, E-Mail-Marketing-Plattformen).
• Fehler in Microservices oder Teilsystemen, die nicht von unserem Team entwickelt oder betrieben werden (wir können bei Diagnose und Koordination unterstützen).
• Fälle, in denen erforderliche Zugänge nicht bereitgestellt wurden (Einschränkungen gelten; siehe „Zugangsvoraussetzungen" und „Onboarding").

Vorgehen bei Ursachen außerhalb unserer Kontrolle

Wenn eine Störung durch Drittanbieter oder externe Abhängigkeiten verursacht wird, können wir:

• Die Art des abhängigkeitsbedingten Fehlers identifizieren und bestätigen.
• Technischen Kontext und Protokolle (Logs) bereitstellen, sofern verfügbar.
• Den Auftraggeber als technischer Vermittler bei der Kommunikation mit dem Anbietersupport unterstützen, sofern im Supportplan vorgesehen.
• Erkenntnisse im Ticket dokumentieren und Maßnahmen zur Schadensbegrenzung oder Umgehungslösungen (Workarounds) vorschlagen, soweit möglich.

Modell geteilter Verantwortung

Support und Wartung erfolgen im Rahmen eines Modells geteilter Verantwortung:

• Unsere Verantwortung: Anwendungscode und Geschäftslogik, Deployment- und Release-Prozesse, Konfiguration der von uns verwalteten Komponenten, Diagnostik und Koordination bei Störungen, Überwachung im vereinbarten Umfang.
• Verantwortung des Auftraggebers: Infrastruktur und Hosting-Umgebung (Server, Netzwerk, DNS, Load Balancer), Bereitstellung von Zugängen und Verwaltung von Anmeldedaten, Verträge mit Drittanbieterdiensten (Zahlungsanbieter, E-Mail-Dienste, CDN), geschäftliche Entscheidungen zur Akzeptanz von Sofortmaßnahmen und zur Priorisierung von Änderungen.
• Gemeinsam / koordiniert: Verwaltung der CI/CD-Pipeline (abhängig von Zugangsberechtigungen), Datenbankadministration (abhängig vom Leistungsumfang), Sicherheitspraktiken (Anwendungs- vs. Infrastrukturebene).

Die genaue Abgrenzung wird pro Projekt beim Onboarding festgelegt und im SOW dokumentiert.

Ticket

Ein Ticket ist das primäre Objekt für Erfassung, Triage, Eskalation, Reaktion und Berichterstattung. Die SLA-Erfassung basiert auf Tickets.

Störung (Incident)

Eine Störung ist ein Dienstausfall, der die Verfügbarkeit oder Kernfunktionalität in der Produktionsumgebung beeinträchtigt. Beispiele:

• Website/Dienst ist nicht erreichbar (vollständiger oder teilweiser Ausfall).
• Wiederkehrende Serverfehler (z. B. HTTP 500), die die Nutzung blockieren.
• Kritischer Ausfall bei Deployment oder Infrastruktur mit Auswirkung auf die Produktionsumgebung.

Fehler (Bug)

Ein Fehler ist ein fehlerhaftes Verhalten einer bestehenden Funktion. Beispiele:

• Warenkorb-Funktion schlägt fehl.
• Zahlungsvorgang schlägt fehl oder liefert Fehler.
• Benutzerkonto-Funktionalität ist gestört.

Änderungsanfrage (Change Request)

Eine Änderungsanfrage ist eine Anforderung zur Änderung oder Verbesserung des Systems (neue Oberfläche, neue Funktion, neue Geschäftslogik). Diese Arbeit wird als geplanter Lieferprozess behandelt:

• Sie wird geschätzt.
• Sie wird nach Auslastung und Vertragsbedingungen eingeplant.
• Sie wird nicht als Störung behandelt, es sei denn, sie blockiert den Produktionsbetrieb.

Dringende Änderungen mit externen Fristen

Einige Änderungen sind dringend aufgrund externer Fristen (Gesetz/Regulatorik, zeitgebundene Kampagne, kritisches Geschäftsereignis). Diese können als dringende Aufgaben priorisiert werden, auch wenn es keine Störungen sind. Die Priorisierung richtet sich nach der geschäftlichen Auswirkung und dem Supportplan.

Erstreaktionszeit (First Response) — Bestätigung und Arbeitsbeginn

Erstreaktionszeit bedeutet:

• Das Ticket ist bestätigt.
• Das Team bestätigt den Eingang und den Beginn der Bearbeitung.
• Bei Bedarf wird eine Eskalation ausgelöst (die richtigen Ansprechpartner werden einbezogen).

Sofortmaßnahmen / Dienstwiederherstellung (Mitigation)

Sofortmaßnahmen bedeuten die schnellstmögliche Wiederherstellung eines minimal funktionsfähigen Betriebs (auch wenn die vollständige Ursachenbehebung zusätzliche Zeit erfordert). Dies ist der Standardansatz bei kritischen Störungen.

Vollständige Behebung (Resolution)

Vollständige Behebung bedeutet eine umfassende Korrektur, die die Ursache beseitigt und die gesamte Funktionalität wiederherstellt. In komplexen Fällen kann die vollständige Behebung nach der Dienstwiederherstellung erfolgen (insbesondere bei Störungen außerhalb der Geschäftszeiten).

Standardabdeckung: Geschäftszeiten (CET/CEST)

Die Standard-Supportabdeckung wird während der Geschäftszeiten nach CET/CEST erbracht.

Erweiterte Abdeckung: außerhalb der Geschäftszeiten und Bereitschaft (On-Call) — je nach Plan

Erweiterte Abdeckung kann für ausgewählte Pläne bereitgestellt werden:

• Reaktion außerhalb der Geschäftszeiten bei kritischen Störungen.
• Bereitschaftsingenieur (On-Call) zur Zeitzonenüberlappung mit dem Auftraggeber (einschließlich US-Zeitzonen, falls im Plan vorgesehen).
• Planung kritischer Deployments in für den Auftraggeber geeigneten Fenstern (z. B. Nacht-/Frühstunden zur Reduzierung der Nutzerauswirkung).

Feiertage und arbeitsfreie Tage

Feiertagskalender können nach Leistungsort und Vertragskontext abgestimmt werden (in der Praxis verwendete Beispiele: Moldawien, Deutschland, USA). Der anwendbare Kalender kann pro Supportplan / SOW festgelegt werden.

Zeitzonenvorteil für US-Auftraggeber

Der Betrieb nach CET/CEST schafft einen strukturellen Vorteil für Auftraggeber in US-Zeitzonen:

• Störungsreaktion in der US-Nachtzeit: Kritische Störungen, die während der US-Nachtzeit auftreten, überlappen sich mit unseren regulären Geschäftszeiten, was eine sofortige Einbindung von Ingenieuren ohne Bereitschaftszuschläge ermöglicht.
• Release-Fenster: Deployments und kritische Wartungsarbeiten können in die US-Nacht-/Frühstunden geplant werden, um die Auswirkung auf den US-Geschäftsbetrieb zu minimieren.
• Abdeckung für GUS-Zeitzonen kann ebenfalls vereinbart werden.

Unterstützte Sprachen

• Englisch und Russisch: Vollständige Unterstützung für alle Kommunikation, Dokumentation und Berichterstattung.
• Deutsch: Verfügbar für Kundenkommunikation und Dokumentation.
• Weitere Sprachen: Können nach Vereinbarung bereitgestellt werden.
• KI-gestützte Übersetzung ist als Option verfügbar, um Sprachbarrieren in der operativen Kommunikation zu reduzieren, vorbehaltlich der Datenverarbeitungsrichtlinie des Auftraggebers.

Offizieller Supportkanal (hier beginnt die SLA-Erfassung)

Der offizielle Eingangskanal für die SLA-Erfassung ist ein Ticketsystem. Chat-basierte Anfragen (z. B. über Messenger) können für die operative Kommunikation genutzt werden, sollten jedoch in Tickets überführt werden, um eine einheitliche Erfassung und Berichterstattung sicherzustellen.

Erforderliche Angaben in einer Anfrage (Mindestumfang)

Um die Triage-Zeit zu verkürzen und wiederholte Rückfragen zu vermeiden, sollte eine Anfrage enthalten:

• Was passiert ist (kurze Beschreibung).
• Wann es passiert ist (Zeitfenster).
• Wo es aufgetreten ist (Seite/Route/API/Funktion; Umgebung, falls bekannt).
• Geschäftliche Auswirkung (was blockiert ist; wer betroffen ist).
• Erste Einschätzung der Kritikalität (falls der Auftraggeber diese angeben kann).
• Nach Möglichkeit relevante Nachweise: Screenshots, Fehlermeldungen, Logs, Trace-IDs.

Zugangsvoraussetzungen und operative Einschränkungen

Die Supporteffektivität hängt von den Zugängen ab. Beispiele:

• Ohne Produktionszugang kann der Support auf Änderungen auf Repository-Ebene und Beratung beschränkt sein.
• Infrastrukturausfälle (fehlerhafte Deployment-Pipeline, Probleme der Laufzeitumgebung) können ohne Zugang zur betreffenden Infrastrukturebene nicht vollständig behoben werden. Zugangsvoraussetzungen werden beim Onboarding festgelegt.

Kritikalitätsstufen und Zuordnung zu Prioritäten

Wir verwenden ein Kritikalitätsmodell, das mit der gängigen Enterprise-Praxis kompatibel ist:

• Kritikalitätsstufen S1–S4 (Severity), zuordenbar zu Prioritätsstufen P0–P4 (Priority).

Definitionen der Kritikalität (geschäftliche Auswirkung zuerst)

S1 / P0 — Kritisch, geschäftsblockierend

• Vollständiger oder teilweiser Dienstausfall.
• Geschäftskritischer Ablauf blockiert (Zahlungen/Bestellungen/Kontozugang).
• Kritischer Infrastruktur-/Deployment-Ausfall mit Auswirkung auf die Produktionsumgebung.
• Sicherheitsvorfall mit Risiko einer Datenoffenlegung oder erheblichem Reputationsschaden.

S2 / P1 — Hohe Auswirkung, nicht vollständig blockierend

• Erhebliche Beeinträchtigung oder Ausfall einer wichtigen Funktion, wobei der Geschäftsbetrieb mit Einschränkungen oder Umgehungslösungen fortgeführt werden kann.
• Beispiele: SEO-/Indexierungsauswirkung, wichtige Seiten fehlerhaft, sekundäre, aber geschäftsrelevante Abläufe beeinträchtigt.

S3 / P2 — Mittlere Auswirkung

• Funktionale Fehler mit begrenzter Auswirkung oder verfügbaren Umgehungslösungen.
• Geeignet für die geplante Fehlerbehebungs-Warteschlange.

S4 / P3–P4 — Geringe Auswirkung / Backlog

• Kosmetische Probleme, geringfügige UX-Änderungen, nicht dringende Verbesserungen.
• Werden nach Auslastung und Vertragsbedingungen eingeplant.

Dringende Änderungen aufgrund externer Fristen

• Können als erhöhte Priorität behandelt werden, wenn ein explizites geschäftliches Fristrisiko besteht (regulatorische Anforderungen, zeitgebundene Kampagne, veranstaltungsspezifische Anforderungen). Die Behandlung richtet sich nach Plan und Auswirkung.

Zielwerte richten sich nach dem Supportplan

Die Zielwerte des Service richten sich nach dem gewählten Supportplan (Basic / Extended / Enterprise). Genaue Werte können im SOW / Anhang zum Supportplan dokumentiert werden.

Zielwerte der Erstreaktionszeit (operative Basis)

• Während der Geschäftszeiten ist bei kritischen Störungen das operative Ziel, die Arbeit schnell nach Ticketeingang zu beginnen; typischer Zielwert für kritische Fälle: ca. 20 Minuten (schneller bei höheren Plänen, sofern Ressourcen verfügbar).
• Die Reaktion außerhalb der Geschäftszeiten wird je nach Plan erbracht; typische Reaktionszeit außerhalb der Geschäftszeiten kann im Bereich von Stunden liegen, bedingt durch Benachrichtigung und Verfügbarkeit des Bereitschaftsdienstes.

Zielwerte der Dienstwiederherstellung (Wiederherstellung vs. vollständige Behebung)

Der Ansatz „Wiederherstellung zuerst" (Restore-First) bedeutet die schnellstmögliche Wiederherstellung der minimal kritischen Funktionalität, auch wenn die vollständige Ursachenbehebung zusätzliche Zeit erfordert. Die Wiederherstellungsziele gelten, wenn die Ursache in unserem Verantwortungsbereich liegt (Anwendungscode, Konfiguration, Deployment unter unserer Kontrolle).

Wesentliche Einschränkungen:

• Endgültige Wiederherstellungsziele werden im SOW pro Projekt festgelegt und hängen ab von: Technologie-Stack, Systemreife, Zugangsebene, Umfang der Infrastrukturkontrolle und Anzahl der Drittanbieterabhängigkeiten.
• Wenn die Ursache außerhalb unserer Kontrolle liegt (Rechenzentrumausfall, Netzwerkausfall, Problem des Hosting-Anbieters), bieten wir Koordination und technische Unterstützung, können jedoch keine Wiederherstellungszeit für Infrastruktur garantieren, die wir nicht verwalten.
• Wiederherstellung bedeutet die Rückführung geschäftskritischer Abläufe in einen funktionsfähigen Zustand. Dies kann den Betrieb im eingeschränkten Modus (begrenzte Funktionalität) einschließen, während die vollständige Wiederherstellung fortgesetzt wird.
• Die Ursachenanalyse (RCA) erfolgt nach der Dienstwiederherstellung, nicht anstelle davon.

Kommunikationsmeilensteine (Statusaktualisierungen)

Aktualisierungen im Ticket werden anhand von Fortschrittsmeilensteinen bereitgestellt:

• Bestätigt / Arbeit begonnen.
• Diagnoserichtung bestätigt.
• Dienst wiederhergestellt (Sofortmaßnahmen umgesetzt) — falls zutreffend.
• Korrektur ausgerollt (vollständige Behebung) — falls zutreffend.
• Abschließende Anmerkungen und Empfehlungen.

Die Frequenz der Statusaktualisierungen richtet sich nach dem Supportplan (siehe „Enterprise-Bedingungen und vertragliche Anhänge" → „Kommunikation während eines Vorfalls: Frequenz der Statusaktualisierungen"). Mindestfrequenz der Aktualisierungen für einen aktiven S1-Vorfall: alle 4 Stunden (Basic), mit höherer Frequenz für Extended und Enterprise.

Blockierende Faktoren: Zugänge und kundenseitige Zulieferungen

Wenn der Fortschritt durch fehlende Zugänge oder fehlende Zulieferungen des Auftraggebers blockiert ist:

• Wir fordern die benötigten Zugänge/Informationen im Ticket an.
• Die Arbeit kann bis zur Bereitstellung der Zugänge/Informationen ausgesetzt werden.
• Die verstrichene Zeit beinhaltet die Wartezeit, sofern nicht anders vereinbart, da die Störung ohne die erforderlichen Voraussetzungen nicht behoben werden kann.

Eskalationsstufen (wer wird einbezogen)

Der standardmäßige Eskalationsweg:

1. Bereitschaftsingenieur / zugewiesener Ingenieur (Erstreagierende/r)
2. Projektleitung / Tech Lead (Fachverantwortliche/r)
3. Leitende Führungskräfte / Rollen mit erweiterten Befugnissen (CTO, Architekt) — für komplexe oder kritische Fälle

Wann eine Eskalation erfolgt

Eine Eskalation wird ausgelöst:

• Sofort, wenn dem/der Erstreagierenden der Fachkontext oder Zugang fehlt (z. B. Zahlungsmodul, Infrastrukturebene).
• Nach Untersuchung, wenn die Störung in ein Teilsystem führt, für das die erforderlichen Zugänge oder Kompetenzen fehlen.

Auslöser für die Einbindung der Führungsebene

Die Einbindung leitender Führungskräfte kann erfolgen, wenn:

• Geschäftskritische Auftraggeber direkte finanzielle Verluste erleiden (z. B. Bank-/Handelsabläufe).
• Ein Reputationsvorfall eine schnelle Eindämmung erfordert (z. B. sichtbare Kompromittierung/Verunstaltung).
• Ein kritischer Sicherheitsvorfall eine koordinierte Reaktion erfordert.

Zeitbasierte Eskalationsschwellen (Enterprise)

Für den Enterprise-Plan wird eine Eskalationsmatrix mit zeitbasierten Schwellenwerten im SOW dokumentiert (siehe „Enterprise-Bedingungen und vertragliche Anhänge" → „Eskalationsmatrix mit zeitbasierten Schwellenwerten").

Operative Priorität: Dienst zuerst wiederherstellen

Bei S1/S2-Störungen ist die erste Priorität die Wiederherstellung eines minimal funktionsfähigen Betriebs. Die tiefgehende Ursachenanalyse folgt nach der Dienstwiederherstellung.

Maßnahmenkatalog zur Schadensbegrenzung (Beispiele aus der Praxis)

Maßnahmen zur Schadensbegrenzung (Mitigation) richten sich nach der Art der Störung und können umfassen:

• Vorübergehende Deaktivierung oder Einschränkung einer fehlerhaften Funktion.
• Sperrung einer überlasteten Route/eines Endpunkts zur Unterbindung von Kaskadenausfällen.
• Notfallmaßnahmen zur Reduzierung der Lastauswirkung bei gleichzeitiger Untersuchung von Infrastruktur- oder Anwendungsproblemen.
• Bereitstellung eines gezielten Notfall-Patches (Hotfix) bei Bedarf.

Kommunikationsansatz während Störungen

Die Kommunikation ist meilensteinbasiert:

• „Störung empfangen, Arbeit begonnen."
• „Fehlerbereich lokalisiert / vermutete Ursache bestätigt."
• „Kritische Funktion wiederhergestellt / Auswirkung reduziert."
• „Wir arbeiten an der vollständigen Behebung und Verifizierung." Dies hält den Auftraggeber informiert, ohne einen Mehraufwand zu erzeugen, der die Wiederherstellung verlangsamt.

Abschlusskriterien für Störungen

Eine Störung gilt als abgeschlossen, wenn:

• Der Dienst wiederhergestellt und für geschäftskritische Abläufe funktionsfähig ist.
• Der primäre Fehlermodus so behoben/gemindert ist, dass er den Geschäftsbetrieb nicht weiter blockiert. Die vollständige Wiederherstellung aller Funktionalitäten oder tiefergehende systemische Verbesserungen können als geplante Arbeiten nach der Stabilisierung fortgesetzt werden.

Vorläufige Erklärung während der Wiederherstellung

Während der Störungsbehandlung stellen wir eine kurze operative Erklärung bereit, basierend auf beobachteten Symptomen und Erstdiagnose.

RCA-Zusammenfassung nach der Behebung (bei schwerwiegenden Störungen)

Nach Stabilisierung und Behebung kann eine strukturierte RCA-Zusammenfassung durch die Projektleitung / Technische Leitung erstellt werden. Die RCA-Zusammenfassung konzentriert sich auf:

• Was passiert ist (übergeordnet).
• Warum es passiert ist (wahrscheinliche Ursache).
• Welche Maßnahmen zur Behebung/Minderung ergriffen wurden.
• Welche Empfehlungen zur Vermeidung einer Wiederholung bestehen (Maßnahmen und Verbesserungen). Das RCA-Format ist auf praktischen Nutzen und aggregierte Erkenntnisse ausgerichtet; übermäßig detaillierte Zeitachsen werden standardmäßig nicht erstellt, es sei denn, der Auftraggeber fordert dies ausdrücklich an.

Überwachung richtet sich nach dem Supportplan

Umfang und Tiefe der Überwachung richten sich nach dem Supportplan. Typische Leistungen umfassen:

Basisüberwachung

• Synthetische Verfügbarkeitsprüfungen für kritische Domains/Seiten in definierten Intervallen.
• Alarmierung bei Nichtverfügbarkeit von Endpunkten oder fehlerhaften Antworten.

Überwachung von Ablauffristen

• Überwachung des Ablaufs von Zertifikaten.
• Überwachung des Ablaufs von Domains und zugehörige Betriebsalarme.

Erweiterte Überwachung (je nach Plan)

• Inhaltliche Prüfungen (HTML-Marker / erwartete Textblöcke) zur Erkennung von „HTTP 200, aber fehlerhafte Seite"-Szenarien.
• Infrastruktur- und Ressourcenüberwachung zur Erkennung von Lastspitzen oder unzureichender Kapazität.

Alarmweiterleitung und Reaktion

• Alarme können an die für den unterstützten Dienst verantwortlichen Ingenieurteams weitergeleitet werden.
• Bei Plänen mit 24×7-Überwachung stehen Alarme rund um die Uhr zur Verfügung und können eine Bereitschaftsreaktion auslösen.

Proaktive Kundenbenachrichtigungen

• Bei kritischen Störungen wird der Auftraggeber mit einem Erststatus und den erwarteten nächsten Schritten benachrichtigt.
• Bei unkritischen Problemen, die schnell behoben werden, kann die Benachrichtigung entfallen, um unnötigen Informationsüberschuss zu vermeiden. Benachrichtigungsregeln können je nach Plan angepasst werden.

Klassifizierung von Schwachstellen und Ticket-Kennzeichnung

Sicherheitsprobleme werden als Tickets mit expliziter Sicherheitsklassifizierung (z. B. „Schwachstelle / Sicherheitsvorfall") und hoher Priorität behandelt.

Reaktionsprinzipien bei Sicherheitsproblemen

Bei Sicherheitsproblemen liegt die operative Priorität auf Eindämmung und Risikominderung:

• Schnelle Schadensbegrenzung zur Reduzierung des Gefährdungsfensters (Exposure Window).
• Verifizierung, dass die Schwachstelle gesperrt oder kontrolliert ist.
• Einbindung leitender technischer Rollen bei Bedarf. Öffentlich wird die Behandlung von Sicherheitsproblemen als bestmögliche Leistung (Best Effort) mit hoher Priorität definiert, mit planabhängigen Eskalations- und Reaktionsoptionen.

Benachrichtigungsrichtlinie für Sicherheitsvorfälle

• Wenn ein Sicherheitsproblem in der Produktionsumgebung beobachtet oder extern gemeldet wird, wird der Auftraggeber benachrichtigt und informiert gehalten.
• Wenn eine potenzielle Schwachstelle intern entdeckt wird, richtet sich die Benachrichtigung nach dem Risikoniveau. Bei hohem Gefährdungspotenzial kann der Auftraggeber benachrichtigt werden, um rechtliche/operative/kommunikative Maßnahmen vorzubereiten, auch wenn eine Ausnutzung nicht bestätigt ist.

Standardmodell: Infrastruktur des Auftraggebers

• Daten werden auf der Infrastruktur des Auftraggebers verarbeitet und gespeichert (Hosting, Cloud, eigene Server).
• Der Zugriff auf die Systeme des Auftraggebers erfolgt über vereinbarte sichere Kanäle (VPN, SSH, Bastion-Hosts), die beim Onboarding definiert werden.

Testumgebungen und Testdaten

• Für unkritische Projekte kann eine Testumgebung (Staging) bei Webdelo für Entwicklungs- und Testzwecke gehostet werden.
• Wenn kein Zugang zu Produktivdaten besteht, werden Testdaten oder anonymisierte Datensätze verwendet.
• Die Verwendung echter Produktivdaten in Testumgebungen erfordert die ausdrückliche Zustimmung des Auftraggebers und zusätzliche Sicherheitsmaßnahmen.

Umgang mit sensiblen Daten

• Der Auftraggeber ist verpflichtet, uns über Systeme zu informieren, die sensible Daten verarbeiten (personenbezogene Daten, Finanzdaten, Gesundheitsdaten, regulierte Daten).
• Für Systeme mit sensiblen Daten gelten zusätzliche Maßnahmen:
• Eingeschränkter Zugangsumfang und Personalkreis.
• Bei Bedarf können gesonderte Vereinbarungen mit Teammitgliedern getroffen werden.
• Bevorzugung der ausschließlichen Arbeit auf der Infrastruktur des Auftraggebers ohne lokale Datenkopien.
• Die Definition „sensibler Daten", Zugangsgrenzen und spezifische Anforderungen werden im SOW dokumentiert.

Zugangsentzug bei Vertragsbeendigung

• Bei Vertragsende werden alle gewährten Zugänge kontrolliert entzogen.
• Verifizierung, dass keine Datenkopien auf Webdelo-Systemen verbleiben (falls temporäre Kopien während der Zusammenarbeit zulässig waren).
• Die Checkliste zum Zugangsentzug ist Teil des Beendigungsverfahrens (siehe „Dienstkontinuität und Wissensmanagement").

Angewandte Sicherheitspraktiken

Die folgenden Praktiken sind Teil des standardmäßigen Entwicklungs- und Supportprozesses:

• Code-Review: Alle Änderungen am Produktivcode werden vor dem Deployment geprüft.
• Abhängigkeitsmanagement: Regelmäßige Überwachung und Aktualisierung von Drittanbieter-Bibliotheken und Frameworks zur Behebung bekannter Schwachstellen.
• Zugangskontrolle: Rollenbasierter Zugang, Prinzip der geringsten Berechtigung, Zugangsentzug bei Teamänderungen.
• Protokollierung und Überwachung: Protokollierung auf Anwendungsebene für Diagnostik und Störungsuntersuchung; Überwachung im vereinbarten Umfang.
• Verwaltung sensibler Zugangsdaten (Secrets Management): Anmeldedaten, API-Schlüssel und Token werden sicher gespeichert und nicht in Repositories eingecheckt.
• Framework- und Laufzeitaktualisierungen: Werden mit dem Auftraggeber abgestimmt; sicherheitsbedingte Aktualisierungen können priorisiert werden.

Tiefe der Sicherheitspraktiken hängt vom Kontext ab

Tiefe und Strenge der Sicherheitspraktiken werden gegen Projektanforderungen und Budget abgewogen:

• Basispraktiken (oben aufgeführt) werden auf alle Projekte angewandt.
• Erweiterte Maßnahmen (Penetrationstests, Sicherheitsaudits, Bedrohungsmodellierung, statische/dynamische Analyse) sind nach Vereinbarung verfügbar und werden im SOW dokumentiert.
• Geplante Sicherheitsarbeiten (Audits, Härtung, Infrastrukturüberprüfung) werden als separater Arbeitsbereich behandelt, nicht als Störungsbehebung.

Zertifizierungsstatus

• Eine formale Zertifizierung (SOC 2, ISO 27001) liegt derzeit nicht vor.
• Eine Zertifizierung ist im Zeitraum von 12–15 Monaten geplant. Dies ist eine erklärte Absicht und Planung; der Auftraggeber sollte den aktuellen Status vor Vertragsabschluss erfragen.
• Ein Sicherheitsfragebogen mit Beschreibung der angewandten Kontrollmaßnahmen, Datenverarbeitungspraktiken und organisatorischen Maßnahmen ist auf Anfrage verfügbar.

Zielwerte der Testabdeckung (operative Referenz)

• Standardziel: nicht weniger als 90 % automatisierte Testabdeckung des Anwendungscodes (Unit- und Integrationstests, je nach Technologie-Stack).
• Kritische Geschäftspfade — 100 % Testabdeckung: Alle Codepfade im Zusammenhang mit Zahlungen, Kundendatenverarbeitung, Kerngeschäftslogik und Authentifizierung müssen ausnahmslos durch automatisierte Tests abgedeckt sein.
• Testarten und -tiefe (Unit, Integration, End-to-End) werden projektspezifisch vereinbart und im SOW dokumentiert.

Verantwortung des Auftraggebers für Entscheidungen zum Testbudget

• Wenn der Auftraggeber beschließt, die Testabdeckung zur Budgetoptimierung zu reduzieren oder darauf zu verzichten, muss diese Entscheidung ausdrücklich schriftlich bestätigt werden (Ticket, E-Mail oder SOW-Nachtrag).
• Mit der Bestätigung der reduzierten Testabdeckung erkennt der Auftraggeber die damit verbundenen Risiken an: erhöhte Wahrscheinlichkeit von Regressionen, längere Diagnose- und Behebungszeiten bei Störungen sowie höhere Kosten zukünftiger Änderungen.
• Webdelo dokumentiert die Entscheidung zur reduzierten Abdeckung und deren potenzielle Auswirkungen im Projekt-Risikoregister.

Statische Analyse und Code-Review-Standards

• Alle Änderungen am Produktivcode unterliegen einem Code-Review vor dem Deployment.
• Statische Analysewerkzeuge (Linter, Code-Style-Prüfer) sind, wo anwendbar, Teil der Standard-CI/CD-Pipeline.
• Für Projekte mit erhöhten Sicherheitsanforderungen können SAST/DAST-Werkzeuge nach Vereinbarung integriert werden (im SOW dokumentiert).

Verfügbarkeit der Berichterstattung (auf Anfrage / nach Plan)

Berichterstattung kann auf Basis von Ticketdaten erstellt werden. Standardmodus:

• Auf Anfrage, um unnötigen Aufwand für niedrige Pläne zu vermeiden. Für Enterprise-Pläne kann periodische Berichterstattung vereinbart werden.

Metriken, die aus der Tickethistorie ermittelt werden können

Bei Arbeit über Tickets können folgende Metriken für gewählte Zeiträume extrahiert werden:

• Zeit bis zur Erstreaktion.
• Zeit bis zur Dienstwiederherstellung (falls zutreffend).
• Anzahl der Störungen nach Kritikalität und Kategorie.
• Historische Störungslisten und Zusammenfassungen.

Nutzung der Berichterstattung zur kontinuierlichen Verbesserung

Ticketbasierte Berichterstattung kann genutzt werden für:

• Identifizierung wiederkehrender Störungsmuster.
• Verbesserung der Überwachungsabdeckung und Alarmqualität.
• Verkürzung der Erkennungs- und Wiederherstellungszeiten durch Fokussierung auf Schwachstellen im Dienst.

Format und Frequenz der Berichterstattung

• Basic: Berichterstattung auf Anfrage.
• Extended: Monatliche Berichterstattung als Option verfügbar; Format wird projektspezifisch vereinbart.
• Enterprise: Periodische Berichterstattung (standardmäßig monatlich); Format wird im SOW vereinbart (PDF-Zusammenfassung, CSV-Export oder Dashboard-Zugang).

Werkzeuge und Integrationen

• Ein Ticket-Portal ist für alle Pläne obligatorisch.
• Extended und Enterprise: Jira wird standardmäßig für das Ticketmanagement verwendet.
• Enterprise (nach Vereinbarung): Integration mit dem bestehenden System des Auftraggebers ist möglich. Beispiele koordinierbarer Systeme: Jira Service Management, ServiceNow, PagerDuty, Zendesk.
• Kommunikationskanäle: Ticketsystem (obligatorisch), Slack / Microsoft Teams (nach Vereinbarung für operative Kommunikation).
• Ein Wechsel oder eine Integration von Werkzeugen erfordert Onboarding, Prozessanpassung und kann die Kosten beeinflussen — wird im SOW dokumentiert.

Abhängigkeiten von Drittanbietern

Wenn die geschäftliche Auswirkung durch externe Dienste verursacht wird (Zahlungsanbieter, E-Mail-Dienste, sonstige APIs):

• Wir können den externen Dienst nicht reparieren.
• Wir können diagnostizieren, Nachweise bereitstellen, Maßnahmen zur Schadensbegrenzung vorschlagen und die Koordination zwischen Auftraggeber und Anbieter im Rahmen des bezahlten Supportumfangs unterstützen.

Pflichten des Auftraggebers mit Einfluss auf das Ergebnis

Für bestmögliche Ergebnisse sollte der Auftraggeber bereitstellen:

• Erforderliche Zugänge (Produktionsumgebung, Logs, CI/CD, soweit zutreffend).
• Zeitnahe Antworten auf Supportanfragen, wenn Informationen benötigt werden.
• Bestätigung der geschäftlichen Auswirkung und Freigabe von Sofortmaßnahmen, wenn erforderlich.

Was als Änderung gilt

Eine Änderung ist jede Modifikation der Produktionsumgebung oder Codebasis, die das Systemverhalten beeinflussen kann:

• Code-Deployments (neue Funktionen, Fehlerbehebungen, Refactoring).
• Aktualisierungen von Abhängigkeiten und Frameworks.
• Konfigurationsänderungen (Umgebungsvariablen, Routing, Zugriffsregeln).
• Infrastrukturänderungen in unserem Verwaltungsbereich (Container-Konfiguration, CI/CD-Pipeline-Modifikationen).

Freigabeprozess

• Standardänderungen: Anforderung über Ticket, Schätzung, Planung und Deployment nach Freigabe durch den Auftraggeber.
• Enterprise / integrierter Prozess: Änderungen können über den Workflow des Auftraggebers koordiniert werden — Sprintplanung, Änderungsprüfung oder Freigabestufen. Integrationsdetails werden im SOW dokumentiert.
• Autorisierte Ansprechpartner: Der Auftraggeber benennt Personen, die zur Freigabe von Änderungen berechtigt sind (geschäftliche, technische, infrastrukturelle Rollen). Die Liste der autorisierten Kontakte wird im SOW oder in der Projektdokumentation geführt.

Wartungsfenster

• Für kleinere Projekte werden Änderungen typischerweise während der Geschäftszeiten ohne formales Wartungsfenster deployed.
• Für Enterprise und kritische Systeme werden Wartungsfenster im Voraus vereinbart und im SOW dokumentiert.
• Die Deployment-Planung kann an die Geschäftszeiten des Auftraggebers angepasst werden, um die Auswirkung auf Nutzer zu minimieren (z. B. Nacht- oder Frühstundenfenster).

Rollback-Plan

• Ein Rollback-Plan ist obligatorisch für kritische Änderungen (Änderungen, die geschäftskritische Abläufe betreffen, Datenbankmigrationen, Infrastrukturmodifikationen).
• Der Rollback-Ansatz wird im Ticket vor dem Deployment dokumentiert.
• Für unkritische Änderungen wird die Rollback-Bereitschaft als standardmäßige Ingenieurspraxis aufrechterhalten.

Notfalländerungen

• Bei einem vollständigen Dienstausfall, der durch eine kürzliche Änderung verursacht wurde, kann ein Notfall-Rollback oder Hotfix ohne vorherige Freigabe des Auftraggebers angewendet werden, um den Dienst wiederherzustellen.
• Notfalländerungen ändern keine Geschäftsanforderungen — sie stellen den vorherigen Arbeitszustand wieder her oder wenden eine gezielte Korrektur an.
• Der Auftraggeber wird unmittelbar nach Anwendung einer Notfalländerung benachrichtigt, mit einer Erklärung, was durchgeführt wurde und warum.

Planvergleich (Leistungsumfang)

Zusätzliche Leistungsmerkmale nach Plan (Enterprise-Bedingungen im SOW definiert)

Verfügbarkeitsziele und Rahmenwerte

Für Systeme, bei denen wir vollen Zugang zur Anwendungsebene und zum Deployment-Prozess haben und die Infrastruktur stabil und angemessen kontrolliert ist, beträgt der operative Verfügbarkeitszielwert 99,5 % mit einem Zielwert von 99,8 %. Dies gilt für Systeme, die von unserem Team entwickelt oder wesentlich betreut werden und nur begrenzte komplexe Drittanbieterabhängigkeiten aufweisen.

Verfügbarkeitsziele werden nicht als bedingungslose Garantien veröffentlicht, da die Verfügbarkeit von Faktoren außerhalb unserer Kontrolle abhängt:

• Stabilität der Infrastruktur und SLA des Hosting-Anbieters.
• Zuverlässigkeit von Drittanbieterdiensten (Zahlungs-Gateways, externe APIs, CDN).
• Rechtzeitige Bereitstellung von Zugängen und Freigaben durch den Auftraggeber.
• Architektonische Reife des Systems und Niveau der technischen Schulden.

Projektspezifische Verfügbarkeitsziele werden im SOW nach Onboarding und Systembewertung dokumentiert. Wir verpflichten uns zu dem, was wir kontrollieren; die Verfügbarkeit auf Infrastrukturebene liegt in der Verantwortung des Hosting-Anbieters.

Warum keine öffentlichen Preise: Kostenfaktoren für Supportpläne

Die Preise für den Support werden nicht öffentlich fixiert, da die Kosten für zuverlässige SLA-Verpflichtungen von mehreren projektspezifischen Faktoren abhängen:

• Komplexität des Technologie-Stacks (Go-Microservices, Laravel, Symfony, Altsysteme, gemischte Umgebungen).
• Anzahl der Integrationen und Drittanbieterabhängigkeiten (Zahlungssysteme, externe APIs, Datenanbieter).
• Erforderliche Seniorität der Ingenieure (Senior-/Lead-Beteiligung für kritische Systeme vs. Standardsupport für stabile Anwendungen).
• Anforderungen an Reaktion und Kommunikation (Aktualisierungsfrequenz, 24×7-Verfügbarkeit, Anzahl der Kommunikationskanäle).
• Anforderungen an Berichterstattung und Werkzeuge (Integration mit Kundensystemen wie Jira, ServiceNow; Dashboard-Zugang; individuelle Berichterstattung).
• Anforderungen an Sicherheitsprozesse (Tiefe der sicheren Entwicklungspraktiken, Sicherheitsaudits, Penetrationstests).
• Einschränkungen bei der Datenverarbeitung (Verbot externer KI-Werkzeuge, Bereitstellung lokaler Modelle, eingeschränkte Zugangsumgebungen).

Leistungsumfang und Zielwerte werden im SOW definiert. Teamzusammensetzung und Seniorität der Ingenieure richten sich nach der Kritikalität der Störungen und der Systemkomplexität. Anforderungen an Berichterstattung, Überwachungstiefe und Kommunikationsfrequenz wirken sich direkt auf die Kosten aus. Wir verpflichten uns zu dem, was wir kontrollieren; projektspezifische Zielwerte werden vertraglich vereinbart.

Vertragliche Verpflichtungen im SOW dokumentiert

Detaillierte vertragliche Verpflichtungen (einschließlich Servicegutschriften, zeitbasierte Eskalationsschwellen, RPO/RTO, Fristen für Sicherheitsbenachrichtigungen, Frequenz der Serviceüberprüfungen und Verfügbarkeitsziele) werden im SOW / Anhang zum Supportplan dokumentiert, nicht auf dieser öffentlichen Seite.

Servicegutschriften (Service Credits)

Für den Enterprise-Plan können finanzielle Kompensationen (Servicegutschriften) bei Verfehlung der Zielwerte für Erstreaktion/Arbeitsbeginn anfallen. Die konkreten Bedingungen, Berechnungsmethoden und Obergrenzen werden im SOW / Vertragsanhang dokumentiert.

Im SOW dokumentierte Grundsätze:

• Grundlage: Eine Servicegutschrift wird angewendet, wenn der Auftragnehmer die Arbeit an einem S1-Vorfall nicht aufnimmt (keine Bestätigung der Annahme und des tatsächlichen Arbeitsbeginns) innerhalb der vereinbarten Erstreaktionszeit.
• Höhe: ab 2 % der monatlichen Supportgebühr pro Vorfall, der für eine Servicegutschrift qualifiziert.
• Obergrenze: insgesamt nicht mehr als 30 % der monatlichen Supportgebühr pro Abrechnungszeitraum (Monat).
• Form der Kompensation: Servicegutschrift (Rabatt) auf den nächsten Abrechnungszeitraum.
• Servicegutschriften gelten für die Erstreaktion/den Arbeitsbeginn, jedoch nicht für die vollständige Behebungsdauer, da die Behebungszeit von der Art des Vorfalls abhängt und nicht immer vorhersagbar ist.
• Auf Wunsch des Auftraggebers können die Bedingungen (Prozentsätze, Obergrenzen, Metriken) angepasst werden; die Servicegebühr wird entsprechend dem Verpflichtungsniveau neu berechnet.

Eskalationsmatrix mit zeitbasierten Schwellenwerten

Für den Enterprise-Plan wird eine Eskalationsmatrix mit zeitbasierten Schwellenwerten (wann Führungsrollen einbezogen werden) im SOW / Anhang zum Supportplan dokumentiert.

Im SOW dokumentierte Grundsätze:

• Rollen: Bereitschaftsingenieur → Technische Projektleitung → CTO → CEO.
• Auslöser (S1):
• 4 Stunden ohne Arbeitsbeginn bei S1 → Technische Projektleitung wird benachrichtigt.
• 8 Stunden ohne Arbeitsbeginn bei S1 → CTO wird benachrichtigt.
• 12 Stunden ohne Arbeitsbeginn bei S1 → CEO wird benachrichtigt.
• Benachrichtigungskanäle: Ticketsystem (obligatorisch) + zusätzliche Kanäle laut Vertrag (siehe „Kommunikationskanäle").

Kommunikation während eines Vorfalls: Frequenz der Statusaktualisierungen

Die Frequenz der Statusaktualisierungen richtet sich nach dem Supportplan. Der primäre Kanal in allen Plänen ist das Ticketsystem.

• Enterprise: für S1 — alle 30 Minuten; für S2 — alle 4 Stunden (während der vereinbarten Supportzeiten).
• Extended (Pro): für S1 — alle 2 Stunden; für S2 — täglich.
• Basic (Start): für S1 — alle 4 Stunden; für S2 — bei Schlüsselmeilensteinen (angenommen / behoben) oder laut Vertrag.

Zusätzliche Kanäle für Enterprise (laut Vertrag): Ticket + Chat + E-Mail und weitere vereinbarte Kanäle.

Hinweis: Höhere Anforderungen an die Aktualisierungsfrequenz und die Anzahl der Kanäle erhöhen die Kosten des Supports — die Bedingungen werden im Vertrag dokumentiert.

Notfallwiederherstellung (Disaster Recovery): RPO/RTO und Datensicherungen (Backups)

Wiederherstellungsziele (RPO/RTO) werden im SOW / DR-Anhang nur dokumentiert, wenn Datensicherungen und Notfallwiederherstellung im vereinbarten Leistungsumfang enthalten sind. RPO/RTO-Werte hängen vom Datenvolumen und der Architektur ab und werden nach einem Audit festgelegt.

Im SOW dokumentierte Grundsätze:

• RPO (Recovery Point Objective) und RTO (Recovery Time Objective) werden pro System nach einem Audit festgelegt und umfassen:
• Zusammensetzung von Daten und Komponenten (Datenbanken, Dateispeicher, Caches, Warteschlangen usw.)
• Datensicherungsmethode (vollständig / inkrementell / differenziell)
• Aufbewahrungsfrist (Retention)
• Konsistenzanforderungen (z. B. MySQL + Redis + MongoDB-Kombinationen usw.)
• Verfahren und Häufigkeit von Wiederherstellungstests
• Wenn Datensicherungen durch den Auftraggeber durchgeführt werden:
• Der Auftragnehmer kann eine Überwachung/Verifizierung der Datensicherungsdurchführung einrichten (laut Vertrag).
• Der Auftragnehmer kann bei der Wiederherstellung während eines Vorfalls unterstützen (laut Vertrag).

Testen der Notfallwiederherstellung (Disaster Recovery Testing)

Wir empfehlen regelmäßiges Testen des Wiederherstellungsprozesses, um die Funktionsfähigkeit der Datensicherungen und die Korrektheit der Wiederherstellungsverfahren zu verifizieren. Eine Datensicherung, die nie getestet wurde, ist keine zuverlässige Datensicherung.

• Empfohlene Häufigkeit: nicht seltener als einmal pro Monat für Produktionssysteme.
• Testumfang: Wiederherstellungstests sollten sowohl das Dateisystem als auch alle Datenbanken (relational, NoSQL, Caches, Warteschlangen, soweit zutreffend) umfassen.
• Testdatenstrategie: Testmarker (bestimmte Datensätze oder Daten-Snapshots) werden im Voraus vorbereitet und über einen Zeitraum im System belassen. Dies ermöglicht die Verifizierung, dass die Wiederherstellung sowohl für ältere Daten als auch für aktuelle Änderungen korrekt funktioniert — und bestätigt, dass kein Datenverlust innerhalb des Sicherungsfensters auftritt.
• Testumgebung: Wiederherstellungstests werden gegen Produktions-Datensicherungen durchgeführt (Wiederherstellung in eine separate Umgebung), um realitätsnahe Wiederherstellungsszenarien zu validieren.
• Für kritische Systeme: Das Testintervall kann verkürzt werden (z. B. zweiwöchentlich oder wöchentlich), wenn der Auftraggeber eine höhere Absicherung benötigt und bereit ist, dafür Budget bereitzustellen.
• Testhäufigkeit und -umfang werden im SOW / DR-Anhang dokumentiert.

Benachrichtigung bei Sicherheitsvorfällen (Security Breach Notification)

Für den Enterprise-Plan wird die Benachrichtigungsfrist für einen bestätigten Sicherheitsvorfall im Vertrag dokumentiert und beträgt standardmäßig bis zu 48 Stunden ab Bestätigung eines unbefugten Zugriffs oder einer bestätigten Datenpanne.

Im SOW dokumentierte Grundsätze:

• Benachrichtigung des Auftraggebers: innerhalb von 48 Stunden ab Bestätigung eines unbefugten Zugriffs oder einer bestätigten Datenpanne.
• Kürzere Fristen (z. B. 24 Stunden) können gesondert mit Neuberechnung der Servicegebühr vereinbart werden.
• Benachrichtigungskanal: Ticketsystem + E-Mail (und/oder vereinbarter sicherer Kanal).

Regelmäßige Serviceüberprüfungen (Service Review / QBR)

Für den Enterprise-Plan stehen regelmäßige Serviceüberprüfungen (QBR, Quarterly Business Review) zur Verfügung: Analyse von Störungen, Trends und Empfehlungen zur Verbesserung der Überwachung und Stabilität. Die Frequenz wird im Vertrag dokumentiert.

Im SOW dokumentierte Grundsätze:

• Frequenz: vierteljährlich (im Enterprise-Plan enthalten), monatlich (optional, separat abgerechnet).
• Eingaben: Ticketbericht, wichtigste Störungen, Stabilitätsrisiken und Empfehlungen.
• Ergebnisse: Maßnahmenplan, Vorschläge zur Verbesserung der Überwachung, Empfehlungen zur Stabilisierung/Refaktorisierung (als separater Arbeitsbereich).

Onboarding ist Voraussetzung für zuverlässige Zielwerte

Onboarding ist erforderlich, da die Komplexität und operative Reife von Diensten variieren. Übernommene Systeme (nicht ursprünglich von unserem Team entwickelt) erfordern eine Bestandsaufnahme, bevor zuverlässige Zielwerte angewendet werden können.

Onboarding-Checkliste (Mindestumfang)

• Einrichtung der Zugänge (Produktionsumgebung/Logs/Repositories/CI/CD, soweit zutreffend).
• Architekturüberblick und Abhängigkeitskarte (einschließlich externer Dienste).
• Identifizierung geschäftskritischer Abläufe und kritischer Seiten/Endpunkte.
• Überprüfung der Störungshistorie und bekannter Schwachstellen.
• Vereinbarung über Überwachungsumfang und Alarmweiterleitung.

Onboarding-Tiefe und Zeiträume

• Kleine, typische Projekte (z. B. Standard-Webanwendungen): erste Einsatzbereitschaft kann innerhalb der ersten Woche erreicht werden.
• Komplexe DevOps-Umgebungen (Container, Kubernetes, komplexe CI/CD): Onboarding erfordert mehr Zeit und praktische Validierung.
• Große Enterprise-Systeme: Onboarding und Stabilisierung können mehrere Monate dauern. Volle SLA-Zielleistung wird nach Erfüllung der Onboarding-Voraussetzungen erwartet.

Grundprinzipien für Legacy-Systeme

• Kein Ausschlusskriterium: Legacy-Code ist kein Grund, ein Projekt abzulehnen. Wir verfügen über Erfahrung mit übernommenen Systemen verschiedener Technologie-Stacks und unterschiedlicher technischer Schulden.
• Ehrliche Erwartungen: Für übernommene Systeme können wir nicht dasselbe Garantieniveau bieten (Reaktionszeiten, Schätzgenauigkeit, Wiederherstellungsziele) wie für Systeme, die wir selbst von Grund auf entwickelt haben. Die Differenz hängt ab von: Dokumentationsqualität, Testabdeckung, architektonischer Klarheit, Anzahl undokumentierter Abhängigkeiten und Zugang zum Wissen des ursprünglichen Entwicklungsteams.
• Onboarding ist entscheidend: Für Legacy-Systeme ist die Onboarding-Phase länger und gründlicher. Sie umfasst Architektur-Discovery, Abhängigkeitskartierung, Identifizierung undokumentierten Verhaltens und Risikobewertung (siehe „Onboarding zur Supportbereitschaft").
• Schrittweise Verbesserung: Wir empfehlen und können einen phasenweisen Ansatz zur Verbesserung von Legacy-Systemen umsetzen: zuerst Stabilisierung (Überwachung, Behebung kritischer Fehler, Testabdeckung für Kernabläufe), dann gezieltes Refactoring und architektonische Verbesserungen als geplanter Arbeitsbereich.

Empfehlungen für Auftraggeber mit Legacy-Systemen

• Budget für die Bestandsaufnahme einplanen: Die initiale Bewertungsphase ist unverzichtbar und sollte nicht übersprungen werden. Sie bestimmt realistische SLA-Zielwerte und identifiziert die Bereiche mit dem höchsten Risiko.
• Angepasste SLA-Zielwerte erwarten: Wiederherstellungszeiten und Schätzgenauigkeit für Legacy-Systeme werden weiter gefasst sein als für Systeme, die wir durchgängig kontrollieren. Diese angepassten Zielwerte werden nach dem Onboarding im SOW dokumentiert.
• In Testabdeckung und Dokumentation investieren: Der schnellste Weg, ein Legacy-System auf ein höheres Serviceniveau zu bringen, ist die Erhöhung der automatisierten Testabdeckung für kritische Pfade und die Erstellung operativer Dokumentation.
• Einen Refactoring-Fahrplan in Betracht ziehen: Wir liefern Empfehlungen zu Refactoring-Prioritäten auf Basis von geschäftlicher Auswirkung, Stabilitätsrisiko und Kosten. Refactoring wird als geplanter Arbeitsbereich behandelt, nicht als Störungsbehebung.

Architekturdokumentation und Wissensbasis

• Architekturdokumentation ist obligatorisch für alle Projekte mit aktivem Support.
• Für übernommene oder Altsysteme wird beim Onboarding dedizierte Zeit für die Dokumentation eingeplant.
• Die Dokumentation umfasst: Architekturüberblick, Abhängigkeitskarte, kritische Abläufe, Deployment-Verfahren, bekannte Risiken und Betriebshandbücher (Runbooks).
• Support-Checklisten und Betriebshandbücher werden für wiederholbare operative Aufgaben erstellt und gepflegt.

Reduzierung des Schlüsselpersonenrisikos

• Für kritische Projekte werden mindestens zwei Fachkräfte mit überlappenden Wissensbereichen eingesetzt.
• Die Einbindung der Technischen Leitung und/oder des CTO wird für große Projekte aufrechterhalten, um architektonische Kontinuität zu gewährleisten.
• Interner Wissensaustausch ist Teil des standardmäßigen Ingenieurprozesses (Code-Reviews, Dokumentation, gemeinsame Bearbeitung komplexer Störungen).

KI-gestützter Support (optional)

KI-basierte Analysewerkzeuge können zur Unterstützung des Betriebs eingesetzt werden:

• Codeanalyse, Protokollanalyse, Integrationsüberprüfung, Analyse der Vorfallshistorie.
• Alle KI-gestützten Maßnahmen werden unter fachlicher Aufsicht durchgeführt (Mensch in der Entscheidungsschleife).
• Auswirkung auf die Liefergeschwindigkeit: Je nach Projekttyp, Komplexität und Kritikalität kann der Einsatz KI-gestützter Werkzeuge routinemäßige Ingenieurtätigkeiten (Codeanalyse, Abhängigkeitsprüfung, Protokollauswertung, Dokumentationserstellung, Test-Scaffolding) um einen geschätzten Faktor von 5× bis 20× gegenüber vollständig manueller Ausführung beschleunigen. Die tatsächliche Beschleunigung variiert je nach Aufgabentyp und ist kein garantierter fester Multiplikator; sie wird als operative Referenz auf Basis interner Erfahrung angegeben.

Die KI-Nutzung ist optional und vereinbarungspflichtig:

• Externe KI-Dienste (cloudbasiert) werden nur mit ausdrücklicher Zustimmung des Auftraggebers verwendet.
• Optionen: Dienste mit Standort in der EU/USA, lokale Modelle auf der Infrastruktur des Auftraggebers oder ein vollständiges Verbot der KI-Nutzung.
• Ein vollständiges Verbot von KI-Werkzeugen ist möglich; dies kann sich auf Bearbeitungszeiten und Kosten auswirken — wird im SOW dokumentiert.

Einarbeitung eines neuen Teammitglieds (Ersatz oder Teamerweiterung)

Die Zeit, die ein neues Teammitglied benötigt, um eigenständig produktiv zu arbeiten, hängt von mehreren Faktoren ab:

• Projektkomplexität: Monolith vs. Microservices, Anzahl der Integrationen, Tiefe des Technologie-Stacks.
• Dauer der Projektbetreuung: Projekte, die von unserem Team über einen längeren Zeitraum betreut werden, verfügen über bessere Dokumentation und etablierte Wissenstransferprozesse.
• Dokumentation und Testabdeckung: Gut dokumentierte Projekte mit hoher Testabdeckung ermöglichen eine schnellere Einarbeitung.
• KI-Werkzeug-Freigabe: Ob KI-gestützte Codeanalyse- und Dokumentationswerkzeuge für das Projekt freigegeben sind, beschleunigt die Einarbeitung.
• Dienstumfang und -größe: Anzahl der Dienste, Module und Geschäftsdomänen, mit denen der Ingenieur arbeiten muss.

Typische Einarbeitungszeiträume (operative Referenz, keine Garantie):

• Minimum: ab 2 Wochen für gut dokumentierte Projekte mit begrenztem Umfang.
• Durchschnitt: etwa 3–4 Wochen für typische Projekte mittlerer Komplexität.
• Komplexe oder Altsysteme: kann länger dauern, abhängig von den oben genannten Faktoren.

Während der Einarbeitungsphase arbeitet das neue Teammitglied unter Anleitung der Technischen Leitung oder eines Senior-Ingenieurs, um Qualität und Kontinuität sicherzustellen.

Ausstiegs- und Beendigungsverfahren

Bei Vertragsende können nach Vereinbarung bereitgestellt werden:

• Vollständige Projektdokumentation und Materialien für den Wissenstransfer.
• Support-Checklisten, Betriebshandbücher und operative Verfahren.
• Vollständige Liste der Zugänge, Integrationen und Abhängigkeiten.
• Risikobericht und Liste bekannter technischer Schulden und Schwachstellen.

Für niedrigere Planebenen ist ein strukturiertes Beendigungsverfahren möglicherweise nicht standardmäßig enthalten und kann separat vereinbart werden.