Incidenten volgen
Incidenten hebben een levenscyclus. Als u het meest effectief wilt reageren, moet u de evolutie van het incident zelf en de evolutie van uw reactie hierop kunnen volgen, vanaf het begin van die levenscyclus.
Evalueer wat u weet
Een goede manier om uw procedure voor het bijhouden van incidenten te evalueren met behulp van een specifiek incident is om uzelf een reeks vragen te stellen:
- Wanneer hoorde u voor het eerst van het probleem? Als het uw doel is om de tijd te verkorten die nodig is om te herstellen van incidenten, moet u beginnen met het vastleggen van informatie vanaf het moment waarop u van het probleem hoorde.
- Hoe kwam u achter het probleem? Heeft uw controlesysteem een waarschuwing gegeven over het incident? Hebt u er voor het eerst over gehoord via uw klanten, hetzij rechtstreeks of op sociale media?
- Als u alleen maar weet wat het probleem is, bent u de eerste die u moet weten? Als dat het geval is, wie moet u dan op de hoogte stellen? Als dat niet het geval is, wie is er dan nog meer op de hoogte van het probleem?
- Als anderen op de hoogte zijn, doen zij er dan ook iets aan? Gaat iedereen ervan uit dat iemand anders ernaar kijkt of heeft iemand al actie ondernomen om het probleem op te lossen?
- Hoe erg is het? We hebben mogelijk geen idee van ernst of impact, en er is geen plek voor ons om erachter te komen hoe slecht het probleem echt is en wie wordt beïnvloed.
Deze vragen kunnen lastig te beantwoorden zijn als er niets wordt bijgehouden.
Standaardiseren waar incidentgegevens worden bijgehouden
Er zijn veel mogelijke plaatsen waar u uw lijst met incidenten kunt bewaren en delen (actief of anderszins) en tevens alle actuele informatie over die incidenten. Dit kan net zo eenvoudig zijn als een gedeeld bestandsgebied met Word-documenten en zo complex als zeer complexe software en services voor het bijhouden van incidenten. Tussen deze twee extremen zijn ticketing- en werktraceringssystemen die u voor deze taak in gebruik kunt drukken. Welk systeem u kiest, is eigenlijk minder belangrijk dan hoe u het gebruikt. Ongeacht het systeem dat u gebruikt, iedereen die mogelijk verbinding heeft met incidenten (technici, klantondersteuning, beheer, public relations, juridische zaken, enzovoort) moet weten waar het systeem moet worden gevonden, hoe een incident moet worden gegenereerd en hoe u toegang krijgt tot de gegevens indien nodig. Het bijhouden van incidenten mislukt gegarandeerd als de personen die het ondersteunen het systeem niet kunnen bereiken als dat nodig is ('wat was de URL van ons systeem ook alweer?').
In deze module gebruiken we de functionaliteit van het werkitem van Azure DevOps voor ons voorbeeldsysteem voor bijhouden.
Een communicatiebrug maken
Als u enkele van de vragen in de voorgaande sectie Evalueert wat u kent en het proces voor het reageren op incidenten wilt starten, moet u een manier hebben om met anderen te communiceren over het incident. Idealiter is dit een soort "teamsamenwerking" elektronisch medium voor gesprekken, hoewel telefoonbruggen ook werken. Vergadergesprekken/telefoonbruggen hebben minder de voorkeur, omdat het moeilijker is om de incidentcommunicatie met terugwerkende kracht te controleren (vandaar de eerder genoemde rol 'Scribe').
Welk medium u ook kiest, u moet ervoor zorgen dat u een uniek kanaal maakt dat strikt beperkt is tot discussie over dit incident en niets anders. Het is belangrijk om niet ter zake doende gesprekken buiten dit kanaal te houden, omdat u de gegevens moet kunnen volgen en later analyseren in uw nacontrole.
In deze module gebruiken we Microsoft Teams als onze methode voor incidentcommunicatie.
De start voor het bijhouden van incidenten automatiseren
Laten we eens kijken naar de onderdelen die we tot nu toe bijeen hebben gevoegd. We hebben een:
- Rooster van de mensen die worden gebeld (en een rotatie die voor hen is gedefinieerd).
- Rol die we kunnen toewijzen aan de personen die aan een incident werken.
- Specifieke plaats waar we het incident gaan declareren en bijhouden.
- Uniek kanaal voor de mensen die aan dat incident werken om erover te communiceren.
U kunt en moet het maken en beheren van al deze dingen zo veel mogelijk automatiseren. Wanneer zich een urgent probleem voordoet, wilt u niet alle benodigde stappen voor het aangeven van een incident intrekken, de juiste mensen meebrengen in en het incident volgen. U wilt alleen maar de startknop hoeven in te drukken, zodat het probleem direct kan worden opgelost.
Logic Apps voor automatisering zonder code gebruiken
Een manier om uw eerste antwoord te automatiseren, is met behulp van Logic Apps, waarmee u de taak van het plannen, automatiseren en organiseren van taken, bedrijfsprocessen en werkstromen kunt vereenvoudigen.
Logic Apps is een Azure-cloudservice voor het bouwen van geïntegreerde oplossingen. Het maakt gebruik van connectoren voor het maken van geautomatiseerde werkstromen. Triggers starten de logische app wanneer een specifieke gebeurtenis optreedt of wanneer gegevens voldoen aan de opgegeven criteria. Vervolgens worden de bewerkingen door middel van acties uitgevoerd in de werkstroom van de logische app.
In ons voorbeeld gebruiken we de volgende logic App-connector s voor het bijhouden van incidenten:
- Azure Boards (een onderdeel van Azure DevOps), waarmee u problemen/incidenten kunt maken en bijhouden.
- Azure Storage, waar u informatie kunt opslaan en ophalen over wie er wordt aangeroepen, zodat u de juiste personen kunt toewijzen om op het incident te reageren. In ons voorbeeld gebruiken we Azure Table Storage omdat het een zeer eenvoudige sleutelwaardearchief biedt waarmee u eenvoudig een lijst met technici en hun status op oproep kunt opslaan.
- Microsoft Teams, die u kunt gebruiken om een nieuw, uniek incidentkanaal te maken om de gesprekken van technische teams in realtime bij te houden terwijl ze communiceren over specifieke incidenten. Hiermee kunt u de interacties met betrekking tot de tijdlijn van gebeurtenissen later behouden bij het uitvoeren van een incidentbeoordeling.
Laten we dit alles bijeenbrengen met een logische app. Bekijk eerst de volledige app, zoals weergegeven in logic apps Designer, waarna we deze stapsgewijs doorlopen.
De eerste stap is het verwerken van een trigger, die HTTP-aanvraag die we hebben vermeld. Er wordt een HTTP POST-aanvraag verzonden naar de logische app die een JSON-payload bevat met informatie over het incident dat we willen aangeven. We parseren die payload en sturen een bevestiging terug dat we deze hebben ontvangen:
Met deze informatie maken we een nieuw werkitem in onze Azure DevOps-organisatie dat dit incident vertegenwoordigt.
Vervolgens wordt er een nieuw Teams-kanaal voor het incident gemaakt:
Zodra het kanaal is gemaakt, wordt het werkitem dat we zojuist hebben gemaakt bijgewerkt met een koppeling naar het nieuwe kanaal. Hiermee behoudt u alle informatie op dezelfde plek (het werkitem) en kan men er later naar kijken om te weten waar men heen moet om aan het kanaal deel te nemen.
Nu is het tijd om de on-call persoon in de foto te brengen. We voeren een zoekopdracht uit in Azure Table Storage voor het e-mailadres van de technicus die wordt vermeld als on-call. Hiermee wordt een JSON-antwoord geretourneerd dat vervolgens wordt geparseerd.
Omdat onze query een lijst retourneert, moeten we elk item in die lijst herhalen als de volgende stap. We wijzen het werkitem aan de desbetreffende personen toe (ze zijn nu 'eigenaren' van het incident).
Vervolgens sturen we als laatste stap een bericht naar het Teams-kanaal met een aanwijzer terug naar het werkitem voor personen die deelnemen aan het kanaal en willen we weten waar de gezaghebbende informatie voor dat incident is opgeslagen.
Dat is slechts één voorbeeld van hoe we het instellen van de mechanismen voor incidenttracking en communicatie kunnen automatiseren. In de volgende les gaan we een beetje dieper in op aspecten van communicatie over een incident.