aiMOOC

Server Cloud und zuverlässiger IT-Betrieb – Änderungen im IT-Betrieb kontrollieren

QR-Code

Server Cloud und zuverlässiger IT-Betrieb – Änderungen im IT-Betrieb kontrollieren

Zielgruppe: Ausbildung – Fachinformatik, Systemintegration und Anwendungsentwicklung

Dauer: ca. 90 Minuten

Schwerpunkte: Test · Freigabe · kontrollierte Änderung · Monitoring · Rückfallplan

Lernform: Kurze Lerneinheiten, Ausbildungsfall, Videos, Schaubilder, lokale Python-Simulation und interaktive Aufgaben.

Einleitung

Ein Softwareupdate soll einen Cloud-Dienst verbessern. Doch was passiert, wenn die neue Version Fehler verursacht?

In diesem Kurs lernst Du, wie Du Änderungen im IT-Betrieb sicher vorbereitest, überprüfst, freigibst und bei Problemen zurücknimmst.

Deine Lernziele:

Änderungsmanagement: Du kannst einen Änderungsantrag beurteilen.
Softwaretest: Du prüfst eine Änderung anhand messbarer Kriterien.
Freigabeprozess: Du unterscheidest Testergebnis und Genehmigung.
Monitoring: Du erkennst kritische Messwerte.
Rollback: Du entwickelst und testest einen Rückfallplan.

Sicherheitsregel: Alle Systeme, Unternehmen, Messwerte und Änderungsanträge im praktischen Ausbildungsfall sind fiktiv. Der Python-Code arbeitet ausschließlich lokal mit Daten im Arbeitsspeicher. Es gibt keine Netzwerkzugriffe, Cloud-Zugangsdaten oder Änderungen an realen Servern. Verwende keine Produktivsysteme oder Kundendaten.

Bildimpuls: Warum muss eine technische Fachkraft vor jeder Änderung wissen, wie sie den ursprünglichen Betriebszustand wiederherstellen kann?

Ausbildungsfall: Das CampusCloud-Update

Du arbeitest im fiktiven Ausbildungsbetrieb CampusCloud IT. Das Team betreut einen webbasierten Lernmaterialdienst.

Die Version 1.0 funktioniert zuverlässig. Version 1.1 soll die Suche nach Lernmaterialien verbessern.

Dein Auftrag lautet:

Prüfe die Änderung, entscheide über die Freigabe und reagiere richtig auf eine Störung.

Merkmal	Ausbildungsfall CHG-017
Dienst	CampusCloud-Lernmaterialdienst
Bisherige Version	1.0
Geplante Version	1.1
Änderung	Verbesserte Suche
Fehlerrate maximal	1,0 %
Antwortzeit p95 maximal	250 ms
Verantwortlichkeiten	Testteam, freigabeberechtigte Stelle, Betriebsteam
Rückfallziel	Stabilen Zustand der Version 1.0 wiederherstellen

Wichtig: Die Grenzwerte sind ausschließlich für diesen Ausbildungsfall festgelegt. Es handelt sich nicht um allgemeingültige Anforderungen für Cloud-Dienste.

Lerneinheit 1: Server und Cloud verstehen

Dauer: 5 Minuten

Cloud Computing stellt IT-Ressourcen wie Rechenleistung, Speicher oder Anwendungen über eine technische Infrastruktur bereit.

Änderungen können unterschiedliche Ebenen betreffen: Server, Betriebssysteme, Plattformen, Anwendungen oder Konfigurationen.

Bildauftrag: Finde die Bereiche Infrastructure, Platform und Application. Überlege, welche Bereiche durch ein Anwendungsupdate betroffen sein können.

Auch die Bereitstellungsform beeinflusst Zuständigkeiten. In einer Public Cloud betreibt der Anbieter Teile der Infrastruktur; in einer Private Cloud kann eine Organisation selbst mehr Verantwortung übernehmen.

Merksatz: Unabhängig vom Cloud-Modell müssen Risiken, Zuständigkeiten und Auswirkungen einer Änderung geklärt sein.

Mini-Aufgabe – Basis: Nenne zwei technische Komponenten, die bei einer Softwareänderung unbeabsichtigt beeinflusst werden könnten.

Lerneinheit 2: Änderungen planen

Dauer: 8 Minuten

Ein Change Request ist ein dokumentierter Änderungsantrag.

Er beschreibt mindestens den Anlass, den betroffenen Dienst, die geplante Änderung, Risiken, Verantwortlichkeiten, Tests, Zeitplanung und Rückfallmöglichkeiten.

Der kontrollierte Änderungsprozess

[Änderung beantragen]
          |
          v
[Risiko und Umfang prüfen]
          |
          v
[Test in isolierter Umgebung]
          |
          v
[Freigabeentscheidung]
     /          \
   Nein          Ja
    |             |
 [Stopp]     [Ausführung]
                  |
                  v
             [Monitoring]
               /     \
          Fehler     Stabil
            |           |
        [Rückfall]   [Abschluss]
            |
         [Nachtest]

Die Reihenfolge ist eine didaktische Vereinfachung. In der betrieblichen Praxis hängen Freigabewege, Prüfungen und Zuständigkeiten von Art und Risiko der Änderung ab.

Welche Änderungen gibt es?

Veränderung	Beispiel	Besondere Prüfung
Softwareupdate	Neue Anwendungsfunktionen	Funktion und Kompatibilität
Konfiguration	Geänderter Speichergrenzwert	Abhängigkeiten und Leistung
Sicherheitspatch	Behebung einer Schwachstelle	Sicherheit und Nebenwirkungen
Servermigration	Umzug einer Anwendung	Verfügbarkeit und Datenintegrität

Bildimpuls: Die Versionsverwaltung macht Änderungen nachvollziehbar. Sie ersetzt jedoch weder eine Datensicherung noch einen getesteten Rückfallplan.

Mini-Aufgabe – Anwendung: Ergänze für CHG-017 ein Risiko, eine zuständige Rolle und einen geeigneten Änderungszeitpunkt.

Fachliche Grundlage: Der BSI-Baustein OPS.1.1.3 fordert unter anderem die Planung, Genehmigung und Dokumentation von Änderungen sowie vorhandene Rückfalllösungen.

Lerneinheit 3: Änderungen testen

Dauer: 8 Minuten

Ein erfolgreicher Test zeigt, ob die neue Version festgelegte Anforderungen erfüllt. Er garantiert nicht, dass später keine Störung auftritt.

Wichtige Testarten:

Testart	Prüffrage
Funktionstest	Funktioniert die neue Suche?
Regressionstest	Funktionieren bisherige Funktionen weiterhin?
Lasttest	Bleiben Antwortzeiten unter erwarteter Belastung akzeptabel?
Sicherheitstest	Werden Sicherheitsanforderungen weiterhin erfüllt?
Wiederherstellungstest	Lässt sich der stabile Zustand zurückgewinnen?

Unsere Testbedingungen:

Der Anteil fehlerhafter Anfragen darf höchstens 1,0 % betragen. Die p95-Antwortzeit darf höchstens 250 Millisekunden betragen. p95 bedeutet hier, dass 95 % der simulierten Antwortzeiten höchstens diesen Wert erreichen.

Tests verwenden ausschließlich erfundene Daten.

Testdaten auswerten

Messung	Version 1.0	Version 1.1 im Test	Grenzwert
Fehlerrate	0,2 %	0,4 %	Höchstens 1,0 %
p95-Antwortzeit	140 ms	180 ms	Höchstens 250 ms

Auswertung: Version 1.1 erfüllt beide festgelegten Testgrenzen.

Aber: Damit liegt noch keine Genehmigung zur Änderung vor.

Mini-Aufgabe – Anwendung: Erkläre, warum die getestete Version trotz bestandener Tests Probleme verursachen könnte.

Lerneinheit 4: Die Freigabe

Dauer: 6 Minuten

Die Freigabe ist die dokumentierte Entscheidung einer zuständigen, berechtigten Stelle.

Ein positives Testergebnis liefert die Entscheidungsgrundlage, ist aber nicht automatisch die betriebliche Genehmigung.

Prüffrage	CHG-017
Sind die Tests dokumentiert?	Ja
Sind die Testgrenzen eingehalten?	Ja
Sind die Auswirkungen bewertet?	Ja, im Ausbildungsfall
Ist ein Rückfallplan vorhanden?	Ja, als Simulation
Hat die zuständige Stelle zugestimmt?	Noch offen

Entscheidung: Ohne Freigabe keine Ausführung.

Die im Kurs abgefragte Freigabe ist ausschließlich eine Rollenspielentscheidung und besitzt keinerlei Wirkung außerhalb des Lernlabors.

Mini-Aufgabe – Basis: Formuliere einen kurzen Freigabevermerk mit Teststand, Verantwortlichkeit, Entscheidung und Begründung.

Lerneinheit 5: Eine Änderung kontrolliert ausführen

Dauer: 8 Minuten

Ein risikoarmes Vorgehen begrenzt möglichst den Umfang einer Änderung.

Beim Canary Release wird eine neue Version zunächst nur einer begrenzten Nutzer- oder Systemgruppe bereitgestellt und überwacht.

Video: Google Cloud Tech – Foundations of canary deployments in GKE.

Beobachtungsauftrag: Erkenne, wie stabile und neue Versionen unterschieden werden. Die gezeigten Cloud-Befehle sind nicht Bestandteil unserer lokalen Übung und werden nicht ausgeführt.

Blue-Green-Deployment

Beim Blue-Green-Deployment stehen zwei getrennte Betriebsumgebungen zur Verfügung. Während die bisherige Umgebung den Dienst liefert, kann die neue vorbereitet werden.

Bildauftrag: Überlege, weshalb eine weiterhin verfügbare alte Umgebung beim Rückfall helfen kann.

Video: Google Cloud Tech – How to reduce deployment risk with blue-green deployments.

Beobachtungsauftrag: Betrachte besonders die Erklärung der Rückkehr zu einer vorherigen Version ab etwa Minute 4:59.

Wichtig: Ein Blue-Green-Wechsel ist nicht automatisch ein vollständiger Rückfall. Gemeinsame Datenbanken, Schemaänderungen und externe Abhängigkeiten können die Wiederherstellung erschweren.

Lerneinheit 6: Monitoring und Rückfallplan

Dauer: 8 Minuten

Nach der simulierten Freigabe wird Version 1.1 aktiviert.

In einem Störungsszenario ergeben sich folgende erfundene Messwerte:

Phase	Fehlerrate	p95-Antwortzeit	Bewertung
Vorher	0,2 %	140 ms	Stabil
Test	0,4 %	180 ms	Test bestanden
Nach Änderung	2,8 %	390 ms	Grenzwerte überschritten
Nach Rückfall	0,2 %	140 ms	Simulierter Normalzustand

Datenvisualisierung: Fehlerrate

Fehlerrate in Prozent
Ein # entspricht 0,2 Prozentpunkten.

Vorher   #               0,2 %
Test     ##              0,4 %
Störung  ##############  2,8 %
Rückfall #               0,2 %

Grenzwert: 1,0 %

Analyse: Die gemessene Fehlerrate liegt um 1,8 Prozentpunkte über der zulässigen Grenze. Auch die Antwortzeit überschreitet den Grenzwert.

Folgerung: Die simulierte Änderung muss gestoppt und der festgelegte Rückfall ausgelöst werden.

Rückfallplan für CHG-017

Schritt	Tätigkeit
Erkennen	Grenzwertüberschreitung feststellen
Entscheiden	Rückfall entsprechend dem genehmigten Plan auslösen
Stoppen	Weitere Verteilung der neuen Version verhindern
Wiederherstellen	Gesicherten stabilen Versionszustand verwenden
Prüfen	Funktionen und Messwerte erneut kontrollieren
Dokumentieren	Ursache, Maßnahmen und Ergebnis festhalten

Merksatz: Ein Rückfall ist erst dann erfolgreich, wenn der wiederhergestellte Dienst geprüft wurde. Ein bloßer Versionswechsel genügt nicht.

Lokales Testlabor: Dein eigener Change-Simulator

Dauer: 15–20 Minuten

Du kannst Test, Freigabe, Ausführung und Rückfall in einer vollständig lokalen Umgebung simulieren.

Voraussetzungen: Python 3.8 oder neuer, lokaler Texteditor und Terminal. Es werden keine zusätzlichen Pakete benötigt.

Isolation: Das Programm öffnet keine Netzwerkverbindung, liest keine fremden Dateien und schreibt keine Betriebsdaten. Sämtliche Messwerte befinden sich im Arbeitsspeicher und sind erfunden.

Codebeispiel 1: Change-Simulator

Speichere folgenden Code unter dem Dateinamen change_lab.py in einem eigens angelegten lokalen Übungsordner.

"""Offline-Labor mit ausschliesslich erfundenen Messwerten."""

GRENZE_FEHLER = 1.0
GRENZE_P95 = 250
BASIS = (0.2, 140)

SZENARIEN = {
    "1": {
        "name": "Stabile Aenderung",
        "test": (0.4, 180),
        "live": (0.5, 190),
    },
    "2": {
        "name": "Fehler erst nach Freigabe",
        "test": (0.4, 180),
        "live": (2.8, 390),
    },
    "3": {
        "name": "Fehler schon im Test",
        "test": (1.8, 300),
        "live": (0.5, 190),
    },
}

def gruen(messung):
    fehler, p95 = messung
    return fehler <= GRENZE_FEHLER and p95 <= GRENZE_P95

def entscheide(szenario, freigabe):
    if not gruen(szenario["test"]):
        return "STOPP_TEST", "1.0"
    if not freigabe:
        return "STOPP_FREIGABE", "1.0"
    if not gruen(szenario["live"]):
        return "ROLLBACK", "1.0"
    return "ERFOLG", "1.1"

def balken(label, messung):
    fehler, p95 = messung
    skala = "#" * round(fehler * 5)
    print(f"{label:12} {skala:14} {fehler:.1f}% | p95 {p95} ms")

def main():
    print("LOKALES AUSBILDUNGSLABOR | keine Netzverbindung")
    for nummer, szenario in SZENARIEN.items():
        print(nummer, szenario["name"])

    nummer = input("Szenario 1/2/3: ").strip()
    if nummer not in SZENARIEN:
        print("Unbekanntes Szenario. Keine Aenderung.")
        return

    szenario = SZENARIEN[nummer]
    balken("Vorher", BASIS)
    balken("Test", szenario["test"])

    if not gruen(szenario["test"]):
        print("STOPP_TEST | Endversion 1.0")
        return

    freigabe = (
        input("Fiktive Freigabe erteilt? j/n: ")
        .strip().lower() == "j"
    )

    if freigabe:
        print("Simulation: Version 1.0 merken, 1.1 aktivieren")
        balken("Nachher", szenario["live"])

    status, version = entscheide(szenario, freigabe)
    print("Entscheidung:", status, "| Endversion:", version)

    if status == "ROLLBACK":
        print("Rueckfall auf Version 1.0; Nachtest:")
        balken("Nachtest", BASIS)

if __name__ == "__main__":
    main()

Start im lokalen Übungsordner:

python3 change_lab.py

Unter Windows kann je nach Installation stattdessen py change_lab.py verwendet werden.

Deine drei Testszenarien

Szenario	Vorgehen	Erwartete Entscheidung
1	Gültige Freigabe im Rollenspiel erteilen	ERFOLG, Version 1.1
2	Gültige Freigabe im Rollenspiel erteilen	ROLLBACK, Version 1.0
3	Test mit kritischen Werten starten	STOPP_TEST, Version 1.0

Zusatzexperiment: Starte Szenario 1 und beantworte die Freigabefrage mit n. Es muss STOPP_FREIGABE erscheinen.

Begründetes Feedback:

ERFOLG ist korrekt, wenn Test, Freigabe und Nachmessung die Bedingungen erfüllen.
STOPP_TEST ist korrekt, wenn bereits die Testwerte zu schlecht sind. Eine Freigabe darf die Testgrenzen nicht umgehen.
STOPP_FREIGABE ist korrekt, wenn keine Zustimmung vorliegt. Gute Messwerte ersetzen keine Genehmigung.
ROLLBACK ist korrekt, wenn nach dem simulierten Versionswechsel die Grenzen überschritten werden. Die Wiederherstellung wird anschließend erneut geprüft.

Codebeispiel 2: Automatisierte Tests

Erstelle im selben lokalen Ordner die Datei test_change_lab.py.

import unittest
from change_lab import SZENARIEN, gruen, entscheide

class TestChangeLab(unittest.TestCase):

    def test_messgrenzen(self):
        self.assertTrue(gruen((1.0, 250)))
        self.assertFalse(gruen((1.1, 250)))

    def test_keine_freigabe(self):
        self.assertEqual(
            entscheide(SZENARIEN["1"], False),
            ("STOPP_FREIGABE", "1.0")
        )

    def test_stoppt_im_test(self):
        self.assertEqual(
            entscheide(SZENARIEN["3"], True),
            ("STOPP_TEST", "1.0")
        )

    def test_rollback(self):
        self.assertEqual(
            entscheide(SZENARIEN["2"], True),
            ("ROLLBACK", "1.0")
        )

    def test_erfolg(self):
        self.assertEqual(
            entscheide(SZENARIEN["1"], True),
            ("ERFOLG", "1.1")
        )

if __name__ == "__main__":
    unittest.main()

Lokaler Testaufruf:

python3 -m unittest -v test_change_lab.py

Erwartetes Ergebnis: Fünf erfolgreiche Tests mit der Abschlussmeldung OK.

Die Beispiele sind bewusst auf Entscheidungslogik beschränkt. Sie simulieren keine echte Serverbereitstellung und dürfen nicht als betriebsfertiges Deployment-System angesehen werden.

Gestufte Hilfen für das Testlabor

Hilfe 1 – Denke an die Reihenfolge:

Wurde die Änderung erfolgreich getestet, bevor eine Freigabe in Betracht kommt?

Hilfe 2 – Prüfe die zwei Grenzen:

Eine Messung ist nur dann erfolgreich, wenn gleichzeitig die Fehlerrate höchstens 1,0 % und die p95-Antwortzeit höchstens 250 ms beträgt.

Hilfe 3 – Modellentscheidung:

Im Störungsszenario 2 besteht Version 1.1 den vorbereitenden Test. Nach der simulierten Ausführung steigen jedoch die Fehlerrate auf 2,8 % und die p95-Antwortzeit auf 390 ms. Deshalb wird der Rückfall auf Version 1.0 ausgelöst.

Transferfrage: Warum darf ein fehlgeschlagener Nachtest nicht einfach durch eine optimistischere Bewertung ersetzt werden?

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Warum wird ein Änderungsantrag dokumentiert? (Damit Änderungen nachvollziehbar und kontrollierbar sind) (!Damit Tests entfallen können) (!Damit alle Änderungen automatisch genehmigt werden) (!Damit keine Verantwortlichkeiten mehr benötigt werden)

Was prüft ein Regressionstest? (Ob bisherige Funktionen nach einer Änderung weiterhin funktionieren) (!Nur die Geschwindigkeit einer neuen Funktion) (!Ausschließlich die Größe einer Softwaredatei) (!Nur den Stromverbrauch eines Servers)

Was ist eine Freigabe im Änderungsprozess? (Eine dokumentierte Genehmigung durch die zuständige Stelle) (!Die erfolgreiche Installation einer Software) (!Ein beliebiger Kommentar im Programmcode) (!Die automatische Auswertung einer Fehlerrate)

Welche Voraussetzung gehört vor die kontrollierte Ausführung? (Erforderliche Tests und Genehmigungen sowie ein geeigneter Rückfallplan) (!Ausschließlich ein neuer Versionsname) (!Möglichst wenig Dokumentation) (!Die Deaktivierung sämtlicher Überwachungen)

Wie reagierst Du auf eine Fehlerrate von 1,8 Prozent im vorbereitenden Test bei einer Grenze von 1,0 Prozent? (Du stoppst die Freigabe und untersuchst die Abweichung) (!Du ignorierst den Grenzwert) (!Du erhöhst die Fehlerrate künstlich) (!Du führst die Änderung ohne weitere Prüfung aus)

Was ist bei deutlich überschrittenen Grenzwerten nach einem Update richtig? (Du stoppst die weitere Verteilung und prüfst den vorgesehenen Rückfall) (!Du entfernst die Überwachung) (!Du löschst die Änderungsdokumentation) (!Du wartest grundsätzlich ohne Zeitgrenze)

Welcher Vorteil kann ein Blue-Green-Deployment bieten? (Die bisherige Betriebsumgebung kann für eine Rückkehr verfügbar bleiben) (!Es werden grundsätzlich keine Tests benötigt) (!Jede Datenbankänderung ist automatisch rückgängig) (!Beide Umgebungen müssen immer gleichzeitig ausfallen)

Welche Daten eignen sich besonders für dieses lokale Ausbildungsprojekt? (Vollständig erfundene Testdaten) (!Ungefragt kopierte Kundendaten) (!Echte Zugangsdaten fremder Systeme) (!Produktive personenbezogene Datensätze)

Welche Angaben benötigt ein sinnvoller Rückfallplan? (Auslöser und Verantwortliche sowie Wiederherstellungsschritte und Nachtests) (!Nur den Namen des Administrators) (!Ausschließlich die Versionsnummer) (!Nur den Zeitpunkt der letzten Besprechung)

Was geschieht, wenn die notwendige Freigabe verweigert wurde? (Die geplante Ausführung wird nicht gestartet) (!Das System wird trotzdem aktualisiert) (!Die Entscheidung wird automatisch überschrieben) (!Die Rückfallprüfung wird gelöscht)

Begründetes Quiz-Feedback

Eine dokumentierte Änderung schafft Nachvollziehbarkeit und klare Verantwortlichkeiten.
Regressionstests erkennen unbeabsichtigte Auswirkungen auf bestehende Funktionen.
Die Freigabe ist eine organisatorische Entscheidung und kein Messwert.
Tests, Genehmigung und Rückfallplanung verringern gemeinsam Änderungsrisiken.
Überschrittene Testgrenzen widersprechen den vorher festgelegten Akzeptanzkriterien.
Nach einer kritischen Abweichung muss die Störung begrenzt und eine sichere Wiederherstellung geprüft werden.
Eine erhaltene alte Umgebung kann die Rückkehr erleichtern, beseitigt aber nicht jedes Datenrisiko.
Fiktive Daten vermeiden unnötige Datenschutz- und Vertraulichkeitsrisiken.
Ein Rückfallplan muss ausführbar, überprüfbar und zuständigkeitsklar sein.
Eine verweigerte Genehmigung darf nicht durch eine technische Aktion umgangen werden.

Memory

Finde die zusammengehörigen Begriffe und Erklärungen.

Änderungsantrag	Dokumentierter Vorschlag für eine Veränderung
Regressionstest	Kontrolle bereits bestehender Funktionen
Freigabestelle	Zuständige Instanz für die Genehmigung
Rückfallplan	Vorgehen zur Wiederherstellung
Schwellwert	Festgelegte Grenze für einen Messwert
Nachtest	Überprüfung nach einer ausgeführten Maßnahme

Drag and Drop

Ordne jeder Phase ihre passende Tätigkeit zu.

Ordne die richtigen Begriffe zu.	Tätigkeit
Antrag	Änderungsumfang dokumentieren
Risikoanalyse	Auswirkungen und Gefährdungen bewerten
Test	Funktionen und Grenzwerte überprüfen
Freigabe	Durchführung verbindlich genehmigen
Monitoring	Verhalten nach der Änderung beobachten
Rückfall	Stabilen vorherigen Zustand wiederherstellen

Kreuzworträtsel

Rollback	Wie lautet der englische Begriff für die Rückkehr zu einem vorherigen Versionszustand?
Freigabe	Wie heißt die dokumentierte Genehmigung einer Änderung?
Monitoring	Wie nennt man die fortlaufende Überwachung eines Dienstes?
Testfall	Wie heißt eine einzelne festgelegte Prüfung?
Version	Welcher Begriff bezeichnet einen bestimmten Entwicklungsstand einer Software?
Risiko	Was wird bei einer Änderung im Hinblick auf mögliche negative Folgen bewertet?

LearningApps

Hier kannst Du nach ergänzenden Lernübungen suchen. Die Suchergebnisse sind externe Angebote und wurden nicht als konkrete Übung vorausgewählt.

Lückentext

Eine geplante Veränderung im IT-Betrieb wird als

bezeichnet.

Der dokumentierte Vorschlag für eine Änderung heißt

.

Vor der Umsetzung sollen mögliche Auswirkungen durch eine

bewertet werden.

Zur Überprüfung bestehender Funktionen dient der

.

Ein positives Testergebnis ersetzt keine dokumentierte

.

Die fortlaufende Beobachtung technischer Messwerte bezeichnet man als

.

Die zulässige Obergrenze für einen Messwert wird als

bezeichnet.

Die Rückkehr zu einem vorherigen stabilen Softwarestand heißt

.

Nach einer Wiederherstellung kontrolliert ein

die Funktionsfähigkeit.

Eine zentrale Grundlage der Nachvollziehbarkeit ist die

.

Bei der praktischen Durchführung dieses Lernlabors werden ausschließlich

verwendet.

Offene Aufgaben

Bearbeite die Aufgaben mit dem fiktiven CampusCloud-Fall. Alle Projekte bleiben lokal oder werden als schriftliches Konzept durchgeführt.

Leicht – Basis

Änderungsmanagement: Zeichne den Ablauf eines kontrollierten Changes mit mindestens sechs Schritten.
Change Request: Erstelle einen kurzen Änderungsantrag für CHG-017.
Softwaretest: Formuliere vier Testfälle für die neue Suchfunktion.
Freigabe: Schreibe eine begründete Entscheidung für die Freigabe oder Ablehnung einer Änderung.

Standard – Anwendung

Python: Starte im lokalen Testlabor alle drei Szenarien und dokumentiere die Ergebnisse.
Monitoring: Visualisiere die vier Fehlerraten des Ausbildungsfalls in einem eigenen Balkendiagramm.
Rollback: Erstelle ein Ablaufdiagramm mit Rückfallauslöser, Verantwortlichkeit und Nachtest.
IT-Service-Management: Führe ein Rollenspiel zwischen Testteam, Freigabestelle und Betriebsteam durch.

Schwer – Transfer

Risikomanagement: Untersuche, wie eine Änderung an einer gemeinsam genutzten Datenbank den Rückfall erschweren kann.
Testautomatisierung: Erweitere die lokale Python-Simulation um ein zusätzliches erfundenes Szenario und passende automatisierte Tests.
Cloud Computing: Entwickle ein Konzept für die kontrollierte Aktualisierung eines aus mehreren Komponenten bestehenden fiktiven Cloud-Dienstes.
Betriebsdokumentation: Produziere ein Erklärvideo oder eine Präsentation, in der Du anhand der fiktiven Messwerte eine Rückfallentscheidung begründest.

Feedback zu den offenen Aufgaben

Niveau	Qualitätsmerkmal	Begründetes Feedback
Basis	Vollständige Schritte, klare Zuständigkeiten	Eine nachvollziehbare Reihenfolge verhindert, dass wesentliche Prüfungen vergessen werden.
Anwendung	Dokumentierte Messwerte und reproduzierbare Entscheidungen	Die Verbindung zwischen Messwerten und Entscheidungen macht den Betrieb überprüfbar.
Transfer	Betrachtung von Abhängigkeiten und Wiederherstellungsrisiken	Ein guter Änderungsplan berücksichtigt nicht nur die geänderte Software, sondern den gesamten betroffenen Dienst.

Selbstkontrolle: Prüfe bei jeder Lösung, ob Deine Entscheidung durch konkrete Fakten oder Messwerte begründet ist.

Lernkontrolle

Die folgenden Aufgaben überprüfen Zusammenhänge und Transferleistungen.

Fehleranalyse: In einem Test sind alle Kriterien erfüllt, nach der Freigabe steigen die Antwortzeiten stark an. Erkläre mindestens drei mögliche Ursachen und leite geeignete Reaktionen ab.
Entscheidungsfindung: Ein wichtiges Sicherheitsupdate soll schnell eingespielt werden, aber ein Test schlägt fehl. Entwickle ein risikoorientiertes Vorgehen einschließlich zuständiger Genehmigungen.
Abhängigkeit: Eine neue Anwendung benötigt ein geändertes Datenbankschema. Begründe, weshalb eine Rückkehr zur alten Softwareversion möglicherweise nicht genügt.
Qualitätssicherung: Zwei Betriebsgruppen schlagen unterschiedliche Rückfallgrenzen vor. Entwickle Kriterien für eine nachvollziehbare Entscheidung.
Betriebssicherheit: Nach einem simulierten Rollback sind die Fehlermeldungen verschwunden. Erkläre, welche zusätzlichen Nachweise für einen erfolgreichen Abschluss erforderlich sind.
Prozessverbesserung: Entwirf drei Maßnahmen, mit denen das CampusCloud-Team zukünftige Änderungen zuverlässiger durchführen könnte.

Bewertungskriterien: Zusammenhang erkannt, Risiken berücksichtigt, Entscheidung begründet, sichere Alternative entwickelt und nachvollziehbar dokumentiert.

Lernnachweis

Erstelle eine kompakte digitale oder schriftliche Change-Dokumentation zum Ausbildungsfall CHG-017.

Der Lernnachweis enthält:

Einen nachvollziehbaren Änderungsantrag mit Umfang und Ziel.
Eine begründete Risikoanalyse.
Mindestens vier überprüfbare Testfälle.
Die protokollierten Ergebnisse der lokalen Python-Simulation.
Eine dokumentierte und begründete Freigabeentscheidung.
Eine Darstellung der erfundenen Monitoringdaten.
Einen Rückfallplan einschließlich Auslösern und Verantwortlichkeiten.
Die Beschreibung eines Nachtests.
Eine kurze Reflexion über Verbesserungen des Änderungsprozesses.
Eine Bestätigung, dass ausschließlich lokale, fiktive Testdaten verwendet wurden.

Erfolgskriterium: Dein Lernnachweis zeigt nicht nur, was entschieden wurde, sondern auch, warum die jeweilige Entscheidung für einen zuverlässigen IT-Betrieb sinnvoll ist.

OERs zum Thema

Wikipedia

Der Artikel über Change Management (ITIL) erläutert grundlegende Abläufe des IT-Änderungsmanagements.

Geprüfte fachliche Quellen

BSI – IT-Grundschutz, OPS.1.1.3 Patch- und Änderungsmanagement: Planung, Genehmigung, Dokumentation und Rückfalllösungen. Offizielle Quelle, Edition 2022
BSI – IT-Grundschutz, OPS.1.1.6 Software-Tests und -Freigaben: Dokumentierte Softwaretests und Freigabeprozesse. Offizielle Quelle, Edition 2023
Google Site Reliability Engineering: Canarying Releases. Fachkapitel zu überwachten Softwareveröffentlichungen
Google Site Reliability Engineering: Configuration Design and Best Practices. Fachkapitel zum sicheren Konfigurationswechsel
PeopleCert: ITIL 4 Practitioner – Change Enablement. Offizielle Praxisbeschreibung

Die BSI-Unterlagen werden hier als fachliche Quellen verwendet. Es wird nicht behauptet, dass sämtliche verlinkten Werke unter einer freien OER-Lizenz stehen.

Medienquellen und Nutzungsrechte

Die Wikimedia-Commons-Mediendateien besitzen dokumentierte freie Lizenzen oder eine CC0-Freigabe. Urheber, Lizenz und Quelldatei:

Medium	Urheber	Lizenz
Techniker am Serverrack	Derrick Coetzee	CC0 1.0
Cloud computing.svg	Sam Johnston	CC BY-SA 3.0
Cloud Computing Stack.svg	Sam Johnston	CC0 1.0
Cloud computing types.svg	Sam Johnston	CC BY-SA 3.0
Git operations.svg	Daniel Kinzler	CC BY 3.0
V-Modell.svg	Michael Pätzold und S. Seyfert	CC BY-SA 3.0
Blue-Green-Deployment	Ssweene2	CC BY-SA 4.0

Lizenzhinweis: Die jeweiligen Lizenzbedingungen gelten für die einzelne Mediendatei. Bei Weitergabe oder Veränderung sind insbesondere Namensnennung und gegebenenfalls Weitergabe unter gleichen Bedingungen zu beachten. Es wurden keine Bilddateien verändert.

YouTube-Videos: Beide eingebundenen Beiträge stammen vom offiziellen Kanal Google Cloud Tech. Die Einbettung erfolgt über den YouTube-Player; die Videos werden nicht kopiert und nicht als frei lizenzierte OER ausgegeben.

Datenschutzhinweis: Das Aufrufen externer Videos, Wikipedia-Seiten oder LearningApps kann Browserdaten an die jeweiligen Anbieter übertragen. Die externe Nutzung ist freiwillig und für den lokalen Lern- und Testpfad nicht erforderlich.