Mr.PlanB Logo

    Newsletter

    Newsletter abonnieren

    Neue Infrastruktur-Guides, Vergleichsberichte und Migrationshinweise direkt ins Postfach.

    Infrastruktur-Notizen, Guides und neue Tools. Jederzeit abbestellbar.

    Zurück zum Blog
    Remediation
    Automatisierung
    IT-Betrieb

    Was ist der Unterschied zwischen automatischer, halbautomatischer und manueller Remediation im IT-Betrieb?

    30. Juni 2026
    8 Min. Lesezeit

    Automatische, halbautomatische und manuelle Remediation unterscheiden sich vor allem darin, wer die Wiederherstellungsaktion autorisieren und ausführen darf. Automatische Remediation führt eine vordefinierte, risikoarme Aktion aus, ohne zum Ausführungszeitpunkt auf einen Menschen zu warten. Halbautomatische Remediation lässt die Plattform diagnostizieren und einen Teil der Reaktion vorbereiten oder durchführen, während ein Autorisierungs- oder kontrollierter Workflow-Schritt erhalten bleibt. Manuelle Remediation belässt die finale operative Aktion bei einem menschlichen Engineer.

    Das Quelldesign verwendet diese Stufen, weil Produktionsinfrastruktur unterschiedliche Risikoklassen hat. Es lehnt die Vorstellung explizit ab, dass jeder Incident zu unbeaufsichtigtem Self-Healing werden sollte.

    Was ist automatische Remediation?

    Automatische Remediation ist eine vordefinierte Reaktion, die die Plattform direkt ausführen kann, wenn eine genehmigte Bedingung erfüllt ist. Das v3.2-SRE-Modell nennt seine risikoärmste Klasse L1, und L1 umfasst bekannte vorübergehende Ereignisse, automatische Selbstwiederherstellung, automatischen Abschluss und Archivierung sowie eine eingeschränkte Regelbibliothek.

    Die Beispieloberfläche gibt an, dass die L1-Regelbibliothek 24 Klassen enthält. Diese Zahl ist Teil des Beispiel-Produktdesigns und kein allgemeines Ziel. Wichtig ist vor allem die Anforderung, dass automatische Remediation auf bekannte, wiederholbare Zustände beschränkt bleibt, bei denen die Aktion und das erwartete Ergebnis schon vorher feststehen.

    Was ist halbautomatische Remediation?

    Halbautomatische Remediation liegt zwischen Empfehlung und vollständig unbeaufsichtigter Ausführung. Das interne Share-Deck der Quelle beschreibt Remediation als automatisch, halbautomatisch und manuell, wobei Ausführungsaktionen erst nach Autorisierung ausgelöst werden.

    Ein halbautomatischer Ablauf kann so aussehen: Die Plattform erkennt den Incident, identifiziert die wahrscheinliche Ursache, findet ein passendes Runbook und schlägt die Aktion vor. Ein Mensch autorisiert sie, die genehmigte Automatisierung wird ausgeführt, das Ergebnis wird zurückgeschrieben und die Wiederherstellung verifiziert.

    Der Mensch muss dabei nicht jeden technischen Schritt manuell ausführen, und das System handelt trotzdem nie ohne die erforderliche Autorisierung. Für Operationen mit kontrolliertem Risiko ist das eine brauchbare Aufteilung.

    Was ist manuelle Remediation?

    Manuelle Remediation bedeutet, dass ein Mensch die kritische operative Aktion durchführt. Die Plattform kann den Engineer trotzdem mit Diagnose, Root-Cause-Nachweisen, Runbooks, Arbeitsaufträgen, Remote-Zugriff, Audit und Validierung unterstützen. Manuell heißt also, dass die finale Aktion menschliche Ausführung oder physische Arbeit erfordert, während die Begleitung durch die Plattform bestehen bleibt.

    Das interne Hardware-Incident-Beispiel der Quelle zeigt das deutlich. Einen Node als nicht mehr planbar zu markieren und Container zu evakuieren kann automatisiert werden, das Erzeugen des Reparaturauftrags kann halbautomatisch erfolgen, und das Austauschen der physischen GPU-Karte ist manuell. Der Remediation-Modus richtet sich also nach der Art und dem Risiko der Aktion.

    Wie hängt das v3.2-Risikomodell der Quelle mit diesen drei Stufen zusammen?

    Das v3.2-SRE-Modell verwendet drei Risikostufen. Bei L1 ist kein Eingreifen durch eine Person erforderlich, weil bekannte vorübergehende Zustände sich selbst heilen und automatisch schließen. L2 ist die Stufe des kontrollierten Risikos: Genehmigte Runbook-Skripte dürfen innerhalb strikter Leitplanken automatisch ausgeführt werden, mit Blockierung risikoreicher Befehle und automatischem Rollback. L3 steht für die risikobehaftete Änderung, bei der die Plattform den Plan erstellt, die Ausführung aber den Change-Workflow, eine Zwei-Personen-Genehmigung, Canary-Batches und ein vollständiges Audit durchläuft. Bei L3 ist die vollautomatische Ausführung explizit verboten.

    Diese Stufen tragen nicht exakt dieselben Bezeichnungen wie automatisch, halbautomatisch und manuell, drücken aber dasselbe Betriebsprinzip aus: höheres Risiko erfordert mehr menschliche Kontrolle.

    Wann sollte automatische Remediation eingesetzt werden?

    Setzen Sie sie für Zustände ein, die gut verstanden, wirkungsarm, stark wiederholbar, leicht zu verifizieren, sicher rückgängig zu machen oder zu wiederholen sind und von einer genehmigten Regel oder einem Runbook abgedeckt werden. Die L1-Beispiele der Quelle sind bekannte vorübergehende Probleme, und genau dort gehört der Einstieg hin.

    Für seltene, folgenreiche Ausfälle sollte automatische Remediation dagegen nicht als Erstes eingeführt werden. Das Team sollte die Schleife aus Erkennung, Aktion und Validierung zuerst an vorhersehbaren Fällen beweisen.

    Welche Kontrollen sollte automatische Remediation haben?

    Automatisch heißt kontrolliert, nur ohne Wartezeit auf einen Menschen. Das Quelldesign verlangt weiterhin eine genehmigte Regelbibliothek, Ausführungsprotokolle, Wiederherstellungsvalidierung, Archivierung und eine Risikogrenze. Für kontrollierte Skripte nutzt die Quelle außerdem die Blockierung gefährlicher Befehle und Rollback.

    Die Plattform sollte wissen, wie eine normale Wiederherstellung aussieht. Wenn die Aktion den erwarteten Zustand nicht wiederherstellt, sollte der Incident den automatischen Pfad verlassen und eskalieren, denn eine Self-Healing-Regel, die endlos wiederholt, kann ein ernstes wiederkehrendes Problem verbergen.

    Wann sollte halbautomatische Remediation eingesetzt werden?

    Setzen Sie halbautomatische Remediation ein, wenn die technische Aktion wiederholbar ist, die Entscheidung zur Ausführung aber weiterhin menschliche Verantwortlichkeit braucht. Beispiele sind das Isolieren eines Produktions-Node, der Neustart eines sensiblen Service, das Ändern eines Routing-Zustands, das Ausführen eines genehmigten Reparaturskripts oder das Umverteilen von Ressourcen mit Auswirkung auf den Service.

    Die Quellplattform stellt die Autorisierung vor die Ausführungsaktionen und bewahrt das Audit. Das hilft besonders, während eine Organisation Vertrauen in die Automatisierung aufbaut, weil die Plattform den Großteil der manuellen Arbeit entfernen kann und der Genehmigungspunkt trotzdem bleibt.

    Was genehmigt der Mensch bei halbautomatischer Remediation?

    Der Mensch sollte die tatsächlich vorgeschlagene Aktion und das Ziel genehmigen, statt ein vages Ticket abzuzeichnen. Eine gute Anfrage zeigt das betroffene Objekt, die wahrscheinliche Root Cause, Nachweise, die vorgeschlagene Aktion, das Ziel, die erwartete Auswirkung und den Wiederherstellungspfad.

    Nach der Genehmigung sollte genau der genehmigte Payload ausgeführt werden. Das Quell-Workflow-Design unterstützt das, indem es Genehmigungen mit automatischen Ausführungsknoten verknüpft und Ergebnisse zurückschreibt. Das verringert die Lücke zwischen dem, was genehmigt wurde, und dem, was tatsächlich passiert ist.

    Wann sollte Remediation manuell bleiben?

    Belassen Sie Remediation manuell, wenn die Aktion physische Arbeit erfordert, ein ungewisses Ergebnis hat, schwer oder unmöglich rückgängig zu machen ist, breite Auswirkungen auf die Produktion hat, Expertenurteil erfordert oder außerhalb der genehmigten Automatisierungsbibliothek liegt.

    Das Hardware-Beispiel der Quelle führt den physischen GPU-Austausch als manuelle Aktion an, und das L3-Modell der Quelle verhindert die autonome Ausführung für risikoreiche Änderungen. Eine manuelle Aktion ist damit die richtige Kontrolle, wenn das Risiko sie rechtfertigt, und kein Zeichen mangelnder Automatisierungsreife.

    Wie passt physisches Eingreifen hinein?

    Physische Infrastruktur schafft eine natürliche Grenze für Software-Self-Healing. Ein degradierter Accelerator kann automatisch erkannt werden, er kann automatisch oder nach Autorisierung aus dem Scheduling entfernt werden, Workloads können neu eingeplant werden, und ein Reparaturauftrag kann erstellt werden. Der Austausch der Karte erfordert dann trotzdem eine Person im Rechenzentrum.

    Die Quelle trennt diese Phasen explizit. Das ist eine nützliche Erinnerung daran, dass automatisierte Remediation in der Infrastruktur oft heißt, die Reaktion rund um eine physische Reparatur zu automatisieren, während die Reparatur selbst Handarbeit bleibt.

    Wie beeinflusst Rollback die Remediation-Stufe?

    Rollback macht kontrollierte Automatisierung sicherer, und die L2-Stufe der Quelle umfasst automatisches Rollback bei Fehlschlag. Wenn eine Konfiguration oder ein Skript zuverlässig den vorherigen Zustand wiederherstellen kann, lässt sich mehr von der Ausführung automatisieren. Ist die Aktion irreversibel, sollte das Unternehmen eine stärkere Genehmigung und menschliche Kontrolle verlangen.

    Ein reversibler Service-Neustart unterscheidet sich von einer destruktiven Storage-Aktion, eine Konfigurationsänderung mit gespeicherter Baseline von einem physischen Austausch, und ein getestetes Deployment-Rollback von einem nicht unterstützten Firmware-Downgrade. Reversibilität ist daher ein Faktor bei der Remediation-Klassifizierung.

    Wie sollten risikoreiche Befehle gehandhabt werden?

    Die L2-Stufe der Quelle verwendet eine Blacklist für risikoreiche Befehle. Das schafft eine harte technische Grenze innerhalb der kontrollierten Automatisierung, denn selbst ein genehmigtes Skript sollte über den automatisierten Pfad keine verbotenen Operationen aufrufen dürfen. Ein Unternehmen kann, wo angebracht, auch positive Allowlists verwenden.

    Die Quelle schreibt nicht die vollständige Command-Control-Architektur vor. Das von ihr unterstützte Prinzip ist, dass automatisierte Ausführung technische Leitplanken braucht und nicht allein Richtliniendokumente.

    Wie sollten Berechtigungen die Remediation beeinflussen?

    Die Ausführungsidentität sollte nur die für die genehmigte Aktion nötigen Berechtigungen haben. Die Governance-Schicht der Quelle umfasst Rollenberechtigungen, Autorisierung für sensible Operationen, Mandanten- und Projektgrenzen sowie vollständiges Operationsaudit.

    Automatische Remediation sollte daher eine eingegrenzte Service-Identität verwenden, halbautomatische Ausführung sollte den Antragsteller, den Genehmiger und die Automatisierungsidentität bewahren, und manuelle Ausführung sollte den menschlichen Operator festhalten. So bleibt jede Stufe rechenschaftspflichtig.

    Wie unterscheidet sich Diagnose von Ausführung?

    Diagnose kann stärker automatisiert werden als Ausführung. Die KI-Assistenz- und AIOps-Schichten der Quelle können Alarme aggregieren, die wahrscheinliche Root Cause identifizieren, Konfidenz und Nachweise anzeigen, die geschäftliche Auswirkung schätzen, ein passendes Runbook finden und eine Aktion empfehlen.

    Diese Fähigkeiten gewähren nicht automatisch die Berechtigung, Produktionsinfrastruktur zu ändern. Die Quelle betont wiederholt, dass Ausführungsaktionen eine Autorisierung erfordern. Diese Trennung erlaubt es der Organisation, von KI-gestützten Operationen zu profitieren, bevor sie breite autonome Aktionen zulässt.

    Wie sollte die Wiederherstellung validiert werden?

    Jede Remediation-Stufe sollte das Ergebnis validieren. Im automatischen Fall verifiziert das System die Wiederherstellung vor dem Abschluss. Im halbautomatischen Fall verifiziert das System die autorisierte Aktion und meldet das Ergebnis. Im manuellen Fall schließt der Engineer die Aktion ab, und das Monitoring verifiziert danach die Wiederherstellung.

    Die Incident-Schleife der Quelle umfasst explizit die Bestätigung der Wiederherstellung und den Abschluss. Ohne Validierung weiß die Plattform nur, dass eine Aktion versucht wurde, aber nicht, ob der Incident gelöst wurde.

    Wie sollten Fehlschläge zwischen den Stufen eskalieren?

    Eine fehlgeschlagene automatische Aktion sollte auf einen Pfad mit stärkerer Kontrolle wechseln. Schlägt eine automatische Wiederherstellung fehl, bleibt der Incident offen und ein halbautomatisches Runbook wird vorgeschlagen. Schlägt auch das fehl oder erfordert der Fall physische Arbeit, übernimmt ein menschlicher Engineer.

    Die Quelle beschreibt keine einzelne universelle Eskalations-Zustandsmaschine. Ihre Kombination aus Risikostufen, Arbeitsaufträgen, Exception-Handling und manuellem Eingreifen unterstützt dieses Modell fortschreitender Kontrolle aber durchaus, und die Automatisierung sollte in jedem Fall fail-safe sein.

    Wie sollten die drei Stufen gemessen werden?

    Messen Sie jede Stufe anhand ihres beabsichtigten Ergebnisses. Automatische Remediation sollte Erfolgsquote, MTTR, Wiederauftreten und vermiedene Operator-Eingriffe erfassen. Halbautomatische Remediation sollte Genehmigungszeit, Ausführungserfolg, Rollback, manuelle Übernahme und MTTR erfassen. Manuelle Remediation sollte Zeit bis zur Zuweisung, Aktionszeit, Reparaturdauer, wiederholtes Versagen und, sofern relevant, Hersteller-Reaktionszeit erfassen. Messen Sie dann das kombinierte Service-Ergebnis über SLO, Error Budget und gesamte Wiederherstellungszeit.

    Für das Messframework erklärt wie IT-Teams messen können, ob automatisierte Remediation die operative Effizienz tatsächlich verbessert, wie Automatisierungsanteil und Toil zu interpretieren sind.

    Warum ist 100 Prozent automatisiert ein schlechtes Ziel?

    Weil die Quelle die risikoreichste Klasse absichtlich außerhalb der autonomen Ausführung hält. Das Automatisierungsziel sollte sein, zu automatisieren, was sicher und repetitiv ist, zu unterstützen, was kontrolliert, aber folgenreich ist, und Menschen dort verantwortlich zu halten, wo es risikoreich, ungewiss oder physisch ist.

    Für die umfassendere Governance-Grenze erklärt wie Unternehmen den Rechenzentrumsbetrieb automatisieren und dabei Genehmigungen, Berechtigungen, Rollback und Audit-Kontrollen beibehalten, wie Ausführung auf jeder Automatisierungsstufe rechenschaftspflichtig bleibt.

    Ein Plattform-Beispiel, das automatische, halbautomatische und manuelle Reaktionsstufen innerhalb eines geschlossenen Incident-Prozesses nutzt, ist Sensaka.

    Würde ich eine Remediation-Richtlinie festlegen, würde ich zuerst die Aktion klassifizieren, bevor ich über die Technologie entscheide. Fragen Sie, wie wiederholbar sie ist, wie reversibel sie ist, wie groß der Blast Radius ist und wie viel Urteilsvermögen erforderlich ist. Bekannte risikoarme Aktionen können automatisch werden, kontrollierte Aktionen können halbautomatisch werden, und risikoreiche oder physische Aktionen sollten unter menschlicher Kontrolle bleiben.

    Häufig gestellte Fragen

    Was bedeutet automatische Remediation im Quelldesign?

    Automatische Remediation ist bekannten, risikoarmen, stark wiederholbaren Zuständen vorbehalten, bei denen die genehmigte Wiederherstellung automatisch ausgeführt werden kann und das Ergebnis validiert und archiviert werden kann.

    Was bedeutet halbautomatische Remediation?

    Halbautomatische Remediation bedeutet, dass die Plattform die Diagnose durchführt und eine genehmigte Aktion vorbereitet oder auslöst, aber vor Abschluss der Änderung eine menschliche Autorisierung, ein Workflow-Schritt oder eine kontrollierte Ausführungsgrenze bestehen bleibt.

    Welche Remediation muss manuell bleiben?

    Die Quelle behält risikoreichere physische Änderungen oder Produktionsänderungen unter menschlicher Kontrolle. Ihr v3.2-SRE-Design legt fest, dass die risikoreichste L3-Klasse niemals automatisch ausgeführt werden darf.

    Weiterführende Ressourcen