Runbooks für Reviewer und Operator¶
Dieser Bereich enthält die Schritt-für-Schritt-Runbooks der Personen, die Standardänderungen bearbeiten: des Operators, der eine Änderung vorbereitet und deployt, und des Reviewers, der einen pull request prüft. Sie sind für das Plattform-Team in beiden Betriebsmodellen geschrieben: XMMS-Engineers im Modell Managed Service, die eigenen Engineers im Modell Eigenbetrieb.
Die Runbooks ergänzen die technischen Seiten des Konfigurationsbereichs um die praktische Reihenfolge der Arbeit:
| Dieser Bereich | Der Konfigurationsbereich |
|---|---|
| Was in welcher Reihenfolge zu prüfen ist und was du sagst, wenn etwas nicht stimmt | Wie die Dateien aussehen und was jedes Feld in Azure bewirkt |
| Wie du deployst und wie du das Apply verifizierst | pipelines, layers und Parameter |
| Wie du das Ticket schließt | Die Anfragefelder und der Katalog der Standardänderungen |
Halte beide offen: Das Runbook sagt dir die Reihenfolge, die häufige Anfrage sagt dir die Details.
Runbooks¶
| Änderung | Operator-Runbook | Reviewer-Runbook | Deployment |
|---|---|---|---|
| Firewallregel | Eine Anfrage für eine Firewallregel bearbeiten | Review eines pull requests für Firewallregeln | Deployment von Firewallregeln |
| IP group | Änderung einer IP group (Operator und Reviewer) | Deployment von Firewallregeln (derselbe layer) | |
| Application Gateway | Änderung am Application Gateway | WAF-Policy-Review für WAF-Policy-Dateien | Deployment des Application Gateways |
| Spoke | Spoke erstellen | Review eines Spoke-pull-requests | Spoke-Deployment |
| Managed VM | Review eines pull requests für Managed VMs (Review, Deployment und Fehlerbehebung) |
Die Prüfpunkte, die für jeden pull request gelten, wie du einen zurückschickst und die auto-complete-Einstellungen stehen unter Pull-Request-Review. Der Prozess rund um die Anfrage steht unter Der Standardänderungsprozess.
Der Ablauf jeder Standardänderung¶
Jedes Runbook ist eine Variation derselben Abfolge:
flowchart LR
a["1. Request is complete"] --> b["2. Branch and edit"]
b --> c["3. Validate and push"]
c --> d["4. Pull request and checks"]
d --> e["5. Review"]
e --> f["6. Deploy canary"]
f --> g["7. Verify the apply"]
g --> h["8. Deploy prod"]
h --> i["9. Verify and close the ticket"]| Schritt | Regel |
|---|---|
| 1. Anfrage ist vollständig | Fange nicht an, bevor alle Felder der Kategorie ausgefüllt sind. Frag den Anfragenden. |
| 2. Branch und Änderung | Branche von main. Ändere nur die Dateien, die das Runbook nennt. Mache dieselbe Änderung für jeden Ordner einer Plattform-Umgebung (canary und prod). |
| 3. Validieren und pushen | Führe die Config-Tests lokal aus, wenn du kannst (Tests lokal ausführen). |
| 4. Pull request und Prüfungen | Verlinke das Ticket. Warte auf die Validierungs-pipeline. Behebe, was sie meldet. |
| 5. Review | Ein zweiter Engineer, der die Änderung nicht geschrieben hat. Siehe Pull-Request-Review. |
| 6. canary deployen | Führe die pipeline für den layer aus, für canary. Lies den Plan. |
| 7. Das Apply verifizieren | Öffne das Apply-Log und prüfe, dass die angefragte Änderung durchgeführt wurde. Eine grüne Stage allein ist kein Beweis. |
| 8. prod deployen | Derselbe Lauf für prod. Der Produktionsplan wird von einem zweiten Engineer genehmigt. |
| 9. Verifizieren und schließen | Prüfe das Ergebnis, wie das Runbook es sagt. Füge dem Ticket eine Zeile hinzu, weise es dem Anfragenden zu und setze es auf Resolved. |
Regeln, die überall gleich sind¶
- Ändere nie zuerst Produktion. Immer zuerst canary.
- Verlasse dich nicht allein auf eine grüne pipeline. Bei komplexen Ressourcen wie dem Application Gateway zeigt eine erfolgreiche Apply-Stage nicht, dass die angefragte Änderung vorhanden ist. Öffne das Apply-Log. Wenn die Änderung nicht sichtbar ist, löse das Ticket nicht: Untersuche es und frag bei Bedarf einen zweiten Engineer.
- Halte bei einem destroy an, das niemand erwartet. Der Plan einer Standardänderung zeigt Adds und In-place-Änderungen der Ressourcen, die im Runbook genannt sind. Alles andere ist ein Grund anzuhalten.
- Zugriff. Stelle vor dem Start sicher, dass du Zugriff auf das Tooling der Plattform (das Konfigurations-Repository, die pipelines und das Ticketsystem) und auf den richtigen Tenant hast. Im Modell Managed Service muss sich ein Engineer, der für mehrere Kunden arbeitet, mit dem Konto des richtigen Kunden anmelden.
- Kopiere keine Secrets oder personenbezogenen Daten in Tickets und pull requests.
- Feedback an den Autor. Schick einen pull request mit einem Kommentar im Ticket zurück, erwähne den Autor, setze das Ticket auf den Status New und weise es dem Autor zu (Pull-Request-Review).