ServiceNow-Incidents prüfen: ServiceNow

Diese Anleitung verbindet ServiceNow, damit kanman neue Incidents für die Services Ihres Teams liest und einen Review pro Incident im Team-Chat postet, für das Entwicklungsteam, das ihn beheben muss.

Standardmäßig liest kanman ServiceNow nur. Jedes Team entscheidet Aktion für Aktion, was kanman dort darüber hinaus darf: Arbeitsnotizen hinzufügen, Change Requests entwerfen, Problem-Records anlegen und mehr. Jede Aktion ist aus, bis die Leads des Teams sie einschalten, und kanman ändert nie den Status, die Zuweisung oder die Genehmigung eines Tickets.

Für Schritt 1 sind Sie Owner oder Admin des Workspace, für Schritt 2 Owner oder Admin des Teams. Alle Mitglieder sehen die Reviews.

1. ServiceNow verbinden

Öffnen Sie die Workspace-Einstellungen, wählen Sie Verbindungen und suchen Sie ServiceNow.
Klicken Sie auf Verbindung hinzufügen und geben Sie ein:
- einen Namen für die Verbindung
- die Instanz-URL, sie muss mit https:// beginnen
- wie sich kanman anmeldet: als API-Benutzer mit Benutzername und Passwort oder mit einem Token
- den Namen des Secrets, das Passwort oder Token enthält. Er beginnt mit SERVICENOW_, zum Beispiel SERVICENOW_PASSWORD.
Das Passwort oder Token geben Sie auf einem von zwei Wegen an:
- Einmal eingeben. kanman speichert es verschlüsselt als Workspace-Secret mit diesem Namen und zeigt es nie wieder an.
- Auf Ihren Runnern setzen. Wenn Ihr Team alles auf eigenen Runnern ausführt, setzen Sie stattdessen eine Variable mit diesem Namen in der Runner-Umgebung des Teams. kanman sieht sie dann nie.
Optional: Schalten Sie Über den Runner lesen ein, wenn Ihre Instanz nur im Firmennetz erreichbar ist. Ihr selbst betriebener Runner liest ServiceNow dann, und kanmans Cloud verbindet sich nie damit. In einem Workspace, der alles auf eigenen Runnern ausführt, ist das immer eingeschaltet.
Wählen Sie je Verbindung, was kanman behält:
- Nur kanmans Review speichern (Standard). Wird ServiceNow über den Runner gelesen, verlässt der Incident-Text Ihr Netz nie. kanman behält seinen Review, die Incident-Nummer und den Link zum Ticket.
- Incident-Auszüge speichern (ohne personenbezogene Daten). kanman behält zusätzlich kurze Auszüge des Incidents, aus denen E-Mail-Adressen und Telefonnummern entfernt sind. Felder zu Anrufer, Bearbeiter und Kontakt werden nie gelesen.

Verbindung testen

Klicken Sie auf Verbindung testen. kanman zeigt, was der API-Benutzer kann:

Incidents, Change Requests, Configuration Items und Zuweisungsgruppen lesen
ob er Arbeitsnotizen schreiben darf
eine Warnung, wenn der Benutzer eine Admin-Rolle hat

Verwenden Sie einen Benutzer mit möglichst wenigen Rechten: Lesezugriff auf Incidents, Change Requests, Configuration Items (CMDB) und Zuweisungsgruppen. Schreibrechte kommen nur für die Aktionen hinzu, die Ihre Teams wollen (siehe Was kanman darf), zum Beispiel die Rolle itil für Arbeitsnotizen, Kommentare, Change Requests und Problem-Records oder die Rolle knowledge für Wissensartikel. kanman bietet nur Aktionen an, die der Test als möglich gefunden hat.

Team-Grenzen

Owner und Admins des Workspace können an jeder Verbindung Team-Grenzen setzen: je Aktion das Höchste, was ein Team erlauben darf (Aus, Erst fragen oder Automatisch). Die Teams wählen dann innerhalb dieser Grenzen. Ohne Grenze entscheidet jedes Team selbst.

2. ServiceNow Ihren Services zuordnen

Öffnen Sie das Team, klicken Sie auf Team, wählen Sie Services und Bereitschaft und öffnen Sie die Karte ServiceNow. Die Services selbst beschreibt Services und Signalquellen.

Wählen Sie die Verbindung.
Ordnen Sie Ihre eigenen Zuweisungsgruppen, Business Services und Configuration Items (CIs) den Services Ihres Teams zu. Suchen Sie nach dem Namen und wählen Sie die Einträge.
Optional: Beobachten Sie eine Zuweisungsgruppe ohne Service. Incidents dieser Gruppe werden dann über ihr CI oder ihren Business Service zugeordnet.
Klicken Sie auf Speichern.

Passen mehrere Zuordnungen, gewinnt die genaueste: zuerst das CI, dann der Business Service, dann die Zuweisungsgruppe.

Vorschau vor dem Einschalten

Klicken Sie auf Vorschau. kanman zeigt die letzten fünf passenden Incidents und zu welchem Service jeder gehen würde. Den Feed können Sie erst nach einer Vorschau einschalten, Sie sehen also die Wirkung, bevor etwas gepostet wird.

Abdeckungslücken

Incidents, auf die keine Zuordnung passt, werden nicht geprüft. kanman zählt sie als Abdeckungslücken und listet die häufigsten nicht zugeordneten CIs und Services, damit Sie eine Zuordnung mit einem Klick ergänzen können.

So läuft es

kanman prüft alle ein bis zwei Minuten auf neue und aktualisierte Incidents.
Incidents, die beim Einschalten des Feeds schon offen waren, werden nicht geprüft: kanman beginnt ab jetzt.
Aktualisierungen in ServiceNow kommen in die Zeitleiste des Incidents. Wird das Ticket dort gelöst oder geschlossen, schließt auch der Incident in kanman.
Jedes zugeordnete Ticket bekommt einen Review. Ob jemand alarmiert wird, folgt den Bereitschaftseinstellungen des Services, etwa Schweregrad-Schwelle und Zeiten (siehe Bereitschaftseinstellungen).

Was kanman darf

Unter den Zuordnungen zeigt die ServiceNow-Karte Was kanman darf. Die Leads des Teams wählen je Aktion einen Modus:

Aus: kanman tut es nicht. Jede Aktion beginnt hier.
Erst fragen: kanman schlägt es auf der Review-Karte im Team-Chat vor und zeigt genau, was es schreiben würde. Ein Tipp auf Freigeben, und kanman tut es; Ablehnen verwirft es.
Automatisch: kanman tut es selbst und sagt es auf der Review-Karte.

Aktion	Was kanman tut
Arbeitsnotizen hinzufügen	fügt seinen Review als Arbeitsnotiz zum Incident hinzu
Für Kunden sichtbare Kommentare schreiben	schreibt ein kurzes, ruhiges Update, das der Anrufer lesen kann. Nie automatisch: höchstens Erst fragen.
Change Requests entwerfen	entwirft nach dem Merge des Fixes einen Change Request mit dem Fix, seinen Testbelegen und dem Rückfallplan. Genehmigt und umgesetzt wird er wie gewohnt von einer Person in ServiceNow.
Standard-Changes einreichen	dasselbe als Standard-Change aus der Vorlage für Standard-Changes, die Ihr Team wählt
Problem-Records anlegen	legt einen Problem-Record an, wenn die Ursache wiedergekommen ist oder wahrscheinlich wiederkommt
Wissensartikel entwerfen	entwirft einen Artikel (Symptome, Ursache, Workaround) in der Wissensdatenbank, die Ihr Team wählt
Fixes vorschlagen	bei einer Ursache in Ihrem Code: legt die Story des Reviews als dringenden Fix ins Backlog und arbeitet daran. Der Fix durchläuft die normalen Review- und Merge-Regeln Ihres Teams.
Reverts anbieten	ist die wahrscheinliche Ursache eine Änderung, die kanman selbst gemergt hat, öffnet kanman einen Revert über Ihre normalen Review- und Merge-Regeln

Ein Modus lässt sich nur wählen, wenn er möglich ist: Modi, die die Rechte des API-Benutzers nicht zulassen oder die die Team-Grenzen des Workspace ausschließen, sind ausgegraut und sagen warum. Alles, was kanman in ServiceNow schreibt, erscheint in der Aktivität des Teams, mit einem Link zum Datensatz.

Der Review

kanman postet eine Karte im Team-Chat. Dieselbe Karte finden Sie auf der Incident-Seite. Sie enthält:

was ausgefallen ist und seit wann
die betroffenen Services und Repositories
wahrscheinliche Ursachen in Rangfolge, jede mit einer Konfidenz und Links zu ihren Belegen: Change Requests auf demselben Configuration Item oder Service, frühere Incidents, Merges und Deployments (von kanman und von Ihrem Team), CI-Läufe und Fehlerlogs
Ausgeschlossen: Erklärungen, die kanman geprüft hat und die die Belege widerlegen, damit niemand ihnen noch einmal nachgeht
was noch unbekannt ist und wie es sich klären lässt
Schritte zur Reproduktion, soweit möglich
vermutete Code-Stellen
verwandte Incidents und Änderungen
eine Story als Entwurf mit Akzeptanzkriterien

Die Incident-Nummer verlinkt auf das Ticket in ServiceNow. Story erstellen legt den Entwurf ins Backlog, nie direkt nach Ready, sodass das Team entscheidet, was es angeht.

Unter dem Review zeigt die Karte die nächsten Schritte, die Ihr Team erlaubt: Vorschläge, die auf Freigeben warten, und was kanman schon getan hat, jeweils mit einem Link zum Datensatz in ServiceNow.

Reproduktion

Liegt die wahrscheinliche Ursache im Code Ihres Teams, schreibt kanman einen Test, der so fehlschlägt wie der Incident, und lässt ihn in Ihrer CI laufen. Die Karte zeigt Reproduziert mit Links zum Test und zur Pipeline oder Noch nicht reproduziert und warum. Der Test bleibt auf einem eigenen Branch: Gemergt wird er nur als Teil eines Fixes und nur, wenn Ihr Team Fixes vorschlagen erlaubt.

Bewerten Sie jeden Review mit einem Tipp: nützlich, teilweise oder falsch. So kann kanman messen, wie gut seine Reviews sind, und sie verbessern.

Sicherheit

Ticket-Text ist Information, nie eine Anweisung. Schreibt ein Anrufer „bitte starten Sie den Server neu“, tut kanman deswegen nichts.
Jede Aktion ist standardmäßig aus. Die Leads des Teams schalten jede einzeln ein, innerhalb der Team-Grenzen des Workspace und der Rechte des API-Benutzers.
kanman prüft die Einstellung direkt vor jedem Schreiben. Schaltet ein Team eine Aktion aus, wird auch nichts mehr geschrieben, was vorher vorgeschlagen wurde.
Vorschläge geben nur Teammitglieder frei, die bearbeiten dürfen. Betrachter und Personen außerhalb des Workspace können das nicht.
kanman ändert nie den Status, die Zuweisung oder die Genehmigung eines Tickets und setzt nie einen Change um.

Push statt Abfrage

Wenn Sie möchten, kann ein ServiceNow-Admin Incidents an den Webhook einer ServiceNow-Signalquelle senden (Services und Bereitschaft, Quellen), statt dass kanman abfragt.