In letzter Zeit haben solche Anzeigen das Internet überflutet. Trotz des angenehmen Gehalts muss man sich schämen, dass eine wilde Häresie drin steht. Zunächst wird davon ausgegangen, dass „DevOps“ und „engineer“ irgendwie in einem Wort zusammengefügt werden können. Anschließend wird eine zufällige Liste von Anforderungen erstellt, von denen einige eindeutig von der Stelle des Systemadministrators übernommen wurden.
In diesem Beitrag möchte ich ein wenig darüber sprechen, wie wir dahin gekommen sind, was DevOps wirklich ist und was wir jetzt damit machen sollen.
Solche offenen Stellen können auf jede erdenkliche Weise verurteilt werden, aber die Tatsache bleibt: Es gibt viele davon, und so funktioniert der Markt derzeit. Wir haben eine Devo-Konferenz abgehalten und offen erklärt: " DevOops - nicht für DevOps-Ingenieure." Hier wird es vielen seltsam und wild vorkommen: Warum Leute, die eine komplett kommerzielle Veranstaltung machen, gegen den Markt gehen. Wir werden jetzt alles erklären.
Über Kultur und Prozesse
Zunächst ist DevOps keine technische Disziplin. Angefangen hat alles damit, dass die historisch gewachsene Rollenverteilung nicht auf die Qualität der Produkte zutrifft. Wenn Programmierer nur programmieren, aber nichts über das Testen hören möchten, ist die Software mit Fehlern übersät. Wenn Administratoren sich keine Gedanken darüber machen, wie und warum Software geschrieben wird, wird Support zur Hölle.
Zum Beispiel beginnt das berühmte Google SRE-Buch mit einer Beschreibung des Unterschieds zwischen dem Sysadmin- und dem SRE-shny-Ansatz für das Service-Management. Im Rahmen der DORA-Umfrage wurden interessante Studien durchgeführt. Es zeigt sich, dass es den besten Entwicklern irgendwie gelingt, neue Produktionsänderungen schneller als einmal pro Stunde zu implementieren. Sie testen mit ihren Händen nicht mehr als 10% (dies ist aus der letztjährigen DORA ersichtlich). Wie machen sie das? "Excel or Die", sagt einer der Berichtsköpfe. Für eine detaillierte Diskussion dieser Statistiken in Bezug auf Tests können Sie sich an Baruch Sadogurskys Keynote „We have DevOps. Lasst uns alle Tester entlassen “ auf unserer anderen Konferenz, Heisenbug.
"Wenn es keine Einigung unter den Genossen gibt,
Es wird nicht gut gehen,
Und es wird nicht herauskommen, nur Mehl.
Einst ein Schwan, Krebs und Hecht ... "
Was denken Sie, welcher Teil der Webprogrammierer versteht wirklich die Bedingungen, unter denen ihre Anwendungen auf Produkten betrieben werden? Wie viele von ihnen werden zu den Admins gehen und versuchen herauszufinden, was passieren wird, wenn die Basis fällt? Und wer von ihnen wird zu den Testern gehen und lernen, wie man Tests richtig schreibt? Und es gibt immer noch Sicherheitspersonal, Produktmanager und eine Menge Leute.
Die allgemeine Idee von DevOps besteht darin, eine Interaktion zwischen Rollen und Abteilungen herzustellen. Erstens wird dies nicht durch eine gerissene Software erreicht, sondern durch die Praxis der Kommunikation. DevOps handelt von Kultur, Praxis, Methodik und Prozessen. Es gibt keine solche technische Spezialität, die diese Fragen beantworten könnte.
Teufelskreis
Woher kam dann die Disziplin „Devops Engineering“? Wir haben eine Version! Die Ideen von DevOps erwiesen sich als gut - so gut, dass sie Opfer ihres Erfolgs wurden. Um dieses Thema herum begannen sich schlammige Rekrutierer und Schlepper mit einer ganz besonderen Atmosphäre zu bewegen.
Stellen Sie sich vor: Sie haben gestern in Khimki Döner gemacht, und heute sind Sie bereits ein großer Mann, leitender Rekrutierer. Es gibt einen ganzen Prozess der Suche und Auswahl von Kandidaten, alles ist nicht einfach, Sie müssen verstehen. Angenommen, der Abteilungsleiter sagt: Finden Sie einen Spezialisten für X. Wir weisen X das Wort "Ingenieur" zu, und der springende Punkt ist der Hut. Benötigen Sie Linux? Nun, es ist definitiv ein Linux-Ingenieur, Sie wollen DevOps - DevOps-Ingenieur. Ein Job besteht nicht nur aus einer Überschrift, sondern es muss Text eingegeben werden. Am einfachsten ist es, eine Reihe von Schlüsselwörtern von Google einzugeben, für die es genügend Vorstellungskraft gibt. DevOps besteht aus zwei Wörtern - "Dev" und "Ops". Dies bedeutet, dass Sie die Schlüsselwörter für Entwickler und Administratoren in einem Stapel zusammenfügen müssen. Es sind also Stellen zu besetzen, 42 Programmiersprachen zu besitzen und 20 Jahre gleichzeitig Kubernetes und Swarm zu verwenden. Arbeitsschema.
Das gedankenlose und gnadenlose Image eines bestimmten Superhelden - „devoops“ - hat sich also in den Köpfen der Menschen festgesetzt, die alle auf Jenkins einstellen werden, und das Glück wird kommen. Ah, wenn es nur so einfach wäre. "Und auf diese Weise können Sie auch Systemadministratoren hacken", meint Eichar, "das Wort ist in Mode, die Schlüsselwörter sind die gleichen, sie müssen picken."
Nachfrage schafft Angebot, und eine verrückte Anzahl von Systemadministratoren ist auf all diese Papierkorbleerstellen gestoßen, die erkannt haben, dass Sie dasselbe tun können wie zuvor, aber mehrmals mehr bekommen und sich "Entwickler" nennen. Wenn Sie den Server einzeln über SSH konfiguriert haben, fahren Sie mit der Konfiguration fort. Dies ist jedoch vermutlich eine Devop-Praxis. Dies ist ein komplexes Phänomen, das teilweise sowohl mit der Unterschätzung der klassischen Administratoren als auch mit dem Hype um DevOps zusammenhängt, aber im Allgemeinen stellte sich heraus, was passiert ist.
Wir haben also Angebot und Nachfrage. Ein Teufelskreis, der sich selbst ernährt. Damit kämpfen wir (auch durch die Einrichtung der DevOops-Konferenz).
Neben den Systemadministratoren, die in "devops" umbenannt wurden, gibt es natürlich auch andere Teilnehmer - zum Beispiel professionelle SRE oder Entwickler von Infrastructure-as-Code.
Was machen die Leute in DevOps (eigentlich)
Sie möchten also das Lernen und Anwenden von DevOps-Praktiken vorantreiben. Aber wie soll es gehen, wie soll es aussehen? Offensichtlich lohnt es sich nicht, blind durch beliebte Keywords geführt zu werden.
Wenn es Arbeit gibt, sollte es jemand tun. Wir haben bereits herausgefunden, dass es sich nicht um "DevOps-Ingenieure" handelt. Wer dann? Es scheint richtiger zu sein, dies nicht in Bezug auf Stellen, sondern in Bezug auf bestimmte Arbeitsbereiche zu formulieren.
Erstens können Sie das Herzstück von DevOps bilden - Prozesse und Kultur. Kultur ist keine schnelle und schwierige Angelegenheit, und obwohl dies traditionell in der Verantwortung von Managern liegt, ist jeder daran beteiligt, vom Programmierer bis zum Administrator. Vor ein paar Monaten sagte Tim Lister in einem Interview :
„Kultur wird von den Grundwerten der Organisation bestimmt. Normalerweise merken die Leute das nicht, aber wir, die wir seit vielen Jahren in der Beratung arbeiten, sind es gewohnt, es zu bemerken. Sie betreten die Firma und beginnen buchstäblich in wenigen Minuten zu spüren, was passiert. Wir nennen es "Aroma". Manchmal ist dieser Geschmack wirklich gut. Manchmal verursacht es Übelkeit. (...) Sie können eine Kultur nicht ändern, bevor die Werte und Überzeugungen hinter konkretem Handeln nicht erkannt wurden. Verhalten ist leicht zu beobachten und Überzeugungsarbeit ist schwierig. DevOps ist nur ein gutes Beispiel dafür, wie es immer schwieriger wird. “
Natürlich gibt es auch einen technischen Teil der Frage. Wenn Sie in einem Monat einen neuen Code zum Testen erhalten und dieser in der Veröffentlichung nur in einem Jahr erscheint und es physikalisch unmöglich ist, all dies zu beschleunigen, können Sie die guten Praktiken nicht einhalten. Gute Praktiken werden durch gute Werkzeuge unterstützt. Mit Blick auf die Idee der Infrastruktur als Code können Sie beispielsweise alles von AWS CloudFormation und Terraform bis hin zu Chef-Ansible-Puppet verwenden. Sie müssen dies alles wissen und können, und dies ist eine vollkommen technische Disziplin. Es ist wichtig, die Ursache nicht mit den Konsequenzen zu verwechseln: Zuerst arbeiten Sie an den Prinzipien von SRE und erst dann setzen Sie diese Prinzipien in Form bestimmter technischer Lösungen um. Gleichzeitig ist SRE eine sehr umfassende Methode, die nicht die Konfiguration von Jenkins beschreibt, sondern fünf grundlegende Prinzipien:
- Verbesserung der Interaktion zwischen Rollen und Abteilungen
- Fehler als integralen Bestandteil der Arbeit akzeptieren
- Fortschrittliche Veränderung
- Tuning und andere Automatisierung verwenden
- Alles messen, was gemessen werden kann
Dies ist nicht nur eine Reihe von Aussagen, sondern eine spezifische Anleitung zum Handeln . Auf dem Weg zu Fehlern müssen Sie sich beispielsweise mit Risiken auseinandersetzen, die Verfügbarkeit und Unzugänglichkeit von Diensten mithilfe von SLI ( Service Level Indicators ) und SLO ( Service Level Objectives ) messen, das Post-Mortem-Schreiben erlernen und das Schreiben vereinfachen .
In der SRE-Disziplin ist der Einsatz von Tools nur ein Teil des Erfolgs, jedoch wichtig. Wir müssen uns ständig technisch weiterentwickeln, beobachten, was auf der Welt passiert und wie es in unserer Arbeit angewendet werden kann.
Cloud Native-Lösungen sind mittlerweile sehr beliebt. Nach dem derzeitigen Verständnis der Cloud Native Computing Foundation ermöglichen Cloud Native-Technologien Unternehmen die Entwicklung und Ausführung skalierbarer Anwendungen in heutigen dynamischen Umgebungen wie öffentlichen, privaten und hybriden Clouds. Beispiele hierfür sind Container, Service Meshes, Microservices, unveränderbare Infrastrukturen und deklarative APIs. Alle diese Techniken ermöglichen es lose gekoppelten Systemen, flexibel, handhabbar und gut beobachtbar zu bleiben. Durch eine gute Automatisierung können Ingenieure häufig und mit vorhersehbaren Ergebnissen große Änderungen vornehmen, ohne dass daraus eine teuflische Arbeit wird. All dies wird durch eine Reihe bekannter Tools wie Docker und Kubernetes unterstützt.
Diese ziemlich komplizierte und gewichtige Definition hängt mit der Tatsache zusammen, dass die Region ziemlich kompliziert ist. Einerseits wird argumentiert, dass neue Änderungen an diesem System ganz einfach hinzugefügt werden sollten. Um andererseits herauszufinden, wie eine Art containerisierter Umgebung erstellt werden kann, in der lose gekoppelte Dienste auf einer softwaredefinierten Infrastruktur basieren und dort mithilfe einer fortlaufenden CI / CD bereitgestellt werden, und um all diese DevOps-Praxis aufzubauen, benötigen Sie mehr als eine einen Hund zu essen.
Was tun mit all dem?
Jeder löst diese Probleme auf seine Weise: Sie können beispielsweise normale Jobs veröffentlichen, um den Teufelskreis zu durchbrechen. Sie können herausfinden, was Wörter wie DevOps und Cloud Native bedeuten, und sie richtig und auf den Punkt verwenden. Sie können in DevOps entwickeln und anhand Ihres eigenen Beispiels die richtigen Ansätze demonstrieren.
Wir machen die DevOops 2020- Konferenz in Moskau , die die Gelegenheit bietet, die Dinge, über die wir gerade gesprochen haben, besser zu verstehen. Hierzu gibt es mehrere Gruppen von Berichten:
- Prozesse und Kultur;
- Site Reliability Engineering;
- Wolke Eingeborener
Wie wähle ich wo ich hingehen soll? Es gibt einen subtilen Punkt. Einerseits geht es bei DevOps um Interaktion, und wir möchten, dass Sie Berichte aus verschiedenen Blöcken aufrufen. Auf der anderen Seite, wenn Sie ein Entwicklungsleiter sind, der zur Konferenz gekommen ist, um sich auf eine bestimmte Aufgabe zu konzentrieren, schränkt Sie niemand ein - dies wird offensichtlich ein Block über Prozesse und Kultur sein. Vergessen Sie nicht, dass Sie nach der Konferenz Notizen haben (nachdem Sie das Feedback-Formular ausgefüllt haben), damit Sie später immer weniger wichtige Berichte sehen können.
Selbstverständlich können Sie auf der Konferenz nicht sofort auf drei Tracks gleichzeitig zugreifen. Daher erstellen wir das Programm so, dass in jedem Zeitfenster Themen für jeden Geschmack vorhanden sind.
Es bleibt nur zu verstehen, was zu tun ist, wenn Sie ein DevOps-Ingenieur sind! Versuchen Sie zunächst festzustellen, was Sie tatsächlich tun. Normalerweise nennen sie dieses Wort gerne:
- Entwickler, die sich mit Infrastruktur befassen. SRE- und Cloud Native-Gesprächsgruppen sind am besten für Sie geeignet.
- Systemadministratoren. Es ist komplizierter. Bei DevOops geht es nicht um Systemadministration. Glücklicherweise gibt es im Internet viele hervorragende Konferenzen, Bücher, Artikel, Videos usw. zum Thema Systemadministration. Wenn Sie andererseits daran interessiert sind, Ihr Verständnis für Kultur und Prozesse zu entwickeln, Cloud-Technologien und die Details des Lebens mit Cloud Native zu erkunden, dann freuen wir uns, Sie zu sehen! Denken Sie darüber nach: Hier sind Sie in der Verwaltung, und was werden Sie dann tun? Um nicht plötzlich in eine unangenehme Situation zu geraten, lohnt es sich jetzt zu studieren.
Es gibt noch eine andere Möglichkeit: Sie behaupten weiterhin, dass Sie ein DevOps-Ingenieur sind und nichts anderes, was auch immer das bedeutet. Dann ist DevOops, gezwungen zu trauern, keine Konferenz für DevOps-Ingenieure!
Folie aus dem Bericht von Konstantin Diener in München
DevOops 2020 Moskau findet vom 29. bis 30. April in Moskau statt, Tickets können bereits auf der offiziellen Website gekauft werden .
Außerdem können Sie Ihren Bericht bis zum 8. Februar einreichen . Bitte beachten Sie, dass Sie beim Ausfüllen des Formulars die Zielgruppe auswählen müssen, für die Ihr Bericht besser geeignet ist ( eine Überraschung ist in der Liste enthalten ).