DevOps ist in den letzten Jahren zu einem sehr beliebten Thema geworden. Viele Menschen träumen davon, dort einzusteigen, aber wie die Praxis zeigt, oft nur wegen der Höhe der Gehälter.
Manche Leute nennen DevOps in ihrem Lebenslauf, obwohl sie den Kern des Begriffs nicht immer kennen oder verstehen. Manche Leute denken, dass man nach dem Studium von Ansible, GitLab, Jenkins, Terraform und Co. (die Liste lässt sich beliebig fortsetzen) sofort zum „Devopsisten“ wird. Das stimmt natürlich nicht.
Seit einigen Jahren beschäftige ich mich hauptsächlich mit der Implementierung von DevOps in verschiedenen Unternehmen. Zuvor war er mehr als 20 Jahre lang in Positionen vom Systemadministrator bis zum IT-Leiter tätig. Derzeit DevOps Lead Engineer bei Playgendary.
Wer ist DevOps?
Die Idee, einen Artikel zu schreiben, entstand nach einer anderen Frage: „Wer ist DevOps?“ Es gibt noch keinen etablierten Begriff dafür, was oder wer es ist. Einige der Antworten finden Sie bereits hier . Zuerst werde ich die wichtigsten Punkte hervorheben und dann meine Beobachtungen und Gedanken mitteilen.
DevOps ist kein Spezialist, der eingestellt werden kann, keine Gruppe von Versorgungsunternehmen und keine Abteilung von Entwicklern mit Ingenieuren.
DevOps ist eine Philosophie und Methodik.
Mit anderen Worten handelt es sich um eine Reihe von Praktiken, die Entwicklern helfen, aktiv mit Systemadministratoren zu interagieren. Das heißt, Arbeitsprozesse miteinander zu verbinden und zu integrieren.
Mit dem Aufkommen von DevOps blieben die Struktur und die Rollen der Spezialisten gleich (es gibt Entwickler, es gibt Ingenieure), aber die Regeln der Interaktion haben sich geändert. Die Grenzen zwischen den Abteilungen verschwimmen.
Die Ziele von DevOps lassen sich in drei Punkten beschreiben:
- Die Software muss regelmäßig aktualisiert werden.
- Software muss schnell fertig sein.
- Die Software sollte bequem und in kurzer Zeit bereitgestellt werden.
Es gibt kein einzelnes Tool für DevOps. Das Konfigurieren, Bereitstellen und Studieren mehrerer Produkte bedeutet nicht, dass DevOps im Unternehmen Einzug gehalten hat. Es gibt viele Werkzeuge, die alle in unterschiedlichen Phasen eingesetzt werden, aber einem gemeinsamen Zweck dienen.
Und das ist nur ein Teil der DevOps-Tools
Ich führe nun schon seit mehr als zwei Jahren Vorstellungsgespräche für die Position eines DevOps-Ingenieurs und mir ist klar geworden, wie wichtig es ist, die Essenz des Begriffs klar zu verstehen. Ich habe konkrete Erfahrungen, Beobachtungen und Gedanken gesammelt, die ich teilen möchte.
Aus Interviewerfahrung sehe ich folgendes Bild: Spezialisten, die DevOps als Berufsbezeichnung betrachten, haben meist Missverständnisse mit Kollegen.
Es gab ein markantes Beispiel. Ein junger Mann kam mit vielen klugen Worten in seinem Lebenslauf zu einem Vorstellungsgespräch. Bei seinen letzten drei Jobs verfügte er über 5-6 Monate Berufserfahrung. Ich habe zwei Startups verlassen, weil sie „nicht durchstarteten“. Aber über das dritte Unternehmen sagte er, dass ihn dort niemand verstehe: Die Entwickler schreiben Code unter Windows, und der Direktor erzwingt, dass dieser Code in reguläres Docker „verpackt“ und in die CI/CD-Pipeline integriert wird. Der Typ sagte viel Negatives über seinen jetzigen Arbeitsplatz und seine Kollegen – ich wollte nur antworten: „Sie verkaufen also keinen Elefanten.“
Dann habe ich ihm für jeden Kandidaten eine Frage gestellt, die ganz oben auf meiner Liste steht.
— Was bedeutet DevOps für Sie persönlich?
- Generell oder wie nehme ich das wahr?
Mich interessierte seine persönliche Meinung. Er kannte die Theorie und den Ursprung des Begriffs, widersprach ihnen jedoch entschieden. Er glaubte, DevOps sei eine Berufsbezeichnung. Hier liegt die Wurzel seiner Probleme. Sowie andere Spezialisten mit der gleichen Meinung.
Arbeitgeber, die viel über die „Magie von DevOps“ gehört haben, möchten eine Person finden, die diese „Magie“ erschafft. Und Bewerber aus der Kategorie „DevOps ist ein Job“ verstehen nicht, dass sie mit diesem Ansatz den Erwartungen nicht gerecht werden können. Und im Allgemeinen haben sie DevOps in ihren Lebenslauf geschrieben, weil es ein Trend ist und sie viel dafür bezahlen.
DevOps-Methodik und -Philosophie
Die Methodik kann theoretisch und praktisch sein. In unserem Fall ist es das zweite. Wie ich oben erwähnt habe, handelt es sich bei DevOps um eine Reihe von Praktiken und Strategien, die zur Erreichung festgelegter Ziele eingesetzt werden. Und je nach Geschäftsprozess des Unternehmens kann es in jedem Fall deutliche Unterschiede geben. Was es nicht besser oder schlechter macht.
Die DevOps-Methodik ist lediglich ein Mittel, um Ziele zu erreichen.
Nun zur DevOps-Philosophie. Und das ist wahrscheinlich die schwierigste Frage.
Es ist ziemlich schwierig, eine kurze und prägnante Antwort zu formulieren, da diese noch nicht formalisiert wurde. Und da Anhänger der DevOps-Philosophie eher in der Praxis engagiert sind, bleibt einfach keine Zeit zum Philosophieren. Dies ist jedoch ein sehr wichtiger Prozess. Darüber hinaus steht es in direktem Zusammenhang mit Ingenieurtätigkeiten. Es gibt sogar ein spezielles Wissensgebiet – .
An meiner Universität gab es kein solches Fach, ich musste alles selbst lernen und dabei die Materialien verwenden, die ich in den 90er Jahren finden konnte. Das Thema ist für die Ingenieurausbildung optional, daher fehlt die Formalisierung der Antwort. Aber diejenigen, die sich ernsthaft mit DevOps befassen, beginnen, einen gewissen „Geist“ oder eine „unbewusste Vollständigkeit“ aller Prozesse des Unternehmens zu spüren.
Anhand meiner eigenen Erfahrung habe ich versucht, einige der „Postulate“ dieser Philosophie zu formalisieren. Das Ergebnis ist folgendes:
- DevOps ist nichts Unabhängiges, das in einen separaten Wissens- oder Tätigkeitsbereich unterteilt werden kann.
- Alle Mitarbeiter des Unternehmens sollten sich bei der Planung ihrer Aktivitäten an der DevOps-Methodik orientieren.
- DevOps betrifft alle Prozesse innerhalb eines Unternehmens.
- DevOps dient dazu, die Zeitkosten für alle Prozesse innerhalb eines Unternehmens zu reduzieren, um die Entwicklung seiner Dienste und maximalen Kundenkomfort sicherzustellen.
- DevOps ist in moderner Sprache die proaktive Haltung jedes Mitarbeiters des Unternehmens, die darauf abzielt, Zeitkosten zu reduzieren und die Qualität der IT-Produkte um uns herum zu verbessern.
Ich denke, dass meine „Postulate“ ein separates Diskussionsthema sind. Aber jetzt gibt es etwas, worauf man aufbauen kann.
Was DevOps macht
Das Schlüsselwort hier ist Kommunikation. Es gibt viele Mitteilungen, deren Initiator genau derselbe DevOps-Ingenieur sein sollte. Warum so? Denn das ist Philosophie und Methodik und erst dann Ingenieurswissen.
Ich kann nicht mit hundertprozentiger Sicherheit über den westlichen Arbeitsmarkt sprechen. Aber ich weiß ziemlich viel über den DevOps-Markt in Russland. Zusätzlich zu Hunderten von Interviews habe ich in den letzten anderthalb Jahren an Hunderten von technischen Vorverkäufen für den Service „Implementierung von DevOps“ für große russische Unternehmen und Banken teilgenommen.
In Russland ist DevOps ein noch sehr junges, aber bereits im Trend liegendes Thema. Soweit ich weiß, betrug der Mangel an solchen Fachkräften allein in Moskau im Jahr 2019 mehr als 1000 Menschen. Und das Wort Kubernetes ist für Arbeitgeber fast wie ein rotes Tuch für einen Bullen. Anhänger dieses Tools sind bereit, es auch dort einzusetzen, wo es nicht notwendig und wirtschaftlich rentabel ist. Der Arbeitgeber weiß nicht immer, in welchen Fällen er besser geeignet ist, und bei ordnungsgemäßer Bereitstellung kostet die Wartung eines Kubernetes-Clusters zwei- bis dreimal mehr als die Bereitstellung einer Anwendung mithilfe eines herkömmlichen Clusterschemas. Nutzen Sie es dort, wo Sie es wirklich brauchen.
Die Implementierung von DevOps ist finanziell teuer. Und es ist nur dann gerechtfertigt, wenn es in anderen Bereichen wirtschaftliche Vorteile bringt, und nicht für sich allein.
DevOps-Ingenieure sind in der Tat Pioniere – sie sollten die ersten sein, die diese Methodik im Unternehmen implementieren und Prozesse entwickeln. Damit dies gelingt, muss der Spezialist ständig mit Mitarbeitern und Kollegen auf allen Ebenen interagieren. Wie ich immer sage, sollten alle Mitarbeiter des Unternehmens in den DevOps-Implementierungsprozess einbezogen werden: von der Putzfrau bis zum CEO. Und das ist eine Voraussetzung. Wenn das jüngste Mitglied des Teams nicht weiß und versteht, was DevOps ist und warum bestimmte organisatorische Maßnahmen durchgeführt werden, wird eine erfolgreiche Implementierung nicht funktionieren.
Außerdem muss ein DevOps-Ingenieur von Zeit zu Zeit eine Verwaltungsressource nutzen. Zum Beispiel, um „Umweltwiderstände“ zu überwinden – wenn das Team nicht bereit ist, DevOps-Tools und -Methoden zu akzeptieren.
Der Entwickler sollte nur Code und Tests schreiben. Dafür benötigt er keinen superstarken Laptop, auf dem er die gesamte Projektinfrastruktur bereitstellt und lokal betreut. Beispielsweise behält ein Front-End-Entwickler alle Elemente der Anwendung auf seinem Laptop, einschließlich der Datenbank, des S3-Emulators (Minio) usw. Das heißt, er verbringt viel Zeit damit, diese lokale Infrastruktur aufrechtzuerhalten und kämpft im Alleingang mit allen Problemen einer solchen Lösung. Anstatt Code für die Front zu entwickeln. Solche Menschen können jeder Veränderung gegenüber sehr resistent sein.
Es gibt aber auch Teams, die im Gegenteil gerne neue Tools und Methoden einführen und sich aktiv an diesem Prozess beteiligen. Obwohl auch in diesem Fall die Kommunikation zwischen dem DevOps-Ingenieur und dem Team nicht abgebrochen wurde.
Wenn DevOps nicht benötigt wird
Es gibt Situationen, in denen DevOps nicht erforderlich ist. Das ist eine Tatsache – sie muss verstanden und akzeptiert werden.
Dies gilt zunächst für alle Unternehmen (insbesondere kleine Unternehmen), deren Gewinn nicht direkt vom Vorhandensein oder Fehlen von IT-Produkten abhängt, die Informationsdienste für Kunden bereitstellen. Und hier geht es nicht um die Website des Unternehmens, sei es eine statische „Visitenkarte“ oder mit dynamischen Nachrichtenblöcken usw.
DevOps ist erforderlich, wenn die Zufriedenheit Ihres Kunden und sein Wunsch, wieder zu Ihnen zurückzukehren, von der Verfügbarkeit dieser Informationsdienste für die Interaktion mit dem Kunden, ihrer Qualität und Zielgruppe abhängen.
Ein markantes Beispiel ist eine bekannte Bank. Das Unternehmen verfügt nicht über herkömmliche Kundenbüros, der Dokumentenfluss erfolgt per Post oder Kurier und viele Mitarbeiter arbeiten von zu Hause aus. Das Unternehmen ist nicht mehr nur eine Bank, sondern hat sich meiner Meinung nach zu einem IT-Unternehmen mit entwickelten DevOps-Technologien entwickelt.
Viele weitere Beispiele und Vorträge finden sich in den Aufzeichnungen thematischer Treffen und Konferenzen. Einige von ihnen habe ich persönlich besucht – das ist eine sehr nützliche Erfahrung für diejenigen, die sich in diese Richtung weiterentwickeln möchten. Hier finden Sie Links zu YouTube-Kanälen mit guten Vorträgen und Materialien zum Thema DevOps:
Schauen Sie sich nun Ihr Unternehmen an und denken Sie darüber nach: Wie sehr hängen Ihr Unternehmen und seine Gewinne von IT-Produkten ab, um die Interaktion mit Kunden zu ermöglichen?
Wenn Ihr Unternehmen Fisch in einem kleinen Laden verkauft und das einzige IT-Produkt zwei 1C: Enterprise-Konfigurationen (Buchhaltung und UNF) sind, dann macht es kaum Sinn, über DevOps zu sprechen.
Wenn Sie in einem großen Handels- und Produktionsunternehmen arbeiten (z. B. Jagdgewehre produzieren), sollten Sie darüber nachdenken. Sie können die Initiative ergreifen und Ihrem Management die Perspektiven für die Implementierung von DevOps vermitteln. Nun, und gleichzeitig diesen Prozess leiten. Eine proaktive Haltung ist einer der wichtigen Grundsätze der DevOps-Philosophie.
Die Größe und das Volumen des jährlichen Finanzumsatzes sind nicht das Hauptkriterium dafür, ob Ihr Unternehmen DevOps benötigt.
Stellen wir uns ein großes Industrieunternehmen vor, das nicht direkt mit Kunden interagiert. Zum Beispiel einige Autohersteller und Automobilhersteller. Ich bin mir jetzt nicht sicher, aber meiner Erfahrung nach erfolgte viele Jahre lang die gesamte Kundeninteraktion per E-Mail und Telefon.
Ihre Kunden sind eine begrenzte Liste von Autohändlern. Und jedem wird vom Hersteller ein Spezialist zugeteilt. Der gesamte interne Dokumentenfluss erfolgt über SAP ERP. Interne Mitarbeiter sind im Wesentlichen Kunden des Informationssystems. Dieser IS wird jedoch mit klassischen Mitteln zur Verwaltung von Clustersystemen gesteuert. Dies schließt die Möglichkeit der Verwendung von DevOps-Praktiken aus.
Daher die Schlussfolgerung: Für solche Unternehmen ist die Implementierung von DevOps nicht von entscheidender Bedeutung, wenn wir uns an die Ziele der Methodik vom Anfang des Artikels erinnern. Aber ich schließe nicht aus, dass sie heute einige DevOps-Tools verwenden.
Auf der anderen Seite gibt es viele kleine Unternehmen, die Software mithilfe der DevOps-Methodik, -Philosophie, -Praktiken und -Tools entwickeln. Und sie glauben, dass die Kosten für die Implementierung von DevOps die Kosten sind, die es ihnen ermöglichen, effektiv auf dem Softwaremarkt zu konkurrieren. Beispiele für solche Unternehmen sind zu sehen .
Das Hauptkriterium, um zu verstehen, ob DevOps benötigt wird: Welchen Wert Ihre IT-Produkte für das Unternehmen und die Kunden haben.
Wenn das Hauptprodukt des Unternehmens, das Gewinn generiert, Software ist, benötigen Sie DevOps. Und es ist nicht so wichtig, ob Sie mit anderen Produkten echtes Geld verdienen. Hierzu zählen auch Online-Shops oder mobile Anwendungen mit Spielen.
Alle Spiele existieren dank der Finanzierung: direkt oder indirekt durch die Spieler. Bei Playgendary entwickeln wir kostenlose Handyspiele, an deren Entwicklung über 200 Personen direkt beteiligt sind. Wie nutzen wir DevOps?
Ja, genau das gleiche wie oben beschrieben. Ich kommuniziere ständig mit Entwicklern und Testern und führe interne Schulungen für Mitarbeiter zu DevOps-Methodik und -Tools durch.
Wir nutzen Jenkins jetzt aktiv als CI/CD-Pipeline-Tool für die Ausführung aller Assembly-Pipelines mit Unity und die anschließende Bereitstellung im App Store und Play Market. Mehr aus dem klassischen Toolkit:
- Asana – für Projektmanagement. Die Integration mit Jenkins wurde konfiguriert.
- Google Meet – für Videokonferenzen.
- Slack – für Kommunikation und verschiedene Benachrichtigungen, einschließlich Benachrichtigungen von Jenkins.
- Atlassian Confluence – für Dokumentation und Gruppenarbeit.
Zu unseren unmittelbaren Plänen gehört die Einführung einer statischen Codeanalyse mit SonarQube und die Durchführung automatisierter UI-Tests mit Selenium in der Phase der kontinuierlichen Integration.
Statt einer Schlussfolgerung
Abschließen möchte ich mit folgendem Gedanken: Um ein hochqualifizierter DevOps-Ingenieur zu werden, ist es wichtig zu lernen, wie man live mit Menschen kommuniziert.
Ein DevOps-Ingenieur ist ein Teamplayer. Und sonst nichts. Die Initiative zur Kommunikation mit Kollegen sollte von ihm ausgehen und nicht unter dem Einfluss bestimmter Umstände. Ein DevOps-Spezialist muss die beste Lösung für das Team finden und vorschlagen.
Und ja, die Umsetzung jeder Lösung erfordert viele Diskussionen und am Ende kann es sein, dass sich alles völlig ändert. Da er sich selbstständig entwickelt, seine Ideen vorschlägt und umsetzt, ist er sowohl für das Team als auch für den Arbeitgeber von wachsendem Wert. Was sich letztlich in der Höhe seiner monatlichen Vergütung oder in Form zusätzlicher Prämien niederschlägt.
Source: habr.com