Skip to content

DevOpsDaysZH 2017 ...

Am dritten und vierten Mai habe ich an den ersten DevOpsDays in Zürich-Winterthur teilgenommen. Diese Konferenzform hat in der Schweiz zum ersten Mal stattgefunden und die Organisatoren haben meiner Ansicht nach herausragende Arbeit geleistet.

Das Veranstaltungsformat gefällt mir sehr. Vorträge bis zum Mittagessen, danach - um einem Schnitzelkoma vorzubeugen - Ignite Talks (ein Format, das ich vorher noch nicht kannte, ich kenne nur Lightning Talks) und abschliessend zum Mitmachen Open Spaces (das kenne ich bereits von Barcamps).

Zu den einzelnen Programmpunkten werde ich in weiteren Artikeln noch Stellung beziehen, hier an dieser Stelle möchte ich nur zwei Punkte hervorheben.

Für mich ist sehr interessant zu sehen, dass die Hauptprobleme bei DevOps die Menschen sind und nicht die Technologie. Das ist sehr logisch, aber es ist vielen nicht bewusst. Zu den Menschen zählt auch Unternehmenskultur und festgefahrene Meinungen. Das wird von vielen Entscheidern anders veranstanden, aus diesem Grund ist es wichtig, das besonders hervorzuheben.

Passend dazu das HumanOps Manifest:

  • Humans build and fix systems.
  • Humans get tired and stressed, they feel happy and sad.
  • Systems don't have feelings yet. They only have SLAs.
  • Humans need to switch off and on again.
  • The wellbeing of human operators impacts the reliability of systems.
  • Alert Fatigue == Human Fatigue
  • Automate as much as possible, escalate to a human as a last resort.
  • Document everything. Train everyone. Save time.
  • Kill the shame game.
  • Human issues are system issues.
  • Humans > systems
  • Human health impacts business health.

In meinem Umfeld, System Engineering und Systemadministration, wird die DevOps-Bewegung wahrgenommen als (viele Entwickler vertreten das auch so, sie haben es eifnach nicht verstanden):

Jetzt haben wir Entwickler endlich Zugriff auf die Produktion, jetzt zeigen wir Euch, wo es lang geht und wie Agil funktioniert.

Dazu passt irgendwie gar nicht, dass bei den Entwicklern eines der Hauptthemen Bereitschaft ("On-Call" oder Pikett) war, etwas, das in der Systemtechnik schon seit Jahren kein Problem ist. Interessanterweise ist die Frage aufgetaucht, wie man denn in der Bereitschaft entscheiden sollte, was man tun darf und muss. Wenn die Entwickler der Software das nicht wissen, warum erwarten sie, dass die Ops-Leute das wissen (und seit Jahren praktizieren)? Auch dort steht ein Kulturwechsel an.

Zum Thema Bereitschaft mache ich noch einmal einen separaten Artikel.

Es ist gut, dass immer mehr verstanden wird, dass DevOps ein miteinander ist. Beide "Seiten" können von einander lernen.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

-thh am :

*Ein spannendes Thema, danke!

Ganz am Rande: Du hast demletzt das Farbschema Deines Blogs geändert, oder?

Dirk Deimeke am :

*Das ist für mich auch ein spannendes Thema und es wird auch als Systemadministrator in einer Bank immer spannender.

Stimmt, das Farbschema habe ich gestern geändert und die Schriftart heute.

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen