Aanbevelingen voor het ontwerpen van een strategie voor noodhulp

  • Artikel

Is van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:

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 waarschuwingen te genereren waarvoor actie kan worden ondernomen om reacties op noodgevallen uit te voeren via dashboards en query's. Definieer duidelijk menselijke verantwoordelijkheden, zoals rotaties op oproep, incidentbeheer, toegang tot noodresources en het uitvoeren van postmortems.

In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een strategie voor noodhulp. Sommige problemen die zich voordoen in de loop van de levenscyclus van een workload, zijn essentieel genoeg om te rechtvaardigen dat deze noodsituaties worden aangegeven. U kunt nauw gecontroleerde 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. Noodsituaties verhogen op natuurlijke wijze de stressniveaus van iedereen en kunnen leiden tot een chaotische omgeving als uw team niet goed is voorbereid. 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 noodhulp moet een ordelijke, goed gedefinieerde set processen en procedures zijn. Elk proces en elke procedure moet scripts bevatten om ervoor te zorgen dat uw team met elke stap snel en veilig een probleem kan oplossen. Als u een strategie voor noodhulp wilt ontwikkelen, kunt u het volgende overzicht overwegen:

  • Vereisten
    • Een platform voor waarneembaarheid ontwikkelen
    • Een reactieplan voor incidenten maken
  • Incidentfasen
    • Detectie
    • Containment
    • Sorteren
  • Post-incidentfasen
    • Hoofdoorzaakanalyse (RCA)
    • Postmortem
  • Doorlopende activiteit
    • Oefeningen voor noodrespons

De volgende secties bevatten aanbevelingen voor elk van deze fasen.

Waarneembaarheid

Als u een robuuste strategie voor noodhulp wilt hebben, moet u beschikken over een robuust waarneembaarheidsplatform. Uw waarneembaarheidsplatform moet de volgende kenmerken hebben:

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

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

  • Nuttige 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 ondernomen: maak waarschuwingen die nuttig zijn voor uw workloadteams. Vermijd waarschuwingen waarvoor geen actie van uw teams nodig is. Te veel van dit soort waarschuwingen kan 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. Uw ondersteuningsteam op laag 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 framework voor waarneembaarheid voor meer informatie.

Plan voor reactie op incidenten

De basis van een strategie voor noodhulp is een plan voor het reageren op incidenten. Net als bij een noodherstelplan definieert u duidelijk en grondig rollen, verantwoordelijkheden en procedures voor een incidentresponsplan. Het plan moet een document met versiebeheer zijn dat regelmatig wordt gecontroleerd om ervoor te zorgen dat het up-to-date is.

Definieer duidelijk de volgende onderdelen in uw plan.

Rollen

Identificeer een manager voor incidentrespons. Deze persoon is eigenaar van het incident vanaf het starten tot het herstellen van de hoofdoorzaakanalyse. Een incidentresponsmanager zorgt ervoor dat processen worden gevolgd en dat de juiste partijen worden geïnformeerd wanneer het reactieteam hun werk uitvoert.

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

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 noodherstelplan initiëren. In minder ernstige gevallen voldoet het probleem mogelijk niet aan de criteria van een noodgeval. Maar u moet het probleem nog steeds beschouwen als een noodgeval, waarvoor het noodplan moet worden gestart. Noodsituaties kunnen problemen zijn die intern zijn voor uw workload of 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 gemeld, 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 uw laag-1-ondersteuning eenvoudig contact kan opnemen met de juiste teams om problemen te escaleren. Zorg ervoor dat ze weten welk type communicatie geschikt is voor interne en externe partijen. Neem in communicatie- en escalatieplannen een lijst op met de oproepplanning 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 op te nemen items

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

Documenteer uw referenties voor noodgevallen, ook wel bekend als break-glass-accounts. Voeg een stapsgewijze handleiding toe waarin wordt beschreven hoe ze moeten worden gebruikt.

Maak noodanalyse-instructies en houd bij wanneer er oefeningen zijn uitgevoerd.

Documenteer alle benodigde wettelijke of regelgevende maatregelen, bijvoorbeeld het melden van gegevensschendingen.

Incidentdetectie

Wanneer u een goed ontworpen waarneembaarheidsplatform hebt dat controleert op afwijkingen en er automatisch waarschuwingen op geeft, kunt u snel problemen detecteren en de ernst bepalen. Als het probleem als een 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 aan de ondersteuning via communicatiemiddelen van het ondersteuningsteam. Of ze kunnen contact opnemen met personen met wie ze regelmatig samenwerken, zoals accountmanagers of VM's. Ongeacht hoe het ondersteuningsteam op de hoogte wordt gesteld, moeten ze altijd dezelfde stappen volgen om het probleem te valideren en de ernst te bepalen. Afwijking van het responsplan kan stress en verwarring veroorzaken.

Containment

De eerste stap bij het oplossen van het probleem is om het probleem op te slaan om de rest van uw workload te beveiligen. Een insluitingsstrategie is afhankelijk van het type probleem, maar meestal gaat het om het verwijderen van het betrokken onderdeel uit de paden van de workloadstroom. 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 straal van problemen beperken en de workloadfunctionaliteit in een gedegradeerde status houden totdat het probleem is opgelost. Als een betrokken onderdeel toegankelijk moet zijn om sortering uit te voeren, is het essentieel dat de toegang tot de rest van de workload wordt geblokkeerd. U moet het onderdeel zoveel mogelijk alleen openen via een pad dat is gescheiden van de workload en de rest van de systemen.

Sorteren

Nadat u het probleem hebt opgelost, kunt u beginnen met sorteren. De stappen die u tijdens het sorteren volgt, zijn afhankelijk van het type probleem. Het team voor een bepaald gebied van workloadondersteuning moet procedures maken voor incidenten die gerelateerd zijn aan hun team. Beveiligingsteams moeten bijvoorbeeld beveiligingsproblemen sorteren en scripts volgen die ze ontwikkelen. Het is belangrijk dat teams goed gedefinieerde scripts volgen tijdens het uitvoeren van hun sorteringsinspanningen. Deze scripts moeten stapsgewijze processen zijn die terugdraaiprocessen bevatten om wijzigingen ongedaan te maken die niet effectief zijn of andere problemen kunnen veroorzaken. Gebruik standaardhulpprogramma's voor logboekaggregatie en analyse 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 naar de paden van de workloadstroom.

RCA-rapportage

De service level agreements (SLA's) voor uw klanten kunnen bepalen 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 al dan niet kunnen worden gedeeld. Als u uw eigen sjabloon en richtlijnen wilt maken, moet u ervoor zorgen dat deze worden beoordeeld en goedgekeurd door belanghebbenden.

Incidentpostmortems

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

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

  • Verbeteringen aan het platform voor waarneembaarheid. Drempelwaarden moeten mogelijk opnieuw worden geëvalueerd om het specifieke type incident eerder te ondervangen, of er moet mogelijk nieuwe bewaking worden geïmplementeerd om gedrag te ondervangen dat niet is verwerkt.

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

Overwegingen

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

Op dezelfde manier kan het agressief implementeren van automatisch schalen of andere zelfherstelacties om te reageren op drempelwaarden leiden tot onnodige uitgaven en beheerlast. Mogelijk weet u niet precies welke drempelwaarden u moet instellen 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 mechanismen voor zelfherstel.

Gebruik Monitor om machine learning te integreren. Automatiseer en optimaliseer incidentsorage 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 azure-gerelateerde training voor incidentgereedheid. Zie Inleiding tot azure-incidentgereedheid en Incidentgereedheid voor meer informatie.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid