Das Thema DevOps hat in den letzten Jahren enorm an Popularität gewonnen. Viele träumen davon, Teil davon zu werden, doch zeigt die Praxis, dass oft nur das Gehaltsniveau ausschlaggebend ist.
Einige führen in ihrem Lebenslauf DevOps an, obwohl sie nicht immer den Kern des Begriffs verstehen. Manche sind der Meinung, dass sie, sobald sie Ansible, GitLab, Jenkins, Terraform und ähnliche Technologien beherrschen (die Liste kann je nach Vorliebe fortgesetzt werden), sofort „DevOps-Experten“ sind. Das ist selbstverständlich nicht der Fall.
Seit mehreren Jahren befasse ich mich hauptsächlich mit der Implementierung von DevOps in verschiedenen Unternehmen. Davor habe ich über 20 Jahre in Positionen von Systemadministrator bis IT-Direktor gearbeitet. Derzeit bin ich DevOps Lead Engineer bei Playgendary.
Wer ist ein DevOps?
Die Idee, einen Artikel zu schreiben, entstand nach der wiederholten Frage: „Wer ist ein DevOps?“. Es gibt nach wie vor keinen etablierten Begriff dafür, was oder wer es ist. Einige Antworten sind bereits in diesem . Zuerst werde ich die wichtigsten Aussagen daraus zusammenfassen und anschließend meine Beobachtungen und Gedanken teilen.
DevOps ist kein Spezialist, den man einstellen kann, kein Set von Tools und kein Entwicklerteam mit Ingenieuren.
DevOps ist eine Philosophie und Methodologie.
Mit anderen Worten handelt es sich um eine Reihe von Praktiken, die eine aktive Interaktion zwischen Entwicklern und Systemadministratoren fördert. Das bedeutet, Arbeitsabläufe miteinander zu verknüpfen und zu integrieren.
Mit dem Aufkommen von DevOps sind die Struktur und die Rollen der Fachleute unverändert geblieben (es gibt Entwickler und es gibt Ingenieure), aber die Regeln für die Zusammenarbeit haben sich geändert. Die Grenzen zwischen den Abteilungen sind verschwommen.
Die Ziele von DevOps lassen sich in drei Punkten zusammenfassen:
- Software muss regelmäßig aktualisiert werden.
- Software muss schnell entwickelt werden.
- Software muss einfach und in kurzer Zeit implementiert werden.
DevOps hat kein einzelnes Werkzeug. Die Konfiguration, der Einsatz und das Erlernen mehrerer Produkte bedeuten nicht, dass ein Unternehmen DevOps hat. Es gibt viele Werkzeuge, die in verschiedenen Phasen eingesetzt werden, aber alle dienen einem gemeinsamen Ziel.
Und dies ist nur ein Teil der DevOps-Werkzeuge.
Ich habe mehr als zwei Jahre lang Interviews für die Position des DevOps-Ingenieurs geführt und mir ist bewusst geworden, wie wichtig es ist, den Begriff klar zu verstehen. Es hat sich spezifische Erfahrung, Beobachtungen und Gedanken angesammelt, die ich teilen möchte.
Aus meinen Erfahrungen in Vorstellungsgesprächen sehe ich folgendes Bild: Bei Fachleuten, die DevOps als Position betrachten, gibt es oft Missverständnisse mit den Kollegen..
Ein prägnantes Beispiel gab es, als ein junger Mann zum Vorstellungsgespräch kam, der in seinem Lebenslauf viele kluge Worte hatte. In den letzten drei Arbeitsstellen hatte er nur 5-6 Monate Erfahrung. Aus zwei Startups ist er gegangen, weil sie 'nicht durchgestartet sind'. Bei dem dritten Unternehmen meinte er, dass ihn dort niemand verstehe: Die Entwickler schreiben Code für Windows, während der Geschäftsführer verlangt, dass dieser Code in einen normalen Docker gepackt und in die CI/CD-Pipeline integriert wird. Der Junge hat viel Negatives über seinen aktuellen Arbeitsplatz und seine Kollegen erzählt – man wollte ihm fast sagen: 'So verkaufst du keinen Elefanten.'
Dann stellte ich ihm eine Frage, die ganz oben auf meiner Liste für jeden Kandidaten steht.
— Was bedeutet DevOps persönlich für dich?
— Allgemein oder wie ich es wahrnehme?
Mich interessierte seine persönliche Meinung. Er kannte die Theorie und die Herkunft des Begriffs, war aber kategorisch anderer Meinung. Er war der Ansicht, dass DevOps eine Position ist. Hierin liegt der Grund für seine Probleme, ebenso wie bei anderen Fachleuten mit derselben Meinung.
Arbeitgeber, die von der "Magie von DevOps" gehört haben, suchen nach jemandem, der diese "Magie" erschaffen kann. Bewerber, die denken, "DevOps ist nur ein Job", verstehen nicht, dass sie mit dieser Einstellung die Erwartungen nicht erfüllen können. Generell haben sie in ihrem Lebenslauf DevOps erwähnt, weil es ein Trend ist und viel bezahlt wird.
Die Methodologie und Philosophie von DevOps
Die Methodologie kann theoretisch oder praktisch sein. In unserem Fall handelt es sich um Letzteres. Wie ich bereits erwähnt habe, ist DevOps ein Set von Praktiken und Strategien, die zur Erreichung bestimmter Ziele angewendet werden. Je nach den Geschäftsprozessen des Unternehmens kann es dabei erhebliche Unterschiede geben, was jedoch nicht bedeutet, dass es besser oder schlechter ist.
Die DevOps-Methodologie ist lediglich ein Mittel zur Erreichung der gesetzten Ziele.
Kommen wir nun zur Philosophie von DevOps. Und das ist wahrscheinlich die schwierigste Frage.
Es ist schwierig, eine kurze und prägnante Antwort zu formulieren, da es noch nicht formalisiert ist. Da die Anhänger der DevOps-Philosophie hauptsächlich in der Praxis tätig sind, bleibt kaum Zeit für philosophisches Nachdenken. Dennoch ist dies ein sehr wichtiger Prozess, der direkt mit ingenieurtechnischen Tätigkeiten verbunden ist. Es gibt sogar einen spezialisierten Wissensbereich — .
An meiner Hochschule gab es kein solches Fach, sodass ich alles selbstständig aus den Materialien lernen musste, die ich in den 90er Jahren finden konnte. Das Thema ist für die ingenieurtechnische Ausbildung nicht verpflichtend, was die Abwesenheit einer formalisierten Antwort erklärt. Doch diejenigen, die sich ernsthaft mit DevOps beschäftigt haben, beginnen, einen gewissen „Geist“ oder eine „unbewusste Allumfänglichkeit“ aller Unternehmensprozesse zu verspüren.
Ich habe in meiner Erfahrung versucht, einige „Postulate“ dieser Philosophie zu formalize. Folgendes ist dabei herausgekommen:
- DevOps ist nicht etwas Eigenständiges, das man als eigenes Wissensgebiet oder Tätigkeitsfeld abgrenzen könnte.
- Alle Mitarbeiter des Unternehmens sollten sich bei der Planung ihrer Aktivitäten nach der DevOps-Methodologie richten.
- DevOps betrifft alle Prozesse innerhalb des Unternehmens.
- DevOps existiert, um die Zeitaufwände bei allen Prozessen innerhalb des Unternehmens zu reduzieren, um die Entwicklung seiner Dienstleistungen und den maximalen Komfort für die Kunden sicherzustellen.
- DevOps, modern ausgedrückt, ist die proaktive Haltung jedes Mitarbeiters des Unternehmens, die darauf abzielt, Zeitkosten zu senken und die Qualität der IT-Produkte, die uns umgeben, zu verbessern.
Ich denke, dass meine "Postulate" ein eigenes Thema für eine Diskussion sind. Aber jetzt gibt es einen klaren Ausgangspunkt.
Was macht DevOps aus?
Das Schlüsselwort hier ist Kommunikation. Es gibt sehr viele Kommunikationswege, deren Initiator genau der DevOps-Ingenieur sein sollte. Warum? Weil es sich um eine Philosophie und Methodologie handelt, und erst danach um ingenieurtechnisches Wissen.
Ich kann nicht mit 100%iger Sicherheit über den westlichen Arbeitsmarkt sprechen. Aber ich weiß ziemlich viel über den DevOps-Markt in Russland. Neben hunderten von Vorstellungsgesprächen habe ich in den letzten anderthalb Jahren an rund einhundert technischen Presales zur Dienstleistung 'Einführung von DevOps' für große russische Unternehmen und Banken teilgenommen.
In Russland ist DevOps noch ein relativ junges, aber bereits angesagtes Thema. Soweit ich informiert bin, gab es allein in Moskau im Jahr 2019 einen Mangel an solchen Fachkräften von über 1000 Personen. Das Wort Kubernetes ist für Arbeitgeber fast wie ein rotes Tuch für einen Stier. Anhänger dieses Tools sind bereit, es sogar dort einzusetzen, wo es nicht nötig und wirtschaftlich nicht sinnvoll ist. Arbeitgeber verstehen nicht immer, wann es sinnvoller ist, was zu verwenden, und bei einer ordnungsgemäßen Implementierung kostet die Einrichtung eines Kubernetes-Clusters 2-3 Mal mehr als die Bereitstellung einer Anwendung nach einer herkömmlichen Cluster-Architektur. Nutzen Sie es dort, wo es wirklich benötigt wird.
Die Einführung von DevOps ist aus finanzieller Sicht teuer und ist nur dort gerechtfertigt, wo es wirtschaftliche Vorteile in anderen Bereichen bringt, und nicht nur für sich selbst.
DevOps-Engineers sind tatsächlich Pioniere – sie sind diejenigen, die diese Methodik als erste im Unternehmen implementieren und die entsprechenden Prozesse aufbauen müssen. Um dies erfolgreich zu gestalten, ist es wichtig, dass der Spezialist ständig mit Mitarbeitern und Kollegen auf allen Ebenen interagiert. Wie ich oft sage, müssen alle Mitarbeiter des Unternehmens in den DevOps-Implementierungsprozess einbezogen werden: vom Reinigungspersonal bis zum CEO. Das ist eine zwingende Voraussetzung. Wenn das am wenigsten erfahrene Teammitglied nicht weiß und versteht, was DevOps ist und warum bestimmte organisatorische Maßnahmen ergriffen werden, wird die erfolgreiche Einführung nicht gelingen.
Zudem muss der DevOps-Engineer hin und wieder administrative Ressourcen nutzen. Zum Beispiel, um "Widerstände aus der Umgebung" zu überwinden – wenn das Team nicht bereit ist, die Tools und die Methodik von DevOps zu akzeptieren.
Entwickler sollten sich ausschließlich auf das Schreiben von Code und Tests konzentrieren. Dafür benötigen sie keinen leistungsstarken Laptop, auf dem sie die gesamte Infrastruktur des Projekts lokal aufbauen und verwalten. Ein Frontend-Entwickler beispielsweise speichert alle Elemente der Anwendung, einschließlich der Datenbank, des S3-Emulators (minio) und mehr, auf seinem Laptop. Das bedeutet, dass er viel Zeit mit der Wartung dieser lokalen Infrastruktur verbringt und allein mit allen Problemen dieser Lösung zu kämpfen hat, anstatt Code für das Frontend zu entwickeln. Solche Personen könnten sich gegen Veränderungen sträuben.
Es gibt jedoch Teams, die im Gegenteil gerne neue Werkzeuge und Methoden einführen und aktiv an diesem Prozess teilnehmen. Selbst in solchen Fällen bleibt die Kommunikation zwischen dem DevOps-Ingenieur und dem Team unerlässlich.
Wann DevOps nicht benötigt wird
Es gibt Situationen, in denen DevOps nicht benötigt wird. Das ist eine Tatsache, die verstanden und akzeptiert werden muss.
Zunächst betrifft dies alle Unternehmen (insbesondere kleine Unternehmen), deren Gewinn nicht direkt von der Verfügbarkeit oder Abwesenheit von IT-Produkten abhängt, die Informationsservices für Kunden bereitstellen. Hierbei geht es nicht um die Unternehmenswebsite, sei sie eine statische "Visitenkarte" oder mit dynamischen Nachrichtenblöcken usw.
DevOps ist notwendig, wenn die Verfügbarkeit, Qualität und Zielgerichtetheit dieser Informationsservices für die Interaktion mit dem Kunden die Zufriedenheit des Kunden und dessen Wunsch beeinflusst, wieder zu Ihnen zurückzukehren.
Ein anschauliches Beispiel ist eine bekannte Bank. Das Unternehmen hat keine herkömmlichen Kundenbüros; der Dokumentenverkehr erfolgt per Post oder durch Kurierdienste, und viele Mitarbeiter arbeiten von zu Hause aus. Das Unternehmen hat aufgehört, nur eine Bank zu sein, und meiner Meinung nach hat es sich in ein IT-Unternehmen mit entwickelten DevOps-Technologien verwandelt.
Es gibt viele weitere Beispiele und Vorträge, die in den Aufzeichnungen von thematischen Meetups und Konferenzen zu finden sind. Einige davon habe ich persönlich besucht – es ist eine sehr wertvolle Erfahrung für diejenigen, die in diesem Bereich wachsen möchten. Hier sind Links zu YouTube-Kanälen mit guten Vorträgen und Materialien zu DevOps:
Denken Sie jetzt über Ihr Unternehmen nach und stellen Sie sich folgende Frage: Wie stark hängt Ihre Firma und deren Gewinn von IT-Produkten ab, die die Interaktion mit Kunden ermöglichen?
Wenn Ihr Unternehmen Fisch in einem kleinen Laden verkauft und die einzigen IT-Produkte zwei Konfigurationen von 1C: Unternehmen (Buchhaltung und UHN) sind, dann macht es wahrscheinlich keinen Sinn, über DevOps zu sprechen.
Sollten Sie jedoch in einem großen Handels- und Produktionsunternehmen tätig sein (zum Beispiel in der Herstellung von Jagdwaffen), dann sollten Sie ernsthaft darüber nachdenken. Sie können die Initiative ergreifen und Ihrer Führungskraft die Vorteile der Implementierung von DevOps näherbringen. Zudem könnten Sie diesen Prozess leiten. Eine proaktive Haltung ist eines der wesentlichen Prinzipien der DevOps-Philosophie.
Die Größe und der jährliche Finanzumsatz sind nicht das Hauptkriterium dafür, ob Ihre Firma DevOps benötigt.
Stellen Sie sich ein großes Industrieunternehmen vor, das nicht direkt mit Endkunden interagiert. Nehmen wir beispielsweise einige Automobilhersteller. Ich bin mir nicht ganz sicher, aber basierend auf meinen früheren Erfahrungen, wurde der Kundenkontakt über viele Jahre hauptsächlich per E-Mail und Telefon abgewickelt.
Ihre Kunden sind eine begrenzte Liste von Autohändlern, jedem von ihnen ist ein Fachmann des Herstellers zugeordnet. Sämtlicher interner Dokumentenverkehr erfolgt über das ERP-System SAP. Die internen Mitarbeiter sind im Grunde genommen die Kunden des Informationssystems. Die Verwaltung dieses Systems erfolgt jedoch mit klassischen Mitteln zur Verwaltung von Clustersystemen, was die Anwendung von DevOps-Praktiken ausschließt.
Die Schlussfolgerung ist: Für solche Unternehmen ist die Einführung von DevOps nicht von kritischer Bedeutung, wenn man die Ziele der Methodik zu Beginn des Artikels betrachtet. Allerdings schließe ich nicht aus, dass sie heute einige DevOps-Tools nutzen.
Andererseits gibt es viele kleine Unternehmen, die Software unter Anwendung der DevOps-Methodologie, -philosophie, -praktiken und -tools entwickeln. Diese sehen die Kosten für die Implementierung von DevOps als Investition, die ihnen hilft, im Softwaremarkt effektiv zu konkurrieren. Beispiele solcher Unternehmen findet man .
Das entscheidende Kriterium zur Einschätzung, ob DevOps notwendig ist: Welche Bedeutung haben Ihre IT-Produkte für das Unternehmen und die Kunden?
Wenn das Hauptprodukt des Unternehmens, das Gewinn erwirtschaftet, Software ist – dann benötigen Sie DevOps. Es spielt keine Rolle, ob Sie durch andere Waren tatsächlich Geld verdienen. Dazu zählen auch Online-Shops oder mobile Apps mit Spielen.
Jede Art von Spielen existiert nur durch Finanzierung: direkt oder indirekt von den Spielern. Bei Playgendary entwickeln wir kostenlose mobile Spiele, an deren direkter Erstellung mehr als 200 Personen beteiligt sind. Wie setzen wir DevOps ein?
Genau so, wie oben beschrieben. Ich stehe ständig im Kontakt mit Entwicklern und Testern, führe interne Schulungen für Mitarbeiter zur Methodologie und den Tools von DevOps durch.
Aktuell setzen wir Jenkins als Werkzeug für CI/CD-Pipelines ein, um sämtliche Build-Prozesse mit Unity zu realisieren und die Deployments in den App Store und den Play Market durchzuführen. Auch aus dem klassischen Werkzeugset:
- Asana – für das Projektmanagement. Eine Integration mit Jenkins ist eingerichtet.
- Google Meet – für Videokonferenzen.
- Slack – für die Kommunikation und verschiedene Benachrichtigungen, einschließlich Notifications aus Jenkins.
- Atlassian Confluence – für die Dokumentation und Teamarbeit.
In naher Zukunft planen wir die Implementierung einer statischen Code-Analyse mit SonarQube und die Durchführung von automatisierten UI-Tests mittels Selenium im Rahmen der Continuous Integration.
Abschließend
Ich möchte mit dem folgenden Gedanken abschließen: Um ein hochqualifizierter DevOps-Ingenieur zu werden, ist es unerlässlich, effektive Kommunikation mit Menschen zu erlernen.
Ein DevOps-Ingenieur ist ein Teamplayer. Und nichts anderes. Die Initiative zur Kommunikation mit Kollegen muss von ihm selbst ausgehen und nicht durch äußere Umstände ausgelöst werden. Ein DevOps-Spezialist sollte die besten Lösungen für das Team erkennen und vorschlagen.
Ja, die Implementierung jeder Lösung erfordert zahlreiche Diskussionen, und am Ende kann sie sich vollkommen ändern. Jemand, der sich selbst weiterentwickelt, Ideen anbietet und umsetzt, gewinnt sowohl für das Team als auch für den Arbeitgeber zunehmend an Wert. Das spiegelt sich letztendlich auch in der Höhe seiner monatlichen Vergütung oder in Form zusätzlicher Prämien wider.
Quelle: habr.com
