Überblick über die DevOpsDays Moskau-Konferenz: Erkenntnisse aus 6 Berichten

Die dritte Konferenz fand am 7. Dezember statt DevOpsDays Moskau, organisiert von der Moskauer DevOps-Community mit Unterstützung von Mail.ru Cloud Solutions. Neben Vorträgen führender DevOps-Praktiker konnten die Teilnehmer an kurzen, motivierenden Lightning Talks und Workshops teilnehmen und in offenen Räumen kommunizieren.

Wir haben aus sechs Reden wichtige Erkenntnisse gesammelt und Interviews mit mehreren Rednern geführt, um herauszufinden, was hinter den Berichten steckt.

Innerhalb:

1. Baruch Sadogursky, JFrog: „Lassen Sie die Software wie eine Flüssigkeit vom Anbieter zum Benutzer fließen.“
2. Pavel Selivanov, Southbridge: „Entwickler und Ops haben eine gemeinsame Aufgabe – ein Produkt zu entwickeln, das funktioniert“
3. Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise ist Entwicklung ohne Schmerzen und Feuer“
4. Sergey Puzyrev, Facebook: „Production Engineer kümmert sich um den Service als Ganzes: damit sowohl Benutzer als auch Entwickler eine gute Zeit haben“
5. Mikhail Chinkov, AMBOSS: „Eine Abteilung kann dem DevOps-Weg nicht folgen, das gesamte Unternehmen muss ihm folgen“
6. DevOps-Enthusiasten von Rosbank: „1000 Tage, um DevOps in einem blutigen Unternehmen zu implementieren“

1. Baruch Sadogursky, JFrog: „Lassen Sie die Software wie eine Flüssigkeit vom Anbieter zum Benutzer fließen.“

Fehler bei Softwareaktualisierungen treten stündlich und bei jedem auf. Hier nur eine Horrorgeschichte aus der Rede: Knight Capital verlor nach einem erfolglosen Update innerhalb einer Stunde 440 Millionen US-Dollar.

Baruch sprach über DevOps-Muster kontinuierlicher Updates, die dazu beitragen werden, Ausfälle und Benutzerhass zu vermeiden:

Lokales Rollback — Behalten Sie die vorherige Version der Software auf Ihrem Gerät, um bei Problemen ein Rollback durchführen zu können. Dies schützt Sie, wenn die Situation so schlimm wird, dass Sie keinen Patch über Funk senden können.

Over-the-Air-Updates - besser kontinuierlich. Ansonsten wird es wie bei den Jaguar-Entwicklern sein: Aufgrund eines Fehlers im Bremssystem, das nicht über Funk aktualisiert werden konnte, mussten die Autos aus dem Verkauf zurückgerufen werden. Es war schmerzhaft und teuer.

Kontinuierliche Updates — Aktualisieren Sie die Software kontinuierlich, sobald eine neue Funktion verfügbar ist. Bei seltenen Updates werden Funktionen zusammengefasst; ein kritisches Update wartet möglicherweise auf unkritische. Wie bei Tesla wartete ein Update, das zufälliges Bremsen beheben sollte, auf ein Update des Schachspiels.

Automatisierte Bereitstellung - Ersetzen Sie Menschen durch Maschinen, da Menschen schlecht darin sind, Routinetätigkeiten auszuführen.

астые обновления - Ihnen helfen, eine Gewohnheit zu entwickeln und die Angst loszuwerden. Seltene Updates werden zu Notfallereignissen.

Den Zustand des Geräts kennen — Testaktualisierungen, keine Neuinstallation. Dies ist wichtig, da sich Updates je nach Zustand des Geräts unterschiedlich verhalten können.

Kanarische Veröffentlichungen – Führen Sie Updates für eine kleine Anzahl von Benutzern aus und beobachten Sie sie. Dies verringert den Schaden, wenn etwas schiefgeht.

Updates ohne Nichtverfügbarkeit – Sorgen Sie dafür, dass Kunden nur neue Funktionen bemerken und nicht mehrere Wochen lang ohne Service bleiben, während Sie ein Update einführen.

Wir haben mit Baruch Sadogursky darüber gesprochen, wie unterschiedlich die Sicht auf DevOps in der russischen und westlichen IT ist, ob die Cloud bald alles für uns erledigen wird und ob alle Softwaredienste in das AaS-System übergehen werden – sehen Sie sich das Interview an:

2. Pavel Selivanov, Southbridge: „Entwickler und Ops haben eine gemeinsame Aufgabe – ein Produkt zu entwickeln, das funktioniert“

Die Implementierung von Kubernetes wird nicht dazu beitragen, DevOps zu erreichen, im Gegenteil, sie kann alles kaputt machen. Pavel erklärte, warum Technologie (selbst die coolste) nicht alle Ihre Probleme lösen kann:

Die Komplexität des Projekts hat sich über den Code hinaus verlagert. Früher gab es eine komplexe Anwendung: Interaktion innerhalb des Projekts und komplexe Entwicklung, aber eine einfache Struktur – der Administrator hat sie bereitgestellt, alles funktioniert. Wir sind zu Microservices übergegangen: Jeder Service ist eine einfache Anwendung, Kommunikation über Standardprotokolle und schnelle Entwicklung, aber die Projektstruktur ist komplexer geworden. Die Komplexität eines Projekts mit einer Microservice-Architektur ist nicht verschwunden – sie hat sich über den Code hinaus verlagert. Jetzt ist der DevOps-Ingenieur dafür verantwortlich.

Entwickler möchten keine Änderungen nach der Implementierung von DevOps. Infolgedessen sieht der Arbeitsablauf mit Kubernetes weiterhin so aus, als würde man Aufgaben von Dev zu Ops über eine Mauer werfen, nur nicht über eine metaphorische – Git wird zu einer solchen Mauer. Der Entwickler legt den Code dort ab und funktioniert wie zuvor, und die Administratoren haben Kubernetes, CI/CD und alles andere.

Allerdings müssen Entwickler die Änderungen akzeptieren. Eine Situation, in der Entwickler nicht wissen, was Administratoren tun, und Administratoren nicht wissen, was mit Entwicklern los ist, führt zu Problemen.

Wenn sich für die Entwickler nichts geändert hat, ist ihnen nicht bewusst, dass der Betrieb der Anwendung in ihrer Verantwortung liegt – diverse technische Tricks werden nicht funktionieren.

Mit dem Aufkommen von DevOps und Kubernetes wird sich in der Entwicklung viel ändern. Entwickler müssen in Ops kompetent sein und umgekehrt. Diese Spezialisten verfügen über ihre eigenen spezifischen Fähigkeiten, müssen jedoch über die Arbeit des anderen informiert sein. Dev und Ops müssen Freunde sein, bevor sie Kubernetes implementieren, sonst machen Sie kaputt, was Sie haben.

Pavel Selivanov sprach darüber, was in 5 Jahren mit Kubernetes passieren wird und worauf ein modernes Startup einen Technologie-Stack aufbauen sollte – sehen Sie sich das Interview an:

3. Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise ist Entwicklung ohne Schmerzen und Feuer“

Unternehmen kommen zur DevOps-Transformation, wenn sie erkennen, dass die Entwicklung zu langsam ist und nicht den Realitäten entspricht. Sie haben den Wunsch, besser zu entwickeln und schneller einzuführen.

Vladimir erklärte, wie das passiert und was der Haken ist:

1. Zunächst stellen Unternehmen einen DevOps-Ingenieur ein. Dies ist ein leitender Systemadministrator. Er ist an der Bereitstellung einer Version für die Produktion, der Standardisierung der Entwicklungsumgebung, der Einrichtung der Infrastruktur, der Erkennung und Behebung verschiedener Probleme sowie der Automatisierung von Prozessen und anderen technischen Aufgaben beteiligt.
2. Dann reicht ein DevOps-Ingenieur nicht mehr aus und das Unternehmen stellt ein DevOps-Team ein. Hierbei handelt es sich um ein Kompetenzzentrum, das die Bemühungen unterschiedlicher Ingenieure organisiert und deren Konzentration in eine Richtung ermöglicht.
3. Tatsächlich sind DevOps-Ingenieure und DevOps-Teams Anti-Muster der DevOps-Transformation. Da es bei DevOps um Praktiken und Kultur geht, gibt es darüber hinaus Implementierungen von DevOps in Technologieunternehmen (SRE, Production Engineering).

Was zu tun? Stellen Sie ein vorübergehendes DevOps-Team ein, das Sie bei der Umsetzung der DevOps-Transformation, der Durchführung von Praktiken und der Pflege einer Entwicklungskultur und einer Technologiekultur unterstützt.

Wenn ein Unternehmen ins Spiel kommt und in DevOps investiert, sind mehrere Szenarien möglich: Beim Start bricht alles zusammen; bleibt als SRE/Production Engineering oder Embedded Ops bestehen; wird zu BizOps wechseln, wenn Prozesse auf Geschäftsmetriken basieren.

Vladimir Utratenko erzählte uns, wie „blutig“ DevOps in einem Unternehmen wirklich ist und wie Praktiken in großen Einzelhandelsunternehmen umgesetzt werden – sehen Sie sich das Interview an:

4. Sergey Puzyrev, Facebook: „Production Engineer kümmert sich um den Service als Ganzes: damit sowohl Benutzer als auch Entwickler eine gute Zeit haben“

Facebook ist ein riesiges Unternehmen mit einer großen Anzahl an Komponenten, Servern, Mitarbeitern und Rechenzentren. Trotz seiner enormen Größe ist es sehr schnell – Entwickler können Dienste mehrmals am Tag einführen. Auch Facebook wächst rasant und nicht nur die Zahl der Nutzer und Server wächst, auch die Zahl der Entwickler nimmt zu, was die Prozesse komplexer macht.

Sergey erzählte auf Facebook, was ein Produktionsingenieur macht:

1. Ein Produktionsingenieur programmiert viel, er muss über Systemkenntnisse verfügen: Betriebssysteme, Dateisysteme, Datenbanken, Netzwerke und dergleichen. Muss über Erfahrung in der Arbeit mit verteilten Systemen und Reliability Engineering verfügen, d. h. in der Unterstützung der Produktzuverlässigkeit. Es muss eine Rufbereitschaft bestehen, also jederzeit abrufbar sein.
2. Der Produktionsingenieur unterscheidet sich vom Software-Ingenieur dadurch, dass er über fortgeschrittene Fähigkeiten im Betrieb verfügt, ist aber tatsächlich eine Unterart des Software-Ingenieurs. Software-Ingenieure programmieren mehr; sie verfügen möglicherweise über zusätzliche Fähigkeiten, beispielsweise im Zusammenhang mit der Datenverarbeitung. Auf Facebook müssen solche Spezialisten ebenfalls auf Abruf sein, was für viele eine unangenehme Überraschung ist.
3. Die Anforderungspyramide eines Produktionsingenieurs in einem Unternehmen beginnt mit der Überwachung von Servern und deren Lebenszyklus, also der Beschaffung neuer Hardware, der Einrichtung und der Inbetriebnahme. Die nächste Ebene ist die gleiche auf der Serviceebene: Überwachung von Services und deren Lebenszyklus. Dann kommt die nahtlose Skalierung und erweiterte Überwachung. Sie wechseln zur automatischen Skalierung, nachdem der Servicelebenszyklus automatisiert wurde. Und am Ende muss noch ein Tuning durchgeführt werden, damit die Skalierung effektiv ist und das Unternehmen Geld und Ressourcen spart.

5. Mikhail Chinkov, AMBOSS: „Eine Abteilung kann dem DevOps-Weg nicht folgen, das gesamte Unternehmen muss ihm folgen“

Mikhail glaubt, dass DevOps eine kontinuierliche Entwicklung ist. Sie können nicht einige Tools einführen und damit aufhören. Welche Probleme hindern Unternehmen daran, DevOps zu werden und wie lassen sich Praktiken umsetzen?

Unterschied im Verständnis von DevOps. Kanonische Entwickler basieren, wie Evangelisten es sehen, auf fünf Säulen:

• Kultur – Fokus auf Menschen und Zusammenarbeit;
• Automatisierung – Delegation der Routine an den Arbeitsablauf;
• Lean – Schwerpunkt auf der Bereitstellung von Mehrwert für den Benutzer;
• Teilen – kontinuierlicher Wissensaustausch;
• Metriken und Erhalt von Feedback anhand dieser.

Unternehmen konzentrieren sich normalerweise nur auf die Automatisierung und die Bereitstellung von Mehrwert für den Benutzer. Aber Kultur, Wissensaustausch und DevOps-Metriken zur Verfolgung der Entwicklung geraten in den Hintergrund.

Herausforderungen bei der DevOps-Standardisierung. Produktziele sind für jedes Unternehmen unterschiedlich und können nicht standardisiert werden. Der Stand von DevOps in einem Unternehmen hängt vom Unternehmen selbst ab, aber viele verstehen das nicht und glauben, dass es ausreicht, einen DevOps-Ingenieur einzustellen.

Warum sind wir noch nicht DevOps? Es gibt zwei Hauptprobleme. In Unternehmen gibt es eine langsame Entwicklung der Organisation und Schwierigkeiten bei der Änderung des Vektors in den Köpfen Tausender Mitarbeiter. In Startups mangelt es an Wissensquellen und es gibt Probleme bei der Bereitstellung von Ressourcen für die Transformation.

Phasen der DevOps-Entwicklung in einem Unternehmen:

• Das erste ist die Infrastruktur in der Cloud, aber niemand außer ein oder zwei Administratoren weiß, wie sie funktioniert.
• Zweitens ist die Infrastruktur für alle Ingenieure transparent und verständlich, die Prozesse jedoch nicht rationalisiert.
• Drittens: Ingenieure starten und reparieren Live-Dienste selbstständig;
• Viertens: Ingenieure tragen optional zur Kerninfrastruktur bei, transparenter Code in der Cloud, Bereitstellung per Knopfdruck.

Das ideale Schema besteht darin, dass jeder den gleichen Zugriff auf die Infrastruktur hat, alle Ingenieure Zugriff auf das Produkt haben und verstehen, was sie tun.

Nach Abschluss aller kulturellen und technischen Aspekte wird die DevOps-Transformation des Unternehmens das Feedback von Geschäfts- und Plattformmetriken berücksichtigen.

6. DevOps-Enthusiasten von Rosbank: „1000 Tage, um DevOps in einem verdammten Unternehmen zu implementieren“

Yuri Bulich, Dina Maltseva und Evgeny Pankov von Rosbank erzählten, wie sie in drei Jahren zu DevOps kamen. Es gab zwei Ziele: spezifische Probleme in bestimmten Teams zu lösen und zentralisierte Tools zu implementieren.

Hier sind die erzielten Ergebnisse:

Ergebnisse für Produktteams: 30-mal schnellere Montage, 6-mal schnellere Installation, bis zu 30 % Ersparnis im gesamten Zyklus. Wir haben jetzt die Möglichkeit, per Knopfdruck zur Produktivität zu gelangen

Ergebnisse für Plattformbefehle: 10-mal schnellere Montage und Installation, 87 % höhere Anzahl von Installationen, 46 % Autotest-Abdeckung. Das Integrationsteam ist kein Flaschenhals mehr

Wie implementiert man also DevOps-Praktiken in einem verdammten Unternehmen?

Setzen Sie zunächst ein Pilotprojekt um: Wählen Sie Teams aus, entscheiden Sie, wie die Architektur implementiert werden soll, und wählen Sie Tools aus. Wir haben uns für Tools mit offener Lizenz entschieden, mit Installation in der Bank und Fachwissen im Umgang damit. Rosbank stellte gleichzeitig mit der DevOps-Plattform eine private Cloud bereit, was am Anfang hilfreich war. In der Cloud war es möglich, die benötigten Ressourcen per Knopfdruck in 15 Minuten abzurufen; zuvor konnte ein solcher Vorgang eine Woche dauern.

In Banken und anderen Unternehmen ist es notwendig, die Einschränkungen vorab mit dem Informationssicherheitsteam abzustimmen und eine Lösung zu finden, die die Umsetzung der Änderungen ermöglicht.

Nach dem Pilotprojekt muss eine erfolgreiche Lösung skaliert werden.

1. Es ist wichtig, die Pipeline so weit wie möglich zu „begradigen“, unnötige Links daraus zu entfernen, Wertanbieter hervorzuheben und die verbleibenden Komponenten zu entfernen. Zwischenprodukte sind Antimuster. Bei Rosbank beispielsweise entwickelten mehrere Teams keine interne Entwicklung, sondern ließen nur die externe Entwicklung übrig. Dies führte zur Entstehung eines dedizierten DevOps-Teams, das den Transfer des Codes von externen zu internen Entwicklern sicherstellte. Das Problem wurde durch die Integration der externen Entwicklung in CI/CD gelöst, sodass sie nicht nur den Code von sich selbst an die Bank übertragen, sondern auch für dessen Erfolg verantwortlich waren.
2. Das Reifegradmodell umfasste Elemente von DevOps-Praktiken, listete Tools auf und berücksichtigte die Besonderheiten der Zusammenarbeit mit externen Lieferanten – was in Zukunft dazu beitrug, den Rückstand an Aufgaben bei der Umsetzung in neuen Teams schnell abzubauen.
3. Wir brauchen Governance in Form von sanfter Kontrolle und Empfehlungen. Ein gut funktionierendes DevOps-Handbuch besteht aus einer Reihe von Organisations- und Toolmerkmalen, die Teams dabei helfen, die Plattform richtig zu nutzen.
4. Man sollte sofort auf die Kultur achten, dann gehen viele Veränderungen schneller und einfacher vonstatten. Erweitern Sie Ihre interne Community, veranstalten Sie Treffen, technische Workshops, Schulungen und unterhaltsame Aktivitäten. Das trägt Früchte: Man tauscht Praktiken aus, sieht, wer was getan hat, weiß, an wen man sich wenden kann, es herrscht Hype und ein gesunder Wettbewerb im Unternehmen.
5. Es macht keinen Sinn, mit denen zusammenzuarbeiten, die nicht in den Prozess involviert sind. Es ist besser, in interessierte Teams und loyale Leute zu investieren.
6. Die gewählte Lösung muss für die Ingenieure, die sie nutzen, bequem sein.
7. Externe Entwicklung ist kein Hindernis, auch dort können Praktiken umgesetzt werden, Hauptsache, das Team selbst hat Lust.

Ein bisschen mehr Nutzen

Liste der lesenswerten Bücher für DevOps-Experten von Alexander Chistyakov, vdsina.ru:

1. Irina Yakutenko „Wille und Selbstbeherrschung.“
2. Daniel Kahneman „Denken, schnell und langsam“.
3. Barbara Oakley „Ein Geist für Zahlen“.
4. Maxim Dorofeev „Jedi-Techniken“.
5. Viktor Frankl „Die Suche des Menschen nach Sinn“.

Endlich wieder ab November

Wir lieben auch DevOps. Folgen Sie den Serienankündigungen @DevOps und @Kubernetes sowie andere Mail.ru Cloud Solutions-Events in unserem Telegram-Kanal: t.me/k8s_mail

Source: habr.com