Seminar Kuzzle Intensiv – Produktion, Sicherheit und Betrieb

Der Intensivpfad verbindet sichere Administration, Authentifizierung und Berechtigungen, produktives Deployment, Monitoring, Fehleranalyse, Backup, Restore, Testing und Release-Steuerung. Die Praxisumgebung wird nicht nur aufgebaut, sondern unter Last, Ausfall und fehlerhaftem Release geprüft. Theorie, Demonstration und Laborarbeit wechseln in kurzen Zyklen. Jeder technische Schritt wird durch eine Kontrollabfrage, einen Negativtest oder eine nachvollziehbare Zustandsprüfung abgeschlossen.

Inhaltsübersicht

• Zielgruppe und Voraussetzungen
• Didaktischer Zuschnitt
• Tag 1: Betriebsarchitektur und sichere Administration
• Tag 2: Deployment, Secrets und Hochverfügbarkeit
• Tag 3: Monitoring, Alarmierung und Incident Response
• Tag 4: Backup, Restore und Notfallbetrieb
• Tag 5: Security-Tests, CI/CD und Releasekontrolle
• Praxisprojekt und Lernerfolgskontrolle

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis

• Adressierte Rollen
• Erforderliche Vorkenntnisse
• Labor- und Arbeitsmittel
• Einstiegskontrolle

Zielgruppe: Plattformbetrieb, DevOps, Site Reliability Engineering, Security Engineering, technische Architektur und Betriebsverantwortung.

Voraussetzungen: Sichere Linux-, Netzwerk-, Container-, TLS- und Monitoring-Grundkenntnisse; Kuzzle-Grundverständnis oder vorheriger Architekturüberblick.

Zu Beginn werden Vorkenntnisse, Laborzugang, Namenskonventionen und Sicherheitsregeln geprüft. Fehlende Grundlagen werden als konkrete Vorbereitungspunkte dokumentiert; produktive Systeme und reale Zugangsdaten werden in den Übungen nicht verwendet.

Didaktischer Zuschnitt

Kapitelinhaltsverzeichnis

• Begründung der Dauer
• Arbeitsweise
• Dokumentationsstandard
• Qualitätssicherung

Begründung der Dauer: Fünf Tage sind erforderlich, um die sechs zugeordneten Betriebs- und Securitythemen mit realen Nachweisen zu verbinden. Die Dauer bleibt auf fünf Tage begrenzt, indem Anwendungsentwicklung und umfassende IoT-Funktionen nur als Last- und Betriebsobjekte verwendet, nicht erneut vermittelt werden.

Die Lerneinheiten folgen dem Muster Analyse, Aufbau, Funktionsnachweis, Fehlerfall und Wiederholung. Konfigurationen und Testdaten werden versionierbar gehalten. Entscheidungen werden mit Annahme, Alternative, Risiko und Prüfmethode dokumentiert. Dadurch entsteht neben dem fachlichen Verständnis ein direkt nutzbares Arbeitsverfahren.

1. Tag 1: Betriebsarchitektur und sichere Administration

Kapitelinhaltsverzeichnis

• Serviceziele und Risiken
• Komponentenbaseline
• Adminzugänge
• Änderungs- und Freigabeverfahren

Dieses Kapitel verbindet Serviceziele und Risiken, Komponentenbaseline, Adminzugänge und Änderungs- und Freigabeverfahren. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Verfügbarkeit, Wiederherstellungsziele, Datenkritikalität und maximale Ausfallwirkung festlegen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Komponenten, Vertrauenszonen und administrative Pfade vollständig modellieren: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Administrative Identitäten, Rollen und getrennte Verantwortlichkeiten einrichten: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Anonyme Standardrechte, Notfallzugänge und privilegierte Aktionen prüfen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Eine Baseline mit genehmigtem Konfigurationsstand und Änderungsverfahren dokumentieren: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Serviceziele und Risiken ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Komponentenbaseline erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Änderungs- und Freigabeverfahren lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Eine Produktionsreferenzarchitektur erhält sichere Administrationspfade und ein freigegebenes Berechtigungsmodell. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

2. Tag 2: Deployment, Secrets und Hochverfügbarkeit

Kapitelinhaltsverzeichnis

• Reproduzierbare Artefakte
• Konfiguration und Vault
• Mehrinstanzbetrieb
• Ausfalltests

Dieses Kapitel verbindet Reproduzierbare Artefakte, Konfiguration und Vault, Mehrinstanzbetrieb und Ausfalltests. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Versionierte Artefakte und Umgebungskonfiguration strikt trennen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Secrets sowie Zertifikate sicher bereitstellen und einen Rotationsfall durchführen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Mehrere Instanzen hinter dem Ingress mit korrektem Realtime-Verhalten betreiben: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Ressourcen- und Verbindungslimits aus der erwarteten Last ableiten: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Instanz-, Netzwerk- und Abhängigkeitsausfälle gezielt auslösen und Wiederherstellung messen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Reproduzierbare Artefakte ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Konfiguration und Vault erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Ausfalltests lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Die Umgebung wird automatisiert bereitgestellt, horizontal skaliert und gegen zwei Fehlerdomänen getestet. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

3. Tag 3: Monitoring, Alarmierung und Incident Response

Kapitelinhaltsverzeichnis

• Serviceindikatoren
• Logs und Korrelation
• Alarme und Runbooks
• Ursachenanalyse

Dieses Kapitel verbindet Serviceindikatoren, Logs und Korrelation, Alarme und Runbooks und Ursachenanalyse. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Nutzernahe Serviceindikatoren und technische Sättigungssignale auswählen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Logs, Metriken und Request-IDs über alle Schichten zusammenführen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Alarme mit Eigentümer, Priorität, Diagnose und Abbruchkriterien verknüpfen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Einen Incident anhand von Hypothesen, minimalinvasiven Tests und Zeitlinie bearbeiten: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Ursache, beitragende Faktoren und präventive Maßnahmen in einer Review festhalten: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Serviceindikatoren ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Logs und Korrelation erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Ursachenanalyse lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein Störungsszenario wird erkannt, eingegrenzt, behoben und mit messbarer Reaktionszeit ausgewertet. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

4. Tag 4: Backup, Restore und Notfallbetrieb

Kapitelinhaltsverzeichnis

• Sicherungsumfang
• Konsistenz und Schutz
• Wiederherstellung
• Notfallkommunikation

Dieses Kapitel verbindet Sicherungsumfang, Konsistenz und Schutz, Wiederherstellung und Notfallkommunikation. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Daten, Konfiguration, Secrets und anwendungsspezifische Artefakte inventarisieren: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Backups konsistent, verschlüsselt und getrennt vom Primärsystem erzeugen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Eine leere Zielumgebung für die Wiederherstellung bereitstellen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Bestand einspielen und mit technischen sowie fachlichen Stichproben prüfen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – RTO, RPO, Restabweichungen und Freigabe des Notbetriebs dokumentieren: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Sicherungsumfang ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Konsistenz und Schutz erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Notfallkommunikation lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Eine vollständige Restore-Probe weist die Wiederanlauffähigkeit innerhalb definierter Ziele nach. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

5. Tag 5: Security-Tests, CI/CD und Releasekontrolle

Kapitelinhaltsverzeichnis

• Berechtigungs- und Konfigurationstests
• Pipeline-Gates
• Gestufter Rollout
• Rollback und Übergabe

Dieses Kapitel verbindet Berechtigungs- und Konfigurationstests, Pipeline-Gates, Gestufter Rollout und Rollback und Übergabe. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Positiv- und Negativtests für privilegierte sowie fachliche Zugriffe automatisieren: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Konfigurations-, Integrations-, Last- und Restore-Tests als Pipeline-Gates einordnen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Ein Release mit Vorprüfung, Teilrollout und Gesundheitskriterien ausrollen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Einen absichtlich fehlerhaften Stand anhand klarer Abbruchkriterien zurückrollen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Runbooks, Bereitschaftsrollen, Wartungsplan und regelmäßige Übungen übergeben: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Berechtigungs- und Konfigurationstests ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Pipeline-Gates erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Rollback und Übergabe lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein Releasekandidat durchläuft Security- und Betriebstests, wird gestuft ausgebracht und kontrolliert zurückgesetzt. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

Praxisprojekt und Lernerfolgskontrolle

Kapitelinhaltsverzeichnis

• Projektauftrag
• Zwischenprüfungen
• Fehler- und Sicherheitsnachweis
• Technische Abnahme

Das Praxisprojekt verbindet die Kapitel zu einer konsistenten Laborlösung. Vor jedem Inkrement werden Ausgangszustand, Ziel, Eingaben und Abnahmekriterien festgelegt. Nach der Umsetzung folgen Funktionsprüfung, Negativtest, kurze Dokumentationskontrolle und Rücksetzung auf einen bekannten Zustand.

1. Projektauftrag schneiden: Ein fachlich begrenzter Anwendungsfall wird in Daten, Akteure, Schnittstellen, Berechtigungen und Betriebsanforderungen zerlegt.
2. Inkremente umsetzen: Die Kapitelbausteine werden schrittweise integriert; nach jedem Inkrement bleibt die Laborlösung lauffähig.
3. Fehler nachweisen: Mindestens ein Berechtigungs-, Daten-, Verbindungs- oder Konfigurationsfehler wird kontrolliert ausgelöst und diagnostiziert.
4. Abnahme durchführen: Eine technische Checkliste prüft Funktion, Sicherheit, Wiederholbarkeit, Protokollierung und Rückfallfähigkeit.
5. Lernstand dokumentieren: Offene Vertiefungen werden als priorisierte Aufgaben mit benötigtem Nachweis festgehalten.

Die Lernerfolgskontrolle besteht aus kurzen Verständnisfragen, beobachteten Laboraufgaben, einer Fehlersuche und der technischen Abnahme des Praxisprojekts. Bewertet werden nicht nur funktionierende Ergebnisse, sondern auch Begründung, Nachweis, sichere Fehlerbehandlung und Reproduzierbarkeit.