2nd Level Support in agilen DevOps Teams

Einleitung

Agilität in IT-Projekten wird mehr und mehr zum Standard. Die Agilität in den Projekten führt auch zur immer mehr agileren Ansätzen bei Operation. Diese Veränderung hat natürlich auch Auswirkungen auf den Betrieb der agil entwickelten Lösungen. War in der Vergangenheit ‚build‘ und ‚run‘ klar getrennt, wird die Anforderung nach gemischten Teams für agile Projekte immer wichtiger. DevOps ist der Best Practice Ansatz, der hier meistens zum Tragen kommt.

Die Kernaussage in DevOps ist: Die Entwickler:innen sind neben der Weiterentwicklung des Produktes auch Teil des Betriebs, da sie sich auf die Produktqualität fokussieren sollen und Probleme in diesem Bereich im laufenden Betrieb selbst erkennen und davon betroffen sind. Die optimale Lösung wäre, die Aufgaben des 2nd Level und dem 3rd Level in das DevOps-Team zu integrieren. Oft ist dies aber nicht vollständig möglich, da sich die Servicezeiten des Betriebs  mit Wochenendarbeit oder 24/7 stark von denen des Dev-Teams unterscheiden. Zudem gibt es oftmals Standardaufgaben (SOAs) die das agile DevOps Team stark vergrößern würden. Ein Lösungsansatz für dieses Problem ist die Implementierung eines eigenen 2nd Level Supports, der das DevOps Team unterstützt. Aber wie können wir verhindern, das Silos zwischen den Teams entstehen?

Responsibilities des DevOps Teams

Das Ziel bei einem DevOps Team ist eine End-to-End Verantwortung für das Gesamtprodukt zu entwickeln. Es ist dabei wenig hilfreich, wenn die Leistung des Teams über SLAs und KPIs gemessen wird, die meist noch die Leistung von Development und Operation getrennt bewerten.

Dieses Trennung Denken führt meist dazu, dass neben der Verantwortung für die Bereiche auch das Wissens aufgeteilt wird. Eine effektive Methodik gegen diese Trennung ist, dass das DevOps Team alle entwickelten Features selbstständig über alle Stages (Dev, Int, Prod) ausrollt und die Qualität sichert. Das Team muss anschließend die Stabilität des Produktes auf jeder Umgebung überprüfen und gegebenenfalls schnell Fixes ausarbeiten und ausrollen.

Verteilung der Responsibility mit einem 2nd Level

Der 2nd Level sollte den Betrieb in agilen Projekten nicht vollständig übernehmen, sondern eher das DevOps Team bei der täglichen Arbeit unterstützen und wiederkehrende Aufgaben übernehmen. Je kleiner/weniger DevOps Teams existieren, umso einfacher ist es einen 2nd Level zu integrieren. Der Fokus sollte dabei darauf liegen, das zwischen dem DevOps Team und dem 2nd Level ein fließender Übergang besteht und das Wissen auch untereinander geteilt wird.

Weiterhin kann das 2nd Level bei Produkten helfen, die ein 24/7 Support benötigen. Insbesondere wenn das 2nd Level ein Offshore Team ist, da hier auch außerhalb der normalen Bürozeiten ein kompetenter Support zur Verfügung stehen sollte. Dieses Offshore Team kann einfache Probleme selbst lösen und  benötigt nur bei komplexen Themen die Unterstützung des DevOps Teams. Dies führt auch zu Entlastungen des Teams und behält den Fokus auf die Produktqualität und den Weiterentwicklungsfocus bei.

Zudem kann dieser 2nd Level der First Point of Contact (FPoC) sein und die Koordination aller Problem-Incident-Change-Prozesse (PIC-Prozesse) übernehmen und somit die Schnittstelle zwischen der agilen und der klassischen ITIL Welt sein.

Forming a DevOps Team

Wie kann man nun organisatorisch diese Anforderungen in einem agilen Projekt umsetzten?

In unserem Ansatz verantwortet das DevOps Team in der Kernarbeitszeit alle Aufgaben von der Feature Entwicklung bis zur Betriebsaufgaben. Diese beinhalten auch die Incident-Bearbeitung und die Problem-Analyse und -Lösung. Dadurch werden neue Features nicht einfach an den Betrieb übergeben, sondern das Team verantwortet die Gesamt-Produktqualität. Der 2nd Level Support unterstützt bei wiederkehrende Standardaufgaben wie z.B. Anlage und Pflege von Usern. Zusätzlich übernimmt das 2nd Level außerhalb der Kernarbeitszeit die betrieblichen Aufgaben vollständig und kann auch bekannte Probleme selbstständig beheben. Da natürlich nicht alle Mitarbeiter:innen des 2nd Level Teams in den Kernarbeitszeiten an den  agilen Meetings teilnehmen können, wird in jedem DevOps Team mindestens eine Person mit der Rolle des Repräsentanten vom 2nd Level integriert. Dieser ist ein vollständiges Mitglied des DevOps Team und arbeitet bei allen Aufgaben mit. Diese Person ist außerdem dafür verantwortlich, dass keine Wissenslücken zwischen den beiden Teams entstehen. Dies ist sehr wichtig, um nicht wieder auf die alte Trennung zwischen ‚build‘ und ‚run‘  zurückzufallen. Dieses Modell ist auch skalierbar, in dem ein zentraler 2nd Level für mehrere DevOps Teams mit mehreren Repräsentanten eingesetzt wird.

Fazit

Auch in einer agilen Welt kann ein 2nd Level viel Mehrwert liefern. Der Fokus ist dabei die Entlastung des DevOps Team von den wiederkehrenden Aufgaben und die Sicherstellung des Supports außerhalb der Kernarbeitszeit (Wochenende, 24/7). Dadurch bleiben die DevOps Teams in einer akzeptablen Größe und können sich auch auf die Produktqualität und neue Features konzentrieren.

Das oben dargestellte Zusammenarbeitsmodell wurde in der Praxis erfolgreich eingesetzt und hat sich vor allem in gemischten Onshore-Offshore Teams bewährt. In agilen Projekten mit anderen Anforderungen kann eine Anpassung der Prozesse und Strukturen sinnvoll sein.

Use Case

Im folgenden Kundenprojekt, kam der 2nd Level Support in agilen DevOps Teams bereits erfolgreich zum Einsatz:
Entwicklung eines Backends für Fahrerassistenzsysteme bei einem Automobilhersteller.