DevOps-Veteran Chris Bytaert, der Pionier von DevOpsDays, teilt seine Erfahrungen und seine Ergebnisse werden Sie überraschen.
Vor zehn Jahren machten wir plötzlich einen Ausflug. Wir haben einige unserer guten Freunde in Gent (Belgien) zusammengebracht, um über agile, Open-Source- und frühe Cloud-Computing-Erfahrungen zu diskutieren. Im Jahr 2009 hielten John Ollspoe und Paul Hammond bei Velocity einen Vortrag über "10+ Bereitstellungen pro Tag: Zusammenarbeit von Entwicklern und Ops bei Flickr" (und eine Aufzeichnung dieses Vortrags ist sehenswert). Nachdem Patrick Debois diesen Vortrag gesehen hatte, beschloss er, DevOpsDays zu gründen.
Stimmt es, dass sich die DevOps-Welt in diesen 10 Jahren stark verändert hat? Ich habe seit Beginn der Konferenz an DevOpsDays-Veranstaltungen teilgenommen und in dieser Zeit umfangreiche Erfahrungen gesammelt. In diesem Beitrag werde ich 10 Tutorials teilen, die auch für Sie hilfreich sein könnten.
1. Es gibt keinen DevOps-Ingenieur
Viele Teams haben eine Person mit dem Titel „DevOps Engineer“, und nicht alle Spezialisten mögen diesen Titel. Dieser Berufsname vermittelt den falschen Eindruck, dass DevOps eine Aufgabe ist, die von einer Person ausgeführt werden kann. Meistens ist ein DevOps-Ingenieur ein Linux-Ingenieur, der mit etwas Glück Automatisierungsprobleme lösen kann. Wenn Personalvermittler nach einem DevOps-Ingenieur suchen, sollten sich Arbeitssuchende die richtigen Fragen stellen: „Was will das Unternehmen wirklich von dem Arbeitssuchenden? Suchen sie einen Montagetechniker? Senora, die nicht funktionale Anforderungen versteht? Ein Spezialist in der Betriebsabteilung, der mit Automatisierung umgehen kann, oder jemand anderes? " In den meisten Fällen suchen Unternehmen nach einem Spezialisten, der den Rest der Mitarbeiter davon abhält, die praktischen Grundsätze und Anforderungen von Agile nicht einzuhalten.
In Organisationen mit großen DevOps-Abteilungen ist in der Regel niemand an DevOps beteiligt. Das Wort "DevOps" spricht nur von einer Trennung vom Rest des Teams, und der Bewerber kann ein gutes Gehalt erhalten und neue Fähigkeiten bei der Arbeit erlernen, aber er wird nicht "DevOps machen".
2. DevOps-Teams existieren nicht
Wir haben in der Vergangenheit oft gesagt, dass das Ziel von DevOps darin besteht, Verwirrung zwischen verschiedenen Teams zu vermeiden. Insbesondere zwischen Entwicklern und Mitarbeitern der operativen Abteilungen. In letzter Zeit sind wir jedoch auf ein neues Phänomen gestoßen - das Auftauchen vieler DevOps-Teams.
Der Aufbau eines DevOps-Teams klingt nach einer neuen Praxis, aber hier gibt es offensichtliche Widersprüche. In einer Organisation wird sich dieses Team mit Entwicklungstools befassen, in einer anderen ist es buchstäblich eine Mauer zwischen dem Entwicklungsteam und den Betriebsspezialisten. Das Problem ist, dass diese Wand Verwirrung und Frustration erzeugt und das Ausmaß der nützlichen Interaktion verringert. Das Team mit dem Namen "DevOps" löst bestenfalls eine Vielzahl von Problemen und trägt eine gewisse Verantwortung für die Dienste, mit denen sie arbeiten. Normalerweise bevorzugen professionelle Teams, das Wort "DevOps" nicht im Namen zu haben.
Nach meiner Erfahrung kann das Wort "DevOps" in einem Teamnamen das Erreichen der gewünschten Ergebnisse behindern.
3. DevOps-Projekte existieren nicht
Alle Projekte sind endlich. Sie entwickeln, stellen Ihre Lösung bereit und fahren fort. In den letzten 10 Jahren wurde darüber gesprochen, dass DevOps eine kontinuierliche Verbesserung darstellt und eine kontinuierliche Verbesserung endlos ist. Das Ergebnis Ihrer Projekte sind wiederum lang laufende Dienste, und der Dienst impliziert die Sequenz "Entwicklung -> Bereitstellung -> Gesundheitsunterstützung".
Erst wenn wir uns Dienstleistungen außerhalb von Projekten ansehen, können wir Aspekte erkennen, die leicht vergessen werden: nicht funktionale Anforderungen. Zu den nicht funktionalen Anforderungen gehören Funktionen, die nicht in ein bestimmtes Verhalten passen. Diese Anforderungen bestimmen auch unsere Einschätzung der Systemleistung. Diese Anforderungen umfassen häufig Aspekte, die als DevOps klassifiziert werden: Zuverlässigkeit, Benutzerfreundlichkeit, Wartbarkeit und Skalierbarkeit. All diese Eigenschaften sind wichtig, um Geschäftsergebnisse zu erzielen.
Bei der Arbeit an kurzfristigen Projekten besteht das Risiko, dass Sie dieser Arbeit nicht genügend Aufmerksamkeit schenken. Wenn Sie mit dem nächsten Projekt fortfahren, werden Sie nicht mehr an die nicht funktionalen Anforderungen des vorherigen denken, da Sie sich neuen Herausforderungen stellen und der Rest der Probleme Sie nicht mehr stören wird. Wenn Sie einen Service verwalten, tauchen Sie wirklich in die Arbeit ein, und es liegt in Ihrem besten Interesse, alles so zu polieren, dass alles reibungslos funktioniert.
4. DevOps-Tools existieren nicht
Während viele Anbieter versuchen , Ihnen verschiedene Tools zu verkaufen , darunter eines, das alle Ihre Probleme löst, geht es bei DevOps nicht um Tools. Bei DevOps geht es um Menschen und ihre Interaktionen. Einige Tools helfen wirklich bei der Zusammenarbeit. Oft können Tools Menschen mit unterschiedlichem Hintergrund dabei helfen, dieselbe Terminologie und dieselben Ökosysteme zu verwenden. Genauso oft behindern Tools eine effektive Kommunikation.
Eine werkzeugbasierte Kultur kann Menschen isolieren, anstatt ihnen bei der Interaktion zu helfen. Tatsache ist, dass Menschen von ihrer Toolchain besessen sind und sich von denen entfernen, die sie nicht verwenden. Während bestimmte Tools aus technischer Sicht sehr nützlich sein können, haben eine Reihe neuer Tools (üblicherweise als DevOps bezeichnet) die Kluft zwischen verschiedenen Gruppen vergrößert. Zum Beispiel höre ich oft den Satz "das funktioniert in meinem Container". Entwickler verwenden diesen Ausdruck, um anzuzeigen, dass "ihre" Arbeit erledigt ist. Container allein lösen die Interoperabilitätsprobleme, die mit der effizienten Ausführung von Anwendungen verbunden sind, nicht. Wir können nicht zulassen, dass Werkzeuge uns voneinander distanzieren.
5. Es gibt keine Zertifizierung in DevOps
Kein Multiple-Choice-Test kann bestätigen, dass Sie in der Lage sind, effektiv mit Kollegen zu interagieren. Organisationen, die Zertifizierungen anbieten, verfügen möglicherweise über unglaubliches technisches Fachwissen (und sogar effektive Kommunikation), aber Zertifizierungen können nicht zeigen, dass jemand gut in DevOps ist.
Leider benötigen Managementteams Zertifizierungen in einem Bereich, der schwer zu zertifizieren ist. Informieren Sie sich über Ihre Lieblingssoftware und -hardware und erkunden Sie die Cloud. Studieren Sie an einer örtlichen Universität, lesen Sie Bücher, aus denen Sie viel lernen können, insbesondere Bücher von Deming , Forsgren , Humble und vielen anderen... Erwarten Sie jedoch nicht, bei DevOps der Beste zu sein, sobald Sie zertifiziert sind. Der Umgang mit Kollegen ist viel wichtiger.
6. DevOps-Pipeline existiert nicht
„Hat DevOps bereits funktioniert?" „Die DevOps-Pipeline funktioniert." "Die DevOps-Pipeline ist defekt." Wann immer ich diese Aussagen höre, bin ich überrascht, dass wir diese Terminologie entwickelt haben. Haben wir die Bereitstellungspipeline umbenannt oder arbeiten in einigen Unternehmen DevOps-Teams an dieser Infrastruktur? Oder liegt es vielleicht daran, dass die Entwickler anrufen Betriebsteam, wenn die Pipeline defekt ist?
Trotz der immensen Bedeutung von CI / CD-Technologien bin ich skeptisch gegenüber der Verwendung des Begriffs "DevOps-Pipeline". Wenn die Entwicklungspipeline bricht, ist das Betriebsteam schuld. Entwickler denken beim Schreiben von Tests nicht an die Pipeline. Das Konzept selbst ist ebenfalls irreführend. Pipelines werden für jeden Dienst oder jede Anwendung separat erstellt und nicht für die gesamte DevOps-Domäne. Durch die Erstellung generischer Pipelines laufen wir Gefahr, die Lücke zwischen den Teams zu vergrößern, und dies ist keineswegs das Ziel von DevOps.
Ich empfehle die Verwendung einer Technik, die ich in Hunderten von Organisationen auf der ganzen Welt gesehen habe: Nennen Sie jede einzelne Pipeline eine Application X-Pipeline. Diese Terminologie erleichtert es, zu erkennen, welche Anwendung beim Testen, Bereitstellen oder Aktualisieren Probleme hat. Wir werden auch wissen, welches Team an den Korrekturen in Anhang X arbeiten wird (möglicherweise mit Hilfe von Freunden aus dem Betriebsteam).
7. DevOps hat keine Standards
Die schwierigste der Tausenden von DevOps-Geschichten ist die Standardisierung. Ebenso wie wir keine Personen zertifizieren können, gibt es in DevOps keine Einheitsgröße für alle Standards. Jede Organisation hat ihren eigenen Pfad, und diese Pfade können sehr unterschiedlich sein. Es gibt kein magisches Rezept, das die Tools auflistet und die Methoden zum Erstellen von Automatisierungsabläufen beschreibt, die plötzlich zu DevOps in Ihrer Organisation werden.
Der Standard in DevOps bedeutet, dass Sie eine bestimmte Methodik anwenden, die es Ihrem Unternehmen ermöglicht, zusammenzuarbeiten und sich von der Büropolitik zu entfernen. Sie sollte auch die Qualität der Arbeit verbessern, die Arbeitsmoral verbessern und es Ihnen ermöglichen, mit weniger Störungen bessere Ergebnisse zu erzielen.
DevOps sollte als eine Reihe von Praktiken verstanden werden, die der Methodik ähnlich sindITIL . Denken Sie daran, dass das L in ITIL für Bibliothek steht. Und diese Bibliothek sollte nicht als Leitfaden für Maßnahmen verstanden werden, sondern als Liste von Best Practices, aus denen Sie die für Sie am besten geeignete auswählen müssen. ITIL wurde gerade wegen erfolgloser Implementierungen gehasst, bei denen die Bibliothek genau als schrittweise Anleitung verwendet wurde. Die Standardisierung in DevOps führt zu denselben Ergebnissen.
8. DevSecOps gibt es nicht
Wir haben DevOpsDays 2009 gestartet und diese Konferenz war für alle offen. Natürlich war es anfangs eine Veranstaltung für Entwickler und Mitarbeiter von Betriebsteams, aber alle kamen zu uns: Datenbankadministratoren, Tester, Geschäftsanalysten, Finanziers und natürlich Sicherheitsspezialisten. Bereits 2012 haben wir bei OWASP- Treffen darüber gesprochen, was wir getan haben. Wir scherzten, dass das "S" in DevOps für Sicherheit steht, genau wie das "S" in HTTPS.
DevOps ist Sicherheit im Kern. Ich habe festgestellt, dass CD-Prinzipien am besten für Sicherheitsteams geeignet sind. CD ist eine Sicherheitsanforderung: Sie müssen jederzeit in der Lage sein, sie bereitzustellen. Auf diese Weise können Sie die Updates bereitstellen und implementieren, die aus geschäftlichen oder Sicherheitsgründen erforderlich sind.
Einerseits ist es traurig, dass wir uns Worte einfallen lassen müssen, um die für die Sicherheit Verantwortlichen einzubeziehen. Andererseits ist es gut, dass wir das noch einmal besprochen haben. Grundsätzlich gibt es keinen Unterschied zwischen DevSecOps und DevOps. Sicherheit war schon immer ein Teil der Entwicklung und des Betriebs. Ich kann dafür den Begriff DevSecOps verwenden, aber es ist besser, nur den Begriff DevOps zu verwenden.
9. Sie können nicht zu DevOps wechseln
Haben Sie jemals ein Unternehmen getroffen, das eine Aussage wie "Wir machen dieses Jahr im vierten Quartal ein DevOps-Projekt und nächstes Jahr werden wir komplett zu DevOps wechseln" macht, was wirklich erfolgreich war? Also habe ich mich nicht getroffen.
Die Softwarebereitstellung hört nie auf, die Technologie ändert sich immer, sie benötigt immer Unterstützung, und (im Idealfall) sollte der Ansatz und die Einstellung gegenüber DevOps gleich bleiben. Sobald Sie Ihren Lieferansatz verfeinert haben, möchten Sie sich weiter verbessern. Nicht, weil alle Funktionen Ihrer Anwendung implementiert wurden oder weil sich das Ökosystem, in dem sie lebt, nicht mehr entwickelt hat. Sie werden sich weiterentwickeln wollen, weil die Qualität Ihrer Arbeit exponentiell wächst und gleichzeitig die Lebensqualität wächst. DevOps wird sich weiterentwickeln, auch wenn eine Aufgabe den Status "Abgeschlossen" erhält.
10. Es gibt so etwas wie "Dev-oops"
Leider verstehen viele Menschen die Bedeutung der Zusammenarbeit nicht. Sie bauen Mauern zwischen Teams, glauben, dass Werkzeuge wichtiger sind als Praktiken, erfordern die Zertifizierung von allem und jedem. Sie glauben auch, dass alle 9 vorherigen Aussagen falsch sind. Und diese Leute werden für immer darum kämpfen, in dem, was ich Dev-Oops nenne, Erfolg zu haben.
Bei DevOps geht es darum zu denken, dass Tools und Teamtrennung wichtiger sind als echte DevOps-Prinzipien, die Ihre Arbeit verbessern können. Lassen Sie uns versuchen, DevOps zu machen, nicht DevOops.
Hauptziel
Wir betreiben DevOpsDays seit 10 Jahren und in dieser Zeit haben Tausende von Menschen in einer einfachen und offenen Umgebung viele interessante Dinge voneinander gelernt. Einige der Konzepte, die meiner Meinung nach im Widerspruch zu den Zielen von DevOps und Agile stehen, sind beliebt. Konzentrieren Sie sich darauf, dass Ihre Dienste Ihrem Unternehmen helfen, und hören Sie nicht auf zu lernen. Es geht nicht darum, Tools zu kopieren und in Ihrem Unternehmen zu implementieren. Es geht darum, sich in jeder Hinsicht auf kontinuierliche Verbesserung zu konzentrieren.
Erfahren Sie mehr darüber, wie Sie einen hochkarätigen Beruf von Grund auf neu aufbauen oder Ihre Fähigkeiten und Ihr Gehalt verbessern können, indem Sie an den kostenpflichtigen Online-Kursen von SkillFactory teilnehmen:
- DevOps Kurs (12 Monate)
Weitere Kurse
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )