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.
Alex Lichtenberger von Pontine hatte mich gefragt, ob ich einen Artikel zu devops.ch beisteuern könnte und ich habe "selbstverständlich" zugestimmt. Apropos zugestimmt: devops.ch ist ständig auf der Suche nach neuen Autoren und frischen Ideen. (Und nein, ich bekomme von der Firma nichts dafür, dass ich das erwähne).