Managed Infrastructure Services · IT-Betrieb mit SRE-Methodik für den DACH-Mittelstand
Managed Infrastructure Services für den DACH-Mittelstand — IT-Betrieb mit SRE-Methodik.
Über 100.000 offene IT-Stellen im DACH-Raum 2026 (Bitkom - siehe hierzu auch unseren DACH-Datenreport 2026). Konzerne werben Mittelstands-Operations-Profile mit höheren Gehältern ab. Das Ergebnis: Inhouse-Operations-Teams ohne 24/7-Backup, nächtliche Incidents bleiben Stunden offen. Wir schließen die Lücke — mit kleinen Senior-Teams aus Deutschland und EU-Nearshore, SRE-Methodik statt reaktiv-Klassik und einem deutschen Vertragsrahmen.
Wir übernehmen den Betrieb Ihrer Cloud-Infrastruktur, Kubernetes-Cluster, Datenbanken, API-Plattformen und Web-Anwendungen — proaktiv, messbar, mit klaren Service Level Objectives. Auf Wunsch mit KI-gestütztem Monitoring (AIOps) verzahnt. Vertragspartner ist die GLJ Tech GmbH mit Sitz in Münster. Deutscher Gerichtsstand, mittelständische Tagessätze, keine Berater-Pyramide.
IT-Fachkräftemangel und Konzern-Personalverlust
Der Mittelstand verliert Operations-Profile an Konzerne — und steht nachts ohne 24/7-Backup.
Der Mittelstand kämpft im IT-Betrieb an drei Fronten gleichzeitig. Erstens dem allgemeinen IT-Fachkräftemangel — der Bitkom zählt über 100.000 offene IT-Stellen im DACH-Raum 2026, Operations-Profile sind besonders schwer zu finden. Zweitens der Konzern-Konkurrenz, die Mittelstands-Operations-Profile mit höheren Gehältern systematisch abwirbt. Drittens der inhärenten Schwierigkeit, mit kleinen Inhouse-Teams 24/7-Betriebssicherheit zu erreichen. Das Ergebnis: nächtliche Incidents bleiben Stunden offen, bis sie bemerkt werden — wenn überhaupt.
Was IT-Operations im Mittelstand oft scheitern lässt:
- Kein 24/7-Backup — der typische Operations-Lead arbeitet 9 bis 18 Uhr, danach hofft man auf den Sonntag
- Personalverlust an Konzerne durch Gehälter-Wettbewerb — wer geht, hinterlässt eine Wissens-Lücke
- Manuelle Routine-Aufgaben binden Senior-Profile, statt durch Automatisierung skaliert zu werden
- Reaktive Ticket-Bearbeitung statt proaktive SLO-Überwachung
- Keine Post-Mortems nach Incidents — die gleichen Fehler wiederholen sich
- Cloud-Stack-Komplexität wächst (Multi-Cloud, Kubernetes, Microservices) — Operations-Wissen nicht
IT-Operations ist nicht ein Personalproblem. Es ist ein strukturelles Problem. Senior-Teams im Outsourcing-Modell sind kein Luxus, sondern die einzige planbare Antwort darauf.
Architektur-Differenzierung
Vier Säulen — IT-Betrieb, der hält und messbar besser wird.
Vier strategische Entscheidungen, die uns von klassischen Managed Service Providern (MSPs) und vom Inhouse-Operations-Aufbau unterscheiden — und Ihren IT-Betrieb planbar verlässlich machen.
Säule 1 — Senior-Teams statt Ticket-Tunnel
Klassische MSPs arbeiten mit Ticket-Tunneln: Junior-First-Level-Support bearbeitet zuerst, eskaliert an Second Level, dann an Third Level. Bei einem Mittelstands-Incident heißt das oft drei bis sechs Stunden, bis ein Senior das Problem überhaupt sieht. Wir machen das anders. Kleine Senior-Teams aus Deutschland und EU-Nearshore arbeiten direkt am System. Was bei uns rausgeht, machen Senior — das ist nicht teurer, sondern schneller. Die Mean Time to Resolution sinkt im Schnitt um Faktor drei bis fünf.
Säule 2 — SRE-Methodik statt reaktiv-Klassik
Klassische Operations-Modelle sind reaktiv: ein Ticket kommt, jemand bearbeitet es, das Ticket wird geschlossen. Wir arbeiten nach Site-Reliability-Engineering-Prinzipien (ursprünglich bei Google entwickelt). Konkret: Service Level Objectives definieren, was Verlässlichkeit für Ihren Service heißt. Error Budgets quantifizieren, wie viel Ausfallzeit pro Quartal akzeptabel ist. Toil-Reduktion: alles, was repetitiv ist, wird automatisiert. Post-Mortems nach jedem signifikanten Incident — ohne Schuldzuweisung, mit konkreten System-Verbesserungen. Das ergibt einen kontinuierlich verlässlicheren Betrieb, nicht ein endloses Reagieren auf die nächste Krise.
Säule 3 — Deutscher Vertragsrahmen, deutsche Senior-Steuerung
Vertragspartner ist immer die GLJ Tech GmbH mit Sitz in Münster. Deutsche Senior-Architekten steuern jedes Mandat — bei Eskalationen ist der Ansprechpartner deutsch und in deutscher Zeitzone. Kein internationaler Account-Manager, kein Off-Shore-Ticket-Tunnel, keine Übersetzungs-Schleifen. Bei kombinierten Liefer-Modellen über EU-Nearshore (Polen, Rumänien, Ungarn, Bulgarien) bleibt der Vertragsrahmen deutsch.
Säule 4 — Optional mit KI-gestütztem Monitoring (AIOps)
Wer mehr will, bekommt AIOps obendrauf: KI-gestützte Anomalie-Erkennung statt klassischer Threshold-Alerts. Das erkennt Probleme, bevor sie zu Schwellwert-Verletzungen werden. Verzahnt mit unseren KI-Lösungen aus der Enterprise-AI- und KI-Agenten-LP. Optional, kein Muss — manche Mandate brauchen es, manche nicht.
Unser Arbeitsmodus
Wie wir IT betreiben — und was Sie von uns nicht bekommen.
Drei Prinzipien strukturieren unsere Liefer-Logik — egal ob das Mandat eine Kubernetes-Plattform, eine Datenbank-Migration oder ein API-Stack ist.
Prinzip 01 — Verstehen, dann automatisieren
Wir übernehmen keinen Betrieb, den wir nicht verstanden haben. Die Onboarding-Phase ist Pflicht, kein Luxus. Wer Operations übernimmt, ohne die Architektur, die Daten-Flüsse und die historischen Schmerzpunkte zu verstehen, übernimmt nicht Verantwortung, sondern Risiko.
Prinzip 02 — SLOs statt SLAs
Service Level Agreements sind Vertragsklauseln. Service Level Objectives sind messbare Ziele, die wir täglich nachverfolgen. Wir arbeiten an realer, messbarer Verlässlichkeit, nicht an Vertrags-Konformität. Sie sehen täglich, wie Ihr Betrieb gegen die definierten SLOs läuft — kein Sechs-Monats-Reporting-Theater.
Prinzip 03 — Toil-Reduktion, was wir zweimal machen, automatisieren wir
Toil ist im SRE-Sprech die manuelle Routine-Arbeit, die nicht skaliert. Wir reduzieren Toil systematisch durch Automatisierung. Das ist nicht nur kosten-effizient — es macht den Betrieb auch verlässlicher, weil menschliche Fehler bei wiederholten Routine-Aufgaben die häufigste Ausfall-Ursache sind.
Phase 1 · Wir lernen Ihren Betrieb kennen
Onboarding-Phase — Inventur statt Blindflug.
Bevor wir Ihren Betrieb übernehmen, lernen wir ihn kennen. Diese Onboarding-Phase ist der wichtigste Risiko-Filter im Managed-Infrastructure-Services-Mandat — und der Grund, warum wir verbindliche SLOs zusagen können. Sechs Liefer-Bausteine, klar definiert und in drei bis sechs Wochen lieferbar.
Liefer-Baustein 01 — Infrastruktur-Inventur (Hauptartefakt)
Was läuft heute, wo, mit welchen Tools, in welchem Zustand. Cloud-Konten, Kubernetes-Cluster, Datenbanken, Middleware, Bestandssysteme — strukturiert dokumentiert. Das Inventur-Dokument ist die Basis für alles Folgende.
Liefer-Baustein 02 — Monitoring-Stack-Setup
Wir setzen oder erweitern den Monitoring-Stack: Metriken (Prometheus, Grafana), Logs (Loki oder Elasticsearch), Tracing (Tempo oder Jaeger), Application-Monitoring (Sentry). Was nicht messbar ist, ist nicht zuverlässig.
Liefer-Baustein 03 — SLO-Definition pro Service
Wir definieren mit Ihnen gemeinsam, was Verlässlichkeit für jeden Service heißt. Welche Latenz ist akzeptabel? Welche Verfügbarkeit ist Pflicht? Welche Error-Rate ist tolerierbar? Service Level Objectives statt vager Versprechen.
Liefer-Baustein 04 — Runbook-Übernahme und Eskalations-Wege
Die existierenden Operations-Anleitungen werden in unser Team übergeben und mit Senior-Profilen aus Ihrer IT verifiziert. Klare Eskalations-Wege und On-Call-Rotation werden definiert — wer wann erreichbar ist, wie eskaliert wird, was bei welcher Severity passiert.
Liefer-Baustein 05 — Automatisierungs-Roadmap
Wir identifizieren die größten Toil-Quellen — manuelle Routine-Arbeiten, die heute Senior-Zeit binden — und planen ihre Automatisierung. Das ist eine konkrete Roadmap, kein Buzzword-Versprechen.
Liefer-Baustein 06 — Hyper-Care-Plan für die ersten vier Wochen
Die ersten vier Wochen nach Go-Live laufen im Hyper-Care-Modus mit erhöhter Aufmerksamkeit und engerer Abstimmung. Danach geht der Betrieb in den Regelmodus über. Hyper-Care reduziert das Risiko der Übergabe deutlich.
„Wir übernehmen lieber drei Wochen länger im Onboarding, als drei Monate lang reaktiv hinter Incidents herzulaufen, die wir vorher hätten kennen müssen."
Betriebs-Spektrum
Was wir konkret betreiben — und was bewusst nicht.
Managed Infrastructure Services werden im Markt überversprochen. Wir benennen klar, was wir betreiben — und was bewusst nicht in unser Liefer-Modell passt.
Was wir betreiben:
- Cloud-Infrastruktur — AWS, Azure, Google Cloud sowie deutsche Cloud-Anbieter (STACKIT, IONOS) bei Souveränitäts-Anforderung
- Kubernetes-Cluster — von Multi-Tenant-Setups bis zu produktionskritischen Workloads, mit Helm, Argo CD, GitOps-Workflows
- Datenbank-Operations — PostgreSQL, MySQL, MongoDB, Redis. Backups, Failover, Performance-Tuning, Replikation
- API-Plattformen und Microservices — REST-APIs, GraphQL-Endpoints, Service-Mesh, API-Gateways
- Web-Anwendungen — produktive B2B-Portale, Frontend plus Backend, CDN- und Caching-Strategien
- KI-Lösungen — Wissens-Assistenten, KI-Agenten, Inferenz-Endpoints (verzahnt mit Enterprise AI und KI-Agenten)
Was wir bewusst NICHT betreiben:
- Klassischer First-Level-Help-Desk und User-Support — das ist nicht unsere Welt
- Hardware-Wartung vor Ort — andere Spezialisten, andere Verträge
- SAP-Operations im IS-U- und BRIM-Sinne — unsere SAP-Nischen-LPs haben dafür Spezial-Setups
- Reine On-Premise-Mandate ohne Cloud-Anteile — zu spezielles Operations-Wissen
„Wir betreiben moderne Cloud- und Container-Stacks — kein Massenkonten-Help-Desk. Wer 5.000 Endgeräte-Tickets pro Monat managen will, ist bei klassischen MSPs besser aufgehoben."
Was wir konkret einsetzen
Was technisch hinter unserem Betrieb steht — keine Versteck-Begriffe.
Wir benennen die wichtigsten Operations-Bausteine direkt. Welche konkrete Tool-Auswahl zu Ihrem Mandat passt, klären wir im Erstgespräch — bestehende Tool-Stacks übernehmen wir, neue richten wir nach gemeinsamer Auswahl ein.
Monitoring-Stack
Prometheus und Grafana für Metriken. Loki oder Elasticsearch für Logs. Tempo oder Jaeger für Distributed Tracing. Sentry für Application-Monitoring. PagerDuty oder Opsgenie für On-Call und Eskalation.
Cloud-Targets
AWS, Azure, Google Cloud für internationale Skalierung. Deutsche Cloud-Anbieter STACKIT und IONOS bei Sovereign-Anforderung. Multi-Cloud-Setups bei Anbieter-Diversifizierung.
Automatisierung
Terraform für Infrastructure-as-Code. Ansible für Configuration Management. GitHub Actions oder GitLab CI für CI/CD-Pipelines. Argo CD für GitOps-basierte Deployments.
Container und Orchestrierung
Kubernetes als Standard. Docker für Container-Build. Helm Charts für Deployment-Pakete. Service Meshes (Istio, Linkerd) bei Microservices-Setups.
Backup und Recovery
Velero für Kubernetes-Backups. Cloud-native Backup-Services pro Provider. Restore-Tests als Standard, nicht als Ausnahme.
Security-Stack
IAM und Rollen-Modelle pro Cloud. Secrets-Management (Vault, AWS Secrets Manager). Schwachstellen-Scanning (Trivy, Snyk). Compliance-Monitoring nach BSI-Grundschutz und DSGVO.
Bestehende Tool-Stacks übernehmen wir, wo das sinnvoll ist. Wir wechseln nicht aus Prinzip die Tools, sondern aus Sinn — wenn ein bestehender Stack läuft, lassen wir ihn laufen.
Gegen „Wir nehmen einen klassischen Managed-Service-Provider"
Klassische MSPs reagieren. SRE-Teams gestalten.
Wir sprechen oft mit Mittelständlern, die ihre Operations an klassische Managed Service Provider geben — oder die überlegen, das Inhouse-Team aufzustocken. Wir verstehen beide Reflexe und sagen trotzdem: das ist meistens das falsche Modell.
1. Ticket-Tunnel verkürzt nicht die Mean Time to Resolution
Klassische MSPs arbeiten in Eskalationsstufen — Junior bearbeitet, eskaliert an Senior, eskaliert an Architekt. Bei einem produktionskritischen Incident kostet diese Tunnel-Logik drei bis sechs Stunden, bevor ein Senior das System überhaupt sieht. Bei uns ist der Senior von Minute eins am Problem.
2. Manuelles Operating skaliert nicht — Automatisierung ist die Antwort
Wer Operations skaliert, indem er Personal aufstockt, betreibt klassisches Operations. Wer skaliert, indem er Toil automatisiert, betreibt SRE. Der Unterschied wird in zwei Jahren sichtbar — ein klassisches Team ist dann am Personalmangel verzweifelt, ein SRE-Team läuft mit derselben Mannschaftsstärke und betreibt deutlich mehr.
3. SLOs sind messbar — SLAs sind nur juristisch
Ein Service Level Agreement gibt Ihnen einen Vertragsschaden, wenn der Anbieter nicht liefert. Ein Service Level Objective gibt Ihnen jeden Tag eine konkrete Messung, ob der Betrieb gerade auf Zielkurs ist. Bei uns sehen Sie täglich, wie Ihr Betrieb gegen die definierten SLOs läuft — kein Sechs-Monats-Reporting-Theater.
4. Junior-First-Level zahlt Senior-Tagessätze für Junior-Bearbeitungszeit
Klassische MSPs fakturieren Senior-Tagessätze, auch wenn ein Junior das Ticket zwei Stunden lang bearbeitet, bevor es eskaliert wird. Sie zahlen für Bearbeitungszeit, nicht für Bearbeitungs-Substanz. Bei uns gibt es nur Senior — keine versteckten Junior-Bearbeitungsschichten.
5. Inhouse-Operations ohne 24/7-Senior ist Russisches Roulette
Wer den IT-Betrieb mit einem 9-bis-18-Uhr-Team macht, hofft auf den Sonntag. Jeder Incident außerhalb der Arbeitszeit eskaliert privat — der Operations-Lead arbeitet de facto kontinuierlich, brennt aus oder wechselt zum Konzern. Senior-Teams im Outsourcing-Modell sind nicht teurer als der Burnout-Folgeaufwand — und planbar verlässlich.
Verbandlich verankert im deutschen Mittelstand
InnoShore ist Mitglied im Bundesverband IT-Mittelstand (BITMi). Der BITMi vertritt die Interessen mittelständischer IT-Dienstleister in Deutschland — also genau die Liga, in der wir arbeiten. Für uns ist die Mitgliedschaft kein Reklame-Aufkleber, sondern ein Schulterschluss mit unserer Zielgruppe.
Operations als Teil eines größeren Pakets
Managed Infrastructure Services sind ein Pfeiler — vier weitere ergänzen das Bild.
Operations steht selten allein. Was wir parallel und ergänzend liefern:
KI-Agenten
Wenn Ihre Software einen Wissens-Assistenten oder einen handelnden KI-Agenten einbinden soll, gibt es die Fähigkeitsachse als eigene Lösung — von der Q&A-Antwort bis zum mehrstufig handelnden Agenten mit menschlicher Freigabe.
Enterprise AI
Wenn Ihre Software KI-Komponenten enthält oder enthalten soll — Wissens-Assistent, Document-AI, Workflow-Automatisierung mit KI — verzahnen wir die Software-Entwicklung mit unserer Enterprise-AI-Lösung. Pilot zur P&L-Relevanz in 6 bis 12 Wochen.
Cloud-Governance und Compliance
Bei regulierten Branchen (KRITIS, Defence, öffentlicher Sektor, Pharma) oder bei Sovereign-Anforderung an Ihre Software ist die Jurisdiktions-Achse Ihre Klammer. Deutscher Vertragsrahmen, deutsche Cloud, bei KI architektonisch garantierte Souveränität.
Individuelle Softwareentwicklung
Wenn wir die Software bauen, übernehmen wir auf Wunsch auch deren Betrieb. Ein Vertragspartner, ein Senior-Architekt, durchgängige Verantwortung von Entwicklung bis Operations.
Personaldienstleister
Sie haben Operations-Mandate Ihrer Endkunden und brauchen einen verlässlichen Sub-Channel-Partner mit Senior-Tiefe und deutschem Vertragsrahmen.
Direkter Endkunde im Mittelstand
Sie verantworten den IT-Betrieb in einem Mittelstands-Unternehmen — Industrie, Energie, Bahn, Public Sector, Pharma oder Defence — und brauchen ein verlässliches Operations-Team ohne Personal-Aufstockung.
IT-Consulting-Haus mit KI-Mandat
Sie haben das Operations-Mandat akquiriert und brauchen Senior-Profile mit SRE-Praxis als Teil-Liefer-Partnerschaft.
Häufige Fragen Managed Infrastructure Services
Was uns oft gefragt wird.
FAQ 1: Was unterscheidet Sie von einem klassischen Managed Service Provider?
Senior-Quote und SRE-Methodik. Klassische MSPs arbeiten mit Ticket-Tunneln und Junior-First-Level. Wir arbeiten mit kleinen Senior-Teams direkt am System und nach Site-Reliability-Engineering-Prinzipien: SLOs statt SLAs, Toil-Reduktion, Post-Mortems. Das ist nicht teurer, aber deutlich verlässlicher.
FAQ 2: Was unterscheidet Sie von einer Inhouse-Operations-Aufstockung?
24/7-Verfügbarkeit ohne Personalaufstockung. Inhouse-Operations-Teams im Mittelstand schaffen selten echte 24/7-Abdeckung — das scheitert an Personal-Kosten und Burnout-Risiko. Wir liefern die 24/7-Schicht als Service.
FAQ 3: Wie lange dauert das Onboarding bis zum produktiven Betrieb?
Drei bis sechs Wochen bis zur kompletten Übernahme inklusive sechs Liefer-Bausteinen (Inventur, Monitoring, SLOs, Runbooks, Automatisierungs-Roadmap, Hyper-Care-Plan). Danach vier Wochen Hyper-Care, dann Regelmodus.
FAQ 4: Was sind SLOs und warum sind sie wichtiger als SLAs?
SLA = Service Level Agreement (vertragliche Konsequenz bei Nicht-Erreichen). SLO = Service Level Objective (tägliche messbare Zielsetzung). SLOs sind das, was wir täglich nachverfolgen — Ihre Verlässlichkeit wird real messbar, nicht nur juristisch versichert.
FAQ 5: Übernehmen Sie auch bestehende Tool-Stacks?
Ja. Wir wechseln nicht aus Prinzip die Tools, sondern aus Sinn. Wenn ein bestehender Stack läuft, lassen wir ihn laufen und arbeiten mit dem, was da ist. Tool-Wechsel diskutieren wir nur, wenn es echten Mehrwert bringt.
FAQ 6: Wie funktioniert das mit Cloud-Souveränität?
Bei regulierten Branchen oder Sovereign-Anforderung betreiben wir auf deutsche Cloud-Anbieter (STACKIT, IONOS). Die volle Souveränitäts-Klärung liegt auf der Cloud-Governance-Lösung — Architektur statt Vertragsklausel.
FAQ 7: Was ist AIOps und brauche ich das?
AIOps ist KI-gestützte Anomalie-Erkennung im IT-Betrieb. Statt klassischer Threshold-Alerts (CPU bei 80 Prozent — Alarm) lernt ein KI-Modell das normale Verhalten Ihrer Services und meldet Abweichungen. Sinnvoll bei komplexen, hochvolumigen Setups — nicht zwingend für jeden Kunden. Wir diskutieren das im Erstgespräch.
FAQ 8: Wer ist mein Vertragspartner?
Immer die GLJ Tech GmbH mit Sitz in Münster, Deutschland. Auch bei Liefer-Modellen mit EU-Nearshore-Anteilen ist der Vertragsrahmen deutsch. Eine Rechnung, ein Ansprechpartner, ein deutscher Gerichtsstand.
FAQ 9: Wie sind die On-Call-Regeln und Eskalations-Wege?
Senior-Engineers in Deutschland und EU-Nearshore mit klar definierter On-Call-Rotation. Eskalations-Wege werden im Onboarding mit Ihnen verbindlich festgelegt. Eskalations-Ansprechpartner sind immer Senior, nicht Junior-First-Level.
FAQ 10: Wie sind die Tagessätze positioniert?
Mittelständische Tagessätze. Konkrete Sätze und Service-Pakete werden im Erstgespräch transparent kommuniziert — abhängig von Stack-Komplexität, SLO-Zielen und Liefer-Modell.
Erstgespräch oder Operations Mapping
Sondieren Sie Ihren IT-Betrieb — oder fragen Sie ein Operations-Mapping an.
Wenn Sie strategisch über Managed Infrastructure Services reden wollen — Vier-Säulen-Logik, SRE-Methodik, SLO-Definition, deutscher Vertragsrahmen, AIOps-Verzahnung —, ist das Erstgespräch der richtige Einstieg. Wenn Sie ein konkretes Mandat haben und ein Mapping anfragen möchten: das Formular bringt uns schnell in die Tiefe. Beides geht.