Technische Fallstudien

Technische Entscheidungen unter realen Bedingungen.

Diese tatsächlichen Situationen beschreiben wir nur so detailliert, wie es verantwortbar ist. Im Mittelpunkt stehen Problem, Entscheidung und betrieblicher Zustand danach.

Ausgewählte Arbeiten

Vier Situationen, in denen die Rahmenbedingungen die Lösung bestimmten.

Anonymisierter Kundenfall

Ein SRE-Betriebsmodell für eine rund um die Uhr laufende Produktionsplattform

Ausgangslage: Eine Produktionsplattform ging in den Dauerbetrieb. Die Betreuung musste schichtübergreifend funktionieren, statt vom Gedächtnis Einzelner abzuhängen.
Einschränkung / technisches Problem: Schichten, Rufbereitschaft, Übergabe, Zuständigkeit und Verantwortung bei Vorfällen brauchten klare Grenzen – auch für SRE.
Unser Vorgehen: Wir definierten Schichten, Bereitschaft, Übergabe, Eskalation und Entscheidungsrechte. Die Eskalation führte von der Person in der Schicht über Rufbereitschaft und fachliche Leitung zum Plattformverantwortlichen und CTO.
Ergebnis: Der Produktionsbetrieb ließ sich durch Rollen, Zustand und Abläufe beschreiben statt durch persönliches Wissen oder Heldentaten.
Was der Fall zeigt: Zuverlässiger Betrieb braucht eindeutige Befugnisse und Übergaben, nicht nur fähige Menschen.

Passende LeistungStabilisierung und Zuverlässigkeit

Anonymisierter Kundenfall

Analyse einer ausgelasteten Produktionsdatenbank bei steigender Parallelität

Ausgangslage: Eine Produktionsdatenbank näherte sich der CPU-Sättigung. Zustandsprüfungen schlugen fehl; mehrere externe Verbraucher waren betroffen.
Einschränkung / technisches Problem: Die Wiederherstellung erklärte den Ausfall nicht. Symptome mussten von höherer gleichzeitiger Last und einem langsameren kritischen Datenbankpfad getrennt werden.
Unser Vorgehen: Nachdem der Dienst wiederhergestellt war, setzten wir die Ursachenanalyse fort. Sofortmaßnahmen, Korrekturen, Belege und Annahmen wurden getrennt dokumentiert.
Ergebnis: Der Vorfallbericht hielt Laständerung und Befunde zum Datenbankpfad fest, ohne die Wiederherstellung als Ursachenbeweis auszugeben.
Was der Fall zeigt: Dienstwiederherstellung und Ursachenanalyse sind unterschiedliche Meilensteine.

Passende LeistungStabilisierung und Zuverlässigkeit

Technischer Fall von Gronnark

Wiederherstellung von 17 Git-Repositories nach Verlust des Adminzugangs

Ausgangslage: Der administrative Zugang zu einem alten GitHub-Konto ging verloren; eine Kontowiederherstellung war nicht möglich. Vor der Migration mussten 17 Repositories gesichert werden.
Einschränkung / technisches Problem: Der Umzug durfte nicht zur einzigen Kopie von Historie und Referenzen werden.
Unser Vorgehen: Wir erfassten Referenzen, Historie und Trees, erstellten git bundles und Branch-Archive sowie SHA256-Manifeste und prüften Bundles, Objektintegrität, saubere Klone, Submodule und LFS-Abhängigkeiten.
Ergebnis: Alle 17 Repositories wurden in einer neuen Organisation wiederhergestellt. Relevante Referenzen wurden SHA für SHA geprüft; die alte Organisation blieb historische Quelle.
Was der Fall zeigt: Erst sichern. Dann migrieren.

Passende LeistungInfrastruktur und Plattform

Anonymisierter Kundenfall

Ablösung instabiler Fernwartung für eine Zahnarztpraxis

Ausgangslage: Eine Praxis nutzte eine Windows-basierte Praxissoftware mit lokaler Datenbank. Ein Endnutzer-Fernzugriffstool unterbrach zunehmend die Support-Sitzungen.
Einschränkung / technisches Problem: Datenbank und interne Dienste durften nicht bloß für bequemeren Remote Desktop ins Internet gestellt werden.
Unser Vorgehen: Wir entwarfen die Verbindung getrennt von der Anwendung: verschlüsselter Tunnel, kontrollierter externer Zugang und VPN-Eintritt für autorisierte Techniker vor administrativen Protokollen.
Ergebnis: Das vorgeschlagene Zugangsmodell sah vor, die lokale Datenbank nicht öffentlich zugänglich zu machen und den Netzzugang ausdrücklich zu kontrollieren. Es bot eine sicherere Architektur als Ersatz für den unzuverlässigen Fernwartungsweg.
Was der Fall zeigt: Ein Remote-Desktop-Symptom kann ein Architekturproblem des Fernzugriffs sein.

Passende LeistungInfrastruktur und Plattform

Weitere technische Fälle

Eigenständige Probleme mit konkreten Änderungen am System oder seinem Betrieb.

Anonymisierter Kundenfall

Vorfallmanagement mit klarer Zuständigkeit

Ausgangslage: Schweregrad, Eigentümerschaft, Eskalation und Abschlusskriterien waren uneindeutig.
Was sich geändert hat: Wir führten ein Schweregradmodell, Owner- und Commander-Rollen, Eskalation, Abschlusskriterien für Vorfall und Postmortem sowie Korrekturmaßnahmen mit Verantwortlichen in einem gemeinsamen Datensatz ein.
Ergebnis: Die wieder laufende Produktion war nicht mehr das einzige Kriterium für den Abschluss.

Anonymisierter Kundenfall

SRE-Verantwortung von Anwendungsverantwortung trennen

Ausgangslage: SRE-Beteiligung wurde zunehmend als Erwartung verstanden, jede Anwendungsstörung selbst ursächlich zu erklären.
Was sich geändert hat: Wir trennten Erkennung, Folgenabschätzung, Koordination und Eskalation von der technischen Verantwortung für die Komponente.
Ergebnis: Verantwortung konnte dort liegen, wo auch Befugnis und Kontext zum Handeln vorhanden waren. Ohne Kontrolle gibt es keine echte Zuständigkeit.

Anonymisierter Kundenfall

Schichtübergabe als Betriebssystem gestalten

Ausgangslage: Betriebsinformationen lagen verteilt in Slack, Jira, Confluence und persönlichen Gesprächen.
Was sich geändert hat: Wir standardisierten die Übergabe aktiver Vorfälle, offener Änderungen, erwarteter Ereignisse, Risiken, ausstehender Aufgaben und ihrer Verantwortlichen.
Ergebnis: Die Betriebszusammenfassung wurde eine definierte Systemfähigkeit statt einer informellen Nachricht zwischen Schichten.

Anonymisierter Kundenfall

Fehlgeschlagene Zustandsprüfungen ohne erfundene Ursache untersuchen

Ausgangslage: Kurze Ausfälle bei Zustandsprüfungen gingen mit Verbindungsindizien einher; der Dienst erholte sich rasch.
Was sich geändert hat: Wir hielten Beobachtungen, Belege, einen plausiblen Mechanismus und offene Fragen getrennt fest.
Ergebnis: Das Postmortem benannte die Grenze des Wissens, statt eine nicht belegte Ursache als Gewissheit darzustellen.

Technischer Fall von Gronnark

CI/CD-Vertrauen nach der Repository-Migration neu aufbauen

Ausgangslage: Der Umzug der Repositories übertrug nicht die Identitäten und Berechtigungen für Deployments.
Was sich geändert hat: Wir bauten Actions, Runner, OIDC und AWS-Vertrauen neu auf, tauschten SSH-Schlüssel und Secret und testeten isoliert die Kette von Actions über Runner und AWS bis SSH. Temporären Firewall-Zugang entfernten wir danach.
Ergebnis: Die Vertrauenskette wurde durchgängig geprüft, nicht aus einer grünen Pipeline abgeleitet.

Technischer Fall von Gronnark

Eine isolierte Stage vor Produktionsänderungen aufbauen

Ausgangslage: Website-Änderungen betrafen inzwischen Sprachen, Edge-Logik, CloudFront, WAF, Geografiehinweise und Automatisierung.
Was sich geändert hat: Wir bauten eine Stage mit getrenntem Infrastrukturzustand, Edge-Vorschau und eigenem Deployment-Ablauf. Die Übernahme in Produktion blieb eine eigene Entscheidung.
Ergebnis: Änderungen ließen sich deployed testen, ohne dass jeder Testfehler zur Produktionsänderung wurde; Stage blieb aus dem Suchindex.

Technischer Fall von Gronnark

Internationale Leistung ohne erzwungene Geo-Weiterleitung

Ausgangslage: Die Arbeit in verschiedenen Märkten brauchte mehr als eine Länderliste.
Was sich geändert hat: Wir definierten lokale, regionale und internationale Profile für Remote- und Vor-Ort-Arbeit, Reisen, Arbeitszeitüberschneidung, physische Intervention und Leistungsverfügbarkeit. Das CloudFront-Land ist nur ein Hinweis; die Person wählt selbst.
Ergebnis: Das Modell beschreibt Möglichkeiten, ohne lokales Büro, ständige Präsenz oder Weiterleitungszwang zu behaupten.

Technischer Fall von Gronnark

Technisches Rebranding ohne Betriebsbruch

Ausgangslage: Der Wechsel von Aize.IT zu Gronnark betraf Domains, E-Mail, Workspace, GitHub, DNS, Zertifikate, Automatisierung, Dokumentation und Kundenbeziehungen.
Was sich geändert hat: Wir planten Domainübergänge, Weiterleitungen, E-Mail-Aliasse und -Migration, DNS- und DKIM-Änderungen, eine öffentliche Erklärung und schrittweise Änderungen der Infrastrukturidentität.
Ergebnis: Bestehende Verpflichtungen und Betriebszugänge konnten den Namenswechsel überdauern. Ein technisches Rebranding ist auch eine Migration.

Vertraulichkeit und Einordnung

Kundenfälle sind anonymisiert, wenn vertragliche oder betriebliche Vertraulichkeit es verlangt. Manche beschreiben verschiedene Probleme innerhalb einer längeren Zusammenarbeit; es handelt sich nicht um zwölf verschiedene Kunden.

Kommt Ihnen die Situation bekannt vor?

Beschreiben Sie, was geschieht, was weiter funktionieren muss und wo die Unsicherheit beginnt.

Situation besprechen