RFC
Ein Request for Change (RFC) ist ein formaler Antrag zur Durchführung einer Änderung an IT-Services oder Infrastruktur im Rahmen des Change Management.
Der RFC dokumentiert, was geändert werden soll, warum, welche Risiken bestehen und wie die Änderung durchgeführt wird.
Typische RFC-Inhalte
- Beschreibung: Was soll geändert werden?
- Begründung: Warum ist die Änderung nötig?
- Impact: Welche Services/Kunden sind betroffen?
- Risiken: Was kann schiefgehen?
- Rollback-Plan: Wie machen wir es rückgängig?
- Zeitplan: Wann soll es durchgeführt werden?
- Ressourcen: Wer macht es, was wird benötigt?
- Affected CIs: Welche CMDB-Items betroffen?
RFC-Lebenszyklus
1. RFC erstellen und einreichen
↓
2. Initial Assessment (Ist es vollständig?)
↓
3. CAB-Review (Change Advisory Board)
↓
4. Genehmigung / Ablehnung / Zurückstellung
↓
5. Planung und Scheduling
↓
6. Implementierung
↓
7. Post Implementation Review
↓
8. RFC schließen
Genehmigungsinstanzen
| Change-Typ | Genehmigung durch | Dauer |
|---|
|Standard Change|Pre-authorized|Sofort|
|Normal Change|CAB-Meeting|Tage bis Wochen|
|Emergency Change|Emergency CAB|Stunden|
RFC-Bewertung (7 Rs)
Die 7 Rs
- Raised - Wer beantragt?
- Reason - Warum nötig?
- Return - Welcher Nutzen?
- Risks - Welche Risiken?
- Resources - Was wird gebraucht?
- Responsible - Wer ist verantwortlich?
- Relationship - Abhängigkeiten?
Impact-Analyse
Standard vs. Normal RFC
Standard Change
- Vordefinierter, wiederholbarer Prozess
- Geringes Risiko
- Pre-authorized (vorab genehmigt)
- Beispiel: Monatliche Windows-Updates, Passwort-Reset
Normal Change
- Individuelle Bewertung nötig
- CAB-Genehmigung erforderlich
- Höheres Risiko oder Impact
- Beispiel: Server-Migration, neue Software
Emergency Change
- Dringend und kritisch
- Verkürzte Genehmigung (E-CAB)
- Beispiel: Sicherheitspatch für kritische Lücke
Dokumentation
RFCs werden im Ticketsystem oder speziellen Change-Management-Tools dokumentiert und nachverfolgt.