Die Implementierung validieren¶
In der Validate-Phase prüft eine zweite Person das Deployment anhand von Checklisten. Der Deployment Engineer kann seine eigene Arbeit nicht validieren. Dokumentiere jedes Ergebnis, auch die fehlgeschlagenen Prüfungen und was dagegen getan wurde, im Work Item oder Ticket der Implementierung. Diese Dokumentation ist der Nachweis, den du bei der Übergabe vorlegst.
So validierst du¶
- Vereinbare, wer validiert. Nimm in einem Eigenbetriebs-Team jemanden, der das Deployment nicht durchgeführt hat.
- Erstelle ein Work Item für die Validierung, mit den vier Checklisten unten als Tasks.
- Arbeite jede Checkliste ab. Schreibe zu jedem Punkt passed, failed oder not applicable, eine kurze Notiz und einen Link zum Nachweis (pipeline-Lauf, Screenshot oder Fundort im Portal).
- Behebe jeden fehlgeschlagenen Punkt oder vereinbare mit dem Kunden schriftlich, ihn zu akzeptieren, und prüfe ihn erneut.
- Schließe das Work Item, wenn alle Punkte bestanden oder akzeptiert sind.
Minimum und Ergänzungen
Die Zeilen 1 bis 3 der Tabellen zu Security-Baseline, hub und spoke canvas sowie die Zeilen 1 bis 5 der Tabelle zu pipelines und Agents sind die Mindestprüfungen der ursprünglichen Runbooks. Die übrigen Zeilen sind Ergänzungen, die sich aus dem Rest dieses Abschnitts ergeben. Behalte sie oder entferne sie, je nach deinem Qualitätsstandard.
Security-Baseline¶
| # | Prüfung | Wie |
|---|---|---|
| 1 | Branch protection stellt das Vier-Augen-Prinzip sicher | Öffne die branch policy oder das ruleset des Default-branch des Konfigurations-Repositorys. Ein pull request mit mindestens einer Genehmigung von jemand anderem als dem Autor ist erforderlich, und Force Pushes sind blockiert. |
| 2 | Produktionsläufe brauchen eine Genehmigung | Öffne das environment prod (und das Produktions-environment der spokes, falls vorhanden). Genehmiger sind gesetzt, Selbstgenehmigung ist aus, und Administratoren können nicht umgehen. |
| 3 | Production und canary verwenden unterschiedliche service connections oder credentials | Vergleiche die service connections (oder die federated credentials), die die Entry-pipelines für canary und für prod verwenden. |
| 4 | Das Code-Repository kann weder vom Kunden-Team noch von pipelines geändert werden | Prüfe das ruleset oder die policy auf dem Code-Repository. |
| 5 | Das Plattform-Team hat keinen dauerhaften privilegierten Zugriff | Die Maintainer-Gruppe hat keine aktiven Mitglieder. Engineers bekommen Zugriff über eine eligible PIM-Zuweisung mit Genehmigung (Identität vorbereiten). |
| 6 | Deployment-Secrets sind sicher gespeichert, oder es werden federated credentials verwendet | Prüfe den Secret Store, das Ablaufdatum jedes Client-Secrets und wer sie lesen darf. |
Cloud-Plattform (hub)¶
| # | Prüfung | Wie |
|---|---|---|
| 1 | Alles ist in main gemerged |
Keine offenen Implementierungs-branches mit nicht gemergten Änderungen. Der Default-branch ist main. |
| 2 | Die Plattform ist mit den pipelines deployt, für canary und für prod | Jeder layer in jeder Region zeigt einen erfolgreichen Lauf. |
| 3 | Ein neuer Lauf zeigt keine Änderungen | Führe hub erneut im Modus Plan von main aus. Der Plan zeigt keine Änderungen oder nur das bekannte Rauschen aus den Bekannten Problemen (zum Beispiel Attribute von Policies oder Application Gateway). |
| 4 | Die fixierte Code-Version ist das vorgesehene Release | Dieselbe Version in jeder Entry-pipeline (Versionierung). |
| 5 | Das Design ist umgesetzt | Regionen, Features, Adressbereiche, Firewall-SKU und Gateways entsprechen dem akzeptierten Design oder Discovery-Sheet. |
| 6 | Alerts und Kontakte stimmen | Die Empfänger der action group und der Defender-Sicherheitskontakt sind auf die Adressen des Kunden gesetzt (Day-one-Checkliste). |
Pipelines und Agents¶
| # | Prüfung | Wie |
|---|---|---|
| 1 | Alles ist in main gemerged |
Wie oben, für die Repositories und pipelines, die die runners deployen |
| 2 | Die Job runners sind deployt | Der Lauf von infrastructure war erfolgreich für canary und für prod |
| 3 | Ein neuer Lauf zeigt keine Änderungen | Führe infrastructure erneut aus. Er meldet keine Änderungen. |
| 4 | Die agent pools sind im Projekt verfügbar | Project settings, Agent pools (Azure DevOps) oder die runner groups (GitHub) zeigen die Pools mit online-Agents |
| 5 | Eine pipeline lief auf den Agents und war erfolgreich | Der hub-Lauf selbst belegt das. Nenne den Lauf. |
| 6 | Die Smoke-Tests sind bestanden | Das Ergebnis der Pool-Smoke-Tests im Lauf von infrastructure |
| 7 | Das mcp-Image liegt mit einem Versions-Tag in der Registry |
Container Registry, Repositories |
Spoke canvas¶
| # | Prüfung | Wie |
|---|---|---|
| 1 | Alles ist in main gemerged |
Wie oben, für die spoke-Dateien |
| 2 | Ein Test-spoke ist mit der pipeline deployt | Der spoke-Lauf war erfolgreich und der spoke entspricht der Beschreibung unter Neuer spoke |
| 3 | Ein neuer Lauf zeigt keine Änderungen | Führe spoke für diese Datei erneut aus. Der Plan zeigt keine Änderungen, abgesehen vom bekannten spoke-Rauschen (Bekannte Probleme). |
| 4 | Der Zugriff über PIM funktioniert | Ein Mitglied der Team-Gruppe aktiviert eine spoke-Rolle und sieht die subscription |
Dokumentation der Validierung¶
Verwende im Work Item eine Tabelle wie diese:
| Bereich | Prüfungen | Bestanden | Fehlgeschlagen | Akzeptierte Ausnahmen | Validiert von | Datum |
|---|---|---|---|---|---|---|
| Security-Baseline | ||||||
| Cloud-Plattform | ||||||
| Pipelines und Agents | ||||||
| Spoke canvas |
Offene Punkte kommen auf die Liste des Steering-Reports oder ins Backlog des Plattform-Teams.