In einer Zeit vor ITSM (IT-Service-Management) lag der Fokus von IT-Management-Ansätzen auf den Technologien selbst. Damals gab es traditionell auf der einen Seite die Entwickler*innen, die Softwareprodukte, Services und Infrastrukturen erstellten. Auf der anderen Seite befanden sich die System- oder IT-Administrator*innen, die diese Produkte, Services und Infrastrukturen warteten. Die IT-Teams konzentrierten sich darauf, die eigenen Ziele zu erreichen.

Doch wie wir bereits im letzten Blogartikel gelernt haben, fokussiert sich ITSM darauf, IT-Services gut organisiert bereitzustellen. Bei diesem Ansatz richtet sich die IT nicht mehr primär auf eigene Ziele, sondern die Geschäftsziele ihrer Organisation aus. Dabei kann die ITSM-Idee innerhalb eines Teams auch so umgesetzt werden, dass sie sich an ITIL-Praktiken orientiert und von DevOps-Konzepten beeinflusst wird.

In diesem Fall gibt es dann in der Regel keine Trennung mehr zwischen Entwicklung, Betrieb und Support. Stattdessen sind alle Beteiligten dafür verantwortlich, dass die Systeme zuverlässig funktionieren. Um das zu gewährleisten, müssen die Teammitglieder in der Lage sein, bei Problemen und echten Notfällen im Systembetrieb zur Hilfe eilen zu können. Dementsprechend wichtig ist es, ITSM-Teams darauf vorzubereiten, im Bereitschaftsdienst einsatzfähig zu sein. Wir haben 7 Tipps für dich, wie du Techniker*innen, die neu ins Team kommen, fit für den Bereitschaftsdienst machst!

1. Erkläre die Grundlagen von Bereitschaftsplänen und Eskalationen.

Dieser erste Tipp ist vermutlich ein ziemlich offensichtlicher, aber dennoch von entscheidender Bedeutung. Denn ohne die organisatorischen Basics des Bereitschaftsdienstes und die Eskalationen in deiner Organisation zu kennen, ist es für neue Teammitglieder nicht möglich, wertstiftend zu agieren.

Gibt es in deinem Unternehmen z. B. verschiedene Turnusse für Tages- und Nachtschichten? Habt ihr so etwas wie einen primären und sekundären Bereitschaftsplan? Verfügt ihr über geeignete Eskalationsverfahren für den Fall, dass dein*e Techniker*in aus bestimmten Gründen gerade nicht zur Stelle sein kann? All das sind Beispiele für grundlegende Informationen, die deine Neuzugänge im Team wissen sollten.

Ein Praxisbeispiel liefert uns Opsgenie, die zentrale Incident-Management-Plattform von Atlassian: Unten siehst du, mit welchem Zeitplan sich Opsgenie organisiert und welche Eskalationsrichtlinien dort gelten.

2. Lege Regeln für die Alarmbenachrichtigungen für Techniker*innen fest.

Wie der Begriff “Bereitschaftstechniker*in” schon verrät, müssen deine Teammitglieder im Falle eines Vorfalls immer erreichbar und bereit für ihren Einsatz sein. Lege daher gemeinsam mit ihnen Regeln fest, nach denen sie bei einem Alarm benachrichtigt werden können.

So bewährt es sich als Best Practice, Alarme zu klassifizieren: Je nach Dringlichkeitsstufe des Alarms werden unterschiedliche Benachrichtigungsmethoden eingesetzt. Während Vorfälle mit hoher Dringlichkeit z. B. eine Kombination aus mobilen Push- und Sprachbenachrichtigungen erfordern, genügen bei weniger dringlichen Alarmen oder solchen zu Informationszwecken eine E-Mail, eine SMS, mobile Push- oder Sprachbenachrichtigungen.

Damit du dir besser vorstellen kannst, wie das in der Praxis aussehen kann – hier siehst du die von Opsgenie festgelegten Regeln für Alarmbenachrichtigungen:

3. Sorge dafür, dass alle über die richtigen Tools und Zugriffsrechte verfügen.

Bei einem echten Notfall geht es um Schnelligkeit: Damit deine Techniker*innen nicht von unzureichenden Tool-Kenntnissen oder verweigerten Zugriffsrechten ausgebremst werden, ist es unumgänglich, dass sich alle mit den erforderlichen Befehlen auskennen und für die Umgebungen über die relevanten Zugriffsrechte verfügen.

Checke also, ob sich alle im Team mit den folgenden Punkten auskennen:

• VPN
• SSH-Anmeldeinformationen
• sudo-Zugriffsberechtigungen
• ChatOps-Befehle
• Link zu Runbooks

4. Stelle sicher, dass alle deine Infrastruktur und das Technologie-Portfolio kennen.

Bei Problemen im System verhält es sich ähnlich wie bei gesundheitlichen Beschwerden: Um sie wieder loszuwerden, muss die Ursache gefunden werden. Daher ist es enorm wichtig, dass alle Techniker*innen die Infrastruktur deiner Organisation kennen, um die Ursache eines Problems nachvollziehen und dieses letztlich lösen zu können.

Gib dein Wissen über die Infrastruktur und das Technologie-Portfolio an neue Teammitglieder weiter und stelle sicher, dass die dazugehörige Dokumentation immer vollständig und aktuell ist.

5. Schule deine Techniker*innen in der Anwendung relevanter Diagnose-Tools.

Je nach Team kommt ein anderes Diagnose-Tool zum Einsatz, um zu verfolgen, wie es um die betriebliche Integrität, die Anwendungsleistung oder die Ressourcennutzung steht. Aus diesem Grund ist es für dein Team wichtig, sich mit mehreren solcher Tools auseinanderzusetzen und sich anzuschauen, wie sie anzuwenden sind.

Du könntest deine Bereitschaftstechniker*innen z. B. in den folgenden Diagnose-Tools schulen:

• Icinga oder Grafana: Identifiziere ein komplexes Problem, indem du in den meisten Szenarien den richtigen Vorfall mit den korrekten Metriken in kürzester Zeit abfragst.

• Amazon CloudWatch: Überwache über CloudWatch fast alle deine genutzten AWS-Services.
• Telegraf und InfluxDB: Sofern du Kundenprotokolle oder Performance-Daten in einem TIG-Stack speicherst, sollten deine Techniker*innen z. B. über die unterschiedlichen Protokollarten und darüber, wie sie genutzt und ausgewertet werden, Bescheid wissen.

6. Lege Regeln für Benachrichtigungen zum Bereitschaftsplan fest.

Auch dieser Tipp ist so simpel wie schlüssig: Deine Kolleg*innen im Bereitschaftsdienst müssen selbstverständlich immer darüber informiert sein, wann ihr nächster Dienst ansteht. Sorge demnach dafür, dass alle Teammitglieder Regeln für Benachrichtigungen zum Bereitschaftsplan konfiguriert haben.

So sieht das in der Umsetzung bei Opsgenie aus:

7. Definiere Verantwortlichkeiten für Ersthelfer*innen bei Vorfällen.

Wie sieht die erste Hilfe deiner Bereitschaftstechniker*innen bei Vorfällen konkret aus? Dieser Prozess sollte klar festgelegt (und dokumentiert) sein, um Missverständnisse und Frustration zu vermeiden.

Hier ein paar beispielhafte Fragen zusammengestellt, die in diesem Zusammenhang geklärt sein sollten:

• Wann sollte ein Alarm quittiert werden?
• Wie wird ein Vorfall priorisiert und klassifiziert?
• Wann sollte er an Teammitglieder mit mehr Erfahrung oder an andere Teams eskaliert werden?
• Wann werden die entsprechenden Stakeholder – wie Führungskräfte und der Kundensupport – informiert?
• Wie ist vorzugehen, wenn sich Bereitschaftstechniker*innen für kurze Zeit nicht am Rechner aufhalten?
• Wie werden Vorfälle für eine Post-Mortem-Analyse dokumentiert?

Bereit, loszulegen? Schule dein ITSM-Team!

Jede Organisation, die auf ITSM setzt, fordert eine neue Denk- und Arbeitsweise von ihren Teams. Entwicklung, Betrieb und Support sind nicht mehr klar voneinander getrennt, sondern gehen Hand in Hand. Dabei muss sichergestellt werden, dass alle im Team während des Bereitschaftsdienstes tatsächlich einsatzfähig sind. Mit den hier vorgestellten Tipps kannst du deine neuen Bereitschaftstechniker*innen bestmöglich darauf vorbereiten.

Du möchtest gerne noch tiefer in die Welt von ITSM, DevOps und Co. einsteigen? Dann haben wir noch mehr Lesestoff für dich: Fordere dir hier ganz einfach unser kostenloses Whitepaper “Wie funktioniert IT-Servicemanagement?” an.

Quelle: İbrahim Güntaş, Atlassian Opsgenie

Weiterführende Infos

ITSM, ITIL und DevOps: Was ist was? Fachchinesisch für IT-Newbies einfach erklärt
Wie Jira Service Management in konkreten, praktisch relevanten ITSM-Anwendungsfällen hilft
Don’t call me DevOps Engineer! – Das Mindset und die Prinzipien hinter DevOps