Ga naar inhoud

Afhandeling van incidenten en major incidents

Deze pagina beschrijft hoe het platformteam incidenten op het platform afhandelt: de hub, de pipelines en de baseline van de spokes. Ook legt ze uit hoe je een priority 1 (P1) incident aanmeldt bij de support van de cloudprovider als de oorzaak bij Azure zelf ligt.

Wie het platformteam is, hangt af van je beheermodel. Severities, reactietijden, uren en contactgegevens komen uit je contract (managed service) of uit je eigen definitie (zelfbeheer). Ze staan hier als placeholders. Wat workload teams doen en wat je in een bericht moet opnemen, staat in Support. Voor een eerste severitymodel, zie Operationele verantwoordelijkheden.

Incident, serviceaanvraag of wijziging

Het is een… Wanneer Afgehandeld als
Incident Iets wat werkte werkt niet meer, of slechter Deze pagina
Serviceaanvraag Een workload team vraagt iets wat het platform biedt Hoe vraag je iets aan, een standaardwijziging (Veelvoorkomende aanvragen)
Wijziging Het platformteam wijzigt het platform (codeversie, configuratie, een instelling in Azure) Wijzigingsworkflow

Houd ze gescheiden in je ticketsysteem. Twee redenen: oplostijden betekenen voor elk iets anders, en veel incidenten worden veroorzaakt door een wijziging die niemand heeft vastgelegd (zie de eerste les in Post-mortems).

Een incident afhandelen

flowchart LR
    a["1. Register"] --> b["2. Acknowledge + classify"] --> c["3. Diagnose"] --> d["4. Restore service"]
    d --> e["5. Close + inform"] --> f["6. Post-mortem (sev 1 / major)"]
  1. Registreren. Elk incident krijgt één record in het afgesproken ticketsysteem, ook als het via chat of telefoon is gemeld. Minimale velden: melder, workload en spoke (of hubcomponent), beschrijving, starttijd, of productie wordt geraakt, screenshots of foutmeldingen. Een P1 die alleen via chat wordt afgehandeld laat geen spoor na voor de post-mortem.
  2. Bevestigen en classificeren. Reageer binnen het responsdoel en stel de severity vast. Classificeer opnieuw als je meer weet. Een probleem dat klein lijkt kan severity 1 zijn als productie sinds het weekend plat ligt: classificeer op impact, niet op hoe lang het al duurt.
  3. Diagnosticeren. Begin met de controles in Waar je eerst kijkt. Schrijf bevindingen onderweg in het record.
  4. Service herstellen. Het eerste doel is de service te herstellen, het tweede de oorzaak te vinden. Een tijdelijke fix is prima als je die vastlegt en de definitieve inplant. Los een incident niet op door Azure met de hand te wijzigen zonder het vast te leggen: de volgende pipeline-run draait het terug, of het verbergt de echte oorzaak (drift).
  5. Afsluiten en informeren. Vertel de melder wat er mis was en wat je deed. Sluit het record af met de oorzaak en de fix.
  6. Post-mortem. Verplicht voor elk severity 1-incident en elk major incident (Post-mortems).

Severity

Gebruik het severitymodel uit je contract of je eigen model. Een model dat op managed platforms is gebruikt staat in Operationele verantwoordelijkheden. Welke nummers je ook kiest, leg per severity vast:

Onderdeel Waarde
Definitie, met een of twee voorbeelden van je platform <definition>
Uren waarin het wordt afgehandeld <hours>. Zeg duidelijk of severity 1 buiten kantooruren wordt afgehandeld, en voor welke componenten
Reactietijd <response target>
Updatefrequentie naar de melder <every n minutes / hours>
Wie wordt gebeld, en hoe <on-call contact>

Major incidents

Een major incident is een incident met ernstige bedrijfsimpact dat meer vraagt dan de normale flow: meerdere mensen tegelijk, een gedeeld beeld van de situatie en een communicatieverantwoordelijke. Typische triggers:

  • productieapplicaties van een of meer workload teams zijn onbereikbaar;
  • de verbinding tussen Azure en on-premises is uitgevallen;
  • een platformwijziging is in productie misgegaan en kan niet snel worden teruggedraaid;
  • een incident is severity 1 en de eerste diagnose vond de oorzaak niet binnen <n minutes>.

Rollen

In een klein platformteam kan één persoon meer dan één rol hebben, maar noem ze hardop aan het begin.

Rol Taak
Incident manager Is eigenaar van het incident tot het gesloten is. Beslist over severity, escalatie en wanneer te stoppen. Doet het technische werk niet
Technical lead Leidt diagnose en herstel. Beslist welke wijziging als volgende wordt geprobeerd
Communication lead Houdt stakeholders op de afgesproken frequentie op de hoogte. Enig aanspreekpunt voor de klant, workload teams en partners
Scribe Schrijft de tijdlijn op met tijdstempels: wat is gezien, wat is besloten, wat is gewijzigd, door wie
Partner- en providercontacten Engineers van andere betrokken partijen, bijvoorbeeld het on-premises netwerk- of firewallteam, de applicatie-eigenaar, de support van de cloudprovider

Hoe het verloopt

  1. Open een bridge (call of chatroom) zodra het incident als major is aangemerkt, met iedereen die iets kan wijzigen: het platformteam, de eigenaar van de getroffen workload en de eigenaren van gekoppelde systemen (on-premises netwerk, identiteit). Leg de locatie van de bridge vast in het ticket.
  2. Stem de feiten af: wat is getroffen, sinds wanneer en wat is er recent gewijzigd (platformwijzigingen, releases, wijzigingen van andere teams).
  3. Stop andere wijzigingen in het getroffen gebied tot het incident is gesloten.
  4. Werk in korte cycli: hypothese, controle, actie, vastleggen. Wijzig één ding tegelijk en schrijf het op.
  5. Communiceer in een vast ritme, ook als er niets nieuws is. Elke update zegt: huidige impact, wat bekend is, wat er wordt gedaan, tijdstip van de volgende update.
  6. Verklaar het opgelost wanneer de service hersteld is en de melder dat bevestigt. Is er een workaround, houd het probleem dan open.
  7. Plan de post-mortem binnen <n> werkdagen (het severitymodel van de managed service gebruikt vijf).

Wat werkte in echte incidenten

  • Een benoemd persoon die regelmatig een overzicht van de status gaf, zodat alle anderen konden werken.
  • Mensen die op korte termijn aansloten bij de call, en platformkennis die goed genoeg was om snel de oorzaak te vinden.
  • De andere partijen (on-premises netwerkteam, partner) in dezelfde call betrekken in plaats van berichten door te geven.

Waar je eerst kijkt

De meeste incidenten op het platform vallen in een paar groepen. De tabel is een start voor de diagnose, geen compleet runbook.

Symptoom Kijk naar Gezien oorzaken
Gebruikers krijgen 403 Forbidden op een applicatie achter de Application Gateway WAF-logs: welke regel matchte, voor welk verzoek Een WAF-instelling of regelset is gewijzigd zonder te testen (bijvoorbeeld inspectie van de request body). Schakel de matchende regel tijdelijk uit en los dan de oorzaak op. Zie Application Gateway
Gebruikers krijgen 502 Bad Gateway Backend health van de Application Gateway; DNS-resolutie van de backendnaam vanuit de hub; firewalllogs De backendnaam kan niet worden opgelost omdat het private DNS-record ontbreekt, waardoor verkeer de firewall nooit bereikt. Een net opnieuw aangemaakte firewallregel kan als oorzaak lijken maar is dat niet altijd
Een workload kan een bestemming niet bereiken Firewalllogs voor bron en bestemming (tabellen voor network rules en application rules, zie hieronder); NSG en route table van de spoke Ontbrekende of verwijderde regel, verkeerde IP group, rule collection halverwege een deployment (Firewallregels)
De verbinding tussen Azure en on-premises ligt eruit, en de portal zegt connected Verkeer op de verbinding, niet alleen de status; de logs van de andere partij; of een tweede verbinding werkt De verbindingsstatus is connected maar er stroomt geen verkeer. Het resetten van de verbinding aan beide kanten (de link bewerken en opslaan zonder wijzigingen) herstelde het verkeer in een gemeld geval. Spreek af wie welke kant reset voordat je begint
Een pipeline-run faalt of loopt op een time-out De falende job en layer; Known issues Time-outs bij grote firewallwijzigingen, een state die afwijkt van Azure, een verlopen deployment secret
Veel alerts tegelijk Azure Service Health en Resource Health Een probleem aan de kant van de provider. Zie Een P1 aanmelden bij de cloudprovider

Ga er niet van uit dat twee symptomen één oorzaak delen

Tijdens één gemeld incident veroorzaakten een firewallregelwijziging en een ontbrekend DNS-record tegelijk dezelfde 502. Test elke oorzaak apart voordat je een conclusie trekt.

Logs

Platformlogs gaan normaal gesproken naar een centrale Log Analytics workspace en worden bevraagd met Kusto (KQL).

Bron Waar Opmerkingen
Azure Firewall De firewall-resource, Logs. Resource-specifieke tabellen zoals AZFWNetworkRule, AZFWApplicationRule, AZFWNatRule, AZFWDnsQuery, AZFWFlowTrace en AZFWIdpsSignature (en de aggregatievarianten) Vereist dat firewalldiagnostiek naar Log Analytics aanstaat (Firewallregels)
Application Gateway en WAF De Application Gateway-resource, Logs Afhankelijk van de diagnostische instelling staat de data in de gedeelde tabel AzureDiagnostics (de oudere modus) of in resource-specifieke tabellen
Workloadlogs De eigen Log Analytics workspace van de spoke Van het workload team (Je workload beheren)

Toegang tot de logs is een rol op de workspace-tabellen en Monitoring Reader op de resource. Geef workload teams op een managed platform een alleen-lezen groep voor hun eigen verkeer wanneer ze dat zelf willen troubleshooten, in plaats van het platformteam te vragen de logs voor hen te lezen.

Een P1 aanmelden bij de cloudprovider

Sommige incidenten worden veroorzaakt door Azure, niet door het platform of de workload. Het platformteam (of het workload team, als je opzet dat toelaat) meldt dan een P1 aan bij de support van de cloudprovider. Wie dat mag doen, en via welk kanaal, hangt af van je supportovereenkomst: een eigen Microsoft-supportplan, of een partner (bijvoorbeeld een Cloud Solution Provider) die het doorgeeft. Zie Beheermodellen en Support.

Is het een P1 voor de provider?

Meld een provider-P1 aan voor Meld er geen aan voor
Een Azure-serviceuitval die productie raakt Prestatieproblemen door te weinig resources (schaal op, controleer quota)
Een onverwachte storing in een Azure-systeem Problemen in de applicatie
Kritieke beschikbaarheidsproblemen van een Azure-databaseservice Resources die geen Azure-resources zijn
Een verstoring van een Azure-cloudservice Problemen in Marketplace-applicaties van derden
Subscriptions die buiten de supportovereenkomst vallen

Controleer eerst Azure Service Health en Resource Health. Meldt Azure het probleem al, voeg dan jouw impact eraan toe.

Wie meldt het aan

Beperk het recht om provider-P1's aan te melden tot een paar met naam genoemde personen of rollen, bijvoorbeeld de engineers van het platformteam die bereikbaar zijn (<roles allowed to raise a P1>). Een workload team dat er geen aan mag melden, neemt contact op met het platformteam en zegt dat het probleem op een providerprobleem lijkt. Zet de lijst in je onboardingdocument.

Wat je in het record zet

Maak in het ticketsysteem of het portaal van de provider een incident aan met prioriteit critical (P1), met een duidelijke titel. Vul de beschrijving in deze volgorde in:

Sectie Inhoud
Incidentoverzicht Wat: welke Azure-service is kapot. Impact: aantal gebruikers of services. Wanneer: sinds wanneer. Status: de huidige situatie. Fouten: de relevante foutmeldingen
Technische details Resource-ID's van de getroffen resources, de subscription, gerelateerde monitoringalerts, relevante logregels
Contactgegevens Primair contact met telefoonnummer, back-upcontact, het kanaal waar updates worden geplaatst (<update channel>), andere stakeholders die geïnformeerd moeten worden
Reproductiestappen Exacte stappen om het probleem te zien: waar te kijken (portalpad, resourcenaam), wat te doen, wat er zou moeten gebeuren, wat er in plaats daarvan gebeurt

Tijdens het incident:

  1. Houd de beschrijving actueel.
  2. Zet op elke update een tijdstempel.
  3. Leg elke tijdelijke fix en elke geprobeerde oplossing vast.
  4. Vertel de getroffen workload teams waar ze de status kunnen volgen.

Afhankelijk van het contract

Of provider-P1's 24 uur per dag worden afgehandeld, en door wie, is onderdeel van je contract of supportplan. Beloof workload teams geen afhandeling rond de klok, tenzij dat voor de hub is afgesproken (Support).