Ga naar inhoud

Runbooks voor reviewers en operators

Dit onderdeel bevat de stapsgewijze runbooks van de mensen die standaardwijzigingen afhandelen: de operator die een wijziging voorbereidt en deployt, en de reviewer die een pull request controleert. Ze zijn geschreven voor het platformteam in beide beheermodellen: XMMS-engineers in het managed-servicemodel, je eigen engineers in het zelfbeheermodel.

De runbooks voegen de praktische werkvolgorde toe aan de technische pagina's van het configuratieonderdeel:

Dit onderdeel Het configuratieonderdeel
Wat je controleert, in welke volgorde, en wat je zegt als er iets mis is Hoe de bestanden eruitzien en wat elk veld in Azure doet
Hoe je deployt en de apply controleert Pipelines, layers en parameters
Hoe je het ticket sluit De aanvraagvelden en de catalogus van standaardwijzigingen

Houd beide open: het runbook vertelt je de volgorde, de veelvoorkomende aanvraag vertelt je de details.

Runbooks

Wijziging Runbook voor operators Runbook voor reviewers Deployment
Firewallregel Een aanvraag voor een firewallregel afhandelen Review van een pull request voor een firewallregel Deployment van een firewallregel
IP group IP group-wijziging (operator en reviewer) Deployment van een firewallregel (zelfde layer)
Application Gateway Application Gateway-wijziging Review van WAF policy's voor WAF policy-bestanden Deployment van Application Gateway
Spoke Een spoke aanmaken Review van een pull request voor een spoke Deployment van een spoke
Managed VM Review van pull requests voor managed VM's (review, deployment en troubleshooting)

De controles die voor elke pull request gelden, hoe je er een terugstuurt en de auto-completeinstellingen staan op Pull request review. Het proces rond de aanvraag staat op Het standaard wijzigingsproces.

De vorm van elke standaardwijziging

Elk runbook is een variant op dezelfde reeks:

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"]
Stap Regel
1. Aanvraag is compleet Begin niet voordat alle velden van de categorie zijn ingevuld. Vraag het aan de aanvrager.
2. Branch en bewerken Maak een branch vanaf main. Wijzig alleen de bestanden die het runbook noemt. Voer dezelfde wijziging door voor elke map van een platformomgeving (canary en prod).
3. Valideren en pushen Draai de config tests lokaal als je kunt (De tests lokaal draaien).
4. Pull request en checks Koppel het ticket. Wacht op de validatiepipeline. Los op wat hij meldt.
5. Review Een tweede engineer die de wijziging niet heeft geschreven. Zie Pull request review.
6. Canary deployen Draai de pipeline voor de layer, voor canary. Lees het plan.
7. De apply controleren Open de apply-log en controleer dat de gevraagde wijziging is uitgevoerd. Een groene stage alleen is geen bewijs.
8. Prod deployen Dezelfde run voor prod. Het productieplan wordt goedgekeurd door een tweede engineer.
9. Controleren en sluiten Controleer het resultaat zoals het runbook zegt. Voeg een regel toe aan het ticket, wijs het toe aan de aanvrager en zet het op Resolved.

Regels die overal gelijk zijn

  • Wijzig nooit eerst productie. Altijd eerst canary.
  • Vertrouw niet alleen op een groene pipeline. Bij complexe resources, zoals de Application Gateway, laat een geslaagde apply-stage niet zien dat de gevraagde wijziging er is. Open de apply-log. Is de wijziging niet zichtbaar, los het ticket dan niet op: zoek het uit en vraag zo nodig een tweede engineer.
  • Stop bij een destroy die niemand verwacht. Het plan van een standaardwijziging toont toevoegingen en in-place wijzigingen van de resources die het runbook noemt. Al het andere is een reden om te stoppen.
  • Toegang. Zorg voordat je begint dat je toegang hebt tot de tooling van het platform (de configuratierepository, de pipelines en het ticketsysteem) en tot de juiste tenant. In het managed-servicemodel moet een engineer die voor meerdere klanten werkt, inloggen met het account van de juiste klant.
  • Kopieer geen secrets of persoonsgegevens naar tickets en pull requests.
  • Feedback aan de auteur. Stuur een pull request terug met een opmerking op het ticket, een vermelding van de auteur, het ticket in de status New en toegewezen aan de auteur (Pull request review).