NexTool Solutions

SLA und OLA in GLPI zu konfigurieren ist der einfache Teil - was im echten Betrieb scheitert, ist die Eskalation, die nie auslöst. Im Support von GLPI-Umgebungen unserer Kunden lautet die häufigste Anfrage nicht "wie erstelle ich ein SLA", sondern "ich habe alles eingerichtet, und niemand wird benachrichtigt, wenn die Frist überschritten wird". Dieser Leitfaden konfiguriert SLA und OLA in GLPI 11 von Grund auf und zeigt die SQL-Abfragen, mit denen wir diagnostizieren, warum die Fristen keine Benachrichtigung auslösen.

SLA vs. OLA: Was sich in der Praxis unterscheidet

SLA (Service Level Agreement) ist die Vereinbarung mit dem (internen oder externen) Kunden: Sie definiert die Zusage für Reaktions- und Lösungszeit. Beispiel: "Tickets mit hoher Priorität werden innerhalb von 1 h beantwortet und innerhalb von 4 h gelöst".

OLA (Operational Level Agreement) ist die interne Vereinbarung zwischen den Teams, die dieses SLA tragen. Beispiel: "Die Infrastruktur beantwortet Eskalationen aus dem 1st Level innerhalb von 30 Minuten". In GLPI speichert ein SLA die Fristen in time_to_own und time_to_resolve des Tickets; ein OLA speichert sie in internal_time_to_own und internal_time_to_resolve. Beide laufen parallel - und hier liegt die erste Verwechslung: Eine Eskalation an den 2nd Level hält das SLA des Kunden NICHT an.

Wie GLPI SLA und OLA intern modelliert

Wer das Datenmodell versteht, vermeidet die meisten Konfigurationsfehler. In GLPI sind SLA und OLA keine losen Objekte: Sie leben innerhalb eines SLM (Service Level), und es ist ein SLM, welches den Kalender trägt.

• SLM (glpi_slms): der Überbau. Er hat die calendars_id - der Kalender gehört also zum SLM, nicht zu jedem einzelnen SLA.
• SLA (glpi_slas) und OLA (glpi_olas): Jede Zeile ist eine Frist, mit type (TTO oder TTR), number_time und definition_time (minute / hour / day).
• Eskalationsstufen (glpi_slalevels / glpi_olalevels): die Aktionen, die bei X % der Frist ausgelöst werden.

Zwei Konzepte, die Umsteiger von anderen Werkzeugen oft verwirren:

TTO - Time to Own (Reaktionszeit)

Frist, bis ein Ticket "berücksichtigt" (von einem Techniker übernommen) wird. Achtung: Die TTO endet nicht, wenn jemand ein Ticket nur auf dem Bildschirm öffnet; sie endet mit der ersten Zuweisung oder der ersten Folgeaktion - genau diesen Wert speichert GLPI in takeintoaccount_delay_stat.

TTR - Time to Resolve (Lösungszeit)

Frist bis zur Lösung eines Tickets.

Schritt für Schritt: SLA in GLPI 11 konfigurieren

1. Zuerst der Kalender. Definieren Sie vor dem SLA den Servicekalender (Einrichtung > Kalender) mit den tatsächlichen Arbeitszeitsegmenten (z. B. Mo-Fr, 08:00-18:00). Bleibt ein SLM ohne Kalender (calendars_id = 0), zählt GLPI durchgehend 24 h; mit Kalender zählt es nur Arbeitsstunden.
2. Erstellen Sie den SLM und verknüpfen Sie den Kalender. Er ist der Container, der die SLAs und OLAs des Dienstes bündelt.
3. Erstellen Sie ein SLA pro Priorität, eines für TTO und eines für TTR. Nutzen Sie die folgende Matrix als Ausgangspunkt.
4. Weisen Sie sie per Geschäftsregel zu (Verwaltung > Regeln > Geschäftsregeln für Tickets): Kriterium Priorität = Hoch, Aktion "SLA zuweisen (TTR)" und "SLA zuweisen (TTO)". Ein SLA wird bei der Erstellung angewendet; ändert sich die Priorität später, braucht es eine Regel, die neu berechnet.
5. Konfigurieren Sie die Eskalationsstufen in jedem SLA (Aktionen bei 75 %, 100 % und 150 % der Frist).

Dies sind ehrliche Richtwerte für den Start: Kalibrieren Sie sie nach 60-90 Tagen mit den echten Zahlen Ihres Service Desk neu und übernehmen Sie niemals die Fristen eines anderen Kunden.

OLA konfigurieren

Ein OLA folgt derselben Struktur (TTO/TTR plus Eskalationsstufen), misst aber die interne Zusage zwischen Teams. Das typische Szenario: Wenn der 1st Level an den 2nd Level eskaliert, beginnt das OLA des 2nd Level zu laufen - und GLPI speichert diese Fristen in internal_time_to_own und internal_time_to_resolve, getrennt vom SLA des Kunden. Noch einmal der Punkt, der die meisten Fragen aufwirft: Ein OLA friert ein SLA nicht ein.

Der häufige Fehler: die Eskalation, die nie auslöst

Im Support ist die wiederkehrende Anfrage zum SLA keine Konfigurationsfrage - sie lautet "die Frist wurde überschritten, und niemand wurde benachrichtigt". In fast allen Fällen ist die Ursache dieselbe: Die automatische Aktion slaticket, welche die Eskalationsstufen abarbeitet, läuft im internen Modus (sie läuft nur, wenn jemand in GLPI navigiert), oder der externe GLPI-Cron ist nicht aktiv. Die Stufe existiert, die Frist ist in time_to_resolve gespeichert, aber bei 75 % passiert nichts, weil der Prozess, der die Stufen liest, nie ausgeführt wird. Deshalb steht in unserer Implementierungs-Checkliste die Prüfung von slaticket VOR der Erstellung jeder Eskalationsstufe.

Stellen Sie sicher, dass der GLPI-Cron im externen Modus läuft:

# /etc/cron.d/glpi - runs GLPI's automatic actions (including slaticket)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Prüfen Sie anschließend in der Datenbank, ob die Aktion aktiv ist und im externen Modus läuft:

-- State of the SLA escalation automatic action.
-- mode:  1 = internal (bad, depends on browsing), 2 = external (correct)
-- state: 1 = waiting, 2 = running, 0 = disabled
SELECT name, state, mode, lastrun, frequency
FROM glpi_crontasks
WHERE name = 'slaticket';

Und die Abfrage, die im Support-Alltag läuft: Tickets mit bereits überschrittener Lösungsfrist, die noch offen sind.

-- Tickets with an overdue TTR that are not yet solved.
-- status: 5 = solved, 6 = closed (excluded)
SELECT t.id, t.name, t.time_to_resolve, t.status
FROM glpi_tickets t
WHERE t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()
  AND t.status NOT IN (5, 6)
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Zur Prüfung der Konfiguration (und um einen SLM ohne Kalender zu finden, bevor er die Fristen verfälscht):

-- Configured SLAs and the calendar inherited from the SLM.
-- NULL/empty calendar = 24h straight counting (the classic trap).
SELECT s.name AS sla,
       CASE s.type WHEN 1 THEN 'TTO' WHEN 0 THEN 'TTR' END AS type,
       s.number_time, s.definition_time,
       cal.name AS calendar
FROM glpi_slas s
JOIN glpi_slms slm ON slm.id = s.slms_id
LEFT JOIN glpi_calendars cal ON cal.id = slm.calendars_id
ORDER BY s.name;

Bewährte Praktiken aus dem Betrieb

• Beginnen Sie mit 3-5 Stufen und kalibrieren Sie nach 60-90 Tagen mit echten Daten neu.
• Realistischer Kalender: Konfigurieren Sie kein 24x7, wenn das Team zu Geschäftszeiten arbeitet - sonst "läuft" die Frist nachts, und ein Ticket ist schon bei der Erstellung überfällig.
• Warnen Sie vor der Verletzung (75 %), um Zeit zum Reagieren zu geben, nicht erst bei der Verletzung.
• Bearbeiten Sie Status oder Fristen niemals massenhaft per SQL: Damit umgehen Sie die Neuberechnung der Wartezeit (sla_waiting_duration), und die Frist wird falsch.
• Dokumentieren Sie, welche Geschäftsregel welches SLA zuweist - eine verwaiste Regel ist die zweithäufigste Ursache für "SLA nicht angewendet".

Nächster Schritt

Sobald SLA und OLA laufen, bauen Sie den Servicekatalog auf und verfolgen Sie die KPIs des Service Desk, um zu sehen, ob die Fristen realistisch sind.

Wenn Ihr Betrieb bereits gewachsen ist und das SLA jede Woche zur Diskussion wird, übernimmt der GLPI-Support von NexTool die Konfiguration, den Cron und die Überwachung der Fristen für Sie.

Geprüft vom Team von NexTool Solutions.