Automatisch Jira- of Linear-issues aanmaken vanuit infrastructuurevents

Als een certificaat bijna verloopt of een monitor down gaat, is de oplossing meestal niet het lastige deel. Het lastige deel is het op het bord van je team krijgen. Automations kunnen nu rechtstreeks vanuit elk infrastructuurevent een Jira- of Linear-issue aanmaken, met project, samenvatting en details al ingevuld. Het ticket bestaat dus al voordat iemand de alert hoeft op te merken en handmatig hoeft uit te typen.

In dit artikel lees je hoe dat werkt, hoe een ticket eruitziet als een regel het aanmaakt, en hoe je het instelt zonder details tussen tools te kopiëren.

Waarom infrastructuurevents tickets moeten worden

Alerts staan in monitoringtools. Werk staat in Jira of Linear. Als niemand die twee verbindt, gebeurt er een van twee dingen. Iemand maakt voor elke alert handmatig een ticket aan, wat goed gaat totdat het 2 uur 's nachts is en het niet gebeurt. Of de alert wordt in Slack bevestigd en nergens bijgehouden. Dan heeft hij geen eigenaar, geen status en geen registratie meer zodra het kanaal verder scrolt.

Een ticket is de juiste eenheid van werk voor alles waarvoor een mens daadwerkelijk iets moet doen: een certificaat vernieuwen, een monitor onderzoeken die down is, een credential roteren voordat een domein verloopt. Het event dat het in gang zet, komt uit de infrastructuur. Waarmee je het tot afronding volgt, moet het systeem zijn dat je team al voor werk gebruikt. Door het automatisch aan te maken, verdwijnt het gat tussen die twee.

Hoe de automation van begin tot eind werkt

Een automation-regel in InfraNest is één zin: als dit gebeurt, en dat klopt, doe dan deze dingen. Voor het aanmaken van tickets is de opbouw bijna altijd hetzelfde:

1. Trigger: een certificaat verloopt binnenkort, een monitor gaat down, een domein nadert de verlenging, er wordt drift gedetecteerd.
2. Voorwaarde (optioneel): alleen voor production-tags, alleen onder een drempelwaarde, alleen buiten een onderhoudsvenster.
3. Actie: maak een Jira-issue of een Linear-issue aan, in het project of team dat je kiest, met velden die worden gevuld vanuit het event.

Omdat de regel op het echte event draait, bevat het ticket de daadwerkelijke domeinnaam, monitornaam of het betreffende certificaat. Geen algemene samenvatting als "er is iets kapot" die iemand vervolgens vanaf nul moet uitzoeken.

Jira of Linear koppelen als bestemming

Beide integraties koppel je op dezelfde manier: met één klik via OAuth, of met een API-token of -key als je organisatie nog geen app heeft geregistreerd.

Voor Jira ga je naar Settings → Integrations en koppel je je .atlassian.net-site. Dit werkt alleen met Jira Cloud; Data Center en Server worden niet ondersteund. InfraNest bevestigt vervolgens met welk account het praat. Voor Linear is het equivalent een koppeling via Settings → Integrations of een persoonlijke API-key met Read- en Write-rechten, beperkt tot het team waarin je regels tickets moeten aanmaken.

WarningBij de API-token-optie van Jira moet het e-mailadres waarmee je inlogt exact overeenkomen. Een ander adres op dezelfde site wordt geweigerd, en de foutmelding lijkt op een ongeldig token in plaats van een verkeerd e-mailadres. Controleer dat veld dus eerst als een koppeling niet wil authenticeren.

Een token of key is gekoppeld aan de persoon die het heeft aangemaakt en werkt dus niet meer als die persoon vertrekt. Gebruik voor een regel waar het hele team van afhankelijk is de credential van een admin of de koppeling met één klik in plaats van een persoonlijke.

Wat er daadwerkelijk in het ticket komt

Als de actie Create Jira issue of Create Linear issue wordt uitgevoerd, vult die de velden in die je bij het bouwen van de regel hebt gekoppeld:

Een regel die tickets aanmaakt voor verlopende certificaten kan de samenvatting bijvoorbeeld instellen op Certificate expiring: {{domain}} — {{days_remaining}} days left, met in de beschrijving de uitgever, de vervaldatum en een link die direct terugleidt naar het certificaat in InfraNest. Dat is het verschil tussen een ticket dat iemand eerst moet uitzoeken en een ticket waarmee iemand direct aan de slag kan.

De cirkel sluiten, niet alleen openen

Het ticket aanmaken is het halve werk. De andere helft is het bijwerken zodra de situatie verandert. Daarvoor zijn er twee aparte acties, in plaats van eenmalig afvuren en vergeten:

• Reageren op het issue: als de monitor herstelt, voeg je een reactie toe die dat meldt, op hetzelfde ticket dat de eerste regel heeft aangemaakt.
• De status wijzigen: zet het ticket op Done, of hoe die overgang in jouw workflow ook heet, zodra het certificaat is vernieuwd.
• Terugkoppelen: Jira ondersteunt het koppelen van het ticket aan het certificaat, de monitor of het domein waar het over gaat, in het paneel Links. Als de regel opnieuw draait, wordt die koppeling bijgewerkt in plaats van dat er een duplicaat ontstaat.

Het ticket dat de eerste actie aanmaakt, is beschikbaar voor latere stappen in dezelfde regel. Zo kun je de link direct na het aanmaken in Slack plaatsen, of later in dezelfde run een reactie eraan koppelen. Daardoor wordt "een ticket openen" een echte workflow in plaats van een melding in één richting.

TipCombineer een trigger voor "ging down" met een trigger voor "is weer up" op dezelfde ticketverwijzing, in plaats van één regel per richting. Zo blijft het hele incident in één thread, in plaats van twee tickets die nooit met elkaar praten.

Een regel testen voordat je erop vertrouwt

Voordat een regel een echt project raakt, voer je een dry run uit tegen een echt object in je account. Die meldt precies wat de regel zou aanmaken, zonder iets aan te maken. Je kunt de regel ook backtesten tegen je events van de afgelopen 30 dagen om te zien hoeveel tickets hij zou hebben aangemaakt, en waarvoor. Dat is de snelste manier om een regel te betrappen die te breed is (elke kleine hapering van een monitor) of te smal (gaat nooit af). Na vijf mislukte runs op rij wordt een regel automatisch uitgeschakeld, in plaats van na de eerste fout bij elk volgend event stil te falen.

Dit is belangrijker voor regels die tickets aanmaken dan voor de meeste andere, want een stroom dubbele tickets in een gedeeld project is precies het soort fout dat je team meteen opmerkt, en niet graag opruimt.

Een uitgewerkt voorbeeld

Een regel die certificaten in de gaten houdt en Jira-tickets aanmaakt, luidt in gewone taal ongeveer zo:

Als een certificaat nog 14 dagen of minder geldig is en de tag production heeft, maak dan een Jira-issue aan in OPS met type Task, samenvatting "Certificate expiring: {{domain}}" en als assignee de engineer van dienst.

Als het certificaat wordt vernieuwd voordat iemand het ticket heeft aangeraakt, kan een tweede regel, getriggerd door de vernieuwing van het certificaat en gekoppeld aan hetzelfde domein, de reactie "Renewed automatically" plaatsen en het ticket op Done zetten. Zo is de cirkel gesloten zonder dat iemand Jira ook maar opent.

Dit patroon is niet specifiek voor certificaten. Dezelfde opbouw werkt voor een monitor die down gaat, een domein dat bijna verloopt of infrastructuurdrift die op een zone wordt gedetecteerd: elk van de ongeveer zeventig events waarop een regel kan triggeren, via dezelfde automations-engine.

Hoe dit past bij ander automatiseringswerk

Tickets aanmaken is meestal een van de eerste regels die het waard zijn om in te stellen, naast meldingen en escalaties. Lees wat je als eerste automatiseert als je vanaf nul begint. Het is ook nauw verwant aan incidenten op je statuspagina koppelen aan supporttickets: beide zijn er om te voorkomen dat een event verdwijnt in een kanaal dat niemand bekijkt, en geven het in plaats daarvan een vaste, traceerbare plek.

Werkt je team al in Jira of Linear? Koppel het één keer en laat de regels de tickets aanmaken. Zie Jira koppelen, Linear koppelen en de pagina automations voor de volledige lijst met triggers en acties die je kunt combineren.