ServiceNow-Incidents prüfen: ServiceNow

Diese Anleitung verbindet ServiceNow, damit kanman neue Incidents für die Services deines 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 bist du Owner oder Admin des Workspace, für Schritt 2 Owner oder Admin des Teams. Alle Mitglieder sehen die Reviews.

1. ServiceNow verbinden

1. Öffne die Workspace-Einstellungen, wähle Verbindungen und öffne ServiceNow.
2. Klicke auf ServiceNow verbinden und gib ein:
   • einen Namen für die Verbindung
   • die Instanz-URL, sie muss mit https:// beginnen
   • von wo kanman die Instanz erreicht: aus der kanman-Cloud oder über deinen Runner (in deinem Netz), wenn deine Instanz nur im Firmennetz erreichbar ist. Dein 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 dein Runner.
   • wie sich kanman anmeldet: als API-Benutzer mit Benutzer und Passwort, mit einem Token oder mit einer Variable auf dem Runner
   • den Namen des Secrets, das Passwort oder Token enthält, zum Beispiel SERVICENOW_PASSWORD
3. Das Passwort oder Token gibst du 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 deinen Runnern setzen. Wenn dein Team alles auf eigenen Runnern ausführt, setzt du stattdessen eine Variable mit diesem Namen in der Runner-Umgebung des Teams. kanman sieht sie dann nie.
4. Wähle unter Was kanman speichert:
   • Nur kanmans Review (Standard). Wird ServiceNow über den Runner gelesen, verlässt der Incident-Text dein Netz nie. kanman behält seinen Review, die Incident-Nummer und den Link zum Ticket.
   • Review und Incident-Auszüge. 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

kanman testet die Verbindung beim Speichern und jedes Mal, wenn du auf Verbindung testen klickst. Der Zustand der Verbindung zeigt dann, was der API-Benutzer kann:

• Incidents, Change Requests, Configuration Items und Zuweisungsgruppen lesen
• jedes Schreibrecht, das die Aktionen brauchen, etwa Arbeitsnotizen, aus den Rollen des Benutzers

Verwende einen Benutzer mit möglichst wenigen Rechten: Lesezugriff auf Incidents, Change Requests, Configuration Items (CMDB) und Zuweisungsgruppen. Eine Admin-Rolle braucht er nicht. Schreibrechte kommen nur für die Aktionen hinzu, die deine 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. Findet ein späterer Test weniger Rechte als zuvor, zeigt die Verbindung das an.

Weitere Einstellungen

Alle optional; sie beschreiben, wie deine Firma arbeitet, kanman nimmt nichts an:

• Wer Kommentare liest: wer in deiner Firma die „Additional comments“ eines Incidents sieht, die Anfragenden oder zuerst dein Service Desk. kanman schreibt seine Kommentare für diese Leser. Arbeitsnotizen bleiben immer intern.
• Gruppe für Change-Entwürfe: die Zuweisungsgruppe, deren Change Coordinator kanmans Change-Entwürfe bekommt. Leer: die Gruppe des Tickets.
• Weitere Felder des Change-Formulars: die Felder, die dein Change-Formular verlangt, mit dem Wert, den kanman setzt, zum Beispiel risk=3; cab_required=true. Felder, die einen Change weiterbewegen (Status, Genehmigung, Bearbeiter, Typ), setzt kanman nie.
• Geplantes Zeitfenster für Entwürfe: Tage im Voraus, Startzeit (UTC) und Stunden, zum Beispiel 2 06:00 2.
• Change-Freezes: Freezes, die deine Firma außerhalb von ServiceNow führt, zum Beispiel 11-01..01-07 Jahresend-Freeze (jedes Jahr). kanman liest außerdem einmal am Tag die Blackout-Schedules deines Change-Kalenders.
• Sicherheitskontakte: die E-Mail-Adressen der Personen, die kanman sofort informiert, wenn ein Ticket ein Sicherheitsvorfall sein könnte. Leer: die Owner und Admins des Workspace.

Team-Grenzen

Owner und Admins des Workspace können auf der Seite der Verbindung unter Aktionen 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 deinen Services zuordnen

Sobald der Test klappt, schlägt kanman dir diesen Schritt vor: Im Chat jedes deiner Teams, das die Verbindung noch nicht nutzt, liest kanman, welche Zuweisungsgruppen, Business Services und Configuration Items Tickets wie die des Teams bearbeiten (mit der Zahl der Tickets der letzten 30 Tage), und schlägt die Zuordnungen vor, die anzulegenden Services mit ihren Repositories und einen Test deiner Code-Host-Verbindung, falls sie noch einen braucht. Übernehmen übernimmt genau, was die Karte zeigt; danach siehst du dir die Vorschau an und schaltest ein. Du kannst auch alles selbst zuordnen:

Öffne das Team, klicke auf Team, wähle Verbindungen, öffne die Zeile Alarmquellen und dann ServiceNow. Die Services selbst beschreibt Services und Signalquellen.

1. Wähle die Verbindung.
2. Ordne deine eigenen Zuweisungsgruppen, Business Services und Configuration Items (CIs) den Services deines Teams zu. Such nach dem Namen und wähle die Einträge.
3. Optional: Beobachte eine Zuweisungsgruppe ohne Service. Incidents dieser Gruppe werden dann über ihr CI oder ihren Business Service zugeordnet.
4. Klicke auf Speichern.

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

Vorschau vor dem Einschalten

Klicke auf Vorschau. kanman zeigt die letzten fünf passenden Incidents und zu welchem Service jeder gehen würde. Den Feed kannst du erst nach einer Vorschau einschalten, du siehst 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 du eine Zuordnung mit einem Klick ergänzen kannst.

So läuft es

• kanman prüft alle ein bis zwei Minuten auf neue und aktualisierte Incidents.
• Der erste Tag ist nie still. Wenn du den Feed einschaltest, sieht sich kanman die letzten 30 Tage an: wie viele Tickets, wie viele offen sind, den Median bis zur Lösung und die häufigsten Configuration Items und Kategorien. Diese Zahlen postet kanman im Team-Chat und prüft sofort die zwei neuesten offenen Tickets (dafür wird niemand alarmiert). Danach prüft kanman jedes neue Ticket.
• Am ersten Tag schlägt kanman im Team-Chat außerdem eine Readiness-Checkliste für neue Tickets und ein paar Gewohnheiten vor, die zu deinem Team passen, zum Beispiel ein Briefing vor dem Daily deines Teams, eine Gewohnheit für Tickets mit Priorität 1 und eine für Change-Freezes. Nichts startet, bevor du zustimmst.
• Merkt kanman, dass etwas seine Reviews begrenzt (ein Service ohne Repositories, kein Error-Tracking oder keine Logs verbunden, kein Change-Kalender, ein wiederkehrendes Muster), schlägt kanman einmal die eine Verbindung oder Gewohnheit vor, die geholfen hätte, mit dem Ticket als Beispiel. Einen Vorschlag, den du abgelehnt hast, wiederholt kanman nicht.
• 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.

Change-Entwürfe füllen die Felder deines Change-Formulars aus den weiteren Einstellungen. Im Change-Freeze entwirft kanman den Change als Ausnahme mit Begründung, fragt immer, bevor etwas eingereicht wird, bietet keinen Standard-Change an und sagt das im Team-Chat.

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 findest du 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 deinem 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
• den Readiness-Check, wenn dein Team eine Readiness-Checkliste hat (ein Skill unter Team > Gedächtnis mit dem Namen ticket-readiness): jeder Punkt deiner Checkliste gegen das Ticket geprüft. Fehlende Punkte kommen in die Arbeitsnotiz und, wenn dein Team Kommentare erlaubt, in den Kommentar für die Anfragenden, in der Form, die deine Checkliste beschreibt. Die Checkliste änderst du wie jeden Skill, indem du es kanman im Chat sagst

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 dein Team erlaubt: Vorschläge, die auf Freigeben warten, und was kanman schon getan hat, jeweils mit einem Link zum Datensatz in ServiceNow.

Mögliche Sicherheitsvorfälle

Stellt der Review fest, dass ein Ticket ein Sicherheits- oder Datenschutzvorfall sein könnte, etwa offengelegte Zugangsdaten oder personenbezogene Daten oder unbefugter Zugriff, sagt die Karte das zuerst. kanman macht dort dann nichts von sich aus: Es schlägt höchstens die Arbeitsnotiz vor, reproduziert nichts und bietet keinen Fix an. Deine Sicherheitskontakte informiert kanman sofort, und den Review und die Zeitleiste sichert es als Nachweis.

Nachweis-Paket

Auf der Incident-Seite speichert Nachweis-Paket exportieren die Zeitleiste des Incidents, kanmans Review mit den Links zu den Belegen, alles, was in verbundenen Systemen vorgeschlagen und getan wurde (und wer es wann freigegeben hat), und die Audit-Einträge als eine Datei. Jeder Eintrag ist per Hash mit dem vorherigen verkettet, sodass jede spätere Änderung auffällt. Nutze es als Nachweis für dein Audit (zum Beispiel ISO/IEC 27001, Maßnahme 5.28) oder als Grundlage eines Major-Incident-Berichts.

Reproduktion

Liegt die wahrscheinliche Ursache im Code deines Teams, schreibt kanman einen Test, der so fehlschlägt wie der Incident, und lässt ihn in deiner 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 dein Team Fixes vorschlagen erlaubt.

Bewerte 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 du möchtest, kann ein ServiceNow-Admin Incidents an den Webhook einer ServiceNow-Signalquelle senden (Team > Verbindungen > Alarmquellen), statt dass kanman abfragt.