Self-hosted-Governance und Change-Control

Self-hosted-Governance und Change-Control

Im Self-hosted-Betrieb können Sie vieles ändern. Damit Kontrolle bleibt, brauchen Sie einen praktikablen Governance-Standard: klare Rollen, klaren Scope und belastbare Nachweise für jede Änderung.

Was das löst

• Unklare Rollen im Teambetrieb,
• Änderungen ohne Historie,
• Vorfälle ohne Kontext,
• nicht wiederholbare Deployments.

Empfohlenes Governance-Muster

1. Einzige Change-Quelle — jede Änderung hat einen Ticket-/Issue-Nachweis mit Zweck.
2. Expliziter Owner — ein Owner, ein Freigebender, klarer Rollback-Kontakt.
3. Scope-Lock — Run zielt nur auf geplanten Server/Workspace.
4. Tag-Disziplin — Baseline mit kleinem Tag-Satz, größere Änderungen nach Review.
5. Nachweise — Run-Notizen, Prüfer und Abschlusszeitpunkt jeder Folgeaktivität.

Self-hosted-Checkliste

• Ist die Änderung an ein Entscheidungsdokument gekoppelt?
• Gibt es freigegebenes Change-Fenster und Team-/Client-Kommunikation?
• Ist der Preflight-Status dokumentiert und begründet?
• Ist der Rollback-Plan für diese Änderung getestet?
• Sind Run-Notizen vollständig inklusive Prüfer und nachfolgendem Owner?

Häufige Probleme

• Ausführung außerhalb des genehmigten Scopes ohne Wirkungserklärung,
• Änderung von Variablen ohne Review,
• mischung von Template-Varianten ohne dokumentierte Begründung,
• fehlende Rollback-Bereinigung nach Vorfall.

Querverweise

Im Self-hosted-Betrieb hängt Governance eng mit Templates und Updates zusammen. Nutzen Sie Vorlagen und Workflow zusammen mit self-hosted day-to-day operations als Standardprozess.

Nächste Schritte

• Für den Baseline-Start verwenden Sie die Self-hosted-Onboarding-Checkliste.
• Für Vorfälle nutzen Sie Self-Hosted-Fehlerdiagnose und Störungsbehebung.
• Zum Vergleich mit managed prüfen Sie den Moduswechsel.

Nächster Schritt: Gehen Sie zur ersten Deploy- und Produktions-Checkliste für einen konkreten Standardablauf.