Das Thema DevOps ist in den letzten Jahren sehr populär geworden. Viele träumen davon, darin tätig zu werden, aber wie die Praxis zeigt, geschieht dies oft nur aufgrund des Gehaltsniveaus.
Einige geben in ihrem Lebenslauf DevOps an, obwohl sie nicht immer die Essenz des Begriffs verstehen. Manche glauben, dass sie, nachdem sie Ansible, GitLab, Jenkins, Terraform und ähnliche Tools gelernt haben (die Liste kann nach Belieben fortgesetzt werden), sofort „DevOps“ werden. Das ist natürlich nicht der Fall.
In den letzten Jahren beschäftige ich mich hauptsächlich mit der Implementierung von DevOps in verschiedenen Unternehmen. Zuvor arbeitete ich über 20 Jahre in Positionen vom Systemadministrator bis hin zum IT-Direktor. Derzeit bin ich DevOps Lead Engineer bei Playgendary.
Wer ist DevOps
Die Idee, diesen Artikel zu schreiben, entstand nach einer weiteren Frage: „Wer ist DevOps?“. Es gibt bis heute keinen einheitlichen Begriff dafür, was oder wer das ist. Einige Antworten sind bereits hier vorhanden. . Zunächst werde ich die wichtigsten Punkte daraus herausstellen und dann meine Beobachtungen und Gedanken teilen.
DevOps ist kein Spezialist, den man einstellen kann, kein Werkzeugset und keine Abteilung von Entwicklern und Ingenieuren.
DevOps ist eine Philosophie und Methodologie.
Anders ausgedrückt, es ist eine Sammlung von Praktiken, die Entwicklern hilft, aktiv mit Systemadministratoren zusammenzuarbeiten. Das heißt, Arbeitsprozesse miteinander zu verbinden und zu integrieren.
Mit dem Erscheinen von DevOps sind die Struktur und die Rollen der Spezialisten gleich geblieben (es gibt Entwickler, es gibt Ingenieure), aber die Regeln für die Zusammenarbeit haben sich geändert. Die Grenzen zwischen den Abteilungen haben sich verwischt.
Die Ziele von DevOps lassen sich in drei Punkten beschreiben:
- Software sollte regelmäßig aktualisiert werden.
- Software sollte schnell entwickelt werden.
- Software sollte einfach und in kurzer Zeit bereitgestellt werden.
DevOps hat kein einzelnes Werkzeug. Wenn mehrere Produkte eingerichtet, installiert und erlernt werden, bedeutet das nicht, dass im Unternehmen DevOps vorhanden ist. Es gibt viele Werkzeuge, die in verschiedenen Phasen eingesetzt werden, doch sie dienen einem gemeinsamen Ziel.
Und das ist nur ein Teil der DevOps-Werkzeuge.
Ich führe seit mehr als 2 Jahren Interviews für die Position des DevOps-Ingenieurs und mir ist klar geworden, wie wichtig es ist, die Essenz des Begriffs klar zu verstehen. Ich habe spezifische Erfahrungen, Beobachtungen und Gedanken gesammelt, die ich teilen möchte.
Aus meiner Erfahrung mit Interviews sehe ich folgendes Bild: Fachkräfte, die DevOps als Stelle betrachten, haben normalerweise Missverständnisse mit Kollegen..
Es gab ein prägnantes Beispiel. Ein junger Mann kam zum Vorstellungsgespräch mit einer Menge kluger Worte in seinem Lebenslauf. In den letzten drei Arbeitsstellen hatte er eine Anstellung von 5-6 Monaten. Aus zwei Startups war er gegangen, weil sie "nicht abgehoben" sind. Und über das dritte Unternehmen sagte er, dass dort niemand ihn versteht: Die Entwickler schreiben Code für Windows, und der Direktor zwingt dazu, diesen Code in einen normalen Docker zu packen und in die CI/CD-Pipeline einzufügen. Der Junge erzählte viel Negatives über seinen aktuellen Arbeitsplatz und seine Kollegen – man hätte ihm nur antworten wollen: "So kannst du keinen Elefanten verkaufen."
Dann stellte ich ihm eine Frage, die in meiner Liste eine der ersten für jeden Kandidaten ist.
— Was bedeutet DevOps persönlich für dich?
— Allgemein oder wie ich es wahrnehme?
Ich war an seiner persönlichen Meinung interessiert. Er kannte die Theorie und die Herkunft des Begriffs, war aber kategorisch anderer Meinung. Er dachte, dass DevOps eine Position sei. Hier liegt die Wurzel seiner Probleme. Genauso wie bei anderen Fachleuten mit derselben Meinung.
Arbeitgeber, die von der "Magie von DevOps" gehört haben, möchten eine Person finden, die kommt und diese "Magie" schafft. Und Bewerber aus der Kategorie "DevOps ist eine Position" verstehen nicht, dass sie mit dieser Einstellung die Erwartungen nicht erfüllen können. Und im Allgemeinen haben sie in ihrem Lebenslauf DevOps angegeben, weil es ein Trend ist und dafür viel gezahlt wird.
Methodologie und Philosophie von DevOps
Die Methodologie kann theoretisch oder praktisch sein. In unserem Fall ist es letzteres. Wie ich bereits erwähnt habe, ist DevOps eine Reihe von Praktiken und Strategien, die angewendet werden, um die festgelegten Ziele zu erreichen. Und in jedem Fall kann es je nach Geschäftsprozessen des Unternehmens erheblich variieren. Was es nicht besser oder schlechter macht.
Die Methodologie von DevOps ist nur ein Mittel zur Erreichung der gesetzten Ziele.
Jetzt zum Thema der Philosophie von DevOps. Und das ist wahrscheinlich die schwierigste Frage.
Es ist ziemlich schwierig, eine kurze und prägnante Antwort zu formulieren, da sie noch nicht formalisiert ist. Und da die Anhänger der Philosophie von DevOps mehr mit der Praxis beschäftigt sind, bleibt einfach keine Zeit für philosophische Überlegungen. Dennoch ist dies ein sehr wichtiger Prozess. Er bezieht sich direkt auf die Ingenieurtätigkeit. Es gibt sogar einen spezialisierten Bereich des Wissens — .
An meiner Hochschule gab es dieses Fach nicht, ich musste alles selbst mit den Materialien lernen, die ich in den 90ern finden konnte. Das Thema ist für die Ingenieurausbildung nicht zwingend erforderlich, was sich auch in der Unformuliertheit der Antwort widerspiegelt. Aber die Menschen, die sich ernsthaft mit DevOps beschäftigt haben, beginnen, einen gewissen ‚Geist‘ oder ‚unbewusste Allumfänglichkeit‘ aller Prozesse im Unternehmen zu spüren.
Ich habe versucht, aus meiner Erfahrung einige ‚Postulate‘ dieser Philosophie zu formulieren. Es ergibt sich Folgendes:
- DevOps ist nichts Eigenständiges, das man als separates Wissens- oder Tätigkeitsfeld abgrenzen kann.
- Die DevOps-Methodologie sollte von allen Mitarbeitern des Unternehmens befolgt werden, wenn sie ihre Tätigkeiten planen.
- DevOps betrifft alle Prozesse innerhalb des Unternehmens.
- DevOps existiert, um den zeitlichen Aufwand für alle Prozesse innerhalb des Unternehmens zu reduzieren, um die Entwicklung seiner Dienstleistungen und den maximalen Komfort für den Kunden sicherzustellen.
- DevOps ist in modernen Begriffen die proaktive Haltung jedes Mitarbeiters im Unternehmen, die darauf abzielt, die zeitlichen Kosten zu senken und die Qualität der IT-Produkte, die uns umgeben, zu verbessern.
Ich denke, meine ‚Postulate‘ sind ein separates Diskussionsthema. Aber jetzt gibt es einen Ausgangspunkt.
Was macht DevOps
Das Schlüsselwort hier ist Kommunikation. Es gibt unzählige Kommunikationsprozesse, die genau von diesem DevOps-Ingenieur initiiert werden sollten. Warum? Weil es eine Philosophie und Methodologie ist und erst danach technisches Wissen.
Über den westlichen Arbeitsmarkt kann ich nicht mit 100%iger Sicherheit sprechen. Aber über den DevOps-Markt in Russland weiß ich ziemlich viel. Neben Hunderten von Vorstellungsgesprächen habe ich in den letzten anderthalb Jahren an rund hundert technischen Presales für den Service ‚Implementierung von DevOps‘ für große russische Unternehmen und Banken teilgenommen.
In Russland ist DevOps noch ein sehr junges, aber bereits trendiges Thema. Soweit ich weiß, gab es allein in Moskau im Jahr 2019 einen Mangel an solchen Spezialisten von über 1000 Personen. Das Wort Kubernetes hat für Arbeitgeber fast die gleiche Wirkung wie ein rotes Tuch für den Stier. Befürworter dieses Instruments sind bereit, es sogar dort zu verwenden, wo es nicht nötig und wirtschaftlich nicht vorteilhaft ist. Der Arbeitgeber versteht nicht immer, in welchen Fällen es sinnvoll ist, was zu verwenden, und bei einer ordnungsgemäßen Bereitstellung kostet der Inhalt des Kubernetes-Clusters 2-3 Mal mehr als die Bereitstellung einer Anwendung nach einem herkömmlichen Cluster-Schema. Verwenden Sie es dort, wo es wirklich benötigt wird.
Die Einführung von DevOps aus finanzieller Sicht ist teuer. Und sie ist nur dort gerechtfertigt, wo sie in anderen Bereichen wirtschaftlichen Nutzen bringt, und nicht um ihrer selbst willen.
DevOps-Ingenieure sind tatsächlich Pioniere – sie sind diejenigen, die diese Methodologie im Unternehmen als Erste einführen und Prozesse aufbauen müssen. Damit dies erfolgreich ist, muss der Spezialist ständig mit Mitarbeitern und Kollegen auf allen Ebenen interagieren. Wie ich normalerweise sage, müssen alle Mitarbeiter des Unternehmens in den DevOps-Einführungsprozess einbezogen werden: von der Reinigungskraft bis zum CEO. Und das ist eine zwingende Voraussetzung. Wenn das jüngste Mitglied des Teams nicht weiß und versteht, was DevOps ist und warum bestimmte organisatorische Maßnahmen ergriffen werden, wird die erfolgreiche Einführung nicht gelingen.
Außerdem muss der DevOps-Ingenieur von Zeit zu Zeit administrative Ressourcen nutzen. Zum Beispiel, um den 'Widerstand der Umgebung' zu überwinden – wenn das Team nicht bereit ist, die Werkzeuge und Methodik von DevOps zu akzeptieren.
Ein Entwickler sollte nur Code und Tests schreiben. Dafür benötigt er kein super leistungsstarkes Laptop, auf dem er die gesamte Infrastruktur des Projekts lokal aufbauen und unterstützen würde. Zum Beispiel hat der Frontend-Entwickler alle Elemente der Anwendung auf seinem Laptop, einschließlich der Datenbank, einem S3-Emulator (minio) und anderen. Das heißt, er verbringt viel Zeit mit der Pflege dieser lokalen Infrastruktur und kämpft allein gegen alle Probleme, die mit dieser Lösung einhergehen, anstatt Code für das Frontend zu entwickeln. Solche Personen können sich stark gegen Veränderungen sträuben.
Es gibt jedoch Teams, die im Gegenteil bereit sind, neue Werkzeuge und Methoden zu implementieren und aktiv an diesem Prozess teilnehmen. Auch in solchen Fällen werden die Kommunikationen zwischen dem DevOps-Ingenieur und dem Team nicht abgeschafft.
Wann DevOps nicht notwendig ist
Es gibt Situationen, in denen DevOps nicht notwendig ist. Das ist eine Tatsache, die man verstehen und akzeptieren muss.
Dies betrifft insbesondere Unternehmen (vor allem kleine Unternehmen), deren Gewinn nicht direkt von der Verfügbarkeit oder Abwesenheit von IT-Produkten abhängt, die Informationsdienste für Kunden bereitstellen. Dabei geht es nicht um die Unternehmenswebsite, egal ob sie eine statische "Visitenkarte" oder dynamische Nachrichtenblöcke usw. hat.
DevOps ist erforderlich, wenn die Verfügbarkeit dieser Informationsdienste zur Interaktion mit dem Kunden, deren Qualität und Zielgerichtetheit die Zufriedenheit Ihrer Kunden und deren Wunsch beeinflusst, immer wieder zu Ihnen zurückzukehren.
Ein anschauliches Beispiel ist eine bekannte Bank. Das Unternehmen hat keine gewohnten Kundenbüros, der Dokumentenaustausch erfolgt per Post oder Kurier, und viele Mitarbeiter arbeiten von zu Hause aus. Das Unternehmen hat aufgehört, lediglich eine Bank zu sein, und hat sich meiner Meinung nach in ein IT-Unternehmen mit fortschrittlicher DevOps-Technologie 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 alle, die sich in diesem Bereich weiterentwickeln möchten. Hier sind Links zu YouTube-Kanälen mit guten Vorträgen und Materialien zu DevOps:
Sehen Sie sich jetzt Ihr Unternehmen an und denken Sie an Folgendes: Wie stark hängt Ihr Unternehmen und dessen Gewinn von IT-Produkten ab, die die Interaktion mit dem Kunden gewährleisten?
Wenn Ihr Unternehmen in einem kleinen Laden Fisch verkauft und die einzigen IT-Produkte zwei Konfigurationen von 1C: Unternehmenssoftware (Buchhaltung und UNF) sind, macht es wahrscheinlich keinen Sinn, über DevOps zu sprechen.
Wenn Sie jedoch in einem großen Handels- und Produktionsunternehmen arbeiten (zum Beispiel bei der Herstellung von Jagdgewehren), sollten Sie darüber nachdenken. Sie können Initiative zeigen und Ihrem Management die Perspektiven der Implementierung von DevOps nahebringen. Und nebenbei diesen Prozess anführen. Eine proaktive Haltung ist ein wichtiger Grundsatz der DevOps-Philosophie.
Die Größe und das Volumen des jährlichen Finanzumsatzes sind kein ausschlaggebendes Kriterium 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 Automobilhersteller und Fahrzeugbauunternehmen. Ich bin mir jetzt nicht sicher, aber aus meiner bisherigen Erfahrung wurde viele Jahre lang die gesamte Interaktion mit Kunden über E-Mail und Telefon abgewickelt.
Ihre Kunden sind eine begrenzte Liste von Autohändlern. Und jedem Händler ist ein Spezialist des Herstellers zugeordnet. Der gesamte interne Dokumentenverkehr erfolgt über ERP SAP. Interne Mitarbeiter sind im Grunde genommen die Kunden des Informationssystems. Doch das Management dieses IS erfolgt mit klassischen Methoden des Cluster-Managements. Dies schließt die Möglichkeit aus, DevOps-Praktiken anzuwenden.
Fazit: Für solche Unternehmen ist die Einführung von DevOps nicht von entscheidender Bedeutung, wenn wir die Ziele der Methodik zu Beginn des Artikels bedenken. Ich schließe jedoch nicht aus, dass sie einige DevOps-Tools heute nutzen.
Andererseits gibt es viele kleine Unternehmen, die Software unter Verwendung von DevOps-Methodiken, -Philosophien, -Praktiken und -Tools entwickeln. Sie betrachten die Kosten für die Implementierung von DevOps als Ausgaben, die ihnen ermöglichen, effektiv im Softwaremarkt zu konkurrieren. Beispiele solcher Unternehmen können gesehen werden. .
Das Hauptkriterium für das Verständnis, ob DevOps benötigt wird: welchen Wert haben Ihre IT-Produkte für das Unternehmen und die Kunden.
Wenn das Hauptprodukt des Unternehmens, das Gewinn bringt, Software ist — benötigen Sie DevOps. Es spielt auch keine Rolle, ob Sie mit anderen Produkten echtes Geld verdienen. Dazu gehören auch Online-Shops oder mobile Spiele-Apps.
Alle Spiele existieren dank der Finanzierung: direkt oder indirekt durch die Spieler. Bei Playgendary entwickeln wir kostenlose mobile Spiele, an deren direkter Erstellung mehr als 200 Personen beteiligt sind. Wie verwenden wir DevOps?
Genau so, wie oben beschrieben. Ich stehe in ständigem Kontakt mit Entwicklern und Testern, führe interne Schulungen über die Methodik und Tools von DevOps durch.
Derzeit nutzen wir Jenkins aktiv als CI/CD-Tool für die Ausführung aller Build-Pipelines mit Unity und die anschließende Bereitstellung im App Store und Play Market. Weitere klassische Werkzeuge sind:
- Asana – für das Projektmanagement. Die Integration mit Jenkins ist eingerichtet.
- Google Meet – für Videokonferenzen.
- Slack – für Kommunikation und verschiedene Benachrichtigungen, einschließlich solcher aus Jenkins.
- Atlassian Confluence – für Dokumentation und Teamarbeit.
In naher Zukunft planen wir die Implementierung einer statischen Codeanalyse mit SonarQube und automatisierte UI-Tests mit Selenium im Rahmen der kontinuierlichen Integration.
Zum Abschluss
Ich möchte mit folgendem Gedanken abschließen: Um ein hochqualifizierter DevOps-Ingenieur zu werden, ist es entscheidend, das persönliche Gespräch mit Menschen zu erlernen.
Ein DevOps-Ingenieur ist ein Teamplayer. Und nichts anderes. Die Initiative zur Kommunikation mit Kollegen sollte von ihm selbst ausgehen, nicht durch äußere Umstände bedingt. Der DevOps-Spezialist muss die besten Lösungen für das Team erkennen und vorschlagen.
Und ja, die Einführung jeder Lösung erfordert viele Diskussionen und könnte am Ende ganz anders aussehen. Wenn jemand eigenständig wächst, Ideen einbringt und umsetzt, wird diese Person immer wertvoller für das Team sowie für den Arbeitgeber. Das spiegelt sich letztendlich auch in der Höhe der monatlichen Vergütung oder in Form zusätzlicher Prämien wider.
Quelle: habr.com
