Jira- oder Linear-Tickets automatisch aus Infrastruktur-Events erstellen

Wenn ein Zertifikat bald abläuft oder ein Monitor ausfällt, ist die Behebung meist nicht das Schwierige. Schwieriger ist es, das Problem überhaupt auf das Board deines Teams zu bekommen. Automationen können jetzt direkt aus jedem Infrastruktur-Event ein Jira- oder Linear-Issue erstellen, mit ausgefülltem Projekt, Titel und Details. So existiert das Ticket, bevor jemand den Alert bemerken und von Hand abtippen muss.

In diesem Beitrag erfährst du, wie das funktioniert, wie ein Ticket aussieht, das eine Regel erstellt hat, und wie du alles einrichtest, ohne Details zwischen Tools hin- und herzukopieren.

Warum aus Infrastruktur-Events Tickets werden sollten

Alerts leben in Monitoring-Tools. Die Arbeit lebt in Jira oder Linear. Wenn niemand die beiden verbindet, passiert eines von zwei Dingen: Jemand erstellt für jeden Alert manuell ein Ticket (klappt gut, bis es 2 Uhr nachts ist und es niemand tut), oder der Alert wird in Slack bestätigt und nirgends nachverfolgt. Dann hat er keinen Verantwortlichen, keinen Status und keinen Eintrag mehr, sobald der Channel weitergescrollt ist.

Ein Ticket ist die richtige Arbeitseinheit für alles, bei dem ein Mensch tatsächlich etwas tun muss: ein Zertifikat erneuern, einen ausgefallenen Monitor untersuchen, Zugangsdaten rotieren, bevor eine Domain ausläuft. Das auslösende Event stammt aus der Infrastruktur. Bis zum Abschluss verfolgt werden sollte es aber in dem Tool, das dein Team ohnehin für seine Arbeit nutzt. Das automatische Erstellen schließt die Lücke zwischen beiden.

So funktioniert die Automation von Anfang bis Ende

Eine Automationsregel in InfraNest besteht aus einem Satz: Wenn dies passiert und jenes zutrifft, tu Folgendes. Für das Erstellen von Tickets ist der Aufbau fast immer gleich:

1. Trigger: Ein Zertifikat läuft bald ab, ein Monitor fällt aus, eine Domain steht vor der Verlängerung, ein Drift wird erkannt.
2. Bedingung (optional): nur für Production-Tags, nur unterhalb eines Schwellenwerts, nur außerhalb eines Wartungsfensters.
3. Aktion: ein Jira-Issue oder Linear-Issue im Projekt oder Team deiner Wahl erstellen, mit Feldern, die aus dem Event befüllt werden.

Da die Regel auf dem echten Event läuft, enthält das Ticket den tatsächlichen Domainnamen, Monitornamen oder das betroffene Zertifikat. Es ist also keine generische „irgendwas ist kaputt“-Zusammenfassung, die jemand erst von Grund auf untersuchen muss.

Jira oder Linear als Ziel einrichten

Beide Integrationen werden auf die gleiche Weise verbunden: mit einem Klick per OAuth oder über ein API-Token bzw. einen API-Key, falls deine Organisation noch keine App registriert hat.

Für Jira gehst du zu Einstellungen → Integrationen und verbindest deine .atlassian.net-Site (nur Jira Cloud, Data Center und Server werden nicht unterstützt). InfraNest bestätigt dann, mit wessen Konto es kommuniziert. Für Linear ist das Pendant eine Verbindung unter Einstellungen → Integrationen oder ein persönlicher API-Key mit Lese- und Schreibzugriff, beschränkt auf das Team, in dem deine Regeln Tickets anlegen sollen.

WarningBei der API-Token-Option von Jira muss die E-Mail-Adresse, mit der du dich anmeldest, exakt übereinstimmen. Eine andere Adresse auf derselben Site wird abgelehnt, und die Fehlermeldung sieht nach einem falschen Token aus statt nach einer falschen E-Mail-Adresse. Prüf also zuerst dieses Feld, wenn sich eine Verbindung nicht authentifizieren lässt.

Ein Token oder Key ist an die Person gebunden, die es erstellt hat. Verlässt sie das Unternehmen, funktioniert es nicht mehr. Für eine Regel, auf die sich das ganze Team verlässt, solltest du daher die Zugangsdaten eines Admins oder die Ein-Klick-Verbindung nutzen statt persönlicher Zugangsdaten.

Was tatsächlich im Ticket landet

Wenn die Aktion Jira-Issue erstellen oder Linear-Issue erstellen ausgeführt wird, befüllt sie die Felder, die du beim Anlegen der Regel zugeordnet hast:

Eine Regel, die Tickets für ablaufende Zertifikate erstellt, könnte die Summary etwa auf Certificate expiring: {{domain}} — {{days_remaining}} days left setzen. Die Beschreibung enthält dann den Aussteller, das Ablaufdatum und einen direkten Link zurück zum Zertifikat in InfraNest. Genau das ist der Unterschied zwischen einem Ticket, das erst untersucht werden muss, und einem, das sich sofort abarbeiten lässt.

Den Kreis schließen, nicht nur öffnen

Das Ticket zu erstellen ist nur die halbe Arbeit. Die andere Hälfte ist, es zu aktualisieren, sobald sich die Lage ändert. Dafür gibt es eigene Aktionen statt eines einmaligen Fire-and-Forget:

• Issue kommentieren: Wenn der Monitor wieder läuft, wird ein entsprechender Kommentar hinzugefügt, und zwar im selben Ticket, das die erste Regel erstellt hat.
• Status ändern: Verschieb das Ticket auf Done oder wie auch immer dein Workflow diesen Übergang nennt, sobald das Zertifikat erneuert ist.
• Zurückverlinken: Jira unterstützt es, das Ticket im Links-Bereich mit dem betreffenden Zertifikat, Monitor oder der Domain zu verknüpfen. Läuft die Regel erneut, wird dieser Link aktualisiert, statt ein Duplikat anzulegen.

Das von der ersten Aktion erstellte Ticket steht späteren Schritten derselben Regel zur Verfügung. So kannst du seinen Link direkt nach dem Erstellen in Slack posten oder im selben Durchlauf später einen Kommentar anhängen. Erst dadurch wird aus „Ticket erstellen“ ein echter Workflow statt einer reinen Einwegbenachrichtigung.

TipKombiniere einen „ausgefallen“-Trigger und einen „wieder erreichbar“-Trigger mit derselben Ticket-Referenz, statt für jede Richtung eine eigene Regel anzulegen. So bleibt der gesamte Vorfall in einem Thread, statt in zwei Tickets, die nichts voneinander wissen.

Regel testen, bevor du dich auf sie verlässt

Bevor eine Regel ein echtes Projekt anfasst, führ einen Dry Run gegen ein echtes Objekt in deinem Konto aus. Er zeigt genau, was erstellt würde, ohne etwas zu erstellen. Du kannst die Regel außerdem per Backtest gegen die Events der letzten 30 Tage prüfen und sehen, wie viele Tickets sie zu welchen Themen erstellt hätte. Das ist der schnellste Weg, eine Regel zu erkennen, die zu weit gefasst ist (jeder kurze Monitor-Aussetzer) oder zu eng (löst nie aus). Nach fünf fehlgeschlagenen Durchläufen in Folge wird eine Regel automatisch deaktiviert, statt nach dem ersten Fehler bei jedem weiteren Event stillschweigend zu scheitern.

Bei Regeln, die Tickets erstellen, ist das wichtiger als bei den meisten anderen. Eine Flut doppelter Tickets in einem gemeinsamen Projekt ist genau die Art Fehler, die dein Team sofort bemerkt und nur ungern aufräumt.

Ein Praxisbeispiel

Eine Regel, die Zertifikate überwacht und Jira-Tickets erstellt, liest sich in Klartext etwa so:

Wenn ein Zertifikat noch 14 Tage oder weniger gültig ist und den Tag production hat, erstelle ein Jira-Issue in OPS mit dem Typ Task, der Summary "Certificate expiring: {{domain}}" und der diensthabenden Person aus der Rufbereitschaft als Assignee.

Wird das Zertifikat erneuert, bevor jemand das Ticket anfasst, kann eine zweite Regel, die bei der Zertifikatserneuerung auslöst und auf dieselbe Domain abgestimmt ist, „Automatisch erneuert“ kommentieren und das Ticket auf Done verschieben. Der Kreis schließt sich, ohne dass überhaupt jemand Jira öffnet.

Dieses Muster ist nicht auf Zertifikate beschränkt. Derselbe Aufbau funktioniert für einen ausgefallenen Monitor, eine bald ablaufende Domain oder einen in einer Zone erkannten Infrastruktur-Drift. Das gilt für jedes der rund siebzig Events, auf die eine Regel auslösen kann, über dieselbe Automations-Engine.

Wie sich das in andere Automationen einfügt

Das Erstellen von Tickets gehört meist zu den ersten Regeln, die sich einzurichten lohnen, neben Benachrichtigungen und Eskalationen. Wenn du bei null anfängst, lies was du zuerst automatisieren solltest. Eng verwandt ist auch das Verknüpfen von Statuspage-Vorfällen mit Support-Tickets: Beides soll verhindern, dass ein Event in einem Channel verschwindet, den niemand liest, und ihm stattdessen einen dauerhaften, nachverfolgbaren Platz geben.

Wenn dein Team ohnehin in Jira oder Linear arbeitet, verbinde es einmal und lass die Regeln die Tickets erstellen. Mehr dazu findest du unter Jira verbinden, Linear verbinden und auf der Seite zu Automations mit der vollständigen Liste der Trigger und Aktionen, die du kombinieren kannst.