In letzter Zeit überschwemmen solche Anzeigen das Internet. Trotz des angenehmen Gehalts kann man nicht anders, als sich zu schämen, dass darin wilde Häresie geschrieben steht. Zuerst geht man davon aus, dass sich „DevOps“ und „Ingenieur“ irgendwie zu einem Wort zusammenfügen lassen, und dann gibt es eine zufällige Liste von Anforderungen, von denen einige eindeutig von der Stelle als Systemadministrator übernommen wurden.
In diesem Beitrag möchte ich ein wenig darüber sprechen, wie wir zu diesem Punkt unseres Lebens gekommen sind, was DevOps wirklich ist und was wir jetzt damit machen können.
Solche offenen Stellen kann man auf jede erdenkliche Weise verurteilen, aber Fakt ist: Es gibt viele davon, und so funktioniert der Markt derzeit. Wir haben eine Entwicklerkonferenz abgehalten und offen erklärt: „ – nicht für DevOps-Ingenieure.“ Das wird vielen seltsam und wild vorkommen: Warum Menschen, die eine rein kommerzielle Veranstaltung veranstalten, gegen den Markt verstoßen. Jetzt erklären wir alles.
Über Kultur und Prozesse
Beginnen wir mit der Tatsache, dass DevOps keine Ingenieursdisziplin ist. Angefangen hat alles damit, dass die historisch gewachsene Rollenverteilung für die Qualität der Produkte nicht funktioniert. Wenn Programmierer nur programmieren, aber nichts vom Testen hören wollen, ist die Software voller Fehler. Wenn es Administratoren egal ist, wie oder warum die Software geschrieben wird, wird der Support zur Hölle.
Beschreiben Sie beispielsweise den Unterschied zwischen einem Systemadministrator und einem SRE-Ansatz für das Servicemanagement . Es wurden interessante Studien durchgeführt – Es ist klar, dass es den besten Entwicklern irgendwie gelingt, neue Änderungen schneller als einmal pro Stunde in der Produktion bereitzustellen. Sie testen mit ihren Händen nicht mehr als 10 % (dies ist ersichtlich aus ). Wie machen sie das? „Excel oder stirb“, heißt es in einer der Berichtsüberschriften. Für eine detaillierte Diskussion dieser Statistiken im Kontext des Testens können Sie sich auf die Keynote von Baruch Sadogursky beziehen auf unserer anderen Konferenz, Heisenbug.
„Wenn es unter Genossen keine Einigung gibt,
Sie werden nicht gut funktionieren.
Und es wird nicht herauskommen, nur Mehl.
Es waren einmal ein Schwan, ein Flusskrebs und ein Hecht ...“
Welcher Teil der Webprogrammierer versteht Ihrer Meinung nach wirklich die Bedingungen, unter denen ihre Anwendungen in der Produktion verwendet werden? Wie viele von ihnen wenden sich an die Administratoren und versuchen herauszufinden, was passiert, wenn die Datenbank abstürzt? Und wer von ihnen wird zu den Testern gehen und sie bitten, ihnen beizubringen, wie man Tests richtig schreibt? Und es gibt auch Sicherheitspersonal, Produktmanager und eine Menge anderer Leute.
Die Gesamtidee von DevOps besteht darin, eine Zusammenarbeit zwischen Rollen und Abteilungen zu schaffen. Erstens gelingt dies nicht durch eine geschickt konfigurierte Software, sondern durch die Praxis der Kommunikation. Bei DevOps geht es um Kultur, Praktiken, Methodik und Prozesse. Es gibt keine Ingenieursdisziplin, die diese Fragen beantworten kann.
Teufelskreis
Woher kam damals die Disziplin „Devops Engineering“? Wir haben eine Version! DevOps-Ideen waren gut – so gut, dass sie Opfer ihres eigenen Erfolgs wurden. Einige zwielichtige Personalvermittler und Menschenhändler, die ihre eigene Atmosphäre haben, begannen, sich um dieses ganze Thema zu drehen.
Stellen Sie sich vor: Gestern haben Sie in Chimki Döner zubereitet, und heute sind Sie bereits ein großer Mann, ein leitender Personalvermittler. Es gibt einen ganzen Prozess der Suche und Auswahl von Kandidaten, alles ist nicht einfach, das muss man verstehen. Nehmen wir an, der Leiter einer Abteilung sagt: Finden Sie einen Spezialisten für X. Wir weisen X das Wort „Ingenieur“ zu und fertig. Brauchen Sie Linux? Nun, das ist definitiv ein Linux-Ingenieur. Wenn Sie DevOps wollen, dann ein DevOps-Ingenieur. Die Stellenausschreibung besteht nicht nur aus einem Titel, sondern es muss auch ein Text darin eingegeben werden. Am einfachsten ist es, je nach Vorstellungskraft eine Reihe von Keywords von Google einzugeben. DevOps besteht aus zwei Wörtern – „Dev“ und „Ops“, was bedeutet, dass wir Schlüsselwörter, die sich auf Entwickler und Administratoren beziehen, auf einem Stapel zusammenfassen müssen. So erscheinen Stellenangebote zu Kenntnissen in 42 Programmiersprachen und 20 Jahren gleichzeitiger Nutzung von Kubernetes und Swarm. Arbeitsdiagramm.
Auf diese Weise hat sich das bedeutungslose und gnadenlose Bild eines bestimmten „Devops“-Superhelden in den Köpfen der Menschen etabliert, die jeden so konfigurieren, dass er sich für Jenkins einsetzt, und das Glück wird kommen. Ach, wenn nur alles so einfach wäre. „Und so kann man auch Systemadministratoren jagen“, findet HR, „es ist ein modisches Wort, die Schlüsselwörter sind die gleichen, sie sollten den Köder schlucken.“
Nachfrage schafft Angebot, und all diese leeren Stellen wurden mit einer wahnsinnigen Anzahl von Systemadministratoren besetzt, die erkannt haben: Sie können alles wie zuvor machen, aber ein Vielfaches mehr bekommen, indem Sie sich „Devops“ nennen. So wie Sie Server einzeln über SSH manuell konfiguriert haben, werden Sie sie weiterhin konfigurieren, aber jetzt ist dies angeblich eine DevOps-Praxis. Dies ist eine Art komplexes Phänomen, das teilweise mit der Unterschätzung klassischer Administratoren und dem Hype um DevOps zusammenhängt, aber im Allgemeinen ist das, was passiert ist, passiert.
Wir haben also Angebot und Nachfrage. Ein Teufelskreis, der sich selbst nährt. Dagegen kämpfen wir (unter anderem durch die Gründung der DevOops-Konferenz).
Natürlich gibt es neben den Systemadministratoren, die sich in „Devops“ umbenannt haben, auch andere Teilnehmer – zum Beispiel professionelle SREs oder Infrastructure-as-Code-Entwickler.
Was Menschen in DevOps (wirklich) tun
Sie möchten also beim Erlernen und Anwenden von DevOps-Praktiken vorankommen. Aber wie geht das, in welche Richtung muss man schauen? Natürlich sollten Sie sich nicht blind auf beliebte Keywords verlassen.
Wenn es einen Job gibt, sollte ihn jemand erledigen. Wir haben bereits herausgefunden, dass es sich hierbei nicht um „Devops-Ingenieure“ handelt. Wer ist das dann? Es scheint richtiger, dies nicht in Bezug auf Positionen, sondern in Bezug auf bestimmte Arbeitsbereiche zu formulieren.
Zunächst können Sie sich mit dem Kernstück von DevOps befassen: Prozesse und Kultur. Kultur ist ein langsames und schwieriges Geschäft, und obwohl sie traditionell in der Verantwortung von Managern liegt, ist jeder auf die eine oder andere Weise beteiligt, vom Programmierer bis zum Administrator. Vor ein paar Monaten Tim Lister :
„Kultur wird durch die Grundwerte der Organisation bestimmt. Normalerweise fällt es den Leuten nicht auf, aber da wir viele Jahre in der Beratung gearbeitet haben, sind wir es gewohnt, es zu bemerken. Sie betreten ein Unternehmen und beginnen buchstäblich innerhalb weniger Minuten zu spüren, was vor sich geht. Wir nennen das „Geschmack“. Manchmal ist dieser Duft wirklich gut. Manchmal verursacht es Übelkeit. (...) Man kann eine Kultur nicht ändern, bis man die Werte und Überzeugungen hinter bestimmten Handlungen verstanden hat. Verhalten ist leicht zu beobachten, aber die Suche nach Überzeugungen ist schwierig. DevOps ist einfach ein tolles Beispiel dafür, wie die Dinge immer komplexer werden.“
Natürlich gibt es auch einen technischen Teil des Problems. Wenn Ihr neuer Code in einem Monat getestet wird, aber erst ein Jahr später veröffentlicht wird und es physisch unmöglich ist, alles zu beschleunigen, halten Sie sich möglicherweise nicht an bewährte Praktiken. Gute Praktiken werden durch gute Tools unterstützt. Mit der Idee von Infrastructure-as-Code im Hinterkopf können Sie beispielsweise alles von AWS CloudFormation und Terraform bis hin zu Chef-Ansible-Puppet verwenden. Das alles muss man wissen und können, und das ist schon eine ziemliche Ingenieursdisziplin. Dabei ist es wichtig, Ursache und Wirkung nicht zu verwechseln: Man arbeitet zunächst nach den Prinzipien von SRE und setzt diese Prinzipien erst dann in Form konkreter technischer Lösungen um. Gleichzeitig ist SRE eine sehr umfassende Methodik, die Ihnen nicht sagt, wie man Jenkins einrichtet, sondern fünf Grundprinzipien:
- Verbesserte Kommunikation zwischen Rollen und Abteilungen
- Fehler als integralen Bestandteil der Arbeit akzeptieren
- Änderungen schrittweise vornehmen
- Verwendung von Werkzeugen und anderer Automatisierung
- Alles messen, was gemessen werden kann
Hierbei handelt es sich nicht nur um eine Reihe von Aussagen, sondern um eine spezifische Aussage . Auf dem Weg zur Fehlerakzeptanz müssen Sie beispielsweise die Risiken verstehen und die Verfügbarkeit und Nichtverfügbarkeit von Diensten mithilfe von SLI messen () und SLO (), lernen Sie, Postmortems zu schreiben und machen Sie das Schreiben nicht beängstigend.
In der SRE-Disziplin ist der Einsatz von Werkzeugen nur ein Teil des Erfolgs, wenn auch ein wichtiger. Wir müssen uns technisch ständig weiterentwickeln, schauen, was in der Welt passiert und wie es in unserer Arbeit umgesetzt werden kann.
Im Gegenzug erfreuen sich Cloud Native-Lösungen mittlerweile großer Beliebtheit. Wie heute von der Cloud Native Computing Foundation definiert, ermöglichen Cloud Native-Technologien Unternehmen die Entwicklung und Ausführung skalierbarer Anwendungen in den dynamischen Umgebungen von heute, wie z. B. öffentlichen, privaten und hybriden Clouds. Beispiele hierfür sind Container, Service Meshes, Microservices, unveränderliche Infrastruktur und deklarative APIs. Alle diese Techniken ermöglichen, dass lose gekoppelte Systeme elastisch, beherrschbar und gut beobachtbar bleiben. Eine gute Automatisierung ermöglicht es Ingenieuren, große Änderungen häufig und mit vorhersehbaren Ergebnissen vorzunehmen, ohne dass dies zu einer lästigen Pflicht wird. All dies wird durch einen Stapel bekannter Tools wie Docker und Kubernetes unterstützt.
Diese eher komplizierte und weit gefasste Definition ist darauf zurückzuführen, dass das Gebiet auch recht komplex ist. Einerseits wird argumentiert, dass neue Änderungen an diesem System ganz einfach hinzugefügt werden sollten. Um andererseits herauszufinden, wie man eine Art Containerumgebung schaffen kann, in der lose gekoppelte Dienste auf einer softwaredefinierten Infrastruktur leben und dort mithilfe kontinuierlicher CI/CD bereitgestellt werden, und um all dies herum DevOps-Praktiken aufzubauen – all das erfordert mehr als man den Hund frisst.
Was tun mit all dem?
Jeder löst diese Probleme auf seine eigene Art: Man kann zum Beispiel normale Stellenangebote 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 bringen. Sie können in DevOps entwickeln und anhand Ihres Beispiels die richtigen Ansätze demonstrieren.
Wir machen eine Konferenz , was eine Gelegenheit bietet, tiefer in die Dinge einzutauchen, über die wir gerade gesprochen haben. Hierzu gibt es mehrere Berichtsgruppen:
- Prozesse und Kultur;
- Standortzuverlässigkeitstechnik;
- Cloud-nativ;
Wie wähle ich aus, wohin ich gehen möchte? Hier gibt es einen subtilen Punkt. Einerseits geht es bei DevOps um Interaktion, und wir möchten unbedingt, dass Sie Präsentationen aus verschiedenen Blöcken besuchen. Wenn Sie andererseits ein Entwicklungsmanager sind, der zur Konferenz gekommen ist, um sich auf eine bestimmte Aufgabe zu konzentrieren, dann schränkt Sie niemand ein – offensichtlich wird dies eine Blockade in Bezug auf Prozesse und Kultur sein. Vergessen Sie nicht, dass Sie nach der Konferenz (nach dem Ausfüllen des Feedback-Formulars) Aufzeichnungen erhalten, sodass Sie weniger wichtige Vorträge später immer noch ansehen können.
Natürlich kann man auf der Konferenz selbst nicht drei Tracks gleichzeitig bearbeiten, daher gestalten wir das Programm so, dass in jedem Zeitfenster Themen für jeden Geschmack dabei sind.
Jetzt müssen Sie nur noch verstehen, was Sie als DevOps-Ingenieur tun müssen! Versuchen Sie zunächst herauszufinden, was Sie tatsächlich tun. Normalerweise nennen sie dieses Wort gerne:
- Entwickler, die an der Infrastruktur arbeiten. Die Berichtsgruppen zu SRE und Cloud Native sind für Sie am besten geeignet.
- Systemadministratoren. Hier ist es 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, sich im Hinblick auf das Verständnis von Kultur und Prozessen weiterzuentwickeln, mehr über Cloud-Technologien und die Details des Lebens mit Cloud Native zu erfahren, dann würden wir uns freuen, Sie zu sehen! Denken Sie darüber nach: Sie sind in der Verwaltung tätig, und was werden Sie dann tun? Um nicht plötzlich in eine unangenehme Situation zu geraten, sollten Sie jetzt lernen.
Es gibt noch eine andere Möglichkeit: Sie bleiben bestehen und behaupten weiterhin, dass Sie es sind insbesondere ein DevOps-Ingenieur und nichts anderes, was auch immer das bedeutet. Dann müssen wir Sie enttäuschen, DevOops ist keine Konferenz für DevOps-Ingenieure!
Schieben Sie von in München
DevOops 2020 Moskau findet vom 29. bis 30. April in Moskau statt, Tickets sind bereits erhältlich .
Darüber hinaus können Sie bis 8. Februar. Bitte beachten Sie, dass Sie beim Ausfüllen des Formulars die Zielgruppe auswählen müssen, die am meisten von Ihrem Bericht profitieren wird (In der Liste steckt eine Überraschung).
Source: habr.com