Delen via

Aanbevelingen voor het ontwerpen van een strategie voor noodgevallen

  • Artikel

Is van toepassing op deze controlelijst voor Azure Well-Architected Framework Operational Excellence:

OE:08 Ontwikkel een effectieve praktijk voor noodoperaties. Zorg ervoor dat uw workload zinvolle statussignalen verzendt in de infrastructuur en code. Verzamel de resulterende gegevens en gebruik deze om bruikbare waarschuwingen te genereren die reacties op noodgevallen uitvoeren via dashboards en query's. Definieer duidelijk menselijke verantwoordelijkheden, zoals on-call rotaties, incidentbeheer, toegang tot noodresources en het uitvoeren van postmortems.

In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een strategie voor noodgevallen. Sommige problemen die zich voordoen tijdens de levenscyclus van een workload, zijn essentieel genoeg om te rechtvaardigen dat deze noodsituaties worden declaraties. U kunt nauwkeurig beheerde en gerichte processen en procedures implementeren die uw team kan volgen om ervoor te zorgen dat een probleem op een rustige, ordelijke manier wordt afgehandeld. Noodgevallen verhogen uiteraard de stressniveaus van iedereen en kunnen leiden tot een chaos als uw team niet goed voorbereid is. Om stress en verwarring te minimaliseren, ontwerpt u een responsstrategie, deelt u de responsstrategie met uw organisatie en voert u regelmatig training voor noodgevallen uit.

Belangrijke ontwerpstrategieën

Een strategie voor respons op noodgevallen moet een ordelijke, goed gedefinieerde set processen en procedures zijn. Elk proces en elke procedure moet scripts hebben om ervoor te zorgen dat elke stap uw team doorwerkt naar een snelle en veilige oplossing van een probleem. Houd rekening met het volgende overzicht om een strategie voor noodgevallen te ontwikkelen:

  • Vereisten
    • Een waarneembaar platform ontwikkelen
    • Een reactieplan voor incidenten maken
  • Incidentfasen
    • Detection
    • Containment
    • Sorteren
  • Fasen na incidenten
    • Hoofdoorzaakanalyse (RCA)
    • Postmortem
  • Lopende activiteit
    • Noodresponsanalyses

De volgende secties bevatten aanbevelingen voor elk van deze fasen.

Als u een robuuste strategie voor respons op noodgevallen wilt hebben, moet u een robuust waarneembaarheidsplatform hebben. Uw waarneembaarheidsplatform moet de volgende kenmerken hebben:

  • Holistische bewaking: zorg ervoor dat u uw workload grondig bewaakt vanuit het perspectief van een infrastructuur en toepassing.

  • Uitgebreide logboekregistratie: schakel uitgebreide logboekregistratie in voor uw onderdelen om u te helpen bij onderzoeken wanneer u een probleem opsoreert. Structureer logboeken zodat ze eenvoudig te beheren zijn. Automatisch logboeken verzenden naar gegevenssinks die moeten worden voorbereid voor analyse.

  • Handige dashboards: maak dashboards op basis van een statusmodel die zijn afgestemd op elk team in uw organisatie. Verschillende teams zijn verantwoordelijk voor verschillende aspecten van de workloadstatus.

  • Waarschuwingen waarvoor actie kan worden uitgevoerd: maak waarschuwingen die nuttig zijn voor uw workloadteams. Vermijd waarschuwingen waarvoor geen actie van uw teams is vereist. Te veel waarschuwingen van dit type kunnen ertoe leiden dat mensen waarschuwingsmeldingen negeren of blokkeren.

  • Automatische meldingen: zorg ervoor dat de juiste teams automatisch waarschuwingen ontvangen waarvoor actie van hen is vereist. Het ondersteuningsteam van tier-1 moet bijvoorbeeld meldingen ontvangen voor alle waarschuwingen, terwijl uw beveiligingstechnici alleen waarschuwingen voor beveiligingsgebeurtenissen moeten ontvangen.

Zie Aanbevelingen voor het ontwerpen en maken van een waarneembaarheidsframework voor meer informatie.

Een reactieplan voor incidenten maken

De basis van een strategie voor respons op noodgevallen is een plan voor incidentrespons. Net als een plan voor herstel na noodgevallen definieert u duidelijk en grondig rollen, verantwoordelijkheden en procedures voor een incidentresponsplan. Het plan moet een versiebeheerd document zijn dat onderhevig is aan regelmatige beoordelingen die ervoor zorgen dat het up-to-date is.

Definieer duidelijk de volgende onderdelen in uw plan.

Rollen

Identificeer een incidentresponsmanager. Deze persoon is eigenaar van het incident van initiatie tot herstel naar de hoofdoorzaakanalyse. Een incidentresponsmanager zorgt ervoor dat processen worden gevolgd en de juiste partijen worden geïnformeerd wanneer het antwoordteam hun werk uitvoert.

Identificeer een postmortemleider. Deze persoon zorgt ervoor dat postmortems kort nadat het incident is opgelost, worden uitgevoerd. Ze produceren een rapport, waarmee u de bevindingen kunt toepassen die uit het incident komen.

Processen en procedures

Uw workloadteam moet criteria voor noodgevallen definiëren en begrijpen. Wanneer uw team vaststelt dat een zaak ernstig is, kunt u een noodgeval declareren en het plan voor herstel na noodgevallen initiëren. In minder ernstige gevallen voldoet het probleem mogelijk niet aan de criteria van een noodgeval. Maar u moet nog steeds rekening houden met het probleem, wat het initiëren van het noodplan vereist. Noodgevallen kunnen problemen zijn die intern zijn voor uw workload, of ze kunnen het gevolg zijn van een probleem met een afhankelijkheid van uw workload. Het ondersteuningsteam moet kunnen bepalen of een probleem dat door externe gebruikers wordt gerapporteerd, voldoet aan de criteria voor noodgevallen, zelfs als ze geen inzicht hebben in het onderliggende probleem.

Communicatie- en escalatieplannen nauwkeurig definiëren. Op basis van het type waarschuwingsmelding dat ze ontvangen, moet u ervoor zorgen dat de ondersteuning van laag-1 eenvoudig contact kan opnemen met de juiste teams om problemen te escaleren. Zorg ervoor dat zij weten welk type communicatie geschikt is voor interne en externe partijen. Neem in communicatie- en escalatieplannen een lijst op met de planning en het personeel.

Neem in het algemene plan insluitings- en sorteerscripts op. Teams volgen deze stapsgewijze procedures wanneer ze hun insluitings- en sorteerfuncties uitvoeren. Neem een beschrijving op van wat een incidentsluiting definieert.

Andere items die moeten worden opgenomen

Documenteer alle standaardhulpprogramma's die worden gebruikt tijdens incidenten voor interne communicatie, zoals Microsoft Teams, en voor het bijhouden van de activiteiten tijdens het incident, zoals hulpprogramma's voor ticketing of planningshulpmiddelen voor achterstand.

Documenteer uw referenties voor noodgevallen, ook wel break-glass-accounts genoemd. Neem een stapsgewijze handleiding op waarin wordt beschreven hoe ze moeten worden gebruikt.

Maak drillinstructies voor noodgevallen en houd een record bij wanneer drills zijn uitgevoerd.

Documenteer wettelijke of wettelijke maatregelen die nodig zijn, bijvoorbeeld het doorgeven van gegevensschendingen.

Actie ondernemen op waarneembaarheidstriggers

Wanneer u een goed ontworpen waarneembaarheidsplatform hebt dat controleert op afwijkingen en er automatisch waarschuwingen op uitvoert, kunt u snel problemen detecteren en de ernst ervan bepalen. Als het probleem als noodgeval wordt beschouwd, kan het plan worden gestart. In sommige gevallen wordt het ondersteuningsteam niet op de hoogte gesteld via het waarneembaarheidsplatform. Klanten kunnen problemen melden voor ondersteuning met behulp van communicatiemiddelen van het ondersteuningsteam. Of ze kunnen contact opnemen met personen met wie ze regelmatig werken, zoals accountmanagers of VPs. Ongeacht hoe het ondersteuningsteam wordt gewaarschuwd, moeten ze altijd dezelfde stappen volgen om het probleem te valideren en de ernst te bepalen. Afwijking van het reactieplan kan stress en verwarring toevoegen.

Insluitingsprocedures definiëren

De eerste stap bij het oplossen van problemen is het probleem te bevatten om de rest van uw workload te beveiligen. Een insluitingsstrategie is afhankelijk van het type probleem, maar dit omvat meestal het verwijderen van het betreffende onderdeel uit de werkstroompaden. U kunt bijvoorbeeld een resource afsluiten of verwijderen uit netwerkrouteringspaden. Systeembeheerders, technici en senior ontwikkelaars moeten samenwerken om insluitingsstrategieën te ontwerpen. De insluiting moet de straalstraal van problemen beperken en de workloadfunctionaliteit in een gedegradeerde status behouden totdat het probleem is opgelost. Als een betrokken onderdeel toegankelijk moet zijn om triage uit te voeren, is het essentieel dat de toegang tot de rest van de workload wordt geblokkeerd. Zo veel mogelijk moet u alleen toegang krijgen tot het onderdeel via een pad dat is gescheiden van de werkbelasting en de rest van de systemen.

Triageprocedures definiëren

Nadat u het probleem hebt opgeslagen, kunt u beginnen met het classificeren van werk. De stappen die u tijdens de sortering volgt, zijn afhankelijk van het type probleem. Het team voor een bepaald gebied van workloadondersteuning moet procedures maken voor incidenten die zijn gerelateerd aan hun team. Beveiligingsteams moeten bijvoorbeeld beveiligingsproblemen classificeren en ze moeten scripts volgen die ze ontwikkelen. Het is belangrijk dat teams goed gedefinieerde scripts volgen tijdens het uitvoeren van hun triage-inspanningen. Deze scripts moeten stapsgewijze processen zijn die terugdraaiprocessen bevatten om wijzigingen ongedaan te maken die ineffectief zijn of andere problemen kunnen veroorzaken. Gebruik off-the-shelf logboekaggregatie- en analysehulpprogramma's om efficiënt problemen te onderzoeken waarvoor een grondige analyse is vereist. Nadat het probleem is opgelost, volgt u goed gedefinieerde processen om het betrokken onderdeel veilig terug te brengen in de werkstroompaden.

RCA-incidentrapporten genereren

De service level agreements (SLA's) voor uw klanten kunnen dicteren dat u RCA-rapporten moet uitgeven binnen een bepaalde periode nadat het incident is opgelost. De eigenaar van het incident moet de RCA-rapporten maken. Als dat niet mogelijk is, kan een andere persoon die nauw heeft samengewerkt met de eigenaar van het incident de RCA-rapporten maken. Deze strategie zorgt voor een nauwkeurige boekhouding van het incident. Organisaties hebben doorgaans een gedefinieerde RCA-sjabloon met richtlijnen over hoe informatie wordt gepresenteerd en welke soorten informatie wel of niet kunnen worden gedeeld. Als u uw eigen sjabloon en richtlijnen moet maken, moet u ervoor zorgen dat ze door belanghebbenden worden beoordeeld en goedgekeurd.

Incidentpostmortems bewaren

Een onpartijdig individu moet schuldloze postmortems leiden. In postmortemsessies deelt iedereen hun bevindingen van een incident. Elk team dat betrokken was bij de reactie op incidenten, moet worden vertegenwoordigd door personen die aan het incident hebben gewerkt. Deze personen moeten naar de sessie komen die is voorbereid met voorbeelden van de gebieden die succesvol waren en gebieden die kunnen worden verbeterd. De sessie is geen forum voor het toewijzen van de schuld voor het incident of problemen die mogelijk zijn opgetreden tijdens het antwoord. De leider van de postmortem moet de sessie verlaten met een duidelijke lijst met actie-items die zich richten op verbetering, zoals:

  • Verbeteringen in het responsplan. Processen of procedures moeten mogelijk opnieuw worden geëvalueerd en herschreven om de juiste acties beter vast te leggen.

  • Verbeteringen aan het waarneembaarheidsplatform. Drempelwaarden moeten mogelijk opnieuw worden geëvalueerd om het specifieke type incident eerder te kunnen ondervangen, of nieuwe bewaking moet mogelijk worden geïmplementeerd om het gedrag te ondervangen waarvoor geen rekening is gehouden.

  • Verbeteringen aan de workload. Het incident kan een beveiligingsprobleem in de workload blootstellen dat moet worden aangepakt als permanent herstel.

Overwegingen

Een te agressieve reactiestrategie kan leiden tot valse waarschuwingen of onnodige escalaties.

Op dezelfde manier kan het agressief implementeren van automatische schaalaanpassing of andere zelfherstelacties om te reageren op drempelwaardenschendingen leiden tot onnodige uitgaven en beheerlast. Mogelijk kent u niet de exacte drempelwaarden die moeten worden ingesteld voor waarschuwingen en automatische acties, zoals schalen. Voer tests uit in lagere omgevingen en in productie om u te helpen de juiste drempelwaarden voor uw vereisten te bepalen.

Azure-facilitering

Azure Monitor is een uitgebreide oplossing voor het verzamelen, analyseren en reageren op bewakingsgegevens uit cloud- en on-premises omgevingen. Het bevat een robuust waarschuwingsplatform dat u kunt configureren voor automatische meldingen en andere acties, zoals automatisch schalen en andere zelfherstelmechanismen.

Gebruik Monitor om machine learning te integreren. Automatiseer en optimaliseer incident triage en proactieve maatregelen. Zie AIOps en machine learning in Monitor voor meer informatie.

Log Analytics is een robuust analysehulpprogramma dat is ingebouwd in Monitor. U kunt Log Analytics gebruiken om query's uit te voeren op geaggregeerde logboeken en inzicht te krijgen in uw workload.

Microsoft biedt training voor incidentgereedheid in Verband met Azure. Zie Inleiding tot gereedheid en incidentgereedheid van Azure voor meer informatie.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid