Wie können wir helfen?
3.4 Change Request (Managed Cloud)
Im Modul Managed Cloud unter dem Unterpunkt Change Requests haben Sie die Möglichkeit, Change Requests zu erstellen, anzustoßen und zu bearbeiten. Außerdem können Sie bereits abgeschlossene Change Requests einsehen.
3.4.1 Allgemein
Im Modul Managed Cloud unter dem Unterpunkt Change Requests (CR) erhalten Sie zunächst eine Übersicht aller durch Sie oder für Ihr Unternehmen gestellten CRs. Ob Sie nur die von Ihnen gestellten Request oder die für Ihr gesamtes Unternehmen eingereichten Änderungswünsche sehen, hängt von der Berechtigung ab, die Sie besitzen. Änderungen an der Berechtigung können Sie beim Service Operation Center der ahd beantragen.
Für jeden CR sind folgende Inhalte hinterlegt:
| Kategorie | Beschreibung |
| ID | Pro gestelltem CR wird eine eindeutige ID vergeben. |
| Status | Unter der Rubrik „Status“ wird angezeigt, in welchem Prozessschritt sich der jeweilige CR befindet. Folgende Stati werden verwendet: Eingereicht Bewertet Beauftragt In Bearbeitung zu Testen Erledigt |
| Titel | Der angezeigte Titel leitet sich aus dem Titel ab, den der Ersteller im jeweiligen CR hinterlegt hat. |
| Dringlichkeit | Im CR können Sie eine der folgenden Dringlichkeitsstufen wählen: Niedrig Mittel Hoch Emergency |
| Antragssteller | Unter Antragsteller ist der Name der Person hinterlegt, die der Auftraggeber für den CR ist. |
| Kundenreferenz | Hier können Sie einen Vermerk hinterlegen, z.B. einen Verweis auf ein internes Projekt, dem der CR zugeordnet wird. |
| Erstellt am | Hier wird das Datum angezeigt, an dem Sie den CR erstellt haben. |
| Ersteller | Als Ersteller wird die Person hinterlegt, der den CR operativ angelegt hat. Die Person kann vom Antragsteller abweichen. |
Hilfe
Neben dem Button „+ Change beantragen“ finden Sie rechts einen Hilfe-Button. Klicken Sie diesen an, öffnet sich in einem neuen Fenster ein CR-Kundenhandbuch in PDF-Format. In diesem Handbuch werden alle CR-relevanten Prozesse detailliert beschrieben.
Filtern
Sie haben zwei Möglichkeiten, um die Change Requests zu filtern. Unter „Filter nach:“ können Sie nach Status filtern. Bei “Beauftragt nach” und “Beauftragt vor” können Sie nach Datum filtern.
Sortieren
Alle Change Requests, die Ihnen in der Übersicht angezeigt werden, können mithilfe der Kategorie auf- und absteigend sortiert werden. Dazu wählen Sie die Kategorie aus und klicken diese an.
3.4.2 Standard Changes
Bestimmte Changes erfolgen wiederkehrend und unterliegen einem Standardverfahren. Eine Übersicht über die einzelnen Services und die dazugehörigen Standard Changes finden Sie hier:
Um die Prozesse hinter diesen Standard Changes zu vereinfachen und schneller umsetzen zu können, finden Sie hier beispielhaft vorausgefüllte Change-Request-Formulare für die jeweiligen Services.
Citrix Virtuell App Services
| Titel* | [SCR-RWP1] – Patch Management |
| Dringlichkeit* | Mittel |
| Kurzbeschreibung* | Monatliches Updaten der Citrix Umgebung mit Windows und Standard-Applikations Updates |
| Detailbeschreibung* | Monatliches Aktualisieren der Citrix Images mit Updates • Windows • 7-Zip • Citrix Workspace • Acrobat Reader • Chrome • Firefox Die Updates werden am Montag nach dem 2. Dienstag (Patch Tuesday) im Image eingespielt. Die Applikation Updates werden hierbei durch Chocolatey durchgeführt, um ein möglichst effizientes Patchen zu ermöglichen. Vorgehensweise: Das Image wird am Montag nach dem 2. Dienstag geöffnet und mit entsprechenden Updates versorgt. Sobald die Updates eingespielt sind, wird das Image zum Test bereitgestellt und an den Kunden übergeben. |
| Risiko* | Image wird im Zeitraum durch anderen Change blockiert -> Updatezyklus fällt aus. Emergency Change wird in der Zeit des Updatezyklus gestellt -> Updatezyklus wird verworfen |
| Fallback* | Image Version wird verworfen |
| Beschreibung Testszenario | Tests aller aktualisierten Anwendungen und Grundfunktionalität des Images |
[SCR-RWP2] – Infrastruktur CU Update
| Titel* | [SCR-RWP2] – Infrastruktur CU Update |
| Dringlichkeit* | Niedrig |
| Kurzbeschreibung* | Upgrade des CU Standes auf die Latest Version |
| Detailbeschreibung* | Die Citrix Farm wird auf den latest CU Stand des jeweiligen Major Release aktualisiert. Um Fehler, welche durch den Upgrade Prozess entstehen, schneller zu finden wird der Prozess auf mehrere Tage aufgesplittet und nicht am Stück durchgeführt. Die Systeme werden, eins am Tag, in der folgenden Reihenfolge aktualisiert: • Lizenzserver • Storefront 1 • Storefront 2 • PVS 1 • PVS 2 • CDC 1 • DB Upgrade über CDC 1 • CDC 2 • Citrix Image Version (TDA & VDA) • Bereitstellungsgruppen Hierbei wird jeweils eine Risk Time beim Schwenk der Storefronts, PVS und CDC Systeme benötigt. |
| Risiko* | Nach Update einer Komponente Treten Fehler bei der Verbindung oder UX auf. Diese müssen einzeln betrachtet werden und entweder gelöst werden oder ein Snap Revert stattfinden |
| Fallback* | Snap Revert |
| Beschreibung Testszenario | Testen der Umgebung nach jedem Schritt in Bereichen Anmeldung und UX |
[SCR-RWP3] – Winterzeitumstellung
| Titel* | [SCR-RWP3] – Winterzeitumstellung |
| Dringlichkeit* | Hoch |
| Kurzbeschreibung* | Am {Datum} ist Winterzeitumstellung, zu diesem Zeitraum muss das Standard-Desktop Image einmal geöffnet und mit Winterzeit versiegelt werden |
| Detailbeschreibung* | Proaktive Vermeidung von Fehlern bei der Abarbeitung von Richtlinien nach der Zeitumstellung • Es darf an dem Wochenende kein Image mehr im Test sein • Vor Zeitumstellung wird eine neue Master Version erstellt und gestartet • Nach erfolgter Zeitumstellung wird die neue Master Version getestet und produktiv geschaltet • Neustart der Worker mit neuer vDisk Version • Prüfung auf Funktion, Fehler via Eventlog-Sammelskript |
| Risiko* | Bei Durchführung: Etwaiger Datenverlust beim Verwerfen von offenen Test-Images Bei nicht Durchführung: Fehler bei der Abarbeitung von Richtlinien, massive Funktionsbeeinträchtigung, etwaiger Datenverlust beim Verwerfen von offenen Test-Images |
| Fallback* | Alte Version im Master booten und erneut synchronisieren. |
| Beschreibung Testszenario | • Anmeldung am Citrix fehlerfrei • Prüfung auf vorhandene Fehlereinträge in Bezug auf die Zeitumstellung im Eventlog nach Worker Neustart |
Exchange Service
[SCR-APPL3] – Exchange Security Update Installation
| Titel* | [SCR-APPL3] – Exchange Security Update Installation |
| Dringlichkeit* | Hoch |
| Kurzbeschreibung* | Installation des {MM-YYYY} Exchange Security Updates |
| Detailbeschreibung* | Wo soll das Update installiert werden? • Servername Grund für das Update: • Sicherheitsrisiko CVE-20XX-XXXXX Wartungsfenster vom Kunden Durchführung: • Download und Installation des passenden Security Updates • Neustart Exchange Server • Ggfls. Anpassung (dokumentierter) Sonderkonfigurationen // Drittherstellersoftware • Funktionstest Exchange Dienste • Prüfung auf erfolgte Installation • Dokumentation und Abschluss |
| Risiko* | Exchange Service ist gestört, Benutzer können nicht mit Outlook, OWA, ActiveSync arbeiten, Mailfluss Unterbrechung |
| Fallback* | Abbruch der Installation, Erneute Installation, Reparaturinstallation |
| Beschreibung Testszenario | • Prüfung Dienst- und Datenbankstatus • Prüfung OWA und Outlook Zugriff • Prüfung Mailfluss • Prüfung Eventlog & Monitoring • Prüfung auf erfolgte Installation |
Firewall Service
[SCR-CT2] – Richtlinie erstellen/anpassen
| Titel* | [SCR-CT2] – Richtlinie erstellen/anpassen |
| Dringlichkeit* | Niedrig |
| Kurzbeschreibung* | Der SSL VPN Tunnel soll erstellt / geändert / gelöscht werden |
| Detailbeschreibung* | Wo soll die Firewall-Regel erstellt werden? • Ahd Cloud Firewall • On-Prem Firewall Quellinformation • Username inkl. Kontaktdaten • Authentifizierung (AD Account / Lokal User, Zertifikat, MFA) Zielinformation • Ziel-Hostname(n) • Ziel-IP-Adresse(n) Freizuschaltender Dienst/ Port • Dienst-Name / Port • Kommunikationsart: TCP/UDP • Split-Tunnel ja/nein |
| Risiko* | Bestehende Regeln werden überschrieben. User erlangt Zugriff auf Ressourcen die er nicht erreichen darf |
| Fallback* | Erstellte Konfiguration zurück bauen |
| Beschreibung Testszenario | Verbindungstest durchführen (falls möglich) |
CommVault Service
[SCR-SDP2] CommVault – Schedule ändern/anpassen
| Titel* | [SCR-SDP2] CommVault – Schedule ändern/anpassen |
| Dringlichkeit* | Mittel |
| Kurzbeschreibung* | Änderung des Zeitplans eines Backups |
| Detailbeschreibung* | Der Zeitpunkt oder die Häufigkeiten des Backups eines einzelnen Clients soll angepasst werden. Dies beinhaltet Agentensicherungen wie zum Beispiel: Exchange, SQL oder Oracle. Ausgeschlossen sind Backups auf Hypervisorebene (HyperV CSV, VMware Datastore,…) |
| Risiko* | Performanceprobleme |
| Fallback* | Zurücksetzen des Schedules |
| Beschreibung Testszenario | Prüfung der Backups nach dem nächsten Lauf |
[SCS-SDP3] Commvault – Rückbau Agent Backup
| Titel* | [SRC-SDP3] Commvault – Rückbau Agent Backup |
| Dringlichkeit* | Mittel |
| Kurzbeschreibung* | Entfernen eines Clients aus dem Backup ggf. Löschung der getätigten Backups |
| Detailbeschreibung* | Ein Client der mittels Agentbackup (SQL, Exchange, …) gesichert wird, soll aus dem Backup entfernt werden. Ebenfalls sollen ggf. die getätigten Backups unwiderruflich gelöscht werden. |
| Risiko* | Client wird nicht mehr gesichert Backups gehen unwiderruflich verloren |
| Fallback* | Anpassung Rückgängig machen |
| Beschreibung Testszenario | Prüfung des Rückbaus |
Veeam Service
[SCR-SDP6] Veeam – Schedule ändern/anpassen
| Titel* | [SCR-SDP6] Veeam – Schedule ändern/anpassen |
| Dringlichkeit* | Mittel |
| Kurzbeschreibung* | Änderung des Zeitplans eines Backups |
| Detailbeschreibung* | Der Zeitpunkt oder die Häufigkeiten des Backups eines einzelnen Jobs soll angepasst werden. |
| Risiko* | Performanceprobleme |
| Fallback* | Zurücksetzen des Schedules |
| Beschreibung Testszenario | Prüfung der Backups nach dem nächsten Lauf |
[SCR-SDP7] Veeam – Job Aufbewahrungszeit anpassen
| Titel* | [SCR-SDP7] Veeam – Job Aufbewahrungszeit anpassen |
| Dringlichkeit* | Mittel |
| Kurzbeschreibung* | Anpassung der Aufbewahrungszeit eines Backupjobs |
| Detailbeschreibung* | Die Aufbewahrungszeit in Tagen oder Restorepoints wird in einem Job angepasst. |
| Risiko* | Verlust von Backups Speicherplatzprobleme auf dem Storage |
| Fallback* | Aufbewahrungszeit zurücksetzen |
| Beschreibung Testszenario | Prüfen der vorgehaltenen Restorepoints |
[SCR-SDP8] Veeam – Rückbau Backup
| Titel* | [SCR-SDP8] Veeam – Rückbau Backup |
| Dringlichkeit* | Mittel |
| Kurzbeschreibung* | Löschen oder filtern eines Systems / Jobs / VM mit ggf. Löschung der getätigten Backups |
| Detailbeschreibung* | Ein System / Job / VM soll nicht mehr gesichert werden. Ebenfalls sollen ggf. die getätigten Backups unwiderruflich gelöscht werden. |
| Risiko* | System / Job / VM wird nicht mehr gesichert Backups gehen unwiderruflich verloren |
| Fallback* | Anpassung Rückgängig machen |
| Beschreibung Testszenario | Prüfung des Rückbaus |
3.4.2 Einen neuen Change beantragen
Sie haben zwei Möglichkeiten, einen neuen CR zu erstellen. Wenn Sie im Modul Managed Cloud mit der Maus über den Unterpunkt Change Requests fahren, erscheint ein rot hinterlegtes “+”-Symbol. Wenn Sie darauf klicken, gelangen Sie direkt in ein neues Change-Request-Formular.
Alternativ können Sie direkt über die Unterseite Change Requests gehen. Im oberen rechten Teil der CR-Übersicht befindet sich der Button “Change beantragen”.
Wenn Sie den Button anklicken, werden Sie ebenfalls auf die Seite des Change-Request-Formulars geleitet.
Ausfüllen des Change-Request-Formulars
Geben Sie die notwendigen Informationen für einen neuen Change Request in die dafür vorgesehenen Felder ein. Folgende Felder müssen ausgefüllt werden:
- Titel
- Antragsteller
- Tester
- Dringlichkeit
- Kurzbeschreibung
- Detailbeschreibung
- Risiko
- Fallback
Folgende Felder sind keine Pflichtfelder und können bei Bedarf zusätzlich mit Informationen befüllt werden:
- Grund
- Wunschzeitraum
- Beschreibung Testszenario
- Kundenreferenz
Nachdem Sie alle Felder ausgefüllt haben, müssen Sie den CR zunächst als Entwurf speichern, bevor er eingereicht werden kann.
Sie reichen den CR ein, indem Sie den Button „Change Request einreichen“ in der oberen Menüleiste anklicken. Solange Sie den Change Request noch nicht eingereicht haben, haben Sie die Möglichkeit den Entwurf zu stornieren, dazu klicken Sie auf den Button “Entwurf stornieren”.
Nachdem Sie einen CR eingereicht haben, können Sie keine Anpassungen mehr durchführen. Änderungen können dann nur noch vom ahd Service Delivery Manager (SDM) vorgenommen werden.
Kommentare
Nach jedem Prozessschritt besteht die Möglichkeit, über ein Kommentarfeld weitere Informationen etc. zu hinterlegen.
Änderungsverlauf
Nach jedem Prozessschritt wird am Ende des CR eine Darstellung des CR-Änderungsverlaufs angezeigt.
Der CR wird bewertet
Im nächsten Schritt bewertet der ahd SDM, nach Rücksprache mit den ahd-internen technischen Ansprechpartnern (CAB – Change Advisory Board), Ihre Anforderung. Es werden Machbarkeit, Sinnhaftigkeit und die anfallenden Kosten evaluiert. Außerdem wird geprüft, ob der CR in dem vom Ihnen genannten Wunschzeitraum umgesetzt werden kann. Zusätzlich werden die voraussichtlichen Auswirkungen der technischen Änderung an Ihren Verbrauchsdaten dokumentiert. Anschließend werden einmalige und monatliche Kosten, der voraussichtliche Lieferzeitpunkt, Maßnahmen im Bedarfsfall und potentielle Betriebseinschränkungen hinterlegt.
Anschließend wird der Change offiziell bewertet und an Sie zurückdelegiert. Dazu trägt der SDM das Feedback zum jeweiligen CR unter der Rubrik „Change Request bewerten“ ein. Sobald der SDM die Bewertung gespeichert und anschließend abgegeben hat, liegt der nächste Bearbeitungsschritt bei Ihnen.
Der CR wird beauftragt und bearbeitet
Sind Sie mit den vom SDM eingereichten Änderungen und den anfallenden Beträgen einverstanden, beauftragen Sie den CR. Hierzu bestätigen Sie die Beauftragung durch Anklicken des „Change Request beauftragen“-Buttons. Alternativ kann der Change abgelehnt oder geschlossen werden.
Sobald bei der ahd mit der Umsetzung Ihres Change Requests begonnen wird, ändert sich der Status des CRs von “Beauftragt” in “In Bearbeitung”.
Sobald die Umsetzung von der ahd abgeschlossen ist, wird der CR zum Test freigegeben.
Der CR ist im Status zu testen
Nachdem Sie die neue Lösung getestet haben, können Sie den Erfolg des Tests mit dem Button „Test erfolgreich“ in den nächsten Status versetzten. Alternativ haben Sie die Möglichkeit, den Status „Test fehlgeschlagen“ zu wählen.
Wenn Sie den „Test fehlgeschlagen“-Button angeklickt haben, wird der CR zurück in den Status „In Bearbeitung“ versetzt.
Der CR ist abzurechnen
Ist der Test erfolgreich, schließen Sie den Change Request ab. Der CR wird im Folgenden mit dem Status „Abzurechnen“ angezeigt.
