Kostenanomalien als Tickets – dem richtigen Team zugewiesen, bevor jemand Slack liest

Leiten Sie Anomalien als Jira-, Linear- oder GitHub-Issues an das Team weiter, dem die Ressource gehört – basierend auf Schweregrad, Abrechnungsbereich und Erkennungsmethode.

Die Anomalieerkennung hat kein Erkennungsproblem, sondern ein Zustellproblem. Der Detektor schlägt an, der Slack-Channel und der Posteingang laufen voll, und die Benachrichtigung erreicht alle, die sie abonniert haben. In einem kleinen Team funktioniert das. In einer Organisation, in der das Checkout-Team eine Gruppe von Abrechnungskonten verantwortet, das Datenplattform-Team eine andere und Platform Engineering für alles Kritische geradestehen muss, trifft dieselbe Benachrichtigung vierzig Personen – von denen achtunddreißig nichts daran ändern können. Nach ein paar Wochen wird der Channel stummgeschaltet. Und die beiden Personen, die den fehlkonfigurierten Zeitplan hätten korrigieren können, erfahren davon erst, wenn die Finanzabteilung nachfragt.

Threads bietet jetzt Automatisierungsregeln: Sie legen fest, welche Anomalien (oder Insights) zu welchem Team gehören und wohin deren Issues gehen sollen – und Cloud Intelligence™ legt den Thread im Backlog dieses Teams an, sobald eine passende Anomalie erkannt wird.

Das bekommen Sie

Eine Regel besteht aus Bedingungen und einem Ziel. Die Bedingungen sind die Eigenschaften der Anomalie selbst: Schweregrad, der Abrechnungsbereich, in dem sie erkannt wurde, ob sie aus Abrechnungsdaten oder aus der Echtzeitnutzung stammt, ihr Triage-Status, Labels/Tags usw. Das Ziel ist ein Projekt, Team oder Repository in einem Tracker (Jira, Linear oder GitHub) samt gewünschter zuständiger Person, Labels und Issue-Titel. So wird "jede kritische Anomalie" zu einem GitHub-Issue für Platform Engineering, "mittlere Anomalien in den Checkout-Abrechnungskonten" zu einem Jira-Ticket für das Checkout-Team und "Echtzeit-Anomalien in den Analytics-Projekten" zu einem Linear-Issue für das Datenplattform-Team. Niemand sonst wird alarmiert. Wer den Thread erhält, kann auch tatsächlich etwas ändern.

Sie können eine Regel vor der Aktivierung an aktuellen Anomalien testen – in der Vorschau wird nichts erstellt. Regeln werden von oben nach unten abgearbeitet, und die erste aktive Regel, die passt, übernimmt die Anomalie. Ziehen Sie daher die spezifischen Regeln über die allgemeinen. Eine Regel lässt sich pausieren, ohne sie zu löschen.

Die erste Regel, die auf eine Anomalie passt, erstellt deren primären Thread – mit denselben Belegen wie ein manuell erstellter Thread: was erkannt wurde, wo, wie hoch der beobachtete Wert im Vergleich zum erwarteten war, und ein Link zurück zum Kostenanstieg. Anomalien sind nicht statisch. Erfüllt eine spätere Revision derselben Anomalie weiterhin die Bedingungen, fügt die Regel dem bestehenden Issue einen Kommentar hinzu, statt ein zweites zu eröffnen – selbst wenn das Issue bereits geschlossen ist. Zuständige Person, Status und alles Weitere, was Ihre Engineers gesetzt haben, bleiben unangetastet. Jede Regeländerung wird als unveränderliche Revision gespeichert, und ein Run-Log zeigt, welche Regel ausgelöst hat, was sie erstellt hat und warum.

Wenn Jira, Linear oder GitHub Issues bereits für Threads angebunden ist, müssen Sie nichts Neues installieren. Automatisierung und manuelle Erstellung nutzen denselben Datensatz: Eröffnet eine Kollegin oder ein Kollege zuerst manuell einen Thread, erkennt die Regel das und erstellt kein Duplikat. Außerdem gibt es ein tägliches Erstellungslimit pro Konto, damit ein unruhiger Morgen kein Backlog überfluten kann.

Erste Schritte

1. Verbinden Sie Jira, Linear oder GitHub Issues, falls noch nicht geschehen.
2. Stellen Sie sicher, dass die Anomalieerkennung den für Sie relevanten Bereich abdeckt – einschließlich aller Zuordnungen, auf die Ihre Regeln reagieren sollen. Regeln sehen nur Anomalien, die der Detektor erzeugt.
3. Öffnen Sie Threads, wählen Sie "Thread automation" und erstellen Sie Ihre erste Regel.

Automatisierungsregeln stehen jedem Konto mit der Berechtigung "Thread Manager" zur Verfügung. Was uns jetzt am meisten interessiert: Wie verhalten sich Ihre Regeln über einen echten Monat voller Anomalien – welche haben ausgelöst, obwohl sie es nicht sollten, und welche Teams konnten Sie mit den verfügbaren Bedingungen noch nicht erreichen?