ChatOps: Personalbesetzung ohne Personal

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Demnächst auch in einem Netzwerk in Ihrer Nähe. Präsentiert von der anderen API-Ökonomie.

In der DevOps-Community hat sich der Fokus in letzter Zeit stärker auf die Kultur verlagert. Das liegt wahrscheinlich daran, dass sich viele Vorteile von DevOps ohne einen kulturellen Wandel hin zu einer offeneren, kollaborativen und IT-übergreifenden Umgebung nicht vollständig ausschöpfen lassen. Ein abgeschotteter Informationsaustausch nach dem Prinzip „Kenntnis nur bei Bedarf“ führt zu jenen Silos, die wie Wehrtürme das spezifische Erfahrungswissen der einzelnen Betriebsbereiche umschließen, aus denen sich das zusammensetzt, was wir liebevoll als „IT“ bezeichnen.

Doch diese Silos aufzubrechen, kann schmerzhaft sein. Und unangenehm. Und außerordentlich schwierig. Wir können zwar Witze über das „antisoziale“ Wesen praktisch aller IT-Fachleute machen und uns über die Karikaturen lustig machen, doch in Wahrheit sind diese Archetypen – wie die meisten Legenden und Märchen – aus realen Verhaltensweisen und Eigenschaften entstanden, die noch immer für viele Menschen in diesem Bereich typisch sind.

Beim Myers-Briggs-Typenindikator bin ich ein INTJ. Jedes Mal. Ja, „der Architekt“. Im Insights-Spektrum bin ich ein reformierender Beobachter. Dabei handelt es sich eigentlich nur um einen stark idealisierten, auf Jung basierenden Test, der für sich eine höhere Genauigkeit als der Myers-Briggs-Typenindikator beansprucht. Wie dem auch sei: Ich bin ziemlich introvertiert. Forschende schätzen heute, dass fast 50 % der Bevölkerung introvertiert sind. Und es dürfte Sie wohl kaum überraschen, dass viele von ihnen wie ich in der IT gelandet sind, während unsere unbegreiflichen extrovertierten Gegenstücke in Positionen im Marketing und Management wechselten.

Introvertierte sind nicht gerade begeistert vom „Leuteln“ – so nennen die Kids heutzutage den Umgang mit anderen Menschen. Es liegt wirklich nicht an Ihnen, sondern an uns. Wir verarbeiten Informationen und Daten einfach anders als Extrovertierte und empfinden zu viel direkte Interaktion als überwältigend. Wir können durchaus unter Leute gehen, aber es ist anstrengend. Wir bevorzugen Text und brauchen Zeit zum Nachdenken, bevor wir antworten. Deshalb kommen wir im digitalen Zeitalter eigentlich ziemlich gut zurecht, denn ein Großteil unserer Kommunikation findet genau so statt – aus der Ferne und per Text. Wenn Sie uns nur in unserer digitalen Form kennen, könnten Sie uns sogar für extrovertiert halten.

Wenn man sich die Grundannahme des für DevOps erforderlichen Kulturwandels vor Augen führt, wird der Konflikt sofort deutlich. Austausch und Kommunikation sind beides entscheidende Bestandteile von DevOps. Das bedeutet, dass man eine Gruppe Introvertierter dazu bringen muss, nicht nur mit anderen Menschen zu interagieren, sondern dies auch effektiv zu tun. Einen Weg zu finden, „mit Menschen zu interagieren, ohne mit ihnen interagieren zu müssen“, ist daher wie die Suche nach dem Goldtopf am Ende des Regenbogens.

Wie sich herausstellt, könnte ChatOps genau dieser Goldschatz sein.

ChatOps: Menschliche Interaktion ohne Menschen

Was also ist ChatOps? Jason Hand, einer der führenden Experten für ChatOps, liefert uns eine prägnante Definition: „Man kann sich ChatOps als eine gemeinsam genutzte Kommandozeile vorstellen.“

Natürlich steckt noch mehr dahinter, aber im Kern ist dies ein hervorragender Ausgangspunkt.

Tools wie HipChat und Slack sind im Gegensatz zu klassischen Instant-Messaging-Systemen nicht für die 1:1-Kommunikation konzipiert. Das ist zwar möglich, doch die eigentliche Stärke dieser modernen Kommunikationsplattformen liegt darin, eine offene Kommunikationsumgebung zu schaffen, in der Informationen und Neuigkeiten sofort mit allen Interessierten im Unternehmen geteilt werden. Stilles Mitlesen ist ausdrücklich erwünscht, denn entscheidend sind die Verfügbarkeit und Zugänglichkeit der Informationen – nicht ein fortlaufendes Gespräch.

Kanäle (wie #IRC) bieten die Möglichkeit, das Signal-Rausch-Verhältnis zu steuern, und häufig auch einen eindeutigen Prüfpfad, aus dem hervorgeht, wer wann was getan hat. Diese Tools erreichen das, indem sie mehr als nur Chat-Clients sind. Sie sind Plattformen, deren Funktionalität sich über APIs erweitern lässt, um eine bidirektionale Kommunikation nicht nur mit Menschen, sondern auch mit Systemen zu ermöglichen. Das bedeutet, dass ich einen Kanal namens #alerts hinzufügen kann, in den ich beispielsweise Warnmeldungen von Infrastrukturkomponenten einspeisen kann.

Sie können – und zwar relativ einfach, möchte ich hinzufügen – eine „App“ für Slack entwickeln, die über dessen APIs Informationen abfragt und zurückgibt. Vielleicht sind das Daten von Ihrem Switch, Ihrem Load Balancer oder zum lokalen Wetter. Worum es auch gehen mag: Innerhalb dieser Tools können Sie Befehle aufrufen, die Aufgaben automatisch ausführen. Und Sie können den Aufruf – und die Ergebnisse – mit allen teilen, die davon wissen müssen oder für die diese Informationen nützlich sein könnten. Die ausgeführten Schritte werden dadurch dokumentiert und hinterlassen eine Spur, anhand derer andere nachvollziehen können, was vor sich geht. Statusmeldungen von Überwachungssystemen, neue Tickets vom Helpdesk, ein Hinweis darauf, dass ein Server gerade ausgefallen und nicht mehr verfügbar ist. So gut wie alles, was sich über eine API kommunizieren lässt, kann mit anderen geteilt werden – ohne dass dafür wirklich direkter menschlicher Austausch nötig ist.

Dieser Prozess eröffnet eine Fülle von Möglichkeiten für Mentoring und Schulungen sowie dafür, implizites Wissen zugänglich zu machen, von dem auch andere IT-Bereiche – einschließlich der Entwicklung – profitieren. So lässt sich Wissen in großem Umfang weitergeben, ohne Räume mit Menschen zu füllen oder Schulungen für wissbegierige neue Engineers durchzuführen. Außerdem ist dies eines der wenigen Werkzeuge, die den kulturellen Wandel ermöglichen, der für die erfolgreiche Einführung eines DevOps-Ansatzes im „Netzwerk“ erforderlich ist.

Und wir müssen sie uns zu eigen machen. Falls Sie noch immer skeptisch sind, denken Sie über diese Frage nach, die Atlassian und xMatters in ihrer DevOps-Reifegradstudie 2017 gestellt haben:

Die Autoren haben auf Grundlage ihrer Daten eigene Hypothesen, aber ich habe eine andere, die weitgehend auf dem Kompositionsfehlschluss beruht, der uns daran erinnert, dass die zur Bereitstellung freigegebene Anwendung nicht dieselbe ist wie die Anwendung in der Produktionsumgebung. Durch das Hinzufügen von Anwendungsdiensten und die Interaktion mit dem Netzwerk ändert sich die Zusammensetzung. Die Überprüfung dieser Anwendung ist daher nicht mehr uneingeschränkt aussagekräftig, sofern sie nicht in einer exakten Nachbildung der Produktionsumgebung durchgeführt wird.

Schlimmer noch: Bei fast einem Drittel der Unternehmen werden diese Probleme erst entdeckt, wenn Kunden sie über Serviceunterbrechungen informieren. Das könnte daran liegen, wie Informationen zwischen Entwicklung und IT ausgetauscht werden. 29 Prozent geben an, dass Informationen zwischen den Teams nur auf ausdrückliche Anfrage ausgetauscht werden. Nur 16,8 % machen Informationen „für alle zugänglich und stellen technische Informationen, Ziele, Pläne und Ergebnisse bereit“.

Ohne die spezifischen Informationen zum Verhalten einer App in der Produktionsumgebung ist es oft schwierig, das Problem zu erkennen – geschweige denn seine Ursache. „Auf meinem Rechner funktioniert es“ ist ein defensives Mantra, das aus der Frustration von Entwicklern darüber entstanden ist, fehlerhaftes Verhalten nicht reproduzieren zu können, das in den meisten Fällen auf fehlende Informationen über die Umgebung zurückzuführen ist.

Auch wenn wir nicht unbedingt sofort mit der Automatisierung sämtlicher Netzwerkaufgaben beginnen wollen, ist ChatOps eine gute Möglichkeit, die Kommunikation zwischen IT und Entwicklung zu fördern und einen besseren Einblick in Probleme zu gewinnen, um die MTTR (Mean Time to Resolution) zu verkürzen. So lässt sich ein umfassenderes Bild davon vermitteln, was „im Netzwerk“ vor sich geht, ohne aufdringlich zu sein oder die Arbeit der Techniker bis ins Kleinste zu kontrollieren. Introvertierte können dadurch mit anderen interagieren, ohne direkten persönlichen Kontakt haben zu müssen. Das ermutigt sie, häufiger und ausführlicher und, wie Sie vielleicht feststellen werden, auch mit Begeisterung Informationen auszutauschen.

Wenn ChatOps für Sie Neuland ist, empfehle ich Ihnen wärmstens, Jason Hands E-Book „ChatOps für Dummies“ zu lesen. Dafür müssen Sie zwar Ihre E-Mail-Adresse angeben, aber es lohnt sich.

Und bleiben Sie dran. Hier wird es künftig garantiert noch mehr zum Thema ChatOps geben.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie