So verbesserst du deinen IT-Support-Workflow
IT-Support nach dem DevOps-Ansatz
Die Einführung von DevOps-Prinzipien in IT-Service- und -Entwicklungsteams verbessert nachweislich die Servicequalität, die Teammoral, die Problemlösung und die Unternehmensproduktivität. Unternehmen, die DevOps-Prinzipien anwenden, verzeichnen nach eigenen Angaben durchschnittlich eine um 45 % höhere Kundenzufriedenheit, eine um 43 % höhere Mitarbeiterproduktivität, eine um 41 % verringerte Fehlerquote und eine Senkung der IT-Kosten um 38 %.
Laut Statistiken wie diesen ist die Integration von DevOps-Prinzipien in das IT-Servicemanagement ein großer Gewinn für Unternehmen. Es kann aber auch nach einer komplizierten Veränderung für Teams klingen. Die gute Nachricht? Es ist nicht so kompliziert wie es scheint. Die Schlüsselfaktoren für leistungsstärkere Services sind überraschend einfach.
Was ist DevOps?
Was genau ist DevOps? Es handelt sich um eine Reihe von Praktiken, die zwei häufig strikt getrennte Teams zusammenführen, die immer wieder miteinander im Clinch liegen: Entwicklung und Operations. Das Ziel ist Zusammenarbeit, offene Kommunikation und die Suche nach Möglichkeiten, wie beide Abteilungen ihre jeweiligen Ziele erreichen können.
Unsere Experten erklären es folgendermaßen: "DevOps bezeichnet eine Reihe von Praktiken, die zur Automatisierung der Prozesse zwischen Softwareentwickler- und IT-Teams beitragen. Ziel sind schnellere und zuverlässigere Entwicklungs-, Test- und Release-Verfahren. Die Grundlage für das DevOps-Konzept ist eine Unternehmenskultur der Zusammenarbeit zwischen Teams, die früher relativ isoliert voneinander gearbeitet haben. Zu den versprochenen Vorteilen zählen stärkeres Vertrauen, schnellere Software-Releases, eine raschere Behebung kritischer Fehler und ein verbessertes Management ungeplanter Aufgaben."
Warum DevOps für den IT-Support das Richtige ist
Aus geschäftlicher Sicht sprechen die Zahlen für sich: Die Kundenzufriedenheit steigt um 45 %, die Mitarbeiterproduktivität um 43 % und IT-Kosten werden um 38 % reduziert. Die DevOps-Bewegung hat Unternehmensergebnisse erheblich verbessert. Das ist wahrscheinlich der Grund dafür, dass vier von fünf Unternehmen angeben, zumindest einige DevOps-Prinzipien anzuwenden.
Wenn DevOps richtig umgesetzt wird, steigt die Zufriedenheit von Mitarbeitern und Teams, die Zusammenarbeit wird verbessert und die Anerkennung von Leistung wird gefördert. DevOps reduziert Reibungspunkte in Prozessen, beschleunigt Aufgaben und beseitigt bürokratische Hürden, die lange Zeit für Spannungen zwischen IT, Entwicklung und angrenzenden Teams sorgten.
Wo Operations-Teams häufig frustriert waren, wenn neue Releases veröffentlicht wurden, von denen sie nichts wussten und auf die sie nicht vorbereitet waren (worauf laut Gartner 85 - 87 % der Vorfälle zurückzuführen sind), verbessert DevOps die Kommunikation und bereitet die IT-Operations auf kommende Dinge vor. Wo Entwicklerteams in der Vergangenheit frustriert waren, weil das Operations-Team die Einführung neuer Features verlangsamte, können Teams jetzt Einführungen in Zusammenarbeit beschleunigen, ohne SLA-Versprechen und SLO-Ziele zu gefährden.
DevOps für den IT-Service: Best Practices
Kulturellen Wandel priorisieren
Die größte Herausforderung der DevOps-Integration ist der kulturelle Wandel.
In traditionellen IT-Unternehmen gibt es häufig Teamsilos: Das Entwicklerteam arbeitet in seinem eigenen Ökosystem und das Operations-Team übernimmt, sobald eine Änderung eingeführt wurde – wobei es im Vorfeld oft nicht oder nur eingeschränkt über Systemänderungen informiert wird.
DevOps-Unternehmen hingegen priorisieren Zusammenarbeit und teamübergreifende Kommunikation (durch Praktiken und Tools wie Hack Days, Stand-ups und Chatrooms).
Diese Änderung anzunehmen bedeutet, neuen Tools, neuen Prozessen und einer gewandelten Unternehmenskultur positiv gegenüberzustehen, die teamübergreifende Kommunikation und den gemeinsamen Erfolg priorisiert.
Automatisiere, wo immer dies möglich ist
Die Produktivitätssteigerungen von DevOps beruhen zumindest teilweise auf einer Philosophie, die der Automatisierung Priorität einräumt. DevOps anzunehmen bedeutet, dass sich Teams ständig die Frage stellen sollten: Wo können wir automatisieren?
Können wir die Code-Prüfung auf gängige Fehler automatisieren? Können wir Systeme automatisieren, um zwischen Problemen, Vorfällen und Anfragen einerseits und Änderungen oder Releases andererseits Zusammenhänge herzustellen und so mögliche Ursachen zu finden? Können wir Kontrollen automatisieren, die uns davon abhalten, Code zu veröffentlichen, der die sicherheitsbezogenen oder gesetzlichen Anforderungen nicht erfüllt? Können wir Systeme automatisieren, um neue Releases einzufrieren, wenn wir unseren SLO-Zielen gefährlich nahe sind?
Es gibt Dutzende von Möglichkeiten, DevOps-Metriken zu automatisieren und zu verbessern. Drei der häufigsten sind:
- Workflow (z. B. schnelleres Verschieben von Supporttickets durch den Servicedesk)
- Wissen (wenn ein Vorfall eintritt, sollte dein Servicemanagement-Tool automatisch relevantes Wissen und Dokumentationen anzeigen)
- Eskalation (wenn es in deinem Unternehmen nur zwei Personen gibt, die ein Problem lösen können, sollte ein intelligentes System es direkt an sie eskalieren, anstatt starren, linearen Eskalationspfaden zu folgen)
Wichtige Metriken verfolgen
Als gute Praktik bei der Zusammenarbeit von Entwicklung und IT-Operations gilt, dass der Fortschritt auch entsprechend verfolgt wird.
Zu den gängigen KPIs (Key Performance Indicators) für DevOps zählen MTBF (durchschnittliche Zeit zwischen Ausfällen), MTTR (durchschnittliche Zeit bis zur Wiederherstellung, Reparatur, Reaktion oder Lösung), MTTF (durchschnittliche Zeit bis zum Ausfall) und MTTA (durchschnittliche Zeit bis zur Bestätigung). Viele Unternehmen verwenden auch Zahlen wie die Anzahl der Warnungen oder Anfragen, die in einem bestimmten Zeitraum generiert wurden, die Ausfallkosten pro Minute oder die Kosten für Support pro Anruf/Anfrage.
Die Metriken, die deine Teams verfolgen müssen, hängen von den Teams selbst, den Versprechen an Kunden in deinen SLA-Vereinbarungen, den SLO-Zielen, die du mit dem Unternehmen vereinbart hast, und allen spezifischen Problembereichen ab, für die du zuständig bist. Metriken können sich außerdem auch wandeln. Wenn es zu Veränderungen innerhalb des Unternehmens kommt (etwa bei den Produkten, die die IT unterstützt, den Anforderungen der Stakeholder oder den externen rechtlichen oder sicherheitsbezogenen Verpflichtungen), müssen möglicherweise auch die verfolgten Metriken und die Art der Verfolgung angepasst werden.
Teilen priorisieren
Bei DevOps geht es darum, die Lücke zwischen Erstellung und Wartung, Erstellern und Unterstützern zu schließen. Es geht darum, gemeinsame Ansichten, Ziele, Prozesse und Begriffe zu entwickeln. Es geht um den Austausch von Wissen und Kommunikation. Es geht um gemeinsam genutzte Toolsets, Ressourcen und Codebasen. Und was vielleicht am wichtigsten ist: Es geht um eine gemeinsame Zuständigkeit, was gemeinsame Verantwortung und gemeinsame Erfolge bedeutet.
Viele traditionelle Unternehmen müssen im Rahmen der Umstellung auf DevOps überdenken, wie diese gemeinsamen Verantwortlichkeiten und Erfolge definiert, anerkannt und verfolgt werden können. Stehen die Ziele der Entwickler- und IT-Operations-Teams im Widerspruch zueinander? Erschwert der Erfolg des einen Teams den Erfolg des anderen?
Wenn das Entwicklerteam z. B. die Aufgabe hat, so schnell wie möglich neue Funktionen einzuführen, und das IT-Operations-Team dafür zuständig ist, die Verfügbarkeit aufrechtzuerhalten, könnten sich diese beiden Ziele negativ aufeinander auswirken. Das Operations-Team möchte die Entwicklung möglicherweise verlangsamen, um die Verfügbarkeitsziele zu erfüllen. Das Entwicklerteam dagegen lastet es dem Operations-Team an, seine Einführungsziele nicht erfüllen zu können.
Die Lösung für viele DevOps-Teams ist ein SRE-Ansatz, nach dem Entwicklerteams beliebig viele Neuerungen einführen können, solange die Verfügbarkeit innerhalb der SLO-Ziele liegt. Und wenn die Betriebszeit auf ein inakzeptables Niveau sinkt, werden alle Veröffentlichungen eingefroren, bis die Teams in Zusammenarbeit wieder eine akzeptable Verfügbarkeit erreichen.
ITIL im Vergleich zu DevOps
Wenn du den ITIL-Prinzipen folgst, fragst du dich vielleicht, wie DevOps ins Bild passt. In vielen Unternehmen können ITIL- und DevOps-Praktiken kombiniert werden. Wir hier bei Atlassian beobachten, dass viele Unternehmen die Vorteile und Stärken beider Systeme nutzen.
In diesem Artikel mit einer Gegenüberstellung von DevOps und ITIL wird folgendes erklärt: "Wir brauchen beides. Wir sprechen von sich ergänzenden und nicht konkurrierenden Konzepten. Wir müssen in der Lage sein, intelligenter und schneller zu arbeiten, aber wir brauchen auch noch Prozesse und Kontrolle. Moderne, leistungsstarke Teams und Unternehmen realisieren das langsam und verwenden Elemente aus beiden Ansätzen. Sie haben verstanden, dass es keine Entweder-oder-Frage ist".
ITIL liefert eher Best Practices für Operations, Support, Governance und andere zentrale Geschäftsfunktionen. DevOps bietet Ansätze wie Continuous Delivery, eine Kultur ohne Schuldzuweisungen, Zusammenarbeitstools und agile Praktiken, mit denen die längst in die ITIL-Leitlinien integrierten Praktiken verbessert und erweitert werden können.
Tools für DevOps-orientierte Unternehmen
Die Einführung eines DevOps-Ansatzes kann auch bedeuten, neue Tools zu nutzen – für Kommunikation, Automatisierung und teamübergreifende Zusammenarbeit.
Bei der Bewertung neuer Tools ist es wichtig, Fragen wie folgende zu stellen:
- Funktioniert dieses Tool in unserer Umgebung und lässt es sich in vorhandene Tools integrieren?
- Erfüllt es unsere Anforderungen?
- Arbeiten alle neuen Tools in einem umfassenden, kohärenten Toolset zusammen?
Wir bei Atlassian mögen voreingenommen sein, aber wir nutzen Jira Service Management für das IT-Servicemanagement, Jira Software für die Softwareentwicklung und Bitbucket als unser Code-Repository.
Ein Grund für die hervorragende Funktionsweise dieser Tools besteht darin, dass sie gut zusammenarbeiten. Und wenn du siloartige Teamstrukturen aufbrechen möchtest, solltest du auch auf isoliert arbeitende Tools verzichten.
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
White Paper lesenAtlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
White Paper lesen