Warum Werkzeuge allein DevOps nicht machen

Ich habe gesehen, wie Unternehmen DevOps durch den Kauf von Werkzeugen machen. Kubernetes, eine CI/CD-Plattform, eine Beobachtungs-Suite, vielleicht ein neues Team namens "DevOps". Ein Jahr später sind die Releases immer noch langsam und schmerzhaft, Entwickler werfen immer noch Code über die Wand, und das neue DevOps-Team ist nur das alte Operationsteam mit einem neuen Namen und einer längeren Ticket-Warteschlange.

Das Problem sind nicht die Werkzeuge. Es geht einfach nicht um sie.

Was DevOps reparieren sollte

Der Begriff "DevOps" wurde um 2009 geprägt, als Patrick Debois die ersten DevOpsDays in Belgien organisierte. Das Problem, das es angegangen war, war ein menschliches: Entwickler wollten Änderungen schnell liefern, Operationen wollten Stabilität. Sie hatten unterschiedliche Ziele, unterschiedliche Manager und unterschiedliche Anreize. Also kämpften sie, und die Softwarelieferung war langsam und zerbrechlich.

DevOps schlug vor, sie zusammenzubringen: gemeinsame Ziele, gemeinsame Verantwortung, gemeinsame Werkzeuge und viel Automatisierung, damit Geschwindigkeit und Stabilität nicht mehr Gegensätze sind.

Beachten Sie die Reihenfolge. Menschen und Ziele an erster Stelle, Werkzeuge, um sie zu unterstützen.

Der Rahmen für CALMS

Eine nützliche Art, über DevOps nachzudenken, ist - Das ist nicht nötig., ein von Jez Humble und anderen populär gemachtes Rahmenwerk:

• KulturDie Kommission hat die Kommission aufgefordert, die in diesem Zusammenhang zu ergreifenden Maßnahmen zu prüfen.
• Automatisierung: die Handarbeit, die Fehleranfälligkeit bei der Erstellung, Prüfung, Einführung und dem Betrieb verringert.
• Schlanke: kleine Chargen, Begrenzung der laufenden Arbeiten, Abfallentfernung und Wartezeit.
• Messung: Daten über Lieferung und Zuverlässigkeit (wie die DORA-Messwerte), die zur Verbesserung, nicht zur Bestrafung verwendet werden.
• Teilen: Wissen, Werkzeuge, Verantwortung und Erfolg in Teams.

Die Werkzeuge bedecken hauptsächlich das A und einen Teil des M. Die C, L und S hängen davon ab, wie Menschen zusammenarbeiten.

Werkzeuge machen gute Zusammenarbeit schneller. Sie machen auch schlechte Zusammenarbeit schneller.

Zeichen von "DevOps nur im Namen"

• Ein DevOps-Team, das Tickets erhält Die Kommission hat die Kommission aufgefordert, die in den letzten Jahren durchgeführten Maßnahmen zu prüfen. Das ist ein neues Silo, keine DevOps.
• Entwickler sehen nie die Produktion: keine Zugriff auf Protokolle, Kennzahlen oder Warnungen für ihre eigenen Dienste.
• Schuld nach VorfällenWenn jemand abgeschnitten wird, schaut niemand auf das System.
• Große, seltener Freisetzungen Trotz eines CI/CD-Tools.
• Genehmigungsgremien Wir treffen uns einmal pro Woche.
• Ausgewählte Werkzeuge und andere aufzudrängen, ohne zu fragen, was sie brauchen.

Silos aufbrechen

Was hilft eigentlich:

• Gemeinsame Ziele. Entwickler und Betriebe, die anhand der gleichen Ergebnisse gemessen werden: Ausführungsgeschwindigkeit und Zuverlässigkeit, nicht eine für jeden.
• "Du baust es, du führst es", mit Unterstützung. Die Teams sind Eigentümer ihrer Produktion, auch bei Einsatz, und die Plattformteams machen das überschaubar.
• Plattformteams, die dienen, die Selbstbedienungstools bauen, die es Entwicklern ermöglichen, sich selbstständig zu bewegen, anstatt für sie zu arbeiten.
• Einbettung: ein SRE oder Plattformingenieur, der für eine Weile in einem Produktteam arbeitet und Wissen in beide Richtungen teilt.
• Gemeinsame RitualeGemeinsame Nachbeurteilungen, gemeinsame Dashboards, Demonstrationen zwischen Teams.

Sich sicher fühlen, sich zu äußern

Die Forschung von Google über die Effektivität von Teams, bekannt als Das Projekt Aristoteles, dass der wichtigste Faktor bei leistungsstarken Teams psychologische Sicherheit: der Glaube, dass man nicht bestraft wird, wenn man sich ausspricht, Fragen stellt oder Fehler zugibt.

Die DORA-Studie sagt etwas Ähnliches: Generative Kultur, wo Informationen frei fließen und Fehler eher zur Untersuchung als zur Schuld führen, eine bessere Software-Lieferung und ein besseres Wohlbefinden voraussagen.

In der Praxis sieht die psychologische Sicherheit in DevOps so aus:

• Unschuldige Nachbeurteilungen . Wo die Frage ist: "Wie hat das System das erlaubt?", nicht: "Wer hat das getan?"
• Menschen sagen "Ich weiß es nicht" oder "Ich habe es kaputt gemacht" ohne Angst.
• Junior sind sich wohl dabei, Fragen in öffentlichen Kanälen zu stellen.
• Führungskräfte, die zuerst ihre eigenen Fehler zugeben.

Ohne sie verstecken sich Probleme, und versteckte Probleme werden zu Ausfällen.

Die Veränderung voranbringen

Wenn Sie Ihre Organisation auf echte DevOps ausrichten wollen:

1. Beginnen Sie mit einem Schmerzpunkt, den jeder fühlt.: langsame Freisetzungen, schmerzhafte Einsätze, häufige Vorfälle.
2. Wählen Sie ein Team aus. bereit, es anders zu versuchen. Zeigen Sie Ergebnisse.
3. Vor- und Nachmessung (DORA-Messwerte sind großartig dafür).
4. Investitionen in die Automatisierung Das entfernt die schmerzhafteste manuelle Arbeit.
5. Anreize für Veränderungen: was belohnt und gemessen wird, prägt das Verhalten mehr als jedes Werkzeug.
6. Führungshilfe erhalten- Ich weiß . Die Kultur verändert sich von oben wie von unten.
7. Seien Sie geduldig. Kulturwandel braucht Jahre, nicht Sprints.

Sind Werkzeuge also nutzlos?

- Nein, überhaupt nicht. Gute Werkzeuge machen gute Praktiken möglich und skalierbar. Aber sie kommen nach der Entscheidung, anders zusammenzuarbeiten, nicht stattdessen.

Ich denke, DevOps ist etwas, das man übt, nicht etwas, das du kaufst. Das Werkzeug ist der leichte Teil. Es geht um die Menschen.

Desly