Der Standardänderungsprozess¶
Eine Standardänderung ist eine vorab genehmigte Änderung mit geringem Risiko, bekanntem Ablauf und festen Anfragefeldern. Diese Seite beschreibt den Prozess drumherum: wie eine Anfrage hereinkommt, welche Status sie durchläuft, wer was macht und welche Kategorien es gibt. Der technische Ablauf pro Kategorie steht in den Runbooks, die unter Häufige Anfragen aufgeführt sind. Die Runbooks für Reviewer und Operatoren stehen unter Runbooks für Reviewer und Operatoren.
Alles, was nicht in der Liste der Kategorien steht, ist keine Standardänderung. Es wird als Projekt, als Entwicklungsänderung im Code-Repository oder als Incident behandelt, je nachdem, worum es geht.
Zwei Wege, eine Änderung zu starten¶
Welcher der beiden verfügbar ist, hängt von der Vereinbarung mit deinem Plattform-Team ab (Betriebsmodelle).
| Weg | Was der Anfragende macht | Was das Plattform-Team macht |
|---|---|---|
| A. Anfrage | Beschreibt die Änderung in einem Ticket oder Work Item (User Story) und liefert alle Felder der Kategorie. | Bereitet die Konfigurationsänderung vor, lässt sie reviewen und deployt sie. |
| B. Pull request | Bereitet die Konfigurationsänderung selbst als pull request auf das Konfigurations-Repository vor und verknüpft ihn mit einem Ticket. | Reviewt den pull request, merged ihn und deployt. |
Weg B passt zu Teams, die die JSON-Formate kennen. Er ist üblich für Firewallregeln und IP groups (Firewallregeln und IP groups für workload-Teams) und für Managed-VM- Konfigurationen (Einen Managed-VM-pull-request vorbereiten). Der Anfragende schließt seinen eigenen pull request nie selbst ab, und der pull request ersetzt nie das Ticket: Das Ticket ist der Änderungsnachweis.
Lebenszyklus einer Anfrage¶
Ein Ticket durchläuft eine kleine Menge von Status. Die Namen unten sind ein Beispiel aus einem Work-Item-Board. Verwende das Äquivalent in deinem Tooling.
| # | Status | Wer setzt ihn | Bedeutung |
|---|---|---|---|
| 1 | New | Anfragender | Die Anfrage ist angelegt. Der Anfragende füllt alle Felder der Kategorie aus und setzt sie dann auf Design. |
| 2 | Design | Plattform-Team | Die Anfrage ist vollständig und bereit zur Bearbeitung. Das Plattform-Team prüft sie und fragt nach, wenn Felder fehlen. Danach wird sie Active. |
| 3 | Active | Plattform-Team | Das Plattform-Team arbeitet an der Änderung: bearbeiten, pull request, Review, Deployment. |
| 4 | Resolved | Plattform-Team | Die Änderung ist deployt, und das Team hat das Ergebnis in den Apply-Logs verifiziert. |
| 5 | Done | Anfragender | Der Anfragende hat das Ergebnis validiert und akzeptiert es. Ist es nicht richtig, setzt er es mit einem Kommentar zurück auf Active. |
Regeln:
- Eine Anfrage mit fehlenden Feldern geht mit einem Kommentar, der sagt, was fehlt, an den Anfragenden zurück (Status New). Das Plattform-Team rät nicht.
- Nach Done ist eine neue oder zusätzliche Änderung ein neues Ticket.
- Vereinbare in deinem Vertrag oder deiner internen Vereinbarung eine Ziel-Bearbeitungszeit von Design bis Resolved. Ein übliches Ziel sind einige Arbeitstage, zum Beispiel fünf. Die Zeit hängt von der Kategorie und von der Warteschlange ab, und eine Änderung in Produktion braucht ein Zeitfenster. Trage deinen Wert in dein onboarding-Dokument ein, nicht in diese Dokumentation.
- Ein pull request, der mit dem Ticket verknüpft ist, schließt das Ticket beim Merge nicht automatisch. Das Ticket wird erst nach der Verifikation des Deployments auf resolved gesetzt, schalte also Work Item nach dem Merge abschließen in den Auto-Complete- Einstellungen des pull requests aus.
Wer macht was in einem pull request¶
| Schritt | Wer |
|---|---|
| Die Änderung vorbereiten und den pull request öffnen | Der Anfragende (Weg B) oder das Plattform-Team (Weg A) |
| Den Inhalt genehmigen | Der Owner des workloads und Security, wo die Kategorie es verlangt |
| Technisch reviewen | Ein Plattform-Engineer, der die Änderung nicht geschrieben hat |
| Mergen und deployen | Das Plattform-Team |
Die Checkliste für den Review steht unter Review von pull requests.
Kategorien und Anfragefelder¶
Jede Anfrage hat die drei gemeinsamen Felder aus Häufige Anfragen: Begründung, Umgebung und Kommentare. Die Tabelle zeigt die zusätzlichen Felder pro Kategorie. Das Runbook der Kategorie zeigt, wo jedes Feld in der Konfiguration landet.
| Kategorie | Zusätzliche Anfragefelder | Runbook |
|---|---|---|
| Neuer workload, spoke oder application landing zone | Workload-Name, Kurzname, Beschreibung, Nutzungstyp (Produktions- oder Nicht-Produktionsdaten), Exposition ins Internet, Owner, Team, Größe des IP-Bereichs (ein /24 ist ein üblicher Standard), subnets (Name, Größe, delegations, service endpoints), Team-Gruppe und PIM-Modus |
Neuer spoke |
| Einen spoke ändern | Workload, spoke, was sich ändert (nur die Felder, die sich ändern) | Spoke ändern |
| Einen spoke löschen | Spoke, Umgebung, Bestätigung des Workload-Owners | Spoke löschen |
| Firewallregel (neu oder geändert) | Workload, spoke, Beschreibung, Integration (mit welchen anderen workloads oder On-Premises-Systemen sie verbindet), Regelname, Regeltyp (application oder network), Quelle, Ziel, Protokoll und Port | Firewallregeln |
| IP group (neu oder geändert) | Name, Zweck, die Adressen, welche Regeln sie verwenden | IP groups |
| Application Gateway: einen workload hinzufügen oder ändern | Workload-Name, Backend-Adresse (IP oder FQDN), Listener-URL, Listener-Port (HTTP oder HTTPS), SSL-Zertifikat (Pflicht bei HTTPS), Redirect ja oder nein, health probe (Standard oder benutzerdefiniert mit Pfad, Protokoll und Intervall) | Application Gateway |
| Ein Zertifikat erneuern oder ersetzen | Listener-URL, Zertifikatsname | Ein Zertifikat ersetzen |
| Policy-Zuweisung (neu oder Update) | Name der Policy oder initiative, Scope | Policy-Zuweisungen |
| Policy-Ausnahme | Policy oder initiative, Scope, Kategorie, Begründung, alternative Maßnahmen, Enddatum, Genehmigung | Policy-Ausnahmen |
| Ein Plattform-Feature aktivieren oder deaktivieren | Feature oder Ressourcentyp, Umgebung (Produktion oder Nicht-Produktion) | Plattform-Features |
| Tags auf hub-Ressourcen (anlegen, ändern, löschen) | Tag-Name, Tag-Wert, Umgebung | hub-Tags |
| Managed VM (neu, ändern, entfernen) | Spoke, Kurzname der Konfiguration und die VM-Einstellungen, die sich ändern | Managed-VM-Modul, Felder unter Anfragen und Ändern |
Ältere Anfrageformulare
Ältere Formulare der Standardänderungen führen dieselben Felder unter anderen Namen auf (zum Beispiel Additional spoke canvas für einen neuen spoke und Workload Azure firewall rule). Der Katalog auf dieser Seite folgt den Runbooks.
Was keine Standardänderung ist¶
Das sind häufige Anfragen, die wie Standardänderungen aussehen, aber keine sind. Die Gründe stehen in den Abgrenzungen.
- Ein Feature, das neues Terraform im Code-Repository braucht.
- Spoke-Tags: Das workload-Team setzt sie in der spoke-JSON.
- Policy-initiatives auf einem einzelnen spoke: Das workload-Team ist dafür verantwortlich.
- Alles, was von Hand im Portal erledigt werden müsste, außerhalb des Konfigurations-Repositorys, weil das nächste Deployment es rückgängig machen würde.