JAX London-Interview mit Jeremy Deane

Was passiert, wenn man Entwickler für ein Problem verantwortlich macht?

Coman Hamilton

© Shutterstock.com/PathDoc

Worin besteht die angemessene technische und kulturelle Reaktion auf den Ausfall eines hochverfügbaren Systems? Auf der diesjährigen JAX London hielt der Softwarearchitekturexperte Jeremy Deane Vorträge über die Bedeutung von Resilienz und die Herausforderungen technischen Wandels. Im Interview sprachen wir mit ihm über Diffusionstechniken und eine schuldzuweisungsfreie Arbeitskultur.

JAXenter: Im Rahmen deiner Session auf der JAX London hast du uns daran erinnert, dass insbesondere in hochverfügbaren Systemen Ausfälle unvermeidlich sind. Was geschieht, wenn sie ausfallen?

Jeremy Deane: Das kommt immer darauf an, wie man vor Ort aufgestellt ist. Wenn man kein Monitoring betreibt, bekommt man es vielleicht überhaupt nicht mit. Wenn man Logdateien nicht überwacht oder, beispielsweise, die Queues für das Messaging oder die Middleware, könnte bildlich gesprochen ein Baum im Wald umfallen, ohne dass es einer hört. In diesem Fall merkt man nichts, bis die ersten verärgerten Kunden an die Tür hämmern und fragen, warum die Software nicht funktioniert. Dann muss man alles stehen und liegen lassen und herausfinden, was vor sich geht.

Implementiert man hingegen resiliente Prinzipien und Techniken, so kann man in den meisten Fällen nicht nur sehr schnell reagieren, sondern häufig auch Selbstheilung hinzufügen. Der Verantwortliche muss also nicht mitten in der Nacht herausgeklingelt werden, um das Problem zu beheben. Das Problem behebt sich selbst.

JAXenter: Du hast von Resilienz als dem „vernachlässigten Stiefkind“ gesprochen – wie meinst du das?

Jeremy Deane: Ich glaube, durch Dinge wie die Erstellung mehrere Knoten in einem Cluster, Lastverteilung oder Replikation sind wir ganz gut darin, hochverfügbare Systeme zu erschaffen. Allerdings nehmen wir uns keine Zeit für die Bedrohungsmodellierung, die Aufschluss darüber geben könnte, wie sich ein System bei einem Ausfall verhält – sowohl vom einem technischen als auch von einem Sicherheitsstandpunkt aus betrachtet. Und dann ist da natürlich noch die Kehrseite: Wie schnell kann man bei einem Ausfall reagieren, wie schnell kann man das System wieder ganz machen? Denn darum geht es bei Resilienz: Es ganz machen.

JAXenter: Bleiben wir beim Thema Ausfall. Man hört viel über Firmen wie Etsy, die versuchen, eine Unternehmenskultur zu schaffen, bei der es ohne Schuldzuweisungen zugeht, Ausfälle und Fehler akzeptiert werden und über sie gesprochen wird. Ist es denn nicht auch gut, die Ursachen eines Problems zu identifizieren und mit dem Finger auf sie zu zeigen?

Jeremy Deane: Absolut. Ich meine, wenn man nicht versteht, warum etwas vorgefallen ist, wird man nicht verhindern können, dass es in der Zukunft erneut geschieht. In vielen Fällen ist Ehrlichkeit der einzige Weg dorthin. Selbst der disziplinierteste Programmierer kann Fehler machen. Software ist eine sehr schnelllebige Angelegenheit, da passiert es leicht, dass man Fehler macht.

In der Regel beabsichtigen die Leute nicht, die Produktion zu stören, es passiert einfach. Das schlechteste und demoralisierendste was man in einem solchen Fall tun kann, ist, mit Schuldzuweisungen um sich zu werfen. Denn dann mauern die Leute und sind nicht mehr ehrlich. Und dann findet man die Wurzeln des Problems nicht mehr.

JAXenter: Du hast auch ausführlich über das Thema „Veränderungsmüdigkeit“ und deren Konsequenzen für Software gesprochen. Welche Veränderungen siehst du dort?

Jeremy Deane: Insbesondere seit der weltweiten Finanzkrise von 2008 mussten Organisationen tiefgreifende Veränderungen an ihren Systemen und Architekturen vornehmen – sowohl aufgrund der Business Driver als auch der Nachfrage. Und wenn man sich anschaut, wie sich die Industrie im Hinblick auf die Technologie zur Zeit verändert, dann sieht man diese ganzen neuen Platform-as-a-Service-Frameworks, von OpenShift und Kubernetes bis hin zu CloudFoundry und Amazon. Und dieses Ausmaß an Veränderung, das wir gerade durchmachen, ist fast überwältigend.

Früher war es so, dass sich Entwicklerteams vielleicht mit Groovy, Rails oder Spring auskannten. Jetzt müssen sie sich mit Go beschäftigen oder, wenn sie Chef nutzen, Ruby lernen. Und dann müssen sie sich noch das Framework draufschaffen, das für die entsprechenden Deployments benötigt wird. Die Organisationen werden also von den Veränderungen ziemlich durchgewirbelt. Und mit jedem neuen CTO oder Chief Architect ergeben sich gewisse Störungen.

Ist man nun ein Entwickler, der auf eine Konferenz wie etwa die JAX London geht und all diese Dinge sieht, die potentiell tiefgreifende positive Auswirkungen auf eine Organisation haben, und dann am liebsten gleich am Montag, zurück im Büro, diese Veränderungen realisieren möchte … wie macht man das? Das ist der Kernpunkt meines Vortrags: Diffusionstechniken nutzen, um diese Änderungen einzuführen.

JAXenter: Diffusionstechniken?

Jeremy Deane: Es gibt dieses wunderbare Buch (Diffusion of Innovations) über Veränderungsmuster, die architektonischen Entwurfsmustern nachempfunden sind. Man stelle sich Szenario X vor, für das man eine Brownbag-Sitzung abhält. Oder man bringt einen echten Champion ins Spiel, der etwas Ähnliches bereits in einer anderen Organisation getan hat, und auch versteht, an welchem Punkt im Prozess der Technologieeinführung man sich gerade befindet. Kennen die Leute die Technologie überhaupt? Ein Muster besagt, man solle „Samen pflanzen“: Man postet etwas im Intranet, hält informelle Treffen ab. Man sagt also nicht „lasst es uns machen!“, sondern setzt die Leute einfach dem Thema aus. Und dann, wenn die Leute darüber Bescheid wissen, kann man vielleicht eine Demo erstellen und ihnen zeigen, wie es funktioniert.

Die Beobachtbarkeit hat, wenn es um die Übernahme einer Technologie geht, in der Regel einen Einfluss auf den Entscheidungsfindungsprozess. Und dann, im Laufe des Prozesses, gelangt man vielleicht an einen Punkt, an dem man Förderung braucht. Man braucht dann also sozusagen einen „Engel“, der einem bei der Organisation hilft und sie finanziert. Denn ab einem gewissen Punkt kommt man mit einem Pilotprojekt nicht weiter, es muss institutionalisiert werden. Es geht also darum, ein Verständnis dafür zu haben, in welcher Art von Organisation man arbeitet. Ein Verständnis dafür, mit welcher Art von Leuten man es zu tun hat, eine Kenntnis ihrer Perspektiven und davon, wie sie die Technologie mit der Zeit annehmen.

Aufmacherbild: Concept of accusation of guilty businesswoman von Shutterstock / Urheberrecht: PathDoc

Verwandte Themen:

Geschrieben von
Coman Hamilton
Coman Hamilton
Coman was editor of JAXenter.com at S&S Media Group. He has a master's degree in cultural studies and has written and edited content for numerous websites and magazines, as well as several ad agencies.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: